[SOLVED] Custom kernel, something goes wrong

V

Villefort

Guest
Hi there,
I'm trying to build a custom TC patched 3.16.6 kernel. I'm here 'cuz there on TC forum they said I do all right and it must be working; but it doesn't. Also they said it's a generic kernel building topic, not TC one, so... Maybe you'll point what I'm doing wrong.

What I am doing, exactly in steps:

1. Download linux-3.16.6-patched.xz from the Tiny Core official repo. It's their own package patched with all that Tiny Core stuff.
2. Download default config file from there.
3. Download fbcondecor patch from it's mirror.
4. Unpack xz, then cd into it and make mrproper.
5. Copy the default config into.
6. Make menuconfig. Do my settings, including enable console decorations, turn on some Cyrillic support, changing proc arch, host name etc.
7. make -j 2 bzImage, because they told me fbcondecor patch does not touch modules, so I need to build bzImage, not all modules and firmware.
8. Then I am to replace my current vmlinuz with bzImage and reboot. And all is to work nice, pretty, etc. But it won't.

When I do as listed above, using my old core.gz (initrd image), it crashes saying that arch doesn't coincide: the new vmlinuz is built for ATOM (as I've set) and some modules are built for 486. I think these that are in the core.gz.
So I go and build new bzImage choosing a 486 proc type. It doesn't care and continues shouting of some arch difference (the same error messages I got when booting vmlinuz built for ATOM).
Then I get my ATOM bzImage, and add to that a repacked core.gz, which I had unpacked, and replaced /lib directory with that I have after

make modules_install

After that I pack modified core.gz and try to boot with new bzImage and new core.gz. Still it doesn't work. It starts booting, then right before "Scanning disk for... blah blah... fstab" it takes a long, long pause and outputs that some process was terminated with -9. After that it tries hard, and prints something of my synaptiks touchpad, and ends printing some crap like "Random blocking pool...". After that it is dead, but if I press SysRq+RE, it prints a login prompt, and I can log in as a default user, but sudo is not working and no partitions are mounted. I can't mount them and even save a snapshot or a dmesg output because sudo is not available!

So. I believe I do something wrong when modifying the core.gz (init image). I thought I could only replace /lib within it with new, and that would be enough. And, definitely, I don't know how to build a completely new init image with those libraries I compile from the source. Still, is it required?
 
Last edited:


Where are you doing your builds? On a running TinyCore system, in a vm, or on some other host and cross compiling? If not running on an Atom device, have you used setarch prior to running your makes?

And yeah, you should build a complete new init image. You're using cpio to build core.gz, right?
 
Where are you doing your builds? On a running TinyCore system, in a vm, or on some other host and cross compiling? If not running on an Atom device, have you used setarch prior to running your makes?
No, I need it not, I think. I'm building on a running TinyCore system, on an Atom device.

And yeah, you should build a complete new init image. You're using cpio to build core.gz, right?
Er... that's a weak spot... I know very little of how to build a new init.
Yes, I use cpio for it.
...I mean, after make INSTALL_MOD_PATH=/tmp/initrd modules_install there is only /lib directory inside /tmp/initrd. But, when I unpack an existing core.gz, there are all system directories: /bin, /lib, /dev and so on. So I'm a bit confused, if they are all included in the existing init image, then they are needed. That's why I've tried to modify it, replacing /lib. Somewhere among them is stored a login greeting text. I heard of mkinitrd utility but I'm not sure if I need this. Anyway there isn't mkinitrd in TC.
 
Well, as far as /dev, /bin, and so on, simply make an initram with them and see what happens. IIRC, tinycore is still using grub, so you can easily intercept the boot and point to the test initram before boot process starts. If it fails, reboot with the working bzImage and initram.
 
I've built a new kernel. I'd got to drop the idea to change a kernel a bit more than only turning decorations on, so without touching anything else it accepted an old init image.
There is busybox in there, so I must install it first. Anyway the new kernel didn't accept some modules which I threw into /lib, so the topic isn't closed -- for me. I should read and experiment more. The current problem is solved, though.
 

Members online


Latest posts

Top