FS#51698 - [grub] 10_linux inserts loopback device into grub.cfg when installing into disk image
Attached to Project:
Arch Linux
Opened by Johannes Ernst (jernst) - Friday, 04 November 2016, 21:53 GMT
Last edited by freswa (frederik) - Tuesday, 22 September 2020, 11:35 GMT
Opened by Johannes Ernst (jernst) - Friday, 04 November 2016, 21:53 GMT
Last edited by freswa (frederik) - Tuesday, 22 September 2020, 11:35 GMT
|
Details
Description:
I've been generating bootable disk images with the same script for some time. Recently, without any changes on my end (afaik), the generated images stopped booting because the generated /boot/grub/grub.cfg file now has the loop device used during image creation in the kernel boot line: linux /vmlinuz-linux root=/dev/mapper/loop1p2 rw quiet In previously generated images, this line uses the UUID of the disk image: linux /vmlinuz-linux root=UUID=a6138954-799e-46df-a549-ac6ad14ef3d5 rw quiet which seems more correct. It appears some changes were made recently in /etc/grub.d/10_linux where this line appears to be generated. Is it possible those changes caused this change in behavior? I currently see now way of getting my disk images generated correctly other than modifying 10_linux. Is that correct? Additional info: * 1:2.02.beta3-4 Steps to reproduce: |
This task depends upon
Closed by freswa (frederik)
Tuesday, 22 September 2020, 11:35 GMT
Reason for closing: None
Additional comments about closing: Not seen in a while.
Tuesday, 22 September 2020, 11:35 GMT
Reason for closing: None
Additional comments about closing: Not seen in a while.
/dev/disk/by-uuid/<UUID> exists, after kpartx -a, for the ext4 partition on the disk image, but not for the btrfs partition. This may explain the grub-mkconfig behavior, and the kernel / device mapper / btrfs / kpartx ... may be at fault instead.
If I kpartx -d and recreate the loop devices, the btrfs partition is recognized as well in /dev/disk/by-uuid and lsblk.