0

I entered the live environment and installed Grub on my hard drive, placing the 6.4.0 kernel in the /dev/sda3 location, through mkinitramfs -o /mnt/boot/initrd created the initrd and placed it in the /dev/sda3 location, but it got stuck here during startup, as shown in the screenshot: enter image description here

But when I enter the live environment, I can see/dev/sda3, as shown in the screenshot: enter image description here

What's going on? I followed this link(mdadm: no devices listed in conf file were found - Debian 8 with GPT) and set rootdelay in grub.cfg and executed update grub, which is still the same. Additionally, after entering initramfs, the keyboard was unable to input, so I don't know what happened

grub.cfg:

#Begin cfg
set default=0
set timeout=4

set root=(hd0,gpt3)

menuentry "GNU/Linux, Test-6.4.0-rt" {
    linux /bzImage rw root=/dev/sda3 rootdelay=90
    initrd /initrd
}

fstab:

#device mount-point type options dump fsck order
/dev/sda3   /         ext4  defaults   0 1
/dev/sda2   /boot     ext4  defaults   0 1
/dev/sda1   /boot/efi vfat  umask=0077 0 0
proc   /proc proc  defaults 0 0
sysfs  /sys  sysfs defaults 0 0
tmpfs /tmp tmpfs defaults 0 0
tmpfs /var  tmpfs defaults 0 0
debugfs /sys/kernel/debug  debugfs  default  0  0
devpts  /dev/pts  devpts defaults  0  0
#none   /tmp  ramfs defaults 0 0
#mdev   /dev  ramfs defaults 0 0

reply telcoM and Tom Yan， drivers exist:

sudo unmkinitramfs initrd .
ls main/lib/modules/6.1.0-10-amd64/kernel/drivers/ata/ahci.ko
ls main/lib/modules/6.1.0-10-amd64/kernel/drivers/scsi/sd_mod.ko

====================Problem recurrence=============================

update 6.4.0-rt8:

$ ls main/lib/modules/6.4.0-rt8/kernel/drivers/scsi/sd_mod.ko
main/lib/modules/6.4.0-rt8/kernel/drivers/scsi/sd_mod.ko
$ ls main/lib/modules/6.4.0-rt8/kernel/drivers/ata/ahci.ko
main/lib/modules/6.4.0-rt8/kernel/drivers/ata/ahci.ko

#1 enter image description here #2 enter image description here

3
  • Normally you need generate initramfs after chrooting into the corresponding installation so that it can determine correctly which driver modules are required to mount root. You can also see if your distro provide a way for you to generate a "fallback" initramfs though, which should include most if not all potential drivers.
    – Tom Yan
    Aug 29 at 6:06
  • The thing is, if you generate without chroot, the initramfs would include module files from the current installation/environment, which may not be loadable if the target installation has a different kernel build.
    – Tom Yan
    Aug 29 at 6:25
  • @TomYan Can you help me check again? This problem has reappeared, but I have checked my driver and they are all available.
    – ABeginner
    Sep 4 at 10:00

1 Answer 1

Reset to default
0

Apparently the drivers needed to access your /dev/sda disk is neither built into the kernel nor available as loadable modules within initramfs.

If this is a typical desktop or laptop system, the missing driver would probably be the ahci kernel module or its dependencies: libahci, libata and sd-mod. If these modules are not available, neither the /dev/sda whole-disk device node nor the device nodes for any partition devices (e.g. /dev/sda3) will not appear.

If /dev/sda exists but the partition device nodes don't, then the kernel is missing the appropriate partition table support.

If the device nodes are available but mounting it fails, a typical cause for that would be a missing filesystem driver module.

11
  • 1
    Let's not forget sd-mod and the filesystem driver.
    – Tom Yan
    Aug 29 at 6:08
  • @TomYan Good point, edited.
    – telcoM
    Aug 29 at 6:19
  • @yanzhang92 See my second comment under your post
    – Tom Yan
    Aug 29 at 6:45
  • @TomYan Sorry, I just saw it, so what do you mean is that I should not generate initrd in other environments, but rather execute mkinitramfs - o to generate initrd in chroot?
    – ABeginner
    Aug 29 at 6:48
  • You said you are using a 6.4.0 kernel, but those driver modules are for kernel version 6.1.0. The modules for an older kernel version won't necessarily work with a newer one, and they definitely won't work if the kernel build process is configured to sign the kernel modules & require valid signatures for Secure Boot compatibility.
    – telcoM
    Aug 29 at 6:49

You must log in to answer this question.

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