On 01/21/17 14:04, Scott Sullivan via talk wrote:
On 21/01/17 12:58 PM, Anthony de Boer via talk wrote:
Michael Galea via talk wrote:
I am seeing a problem at boot time that has appeared in kernels after 4.3.0-1-amd64.
My system will boot, show the available debian kernels, select the latest and then jump into initramrs. It claims it can not mount dev and other partitions and, indeed, an ls on the mounted /dev/sda1 shows that my esata drive has been mounted as root!
Debian generates an initramfs at kernel-install time; is it possible that the esata was mounted when you installed that kernel? Maybe run update-initramfs again after booting without the esata connected.
Linux can get its own weird ideas about enumeration order of disks, network cards, PCI slots, etc, and that's why we have UUIDs and I thought the Debian initramfs ought to remember the specific UUID of the root device it was generated to use. However, I don't have any Debian-amd64 hardware to check at home here.
Anthony's advise is good, as it's a path to resolving the problem.
To but it does not include how to diagnose how the root device is selected, or how to tell if it's been change successfully too what you desire.
For myself, I would look at the following places.
1) at boot time, interrupting and appending or editing the boot entry.
2) checking your boot loaders config, which is easy with grub, grub2 configs on the other hand are terrible opaque to read.
3) At run time, by looking at the cmdline file under /proc which is the kernel's command line after booting.
Some samples form my machines:
[scott@failfast ~]$ cat /proc/cmdline BOOT_IMAGE=/vmlinuz-4.8.16-300.fc25.x86_64 root=/dev/mapper/fedora_failfast-root ro rd.lvm.lv=fedora_failfast/root rd.luks.uuid=luks-e37ae023-0aba-417d-82df-157338c8515d rd.lvm.lv=fedora_failfast/swap rhgb quiet LANG=en_US.UTF-8
[root@muse ~]# cat /proc/cmdline BOOT_IMAGE=/vmlinuz-3.10.0-514.2.2.el7.x86_64 root=UUID=4530cd0d-10ed-4fca-a056-534a38e1e717 ro crashkernel=auto rd.md.uuid=1a674618:ee5747c9:08996bc7:5fff0b7d rd.md.uuid=7b9c4991:59009b72:0980bbc3:1ccacf58 rd.md.uuid=18e8b34b:857cab8d:b85d6f0b:30f32d9d rhgb quiet LANG=en_CA.UTF-8
In all cases your looking for the root= parameter.
Further reading: https://wiki.archlinux.org/index.php/Kernel_parameters and the bootparam man page.
Thanks Scott, cat /proc/cmdline indicated GRUB2 was trying to boot from /dev/sda1 despite the provisioning for UUIDs in /etc/fstab. In debian, the /etc/default/grub file has a line "GRUB_DISABLE_LINUX_UUID=true". Commenting that out, update-grub2 and reboot and a now have a nice clean boot. -- Michael Galea