F37 anaconda installation with pre-existing W10 and F33, removed F33 boot/grub-entry. how to restore?

I ‘ve just installed F37 with Anaconda to my laptop’s ssd from a usb-stick created with Fedora Media Writer. My plan was to keep the existing Windows 10 and F33 and install F37 beside them.

I had free, non-allocated partition-space, so i selected the following settings in Anaconda: “custom installation” > and in the sub-menu: “auto create F37 partions”. the resulting installation process created serveral new Brtfs partitions/volumes: p7 and p8 and i think modified p1

zram0 252:0 0 7,4G 0 disk [SWAP]
nvme0n1 259:0 0 238,5G 0 disk
├─nvme0n1p1 259:1 0 260M 0 part /boot/efi
├─nvme0n1p2 259:2 0 16M 0 part
├─nvme0n1p3 259:3 0 42,4G 0 part
├─nvme0n1p4 259:4 0 1000M 0 part
├─nvme0n1p5 259:5 0 1G 0 part
├─nvme0n1p6 259:6 0 117,7G 0 part
├─nvme0n1p7 259:7 0 1G 0 part /boot
└─nvme0n1p8 259:8 0 75,1G 0 part /home

After the installation process had finished i did a reboot. The Grub bootloader now shows entries for Windows 10, F37 and F37-rescue (all are working) but the previous F33 entry is gone. Please help me with instructions to restore F33 grub boot entry!

1 Like

Welcome to ask.fedora @christiansam

It not got removed … the location is since F34 different:
Changes/UnifyGrubConfig - Fedora Project Wiki

dev/nvme0n1p7: UUID="1ec21bb9-d4b5-436b-bbbf-760f485bb30d" BLOCK_SIZE="4096" TYPE="ext4" PARTUUID="806c24cc-2798-4d58-9226-f9b82497245b"
/dev/nvme0n1p5: UUID="2e484fcb-6306-46c5-a7b6-b7ee2d39553d" BLOCK_SIZE="4096" TYPE="ext4" PARTUUID="a52d1840-78c9-4941-b532-01239282ab90"
/dev/nvme0n1p3: TYPE="BitLocker" PARTLABEL="Basic data partition" PARTUUID="4b627553-1fed-4e92-955e-1472cde27b19"
/dev/nvme0n1p1: LABEL_FATBOOT="SYSTEM" LABEL="SYSTEM" UUID="1A53-254F" BLOCK_SIZE="512" TYPE="vfat" PARTLABEL="EFI System Partition" PARTUUID="a60da3c2-b2cb-4d6f-a9e9-3e684fa3bb00"
/dev/nvme0n1p8: LABEL="fedora_localhost-live" UUID="0232550c-42e8-4e2a-92ed-1e39dcade081" UUID_SUB="b64bf106-a88e-4e1c-9ab8-a4fdf526b856" BLOCK_SIZE="4096" TYPE="btrfs" PARTUUID="7cce45c5-7705-4c7e-ac07-a53fec678faf"
/dev/nvme0n1p6: LABEL="fedora_localhost-live" UUID="41ab391f-6b8b-4add-b132-2824de0c0c25" UUID_SUB="e224bd31-90dc-4a0a-9e73-9838793eca38" BLOCK_SIZE="4096" TYPE="btrfs" PARTUUID="0cc30877-1689-43dc-bb40-91880f827825"
/dev/nvme0n1p4: LABEL="WinRE_DRV" BLOCK_SIZE="512" UUID="4634559F34559333" TYPE="ntfs" PARTLABEL="Basic data partition" PARTUUID="a7a21db1-179d-41bb-a0a7-9a5fe7e90416"
/dev/nvme0n1p2: PARTLABEL="Microsoft reserved partition" PARTUUID="9299f15d-cc4b-4839-bb7c-c1d97a06eb15"
/dev/sda3: UUID="89a14935-39dd-3c35-bed6-eae9a4d00ffc" BLOCK_SIZE="4096" LABEL="ANACONDA" TYPE="hfsplus" PARTUUID="1cf9ab0d-03"
/dev/sda1: BLOCK_SIZE="2048" UUID="2020-10-20-00-01-33-00" LABEL="Fedora-WS-Live-33-1-2" TYPE="iso9660" PTUUID="1cf9ab0d" PTTYPE="dos" PARTUUID="1cf9ab0d-01"
/dev/zram0: LABEL="zram0" UUID="1872571f-3ea3-48fc-b30b-622823baf0db" TYPE="swap"

