Bug 1874724 - dual boot Fedora, 2nd installation erases 1st installation's /boot/loader/entries *conf files
Summary: dual boot Fedora, 2nd installation erases 1st installation's /boot/loader/ent...
Keywords:
Status: NEW
Alias: None
Product: Fedora
Classification: Fedora
Component: anaconda
Version: 35
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Anaconda Maintenance Team
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2020-09-02 05:36 UTC by Chris Murphy
Modified: 2021-09-20 12:45 UTC (History)
12 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed:
Type: Bug


Attachments (Terms of Use)
anaconda.log (53.03 KB, text/plain)
2020-09-02 05:38 UTC, Chris Murphy
no flags Details
program.log (17.39 KB, text/plain)
2020-09-02 05:39 UTC, Chris Murphy
no flags Details
program.log (519.12 KB, text/plain)
2020-09-02 05:39 UTC, Chris Murphy
no flags Details

Description Chris Murphy 2020-09-02 05:36:11 UTC
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:

Comment 1 Chris Murphy 2020-09-02 05:38:44 UTC
Created attachment 1713403 [details]
anaconda.log

Comment 2 Chris Murphy 2020-09-02 05:39:05 UTC
Created attachment 1713404 [details]
program.log

Comment 3 Chris Murphy 2020-09-02 05:39:19 UTC
Created attachment 1713405 [details]
program.log

Comment 4 Chris Murphy 2020-09-02 05:41:36 UTC
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*

Comment 5 sumantro 2020-09-02 06:47:29 UTC
I am able to replicate the same on the test case
https://fedoraproject.org/wiki/User:Sumantrom/Draft/dualboot_f33_btrfs

Comment 6 Chris Murphy 2020-09-02 22:55:46 UTC
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.

Comment 7 Chris Murphy 2020-09-02 23:03:07 UTC
/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.

Comment 8 Chris Murphy 2020-09-02 23:14:38 UTC
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.

Comment 9 Chris Murphy 2020-09-02 23:47:17 UTC
Baremetal install, machine-id is unique. However, something still deletes all the 1st installation's conf files in /boot/loader/entries.

Comment 10 sumantro 2020-09-03 05:39:29 UTC
(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

Comment 11 Chris Murphy 2020-09-03 05:44:51 UTC
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.

Comment 12 Fedora Admin user for bugzilla script actions 2021-05-07 00:34:31 UTC
This package has changed maintainer in Fedora. Reassigning to the new maintainer of this component.

Comment 13 Javier Martinez Canillas 2021-06-17 23:21:05 UTC
This bug was filed for grub2, but shouldn't the component be anaconda perhaps ?

Comment 14 Chris Murphy 2021-06-18 05:26:21 UTC
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?

Comment 15 Ben Cotton 2021-08-10 12:48:27 UTC
This bug appears to have been reported against 'rawhide' during the Fedora 35 development cycle.
Changing version to 35.


Note You need to log in before you can comment on or make changes to this bug.