Gentoo install first boot stuck on job dev-disk-by

[alamahant]

I found it.
Most probably you forgot to mount /dev/sda1 on /boot before chrooting.
So when you ran

[kish]

I did `mount /dev/sda1 /boot` after chrooting.

Here are my steps:

[pingtoo]

kish,

Please try alamahant suggestion first, if it work great, problem solved.

If not or you still want to pursue dracut/systemd, we can try then.

As rdsosreport.txt getting nothing. I am sorry about that, Because I forget about a bunch of setup required for initrd at top. We break into initrd very early some steps need manually execute. If after trying alamahant suggestion we are still in game need to solve this mystery I will provide either a simple script or find a different breakpoint into initrd.

[alamahant]

[kish]

I did mount sys, sorry. It was a copy/paste typo.

Moreover, when we switched from UUID to partition numbers, grub did update. So I believe the correct /boot is mounted.

[pingtoo]

kish,

Here are few breakpoints in dracut we can test which hopefully well lead to a clear picture what happen during the boot sequence.

• rd.break=pre-mount
  
• rd.break=mount
  
• rd.timeout=10

I think pre-mount and mount are mutually exclusive, you can only use one or the other. In you screen dump post, the pre-mount seems to always finish so it may be a safe place to break in.

On the other hand rd.break=mount + rd.timeout=10 can be use together for debug rootfs mounting problem. rd.break=mount is breakpoint right before mount rootfs, and rd.timeout=10 will cause dracut timeout and drop to shell if any device waiting over timeout(10 seconds). so hopefully this is the right combo for break to take a look why systemd is waiting for root device.

To test above just do the same dance, got into grub prompt, replace rdinit=/bin/sh to either rd.break=pre-mount or the rd.timeout+rd.break combo.

If timeout occur and you dropped into shell, the /run/initramfs/rdsosreport.txt should already exist. please share the file. please not the file could be big, usually screen dump is not enough.

[kish]

Got it!

Booted with `rd.break=mount rd.timeout=10`.
Dropped me into the emergency shell.
Indeed there was a warning about `/run/initramfs/rdsosreport.txt` being created. It even suggested to copy it to a USB stick or /boot.

Emergency shell output

rdsosreport.txt

Does this help?

[grknight]

You do not have the disk driver enabled that is in use for the VMWare machine.

Often this can be a Fusion MPT or similar by default. If it can be changed to SATA (with AHCI) or similar, then it will save a kernel recompile.

[kish]

Ah! So it's due to a lacking kernel driver for the SCSI disk controller used by VMware...
The VM's disk was created by default using a SCSI disk controller, it didn't prompt me to choose a disk controller when creating the VM.

Switched the SCSI controller to a SATA (AHCI) controller and it booted right up to the login prompt!

Also, I assumed because the Live CD was able to access the disk, that the newly compiled kernel would be able to as well. I didn't realize I needed to compile the kernel with the SCSI support explicitly! Newbie mistake.
The kernel in the Live CD having support for SCSI as both a blessing and a curse: I was able to mount the disk and follow the handbook all the way to the end, but it wouldn't boot at the end due to lack of drivers in the new kernel.
Maybe it's worth adding a note to the Kernel compile section in the handbook to remind users to add kernel support for their disk controllers if not SATA.

What a farce this was, thanks for your time.

[kish]

So one thing I don't understand is, if /dev/sda disk was not accessible by the kernel due to missing SCSI controller driver, how did grub work and the kernel start loading?
Grub and the Linux kernel were installed to /boot, which is on /dev/sda1 partition, which is part of the /dev/sda disk.

Does grub have its own set of built-in drivers to load various disk drive controllers?
And then grub boostrapped the kernel, and then the kernel failed to load the remaining partitions needed to finish booting, /dev/sda2 (swap) and /dev/sda3 (/)?

[Hu]

The LiveCD needs to have broad hardware support, because if it does not work on your hardware as-is, you usually have no reasonable way to replace its kernel with a more capable one. In contrast, the kernel you configure and build for yourself can have narrow support for just your hardware, since you can use an older kernel or the LiveCD to add support if you miss something.

Yes, Grub has its own mechanism for accessing the disk, outside the kernel. This is why Grub can be used to boot non-Linux systems, such as Windows, even when no Linux kernel is installed. These mechanisms may be less capable than the Linux-native driver, such as lacking support for features that obtain the maximum performance your hardware can provide. However, since they are only used long enough to load a small number of files and then transfer control to Linux, you do not need optimum performance from them.

The kernel cannot access a partition until it can access the device on which the partition is stored. Since you lacked the relevant driver, you had no /dev/sda, and thus no access to that device or the partitions on it.

[grknight]

[NeddySeagoon]

kish,

You are getting experience.

That's what you get just after you needed it :)

Enjoy your Gentoo.
_________________
Regards,

NeddySeagoon

Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail.

[kish]

So I'm running into the same driver issue for my network interface. Works in the LiveCD, but not in the new kernel.

How do I go about finding which correct driver to compile into the kernel? Maybe I can grab some info about the nic when booted into the LiveCD?

From the LiveCD:

[pietinger]

[kish]

[tippincows]