if i run a plain grub2-mkconfig to stdout, i see a “Found Fedora 33 (Workstation Edition) on /dev/nvme0n1p6” message. Is the solution to persist it with “grub2-mkconfig -o /boot/grub2/grub.cfg” ?

[root@sampc5 boot]# grub2-mkconfig
Generating grub configuration file ...
# It is automatically generated by grub2-mkconfig using templates
# from /etc/grub.d and settings from /etc/default/grub

### BEGIN /etc/grub.d/00_header ###
set pager=1

if [ -f ${config_directory}/grubenv ]; then
  load_env -f ${config_directory}/grubenv
elif [ -s $prefix/grubenv ]; then
if [ "${next_entry}" ] ; then
   set default="${next_entry}"
   set next_entry=
   save_env next_entry
   set boot_once=true
   set default="${saved_entry}"

if [ x"${feature_menuentry_id}" = xy ]; then

export menuentry_id_option

if [ "${prev_saved_entry}" ]; then
  set saved_entry="${prev_saved_entry}"
  save_env saved_entry
  set prev_saved_entry=
  save_env prev_saved_entry
  set boot_once=true

function savedefault {
  if [ -z "${boot_once}" ]; then
    save_env saved_entry

function load_video {
  if [ x$feature_all_video_module = xy ]; then
    insmod all_video
    insmod efi_gop
    insmod efi_uga
    insmod ieee1275_fb
    insmod vbe
    insmod vga
    insmod video_bochs
    insmod video_cirrus

terminal_output console
if [ x$feature_timeout_style = xy ] ; then
  set timeout_style=menu
  set timeout=5
# Fallback normal timeout code in case the timeout_style feature is
# unavailable.
  set timeout=5
### END /etc/grub.d/00_header ###

### BEGIN /etc/grub.d/01_users ###
if [ -f ${prefix}/user.cfg ]; then
  source ${prefix}/user.cfg
  if [ -n "${GRUB2_PASSWORD}" ]; then
    set superusers="root"
    export superusers
    password_pbkdf2 root ${GRUB2_PASSWORD}
### END /etc/grub.d/01_users ###

### BEGIN /etc/grub.d/08_fallback_counting ###
insmod increment
# Check if boot_counter exists and boot_success=0 to activate this behaviour.
if [ -n "${boot_counter}" -a "${boot_success}" = "0" ]; then
  # if countdown has ended, choose to boot rollback deployment,
  # i.e. default=1 on OSTree-based systems.
  if  [ "${boot_counter}" = "0" -o "${boot_counter}" = "-1" ]; then
    set default=1
    set boot_counter=-1
  # otherwise decrement boot_counter
    decrement boot_counter
  save_env boot_counter
### END /etc/grub.d/08_fallback_counting ###

### BEGIN /etc/grub.d/10_linux ###
insmod part_gpt
insmod ext2
search --no-floppy --fs-uuid --set=root 1ec21bb9-d4b5-436b-bbbf-760f485bb30d
insmod part_gpt
insmod fat
search --no-floppy --fs-uuid --set=boot 1A53-254F

# This section was generated by a script. Do not modify the generated file - all changes
# will be lost the next time file is regenerated. Instead edit the BootLoaderSpec files.
# The blscfg command parses the BootLoaderSpec files stored in /boot/loader/entries and
# populates the boot menu. Please refer to the Boot Loader Specification documentation
# for the files format: https://systemd.io/BOOT_LOADER_SPECIFICATION/.

# The kernelopts variable should be defined in the grubenv file. But to ensure that menu
# entries populated from BootLoaderSpec files that use this variable work correctly even
# without a grubenv file, define a fallback kernelopts variable if this has not been set.
# The kernelopts variable in the grubenv file can be modified using the grubby tool or by
# executing the grub2-mkconfig tool. For the latter, the values of the GRUB_CMDLINE_LINUX
# and GRUB_CMDLINE_LINUX_DEFAULT options from /etc/default/grub file are used to set both
# the kernelopts variable in the grubenv file and the fallback kernelopts variable.
if [ -z "${kernelopts}" ]; then
  set kernelopts="root=UUID=0232550c-42e8-4e2a-92ed-1e39dcade081 ro rootflags=subvol=root00 rhgb quiet "

insmod blscfg
### END /etc/grub.d/10_linux ###

### BEGIN /etc/grub.d/10_reset_boot_success ###
# Hiding the menu is ok if last boot was ok or if this is a first boot attempt to boot the entry
if [ "${boot_success}" = "1" -o "${boot_indeterminate}" = "1" ]; then
  set menu_hide_ok=1
  set menu_hide_ok=0 
# Reset boot_indeterminate after a successful boot
if [ "${boot_success}" = "1" ] ; then
  set boot_indeterminate=0
# Avoid boot_indeterminate causing the menu to be hidden more than once
elif [ "${boot_indeterminate}" = "1" ]; then
  set boot_indeterminate=2
# Reset boot_success for current boot 
set boot_success=0
save_env boot_success boot_indeterminate
### END /etc/grub.d/10_reset_boot_success ###

### BEGIN /etc/grub.d/12_menu_auto_hide ###
if [ x$feature_timeout_style = xy ] ; then
  if [ "${menu_show_once}" ]; then
    unset menu_show_once
    save_env menu_show_once
    set timeout_style=menu
    set timeout=60
  elif [ "${menu_auto_hide}" -a "${menu_hide_ok}" = "1" ]; then
    set orig_timeout_style=${timeout_style}
    set orig_timeout=${timeout}
    if [ "${fastboot}" = "1" ]; then
      # timeout_style=menu + timeout=0 avoids the countdown code keypress check
      set timeout_style=menu
      set timeout=0
      set timeout_style=hidden
      set timeout=1
### END /etc/grub.d/12_menu_auto_hide ###

### BEGIN /etc/grub.d/14_menu_show_once ###
if [ x$feature_timeout_style = xy ]; then
  if [ "${menu_show_once_timeout}" ]; then
    set timeout_style=menu
    set timeout="${menu_show_once_timeout}"
    unset menu_show_once_timeout
    save_env menu_show_once_timeout
### END /etc/grub.d/14_menu_show_once ###

### BEGIN /etc/grub.d/20_linux_xen ###

### END /etc/grub.d/20_linux_xen ###

### BEGIN /etc/grub.d/20_ppc_terminfo ###
### END /etc/grub.d/20_ppc_terminfo ###

### BEGIN /etc/grub.d/30_os-prober ###
grub2-probe: error: cannot find a GRUB drive for /dev/sda3.  Check your device.map.
Found Windows Boot Manager on /dev/nvme0n1p1@/EFI/Microsoft/Boot/bootmgfw.efi
menuentry 'Windows Boot Manager (on /dev/nvme0n1p1)' --class windows --class os $menuentry_id_option 'osprober-efi-1A53-254F' {
	insmod part_gpt
	insmod fat
	search --no-floppy --fs-uuid --set=root 1A53-254F
	chainloader /EFI/Microsoft/Boot/bootmgfw.efi
Found Fedora 33 (Workstation Edition) on /dev/nvme0n1p6

# Other OS found, undo autohiding of menu unless menu_auto_hide=2
if [ "${orig_timeout_style}" -a "${menu_auto_hide}" != "2" ]; then
  set timeout_style=${orig_timeout_style}
  set timeout=${orig_timeout}
### END /etc/grub.d/30_os-prober ###

### BEGIN /etc/grub.d/30_uefi-firmware ###
Adding boot menu entry for UEFI Firmware Settings ...
if [ "$grub_platform" = "efi" ]; then
	menuentry 'UEFI Firmware Settings' $menuentry_id_option 'uefi-firmware' {
### END /etc/grub.d/30_uefi-firmware ###

### BEGIN /etc/grub.d/35_fwupd ###
### END /etc/grub.d/35_fwupd ###

### BEGIN /etc/grub.d/40_custom ###
# This file provides an easy way to add custom menu entries.  Simply type the
# menu entries you want to add after this comment.  Be careful not to change
# the 'exec tail' line above.
### END /etc/grub.d/40_custom ###

### BEGIN /etc/grub.d/41_custom ###
if [ -f  ${config_directory}/custom.cfg ]; then
  source ${config_directory}/custom.cfg
elif [ -z "${config_directory}" -a -f  $prefix/custom.cfg ]; then
  source $prefix/custom.cfg
### END /etc/grub.d/41_custom ###

sry. for the unformatted message chunk, but every time i try to format a text section with fixed type markdown directives, the whole post/reply gets detected as spam and will be hidden

No problem, just do not post whole config files … especially not as a newbie :slight_smile:

We have a topic how to fix that … just give me a moment to find it.
I remember that @computersavvy made a nice howto in a request.

sorry @christiansam , I was trying to help you with formatting but after saving your text, it apparently got detected as spam again, and I don’t have an option to restore. Apologies for kicking the text

please help @hhlp @moderators

okay, grub2-mkconfig seems to be able to detect my previous f33 (root?)-volume/-partition. is it safe to persist it with this command: “grub2-mkconfig -o /boot/grub2/grub.cfg”?

i’m asking because

  • i don’t want to mess up my uefi settings in general and in specific, i don’t want risk to loose my current windows 10 and f37 boot entries.
  • i don’t know if further/future dnf kernel updates will preserve such a manually added/trigger grub2-entry (regarding if i do run “grub2-mkconfig -o /boot/grub2/grub.cfg”)

as stated in the post before: the still-existing f33 partion/volumes seem to get detected by grub2-mkconfig -o … but i’m not sure if this results in a actually created f33 grub/boot entry:

### BEGIN /etc/grub.d/30_os-prober ###
grub2-probe: error: cannot find a GRUB drive for /dev/sda3.  Check your device.map.
Found Windows Boot Manager on /dev/nvme0n1p1@/EFI/Microsoft/Boot/bootmgfw.efi
menuentry 'Windows Boot Manager (on /dev/nvme0n1p1)' --class windows --class os $menuentry_id_option 'osprober-efi-1A53-254F' {
	insmod part_gpt
	insmod fat
	search --no-floppy --fs-uuid --set=root 1A53-254F
	chainloader /EFI/Microsoft/Boot/bootmgfw.efi
Found Fedora 33 (Workstation Edition) on /dev/nvme0n1p6

# Other OS found, undo autohiding of menu unless menu_auto_hide=2
if [ "${orig_timeout_style}" -a "${menu_auto_hide}" != "2" ]; then
  set timeout_style=${orig_timeout_style}
  set timeout=${orig_timeout}
### END /etc/grub.d/30_os-prober ###

### BEGIN /etc/grub.d/30_uefi-firmware ###
Adding boot menu entry for UEFI Firmware Settings ...
if [ "$grub_platform" = "efi" ]; then
	menuentry 'UEFI Firmware Settings' $menuentry_id_option 'uefi-firmware' {
### END /etc/grub.d/30_uefi-firmware ###

It should be safe. But making a backup copy of that file with, e.g., cp /boot/grub2/grub.cfg /boot/grub2/grub.cfg.bak would also be a good idea.

The grub2-mkconfig -o /boot/grub2/grub.cfg will only touch that config file. It will not affect any UEFI settings. If Windows was listed in the output when you omitted -o /boot/grub2/grub.cfg then that boot entry should still be there (but I’d still make a backup of that file just in case).

I think they will. But I’m not 100% certain either.

Note sure why the posts here are being marked as spam by the bots, have restored them all now. Let’s hope it doesn’t happen again.

[root@sampc5 grub2]# grub2-mkconfig -o /boot/grub2/grub.cfg
Generating grub configuration file ...
grub2-probe: error: cannot find a GRUB drive for /dev/sda3.  Check your device.map.
Found Windows Boot Manager on /dev/nvme0n1p1@/EFI/Microsoft/Boot/bootmgfw.efi
Found Fedora 33 (Workstation Edition) on /dev/nvme0n1p6
Adding boot menu entry for UEFI Firmware Settings ...
[root@sampc5 grub2]# pwd

[root@sampc5 grub2]# ll
insgesamt 24
drwx------. 2 root root 4096  5. Nov 10:03 fonts
-rw-------. 1 root root 6863 15. Nov 23:02 grub.cfg
-rw-------. 1 root root 6863 15. Nov 23:02 grub.cfg_org
-rw-------. 1 root root 1024 15. Nov 23:03 grubenv

grub.cfg_org is the backup of the file which was created in the f37 installation process

[root@sampc5 grub2]# diff grub.cfg grub.cfg_org
[root@sampc5 grub2]#

I performed a reboot, no f33 boot-entry showed up. Same situation as before:

  • f37
  • f37-rescue
  • windows
  • UEFI settings (maybe a lenovo specific entry, idk)

All of the above stated boot-entries are functional/working. Sadly the previous f33 boot/grub-entry - along with eventually needed resources (f33 kernel-/initrd images) for such a configuration - was neither migrated nor is referenced from the previous f33 boot-parition, when f37 anaconda created the new f37 boot/grub configuration resp. boot-partition.

according to Changes/UnifyGrubConfig - Fedora Project Wiki there are several
other locations regarding grub2 on uefi systems.

i’m not aware which one i am supposed to provide for "grub2-mkconfig -o “<???>”

[root@sampc5 etc]# find /boot/
/boot/efi/System Volume Information
/boot/efi/System Volume Information/ClientRecoveryPasswordRotation
/boot/efi/System Volume Information/AadRecoveryPasswordDelete
/boot/efi/System Volume Information/IndexerVolumeGuid
/boot/efi/System Volume Information/WPSettings.dat


1 Like

I suspect the problem is that both fedora 33 and fedora 37 use the /boot/efi/EFI/fedora/grub.cfg file but the purpose of that file is totally different in those two releases. Also if the two different releases each has its own /boot partition it would get very complex to have both functional.

Fedora 33 actually uses its main grub.cfg file as the one noted above, but fedora 37 only uses that one as a pointer stub file that redirects grub to the file at /boot/grub2/grub.cfg.

The content of the main grub.cfg file is radically different in those two releases as well. (the /boot/efi/EFI/fedora/grub.cfg in fedora 33 as compared to the /boot/grub2/grub.cfg in fedora 37)

I don’t know how the changes to grub and the file locations and content could be reconciled to allow both to coexist and boot gracefully while using a single efi partition.

1 Like

first: thank you all for the already provided analysis and guidance.

would the following be a feasible solution for my scenario?

if you tell me the relevant files involved, i could manually copy the required f33 (e.g. kernel/initrd boot-images/-resources) files from the old f33 boot-partition to the new f37 boot-partion. this is the content of the previous, still existing, f33 boot-partition:

[root@sampc5 ~]# find /run/media/christian/2e484fcb-6306-46c5-a7b6-b7ee2d39553d

if you tell me which configuration to use, i could possible utilize one of the grub hooks (e.g. 40_custom file located in the /etc/grub.d/) and manually insert the required parameters, so following calls of “grub2-mkconfig -o /boot/grub2/grub.cfg” would presumably create the required f33 boot-entries for usage in the current f37 environement.

Following - afaik - might be the relevant part of my previous f33 boot/grub configuration:

[root@sampc5 ~]# cat /run/media/christian/2e484fcb-6306-46c5-a7b6-b7ee2d39553d/loader/entries/b56092016dbb4086bfdf8b9dac4a3e10-5.13.19-100.fc33.x86_64.conf
title Fedora (5.13.19-100.fc33.x86_64) 33 (Workstation Edition)
version 5.13.19-100.fc33.x86_64
linux /vmlinuz-5.13.19-100.fc33.x86_64
initrd /initramfs-5.13.19-100.fc33.x86_64.img
options root=UUID=41ab391f-6b8b-4add-b132-2824de0c0c25 ro rootflags=subvol=root rhgb quiet
grub_users $grub_users
grub_arg --unrestricted
grub_class kernel

If such an approach does not work, could you provide me as a workaround instructions how to get my previous f33 environment running in some other form? Also a non-presistent, manual way, e.g. via the interactive grub2 recovery during boot-up, would be appreciated. In general i do plan to move to f37, but to ease migration of my current applications/services located in f33, i need a way to get f33 started.

current status: i did a quick tryout of the above describe approach and it worked:

  • at least in terms of my specfic circumstances,
  • and supposedly, a such created f33 grub-entry might be wiped with the next run of “grub2-mkconfig -o …” e.g. kernel updates

anyway, here is what i did:

From a booted f37 environment and with the previous f33 boot-partition accesable/mounted (/run/media…) i performed the following three operations:

cp /run/media/christian/2e484fcb-6306-46c5-a7b6-b7ee2d39553d/vmlinuz-5.13.19-100.fc33.x86_64 /boot/
cp /run/media/christian/2e484fcb-6306-46c5-a7b6-b7ee2d39553d/initramfs-5.13.19-100.fc33.x86_64.img /boot/
cp /run/media/christian/2e484fcb-6306-46c5-a7b6-b7ee2d39553d/loader/entries/b56092016dbb4086bfdf8b9dac4a3e10-5.13.19-100.fc33.x86_64.conf /boot/loader/entries/

I didn’t call any grub-* utilities like grub2-mkconfig afterwards - I just rebooted and a f33 boot-entry was present which i booted into:

[root@localhost boot]# cat /etc/redhat-release 
Fedora release 33 (Thirty Three)

[root@localhost boot]# lsblk
zram0       252:0    0   3,7G  0 disk [SWAP]
nvme0n1     259:0    0 238,5G  0 disk 
├─nvme0n1p1 259:1    0   260M  0 part /boot/efi
├─nvme0n1p2 259:2    0    16M  0 part 
├─nvme0n1p3 259:3    0  42,4G  0 part 
├─nvme0n1p4 259:4    0  1000M  0 part 
├─nvme0n1p5 259:5    0     1G  0 part /boot
├─nvme0n1p6 259:6    0 117,7G  0 part /home
├─nvme0n1p7 259:7    0     1G  0 part 
└─nvme0n1p8 259:8    0  75,1G  0 part 

[root@localhost boot]# ll /boot/
insgesamt 245276
-rw-r--r--. 1 root root   231170 25. Mär 2021  config-5.11.10-200.fc33.x86_64
-rw-r--r--. 1 root root   231195 16. Apr 2021  config-5.11.15-200.fc33.x86_64
-rw-r--r--. 1 root root   234583 18. Sep 2021  config-5.13.19-100.fc33.x86_64
drwx------. 7 root root     4096  1. Jän 1970  efi
-rw-r--r--. 1 root root   155544 29. Jul 2020  elf-memtest86+-5.31
drwxr-xr-x. 2 root root     4096 20. Okt 2020  extlinux
drwx------. 3 root root     4096 12. Apr 2021  grub2
-rw-------. 1 root root 89483912 15. Dez 2020  initramfs-0-rescue-b56092016dbb4086bfdf8b9dac4a3e10.img
-rw-------. 1 root root 32507750 27. Mär 2021  initramfs-5.11.10-200.fc33.x86_64.img
-rw-------. 1 root root 32507777 26. Apr 2021  initramfs-5.11.15-200.fc33.x86_64.img
-rw-------. 1 root root 34772567  2. Okt 2021  initramfs-5.13.19-100.fc33.x86_64.img
drwxr-xr-x. 3 root root     4096 15. Dez 2020  loader
drwx------. 2 root root    16384 15. Dez 2020  lost+found
-rw-r--r--. 1 root root   153868 29. Jul 2020  memtest86+-5.31
-rw-------. 1 root root  5641194 25. Mär 2021  System.map-5.11.10-200.fc33.x86_64
-rw-------. 1 root root  5642862 16. Apr 2021  System.map-5.11.15-200.fc33.x86_64
-rw-------. 1 root root  5775961 18. Sep 2021  System.map-5.13.19-100.fc33.x86_64
-rwxr-xr-x. 1 root root 11698160 15. Dez 2020  vmlinuz-0-rescue-b56092016dbb4086bfdf8b9dac4a3e10
-rwxr-xr-x. 1 root root 10598192 25. Mär 2021  vmlinuz-5.11.10-200.fc33.x86_64
-rwxr-xr-x. 1 root root 10593712 16. Apr 2021  vmlinuz-5.11.15-200.fc33.x86_64
-rwxr-xr-x. 1 root root 10868496 18. Sep 2021  vmlinuz-5.13.19-100.fc33.x86_64
[root@localhost boot]# ll /boot/loader/entries/
insgesamt 16
-rw-r--r--. 1 root root 410 15. Dez 2020  b56092016dbb4086bfdf8b9dac4a3e10-0-rescue.conf
-rw-r--r--. 1 root root 337 27. Mär 2021  b56092016dbb4086bfdf8b9dac4a3e10-5.11.10-200.fc33.x86_64.conf
-rw-r--r--. 1 root root 337 26. Apr 2021  b56092016dbb4086bfdf8b9dac4a3e10-5.11.15-200.fc33.x86_64.conf
-rw-r--r--. 1 root root 337  2. Okt 2021  b56092016dbb4086bfdf8b9dac4a3e10-5.13.19-100.fc33.x86_64.conf
[root@localhost boot]# 

See this as a workaround/POC, i guess a more sustainable scenario involes utilizing grub2 mechanisms to prevent overwriting such a ad-hoc generated grub/boot configuration. Maybe someone with proper knowledge regearding grub and fedora could provided a more lasting solution/instructions.

I think there may be a few other files that could be necessary for long term use, such as
the matching symvers, System-map, and config files for that kernel.
You also probably should modify the /etc/fstab file on the fedora 33 install to mount the different /boot partition.

Lastly, it seems rather critical to avoid damaging /boot/efi/EFI/fedora/grub.cfg that you ensure no kernel or grub updates are performed on fedora 33 with such a blended system.

Other than these few comments I would congratulate you on figuring how to make it work to boot both F33 and F37 on the same drive.


I do not know if or how a kernel update on f37 may impact the f33 kernel. Since dnf normally only keeps 3 kernels it seems probable that any update may remove the f33 kernel so it seems likely that you would have to always carefully exclude the f33 kernel from removal (and never allow the offline updates or gnome software updates to be done).