1

I've been trying to configure a kernel that will not require an initrd to boot. I haven't succeeded. The filesystem I'm attempting to boot from is ext4, and I have all the extended filesystems compiled in my kernel (not as a module, in the kernel itself). I'm using an Early-2011 MacBook Pro with a 2.5" 1TB WD hard drive. My command line is root=PARTUUID=5c595262-cd6a-48f9-b199-6d72dae95b09 ro rootfstype=ext4 rootwait and every time I boot I get a kernel panic about not being able to mount the root partition and the root= section of my command line being invalid. See Update I have CONFIG_DEVTMPFS enabled that mounts /dev before the root filesystem, but since I originally posted this question, I've switched to using a PARTUUID instead of specifying it's dev path, so I shouldn't need it anymore, but it's still enabled. I have the CONFIG_EFI_STUB option enabled and am using that to boot, and my command line is hard coded into the kernel.

Kernel panic trying to boot my kernel (because it's not seKernel panic when I try to boot (because it's not seeing my HDD)

My .config file

What configuration options do I need to change to get my system working without an initrd talking to my HDD? I can't use an initrd because my only method of booting is directly loading my kernel EFI-style, and therefore since the kernel itself can't load an initrd (as far as I know, a bootloader is required to load the initrd) I can't use one.

UPDATE: Since the posting of this question, I've determined that everything is configured fine except my kernel isn't seeing my 2.5" internal 1TB SATA drive (which is why my kernel was originally saying the root argument was invalid, sda didn't exist). So what do I need to configure to get my kernel talking to my internal SATA HDD? (And should I post that as a separate question?)

Output of lsmod running with a slightly-modified configuration to support initial ram disks

lspci on that same slightly-modified configuration and initial ram disk

Billy
  • 665
  • You state many things that don't appear to match but it's hard to be sure with such a bad image to rely on. Did you enable udev in the kernel? Are you absolutely sure that your drive will be detected as /dev/sda and that your root is on its 4th partition? – Julie Pelletier Jun 28 '16 at 04:24
  • @JuliePelletier I'm absolutely sure my Debian ext4 partition is the fourth, but I can't say if I have udev enabled (what's it's config ID?) I do have CONFIG_DEVTMPFS, enabled, however, which I think may be what you're asking. I highly doubt my drive would be anything other than sda. (What else would it be? My system only has one drive.) – Billy Jun 28 '16 at 04:49
  • https://wiki.gentoo.org/wiki/Udev#Kernel – Julie Pelletier Jun 28 '16 at 04:55
  • 1
    Why can't you use a bootloader (e.g. grub)? It sounds like it would avoid this issue entirely. – phemmer Jun 28 '16 at 05:06
  • @Patrick I can, but I'm using a Mac, and a Mac has a boot menu that displays each OS, so I'd like to be able to choose Debian, and get Debian, not a bootloader for the whole system. I also want the learning experience and for anyone in the future that wants to use an EFI stub to boot that sees this to not have this problem. – Billy Jun 28 '16 at 05:36
  • Look at http://stackoverflow.com/questions/28842865/passing-kernel-parametes-to-efi-stub-in-apples-efi-env – fpmurphy Jun 28 '16 at 05:53
  • @fpmurphy1 That won't work for me, because for whatever reason, the only way for me to use an initrd is with a boot manager, passing the initrd option to the kernel won't load the initrd. – Billy Jun 28 '16 at 06:06
  • @JuliePelletier I enabled udev, same kernel panic. – Billy Jun 28 '16 at 06:06
  • @Billy: I can't see your screen while it's booting up and your picture is almost unreadable. Do you see where it detects that system's partitions? Do they match what you expect? – Julie Pelletier Jun 28 '16 at 06:09
  • @Billy. Humm, works fine for me. I have been using EFISTUB on numerous UEFI implementations for years. One difference is that I always boot from the UEFI shell. – fpmurphy Jun 28 '16 at 10:20
  • @Billy You can still have grub and your mac menu. What you're doing is going to be very uncommon and problematic as not using a linux specific bootloader is going to cause lots of headache. It's going to make it difficult to be able to install new kernels, change kernel parameters, etc. – phemmer Jun 28 '16 at 12:04
  • You're missing a driver for your disk drive or a controller or bus on the way to the drive. Recompile the kernel with make localmodconfig to get all the necessary drivers. – Gilles 'SO- stop being evil' Jun 28 '16 at 21:19
  • I was able to get Linux to run without crashing by including an initrd on my EFI system partition, then appending initrd=path to initrd relative to my ESP as root, but with back-slashes instead of forward-slashes. The reason my previous attempts to use an initrd with an EFI-stub failed was because I was using forward-slashes instead of back-slashes. This is a work-around, not the answer to my question, which is why I'm posting this as a comment instead of an answer. – Billy Jun 28 '16 at 21:24
  • @Gilles I'll try that, but doesn't it just copy the file at the path /boot/config-<current-running-kernel-version>-<architecture> to ./.config? – Billy Jun 28 '16 at 21:30
  • @Billy No, the kernel compilation scripts don't know or care about any file in /boot. make localmodconfig is based on drivers in the running kernel. – Gilles 'SO- stop being evil' Jun 28 '16 at 21:32
  • why do backslashes rather than slashes mean that adding initrd=... to the efibootmgr is not an answer? looks like an answer to me - you wanted to know how to boot linux directly from Mac's boot loader without grub and now you do. As @Patrick says, though, avoiding grub is just going to make it difficult to upgrade linux kernels or change boot args (btw, using grub doesn't mean you have to see the grub menu - you can configure it to just instantly load the default kernel and initrd without displaying a menu) – cas Jun 29 '16 at 00:19
  • @cas My problem isn't that I had to use back-slashes instead of slashes, that was just the only way to use initrd. Using an initrd is a work-around, but I would prefer to just go without one (hence the title of the question). That is why I did not post it as an answer. The question is about how to configure a kernel so it will run without an initrd, not how to get an initrd working without a bootloader. – Billy Jun 29 '16 at 04:47
  • yes, that was your question. sometimes a question is completely misguided or just plain wrong and that fact needs to be pointed out. – cas Jun 29 '16 at 05:17
  • The crux of the issue also has nothing to do with an initrd. As Gilles mentioned, the issue is building a custom kernel, and selecting the right drivers. Even if you had an initrd, you'd still have the same problem if you didn't enable the right drivers. – phemmer Jun 29 '16 at 05:22
  • True, if you ignore the fact that initrd-building scripts generally either build/install ALL drivers as modules anyway, or those that are required to boot the current system (e.g. MODULES=[most|netboot|dep|list] in /etc/initramfs-tools/initramfs.conf on debian). It's a solved problem, and was solved long ago. OP seems to mistakenly think that going back to the early-90s is worth the effort. Possibly true as a learning exercise, not true for real-world usage. – cas Jun 29 '16 at 06:23

1 Answers1

0

I was able to get it running by compiling my SATA controller (libata) into my kernel, which was originally being compiled as a module (and which was why it would run fine with an initial ram disk).

Billy
  • 665