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! To boot properly I must power off the esata, boot and wait until the boot is proceeding from the system disk, then power up the esata. The bios boot order is set to boot from the (correct) system disk. /etc/fstab is set to boot using UUIDs, and all UUIDs are correct. The esata drive is not bootable. Can anyone suggest something to look at or try? I would expect that if grub was able to show me my images it would be able to load them, even if the esata was available. -- Michael Galea
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 de Boer
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. -- Scott Sullivan
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
On Sun, Jan 22, 2017 at 09:20:03AM -0500, Michael Galea via talk wrote:
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.
That would certainly explain it. I think some years ago there was a question during a package install about switching to UUIDs, and if you told it no at that time, it would have written that entry to the grub config. That would be when Debian was transitioning to the UUID use for grub. I think the question isn't even asked anymore, but apparently that doesn't mean the value got removed from older systems when the question was removed. All I can find in the changelog is that a commented out line was added in 2008 that could be uncommented to disable the use of UUID in grub. -- Len Sorensen
On 01/21/17 12:58, Anthony de Boer 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.
Sure, almost certainly..
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.
Thanks Anthony, I tried unmount+poweroff esata and "update-initramfs -u" and reboot but no success. It still boots from the hard disk but attempts to mount the OS from esata. The only difference is that the timing of when I have to switch on the esata is now "very tight" at less than a few seconds after I get the clean message from fsck, or boot fails (missing mount in fstab). -- Michael Galea
participants (4)
-
Anthony de Boer -
lsorense＠csclub.uwaterloo.ca -
Michael Galea -
Scott Sullivan