Bug 1874724

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.

This message is a reminder that Fedora Linux 38 is nearing its end of life.
Fedora will stop maintaining and issuing updates for Fedora Linux 38 on 2024-05-21.
It is Fedora's policy to close all bug reports from releases that are no longer
maintained. At that time this bug will be closed as EOL if it remains open with a
'version' of '38'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, change the 'version' 
to a later Fedora Linux version. Note that the version field may be hidden.
Click the "Show advanced fields" button if you do not see it.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora Linux 38 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora Linux, you are encouraged to change the 'version' to a later version
prior to this bug being closed.

Fedora Linux 38 entered end-of-life (EOL) status on 2024-05-21.

Fedora Linux 38 is no longer maintained, which means that it
will not receive any further security or bug fix updates. As a result we
are closing this bug.

If you can reproduce this bug against a currently maintained version of Fedora Linux
please feel free to reopen this bug against that version. Note that the version
field may be hidden. Click the "Show advanced fields" button if you do not see
the version field.

If you are unable to reopen this bug, please file a new report against an
active release.

Thank you for reporting this bug and we are sorry it could not be fixed.