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

Improve this question
20
  • 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, 2016 at 4: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, 2016 at 4:49
  • wiki.gentoo.org/wiki/Udev#Kernel
    – Julie Pelletier
    Jun 28, 2016 at 4:55
  • 1
    Why can't you use a bootloader (e.g. grub)? It sounds like it would avoid this issue entirely.
    – phemmer
    Jun 28, 2016 at 5: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, 2016 at 5:36

1 Answer 1

Reset to default
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).

Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .