Description of problem: Something has cleaned out /boot/loader/entries following a new installation reusing the ext4 /boot volume without reformatting. Kernels and initramfs from the 1st installation are still present. Version-Release number of selected component (if applicable): grub2-common-2.04-30.fc33.noarch anaconda 33.25.2-1.fc33 How reproducible: Always Steps to Reproduce: 1. Perform a Fedora 33 installation using Automatic partitioning. Reboot and run through gnome initial setup. 2. Boot the second Fedora 33 installer. Use Custom partitioning 3. Locate the previous Fedora installation, click on it to reveal existing mount points for reuse 4. Select /boot/efi or BIOS Boot mount point, on the right hand side at the top, find ''Mount Point'' field, type in /boot/efi, click ''Update Settings'' button. 5. Select /boot mount point, on the right hand side at the top, find ''Mount Point'' field, type in /boot, do NOT check the ''Reformat'' box, click ''Update Settings'' button. 6. Select /home mount point, on the right hand side at the top, find ''Mount Point'' field, type in /home, click ''Update Settings'' button. 7. Click + button to create a new / mount point (this is required to be a new subvolume, reformat will be checked, cannot be uncheck but the underlying Btrfs is not reformatted, optionally change the name of the subvolume from root00 to rootkde or rootjam or whatever it is). Click ''Update Settings'' button. 8. Click Done 9. Reboot Actual results: /boot/loader/entries/ has only two new files with the current machine id, maching the current (2nd) installation. The entries for the first installation have been deleted. Expected results: /boot/loader/entries is ostensibly a shared location, entries shouldn't be deleted. Additional info:
Created attachment 1713403 [details] anaconda.log
Created attachment 1713404 [details] program.log
Created attachment 1713405 [details] program.log
I can't tell what's deleting them, the installer or the kernel scripts maybe are doing some kind of garbage collection? Maybe because the machineid is different? *shrug*
I am able to replicate the same on the test case https://fedoraproject.org/wiki/User:Sumantrom/Draft/dualboot_f33_btrfs
1st install = Fedora-Workstation-Live-x86_64-33-20200902.n.0.iso 2nd install = Fedora-Jam_KDE-Live-x86_64-33-20200902.n.0.iso During 2nd install: # fatrace -c python3(2519): O /mnt/sysimage/boot python3(2519): RC /mnt/sysimage/boot 10_linux(3584): O /mnt/sysimage/boot/loader/entries 10_linux(3584): R /mnt/sysimage/boot/loader/entries 10_linux(3584): R /mnt/sysimage/boot/loader/entries 10_linux(3584): C /mnt/sysimage/boot/loader/entries sed(3590): O /mnt/sysimage/boot/loader/entries/e0582bfd542c4f3592c9d7d1a00f6437-5.8.3-300.fc33.x86_64.conf sed(3590): + /mnt/sysimage/boot/loader/entries sed(3590): O /mnt/sysimage/boot/loader/entries/sed6V28bF sed(3590): R /mnt/sysimage/boot/loader/entries/e0582bfd542c4f3592c9d7d1a00f6437-5.8.3-300.fc33.x86_64.conf sed(3590): C /mnt/sysimage/boot/loader/entries/e0582bfd542c4f3592c9d7d1a00f6437-5.8.3-300.fc33.x86_64.conf sed(3590): CW (deleted) sed(3590): D /mnt/sysimage/boot/loader/entries Before starting the 2nd install, I set 'chattr +i' on the two conf files from the 1st installation. INFO:program:Running in chroot '/mnt/sysroot'... grub2-set-default e0582bfd542c4f3592c9d7d1a00f6437-5.8.3-300.fc33.x86_64 Sep 02 18:46:13 localhost-live org.fedoraproject.Anaconda.Modules.Storage[2519]: DEBUG:program:Return code: 0 Sep 02 18:46:13 localhost-live org.fedoraproject.Anaconda.Modules.Storage[2519]: INFO:program:Running in chroot '/mnt/sysroot'... grub2-mkconfig -o /boot/efi/EFI/fedora/grub.cfg Sep 02 18:46:15 localhost-live org.fedoraproject.Anaconda.Modules.Storage[2519]: INFO:program:Generating grub configuration file ... Sep 02 18:46:15 localhost-live org.fedoraproject.Anaconda.Modules.Storage[2519]: INFO:program:sed: cannot rename /boot/loader/entries/sed6V28bF: Operation not permitted Sep 02 18:46:15 localhost-live org.fedoraproject.Anaconda.Modules.Storage[2519]: DEBUG:program:Return code: 4 Is it trying to rename the new 2nd install conf files to the same name as the 1st install conf files? Boot Workstation ISO: # hostnamectl Static hostname: localhost-live Icon name: computer-vm Chassis: vm Machine ID: e0582bfd542c4f3592c9d7d1a00f6437 Boot KDE Jam ISO: $ hostnamectl Static hostname: localhost-live Icon name: computer-vm Chassis: vm Machine ID: e0582bfd542c4f3592c9d7d1a00f6437 OK we don't have unique machine names between live install boots, but why are they identical between images? That's weird. And that'd explain the rename/replace of the conf files.
/dev/mapper/live-base on the two ISOs contains /etc/machine-id and it is a 0 byte file. /dev/mapper/live-rw (dm writable overlay) is mounted at / and contains a non-zer /etc/machine-id and it is always e0582bfd542c4f3592c9d7d1a00f6437 on every boot. That seems wrong.
adamw points out https://www.freedesktop.org/software/systemd/man/systemd-machine-id-setup.html and that qemu-kvm does use --uuid. So that's the likely explanation. And there's no good reason VM's should dual boot. On baremetal, this bug shouldn't happen. I'll test that next.
Baremetal install, machine-id is unique. However, something still deletes all the 1st installation's conf files in /boot/loader/entries.
(In reply to Chris Murphy from comment #9) > Baremetal install, machine-id is unique. However, something still deletes > all the 1st installation's conf files in /boot/loader/entries. I tested on baremetal and can confirm that it deletes all the conf files of 1st installion
Good news: grub2-mkconfig is only replacing the matching machine-id BLS entries. The other entries remain untouched. More good news: updating the kernel only adds a new BLS entry. Gotcha: since two Fedora 33 installs have matching kernel names and thus only one copy on /boot, either installation performing a dnf update in which a kernel is removed, means the kernel is removed for both installs. We're not currently installing kernels and initramfs per the BLS spec recommendation. We're putting them directly in $BOOT/ rather than in $BOOT/$MACHINEID/$KERNELVERS/. Yet more good news: If I make a backup of the 1st installations BLS snippets before performing install #2; and then restore them following install #2, I get a properly populated GRUB menu, and can boot either Fedora 33 variant without further problems.
This package has changed maintainer in Fedora. Reassigning to the new maintainer of this component.
This bug was filed for grub2, but shouldn't the component be anaconda perhaps ?
anaconda-35.17-1.fc35.x86_64 python3-blivet-3.4.0-2.fc35.noarch Yep. Jun 18 01:14:08 org.fedoraproject.Anaconda.Modules.Storage[2544]: INFO:anaconda.threading:Running Thread: AnaTaskThread-CreateBLSEntriesTask-1 (140137196418624) Jun 18 01:14:08 org.fedoraproject.Anaconda.Modules.Storage[2544]: INFO:anaconda.modules.storage.bootloader.utils:Removing old BLS entry: /mnt/sysroot/boot/loader/entries/f5813fe509904a58ad3191bac1540b64-5.13.0-0.rc6.45.fc35.x86_64.conf Jun 18 01:14:08 org.fedoraproject.Anaconda.Modules.Storage[2544]: INFO:anaconda.modules.storage.bootloader.utils:Removing old BLS entry: /mnt/sysroot/boot/loader/entries/f5813fe509904a58ad3191bac1540b64-0-rescue.conf Jun 18 01:14:08 org.fedoraproject.Anaconda.Modules.Storage[2544]: INFO:anaconda.modules.storage.bootloader.utils:Regenerating BLS info for 5.13.0-0.rc6.45.fc35.x86_64 Jun 18 01:14:08 org.fedoraproject.Anaconda.Modules.Storage[2544]: INFO:program:Running in chroot '/mnt/sysroot'... kernel-install add 5.13.0-0.rc6.45.fc35.x86_64 /lib/modules/5.13.0-0.rc6.45.fc35.x86_64/vmlinuz But how does Anaconda know whether to clean them up or not? Could clean up be triggered when the user selects an old sysroot for deletion?
This bug appears to have been reported against 'rawhide' during the Fedora 35 development cycle. Changing version to 35.
This is coming from here: https://github.com/rhinstaller/anaconda/blob/master/pyanaconda/modules/storage/bootloader/utils.py#L229 I think 229-242 should just be removed because per the BLS spec we don't actually know whether we own anything in here or not, unless the user indicates the entire $BOOT can be reformatted, which then takes care of deleting these files if necessary.
Sorry, 229-233. https://github.com/rhinstaller/anaconda/pull/4283
This bug appears to have been reported against 'rawhide' during the Fedora Linux 38 development cycle. Changing version to 38.