[GTALUG] Boot problem

Michael Galea michael at galeahome.ca
Sun Jan 22 09:20:03 EST 2017


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 at 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 at 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


More information about the talk mailing list