Good day,

a recently compiled custom kernel 4.18 won't boot on an old PowerPC machine of mine.

There are plenty of phenomenons I don't understand:

- root partition is not accessible, there is only the message ALERT! /dev/disk/by-uuid/xxxxxxxxx does not exist. Dropping to a shell
- blkid in initramfs shows nothing
- /proc/modules in initramfs don't seem to exist
- /dev/disk shows only two directories, by-path and by-id, but not by-uuid

Could it be that my box just doesn't understand by-uuid? Can I activate a kernel module for that?

To my defense, my CPU and USB are already recognised. :-)

Thanks in advance!

The disk links by UUID and so on are created by udevd in response to the kernel detecting those drives, but the whole thing depends on udev rules that need to be in the /lib/udev directory of the initramfs. You don't say where you got that image from.

If you are building your own kernel, it's much simpler not to use an initramfs at all. Just build the sata driver and your root filesystem (probably ext4) right into the core of the kernel, so that it can boot to that partition directly.

It's actually an image build on my own machine. :-)

If I deactivate initramfs via menuconfig (which I did with the kernel I'm building right now), do I need to compile it too with the --initrd switch?

Right now this is my command to compile my kernels: I also would prefer this way and ext4 as well as sata is builtin. I only have a problem interpreting the (s)ata entries as there are two, one of which says "deprecated" which I don't use right now.

Are we dealing with Debian here? I ask because as far as I know make-kpg is obsolete. It's make deb-pkg now and it probably behaves differently. There's some instructions here.

1 members found this post helpful.

Yes, it's an old PowerPC box which uses Debian 8.11. The paper which I used and did my remarks on is from 2008. Compilation so far was always successful.

Should I ditch my approach and use build-dep here?

On the way to Tesco, I thought of something else which might work. Go into /lib/udev/rules.d and grep for UUID. That will show you the rule which sets the by-uuid links in your root partition and the file that contains it (probably called something like "persistent-storage-rules"). Then unpack your initramfs, find the same file and edit it to do the same. Repack the initramfs and maybe it will boot.

PS: I don't think you would need build-dep. That's only to make it possible to build kernels and you can already do that on your system. If you scroll down that page, you'll see the instructions for the new way to make Debian kernels. Basically you configure the kernel in your usual way but use make deb-pkg instead of make.

Your first thought is exactly what I had last week too and I found this article. There's a chapter "Copying an existing cpio.gz file into the kernel" and I tried that. But somehow I can't find an on my box to use. :-/

Yesterday I compiled a kernel successfully from old sources with from your article.
All good except the fact that I get a "firmware-image" deb as well as a "libc-dev" deb beside the usual "linux-image", "linux-headers" deb files. For what are these for? I wonder where my "linux-source" deb is? o.O Was it split?

Maybe you may be happy to hear now that I know and can apply the "new way" for Debian kernel building too thanks to your hint. :-D

No, you'd have to rename your initrd image to be .cpio.gz (which is what it is internally actually). Or perhaps you can load it in its original name. But I don't see how that would help. Your problem isn't that the initramfs isn't being read but that it doesn't seem to contain the udev rules you need to make the necessary links for your disk ids.
Debian is famous for breaking up packages. If you build a kernel from source and want to install the corresponding headers (as you must do in LFS) you use make headers_install. Your "linux-headers" package was made that way. "libc-dev" is the libc headers that go with those kernel headers. I suspect that "firmware-image" is just the Debian way of keeping the kernel libre; they put the firmware in a different package.

PS: After thought, I think the kernel headers that get installed under /usr/include are the ones in libc-dev. The kernel-headers package must be for those headers that are used only for building the kernel itself. They are needed if you are going to build any kernel modules (for example vbox).