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
---
Talk Mailing List
[email protected]
https://gtalug.org/mailman/listinfo/talk
