Description of problem: (Component might not be bootconf - that seemed the closest of choices) I upgraded from Fedora 29 to Fedora 30, but boot menu does not contain any F30 entries. System boots into F29. Version-Release number of selected component (if applicable): Fedora 30 How reproducible: I haven't been able to change boot menu. Tested several times. Steps to Reproduce: 1. Follow instructions to dnf upgrade from F29 to F30 2. Boot Actual results: 3. Observe boot menu does not contain any F30 entry 4. Observe that F29 (latest boot menu entry) does boot 5. Observe Gnome splash is that of F30 6. Observe all visible components have .fc29 file label Expected results: It should boot into F30 Additional info: system uses efi system has raid1 for /boot and for lvm pv Upgrades over the past years have avoided anaconda and used dnf mostly because of the raid disk configuration. /boot directory does contain initramfs, System-map, vmlinuz with fc30 in the file names. /boot/loader/entries includes ...fc30.x86_64.conf /etc/default/grub is: [root@hoho8 default]# cat grub GRUB_TIMEOUT=5 GRUB_DISTRIBUTOR="$(sed 's, release .*$,,g' /etc/system-release)" GRUB_DEFAULT=saved GRUB_DISABLE_SUBMENU=true GRUB_TERMINAL_OUTPUT="console" GRUB_PRELOAD_MODULES="mdraid1x lvm" GRUB_CMDLINE_LINUX="rd.lvm.lv=fedora_hoho8/root rd.lvm.lv=fedora_hoho8/swap rhgb rd.lvm.lv=fedora_hoho8/home quiet rd.auto rd.md.waitclean=1" GRUB_DISABLE_RECOVERY="true" GRUB_ENABLE_BLSCFG=true ----- Have used grub2-switch-to-blscfg with no perceptible changes fc30 modules are on disk: [root@hoho8 modules]# ls 4.19.12-301.fc29.x86_64 5.0.16-200.fc29.x86_64 4.20.6-200.fc29.x86_64 5.0.16-300.fc30.x86_64
I saw a recommended fix in the Common_F30_bugs: grub> configfile /grub2/grub.cfg.rpmsave I don't have that file in /boot/grub2 (see below) [root@hoho8 grub2]# ls -l total 3 lrwxrwxrwx. 1 root root 25 May 15 04:58 grubenv -> ../efi/EFI/fedora/grubenv drwxr-xr-x. 3 root root 1024 May 9 2012 themes [root@hoho8 grub2]# pwd /boot/grub2 Also, note that the recommended command assumes that grub2 is in the / directory I am booting using efi
The Gnome Software app popped up and said I had 2 updates. I installed those updates, but there is no change to my system as described above. I still boot into FC29 - there has been no change to the boot menu.
There is more action on this subject at: https://bugzilla.redhat.com/show_bug.cgi?id=1652806 That bug report seems to be more centered on legacy systems not efi
Bob, did you use 'dnf system-upgrade' or did you use GNOME Software to initiate the upgrade? If you used dnf, did you follow each of these steps? https://docs.fedoraproject.org/en-US/quick-docs/dnf-system-upgrade/ What happens at step 5? That should reboot with a Fedora 29 kernel, and perform the system upgrade. Whether text boot or graphical boot, there should be a status message indicating percentage of upgrade. If this just reboots back to a login screen rather than upgrade status percent, then please attach the following file: $ sudo journalctl -b-1 -o short-monotonic > bug1711710-journal.txt That will dump journal contents from the previous boot, which should be the one for the failed upgrade following 'dnf system-upgrade reboot'
Also, can you please provide "/var/log/dnf.log" and the output of "dnf system-upgrade log --number=1"?
I haven't had the chance to do these tasks yet. Perhaps I will have time near the end of the week. Since Fedora rolled over to Version 31 yesterday, should I try to make the leap from 29/?? (that I am running now) directly to 31 instead of 30? Is F 31 fixed? I did use the dnf-upgrade scheme. Previously, with Anaconda, I was always fighting with Anaconda's reluctance to use Raid smoothly. The dnf upgrade path was much easier. I had been regularly upgrading Fedora (from version 4 ?). I had one system that lingered at version 9 for a few years, but then the OS was just too old and would not support better versions of Firefox and Dovecot. I now have 3 systems running on F 29. They do different things. 4 systems running Fedora Atomic 29. 2 more in the shipping box.
I am using UEFI boot. This may be different from your system.
Bob, I don't think anyone can answer the "is Fedora 31 fixed" because we don't understand what problem you're running into. I'd say it's an edge case of some kind because quite a lot of people use UEFI these days, including myself, and haven't run into upgrade failure. We need more information about what happens, in detail, after you run 'sudo dnf system-upgrade reboot' - especially if there is one reboot or two. If there's one reboot, we need $ sudo journalctl -b -o short-monotonic > bug1711710-journal.txt If there's two reboots, we need $ sudo journalctl -b-1 -o short-monotonic > bug1711710-journal.txt And additionally the two dnf logs requested by Pavla.
Do I initiate the reboots? Or do they just happen.. As I recall, on previous dnf upgrades, there was a period of time where the screen was almost black, but a line at the top left informed about percentage completion and the name of the module currently being updated. When completed there was an automatic reboot. With the new problem (not so new now ..), I don't recall this black screen period (about 40 minutes or so), and I don't recall whether I just decided that it was finished - and manually rebooted (waiting more than enough time..) I can see that you need more information here..
(In reply to Bob Gustafson from comment #9) > Do I initiate the reboots? Or do they just happen.. You have to initiate it with 'sudo dnf system-upgrade reboot' - if you didn't issue that command then there is no possible way an upgrade will be initiated. That was the point of my questions in comment 4: did you do *each* of those steps? What happens at step 5?
This message is a reminder that Fedora 29 is nearing its end of life. Fedora will stop maintaining and issuing updates for Fedora 29 on 2019-11-26. 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 Fedora 'version' of '29'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 29 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, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
Ok, here is some stuff Step 1 sudo dnf upgrade --refresh This is upgrading f29, which has been upgraded (to 29) a number of times. It has ended at: ... ... Skipped: chromium-libs-77.0.3865.120-1.fc30.x86_64 chromium-libs-media-77.0.3865.120-1.fc30.x86_64 Removed: kernel-5.2.18-200.fc30.x86_64 kernel-core-5.2.18-200.fc30.x86_64 kernel-modules-5.2.18-200.fc30.x86_64 Complete! [user1@hoho8 ~]$ date Sat 02 Nov 2019 12:56:32 PM CDT [user1@hoho8 ~]$ ===== sudo shutdown -r now I will send this to you, then actually reboot as shown.
[user1@hoho8 ~]$ sudo dnf install dnf-plugin-system-upgrade [sudo] password for user1: Last metadata expiration check: 0:30:07 ago on Sat 02 Nov 2019 12:36:09 PM CDT. Package python3-dnf-plugin-system-upgrade-4.0.7-2.fc30.noarch is already installed. Dependencies resolved. Nothing to do. Complete! [user1@hoho8 ~]$ date Sat 02 Nov 2019 01:07:12 PM CDT [user1@hoho8 ~]$ I'm going to do step 3 now. It shouldn't take too long because most of this stuff has already been downloaded ages ago. sudo dnf system-upgrade download --refresh --releasever=30 Just as a precaution, I will send this to you and then commence with the download.
Ok, now comes the problems. There seems to be a switch inside the procedure which says that it is Version 30, whereas it only boots to version 29 [sudo] password for user1: Before you continue ensure that your system is fully upgraded by running "dnf --refresh upgrade". Do you want to continue [y/N]: y Error: Need a --releasever greater than the current system version. [user1@hoho8 ~]$ What should I do now? I am definitely off the checklist, and in a never ending circle. I need to know how to convince the system that the 'current system version' is not 30, but 29. user1@hoho8 ~]$ date Sat 02 Nov 2019 01:14:23 PM CDT [user1@hoho8 ~]$ uname -a Linux hoho8.chidig.com 4.20.6-200.fc29.x86_64 #1 SMP Thu Jan 31 15:50:43 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux
Created attachment 1631939 [details] dnf system-upgrade log --number=1" This is what is in the log at this Errored Step 3. May not contain anything useful as the latest date is a couple of days ago.
It has been awhile.. To summarize, I did sudo dnf system-upgrade download --refresh --releasever=30 [sudo] password for user1: Before you continue ensure that your system is fully upgraded by running "dnf --refresh upgrade". Do you want to continue [y/N]: y Error: Need a --releasever greater than the current system version. ---- I cannot get beyond this point with the current list of instructions. This situation has existed for awhile.
It is strange that dnf thinks you have releasever 30, but in the system-upgrade log, there are only fc29 packages. Can you please also attach "/var/log/dnf.log", "/etc/os-release", "/etc/fedora-release" and the output of "dnf repoquery --whatprovides 'system-release'"?
Created attachment 1632604 [details] /var/log/dnf.log As requested. This is on system which is running F29, but upgrade system thinks it is already at version F30
Created attachment 1632605 [details] /etc/os-release As requested. This is on system which is running F29, but upgrade system thinks it is already at version F30
Created attachment 1632606 [details] /etc/fedora-release
Created attachment 1632608 [details] output of dnf repoquery --whatprovides 'system-release' > dnf-whatprovides-system-release.txt As requested. This is on system which is running F29, but upgrade system thinks it is already at version F30
Hopefully the cyclic problem will be in those uploads. I have been hesitant about making any modifications to any of the upload system files - don't know enough. -- After my failed attempt to upgrade this system over the weekend, I was able to successfully upgrade (29->30) (a much slower system). I will upgrade this slower system from 30->31 in the next few hours. I have another F29 system to be upgraded as well. All of these other system upgrades were queued up to be done after a successful upgrade of this fastest system, which hasn't happened yet. Good luck, and I hope there is some teachable moment in the data I sent.
From the dnf.log, it looks like there are some issues with loading repository metadata and some used metadata are as old as 25 April. This lead me to an idea that maybe you haven't downloaded any packages during the system-upgrade because none were available and when I tried to reproduce this issue (by disabling all repositories when doing system-upgrade), I got into a similar state, where my /etc/os-release says I have the newer release, but all packages are old and there is no boot menu entry for the newer release. Can you make sure that you actually have the Fedora repositories available with fresh metadata?
If you can confirm that the system-upgrade procedure can produce these mismatching files, I suggest to extend this procedure by adding further tests in order to avoid such situations, or at least to warn about occurred mismatching files. In any case, the upgrading user should be warned.
Sorry, I must have downloaded at least some packages, because when I tried disabling all repos and doing system-upgrade on a clean virtual machine, it just didn't do anything and stayed on the older Fedora version (which is expected). My point was, that if you have some broken repositories, then you can get into an inconsistent state. And since there is no list of repositories that are required for a system-upgrade, there is nothing dnf can check.
(In reply to Pavla Kratochvilova from comment #23) > Can you make sure that you actually have the Fedora > repositories available with fresh metadata? Whenever I attempted to do the upgrade again, if it was at least a few days since the last attempt, the initial dnf update --refresh would usually pick up a few new components (in F29?). There wasn't any indication that the repositories were disabled. I think 'something happened' to put my system into an inconsistent state, and the 'usual upgrade' commands don't reset the inconsistent state. If there was a dnf command that would reset the upgrade system to an un-upgraded F29 system, then I'm pretty sure that a redo of the usual upgrade command list would then continue and I would have a successful upgrade. It would mean reloading the whole F30 components, but that is largely automatic and low risk. Dinking with the state by hand to try to do this is risky - at least for me.
Having a dnf command that would reset the upgrade process, would be a useful QA tool too. If there are problems, it would be possible to re-do the upgrade with more logging, etc.
Here is my UEFI boot directory [root@hoho8 fedora]# pwd /boot/efi/EFI/fedora [root@hoho8 fedora]# ls -l total 6552 -rwx------. 1 root root 110 Oct 2 2018 BOOTX64.CSV drwx------. 2 root root 4096 Oct 10 02:35 fonts drwx------. 2 root root 4096 Aug 8 2018 fw -rwx------. 1 root root 65824 Aug 8 2018 fwupia32.efi -rwx------. 1 root root 77496 Aug 8 2018 fwupx64.efi -rwx------. 1 root root 7997 Feb 6 2019 grub.cfg -rwx------. 1 root root 1024 Nov 2 13:05 grubenv -rwx------. 1 root root 1739080 Oct 10 02:35 grubx64.efi -rwx------. 1 root root 1159560 Oct 2 2018 mmx64.efi -rwx------. 1 root root 1210776 Oct 2 2018 shim.efi -rwx------. 1 root root 1210776 Oct 2 2018 shimx64.efi -rwx------. 1 root root 1204496 Oct 2 2018 shimx64-fedora.efi [root@hoho8 fedora]# Note that the date of the grub.cfg file is before fc30 was released. Other files are even older This grub.cfg file was not rewritten with fc30 file names, so the fc30 files that were actually loaded (see next comment), cannot be accessed. Yes?
These are all my /boot files. Note lots of fc30 files [root@hoho8 boot]# pwd /boot [root@hoho8 boot]# ls -l total 174734 -rw-r--r--. 1 root root 201369 Jan 31 2019 config-4.20.6-200.fc29.x86_64 -rw-r--r--. 1 root root 213373 Oct 8 08:11 config-5.3.5-200.fc30.x86_64 -rw-r--r--. 1 root root 213315 Oct 18 15:38 config-5.3.7-200.fc30.x86_64 drwx------. 3 root root 16384 Dec 31 1969 efi drwxr-xr-x. 2 root root 3072 Oct 15 13:13 extlinux drwx------. 3 root root 1024 Oct 16 05:42 grub2 -rw-r--r--. 1 root root 50024741 May 22 2016 initramfs-0-rescue-32bda5ededd6423ba73a8f634ca1df54.img -rw-------. 1 root root 25310620 Feb 6 2019 initramfs-4.20.6-200.fc29.x86_64.img -rw-------. 1 root root 27840970 Oct 16 11:57 initramfs-5.3.5-200.fc30.x86_64.img -rw-------. 1 root root 27985537 Nov 2 12:47 initramfs-5.3.7-200.fc30.x86_64.img -rw-r--r--. 1 root root 560206 Jul 20 2016 initrd-plymouth.img drwxr-xr-x. 3 root root 1024 Oct 30 2018 loader drwx------. 2 root root 12288 May 22 2016 lost+found -rw-------. 1 root root 4111597 Jan 31 2019 System.map-4.20.6-200.fc29.x86_64 -rw-------. 1 root root 4426459 Oct 8 08:11 System.map-5.3.5-200.fc30.x86_64 -rw-------. 1 root root 4426726 Oct 18 15:38 System.map-5.3.7-200.fc30.x86_64 -rwxr-xr-x. 1 root root 6152680 May 22 2016 vmlinuz-0-rescue-32bda5ededd6423ba73a8f634ca1df54 -rwxr-xr-x. 1 root root 8749256 Jan 31 2019 vmlinuz-4.20.6-200.fc29.x86_64 -rwxr-xr-x. 1 root root 9323208 Oct 8 08:11 vmlinuz-5.3.5-200.fc30.x86_64 -rwxr-xr-x. 1 root root 9323208 Oct 18 15:39 vmlinuz-5.3.7-200.fc30.x86_64 [root@hoho8 boot]#
Could I manually edit/add the necessary fc30 file names into /boot/efi/EFI/fedora/grub.cfg and reboot into fc30? Or would the UEFI hash codes say no-no and crash my boot. Maybe get some UEFI folks to look at this. ?
Bob, you could use grub2-mkconfig to at least get those new kernels into the grub.cfg file. If that does not work manually you may ( or may not ) get some clue as to why it is not happening automatically. It would be one step nearer at least and should not have any unwanted side-effects. grub2-mkconfig -o /boot/efi/EFI/fedora/grub.cfg As for the release number blocking the upgrade command you could probably unlock that problem by editing the files you posted above , simply changing 30 back to 29. Since these are currently incorrect, I don't think that would do any harm , though bear in mind I'm a dumb end user, not a dev. /etc/fedora-release /etc/os-release it may be interesting to do one at a time to find out which one is being used but just say "n" when prompted to go ahead. I would not let it run with inconsistency here. FYI, when I run repoquery it returns all results as 29 , unlike you system. dnf repoquery --whatprovides 'system-release' Fedora Modular 29 - x86_64 29 kB/s | 24 kB 00:00 Fedora Modular 29 - x86_64 - Updates 30 kB/s | 21 kB 00:00 Fedora 29 - x86_64 - Updates 24 kB/s | 20 kB 00:00 Fedora 29 - x86_64 33 kB/s | 25 kB 00:00 fedora-release-0:29-1.noarch fedora-release-0:29-11.noarch generic-release-0:29-0.2.fc29.noarch generic-release-0:29-1.fc29.noarch It maybe informative to re-run that command after editing the release id files above.
My wish is very simple: Can anybody, with the necessary skill, write a little program or procedure which tests in deep the structure needed by GRUB2, issuing a diagnostic and some recommendations, without changing anything ? In other contexts, such little programs have been very useful.
(In reply to Bob Gustafson from comment #30) > Could I manually edit/add the necessary fc30 file names into > /boot/efi/EFI/fedora/grub.cfg and reboot into fc30? > > Or would the UEFI hash codes say no-no and crash my boot. > > Maybe get some UEFI folks to look at this. ? You mentioned that the system boots in to F29 but on traditional Fedora there's only one system installed. So you either have F29 packages installed in the rootfs or F30 packages (unless something went wrong and you have some packages from F29 and some packages from F30). And same for the kernels, these could be F29 or F30 packages. Although for the kernel is common to have packages from the previous Fedora release at the beginning of a system upgrade, since you always have 3 kernels (actually the value of installonly_limit in /etc/dnf/dnf.conf which is 3 by default). In other words, you may be booting using a kernel version that was installed by a F29 package but if your rootfs only contains F30 packages, then you are booting in to a F30 system and so dnf is correctly complaining that "--releasever greater than the current system version". About the F30 boot entries not being shown, can you please share your grub.cfg file? If I understood correctly you have F30 BLS snippets in /boot/loader/entries ?
(In reply to Federic from comment #31) > > FYI, when I run repoquery it returns all results as 29 , unlike you system. > For what its worth, I have both fc29 and fc30 repos.. [root@hoho8 boot]# repoquery | grep fc29 | wc Last metadata expiration check: 0:45:18 ago on Fri 08 Nov 2019 08:28:16 AM CST. 1293 1293 52108 [root@hoho8 boot]# repoquery | grep fc30 | wc Last metadata expiration check: 0:45:33 ago on Fri 08 Nov 2019 08:28:16 AM CST. 68702 68702 2778560 [root@hoho8 boot]#
(In reply to Federic from comment #31) > Bob, you could use grub2-mkconfig to at least get those new kernels into the > grub.cfg file. If that does not work manually you may ( or may not ) get > some clue as to why it is not happening automatically. It would be one step > nearer at least and should not have any unwanted side-effects. > > grub2-mkconfig -o /boot/efi/EFI/fedora/grub.cfg > > I don't think that would > do any harm , though bear in mind I'm a dumb end user, not a dev. > I'm also a dumb user. Doing the grub2-mkconfig on my efi files is a very appealing idea. I don't see any problems. However, paraphrasing Donald Rumsfeld, there are a lot of unknowns I don't know about when it comes to EFI booting. I wonder if there are any RedHat EFI folks who could put in a few cents worth here.. Is someone out there positive that it won't screw up my system? Perhaps an EFI dev?
(In reply to Claude Frantz from comment #32) > My wish is very simple: Can anybody, with the necessary skill, write a > little program or procedure which tests in deep the structure needed by > GRUB2, issuing a diagnostic and some recommendations, without changing > anything ? In other contexts, such little programs have been very useful. Yes, this would be a very useful tool. I like especially the part about 'without changing anything'.
to paraphrase Dirty Harry: a wise man knows his limitations ;) That is what grub2-mkconfig is intended for , google the command I suggested if you'd like confirmation.
bob, I fixed my problems by running dnf directly: dnf --releasever=30 distro-sync that gets everything up Fed30 and installs the kernel image in /boot then using grub2-mkconfig (BIOS version) to get the new kernel into grub. NB dnf downloads to /var/cache/dnf not /var/lib/dnf/system-update, so it will probably have to download everything again unless you symlink it or copy rpms across. I see you are very prudent fellow so I'd guess you prefer to let it run its course, rather than poking it .
Wow. I feel like the kid who has slowly inched out to the end of the springboard and finally took the dive!! All I did was do the grub2-mkconfig -o /boot/efi/EFI/fedora/grub.cfg No additional dnf runs. When I did a normal reboot (# shutdown -r now), it came up in fc30 and seems to be running ok. I was watching the boot carefully and it seemed to boot not the latest fc30 kernel in the boot directory, but the one before (if this has any meaning). I will now go through what should be a 'normal' upgrade to fc31 on this system. Thanks much for the hints and encouragement.
After this reboot resulting in the run of the "old" kernel, I suggest to run again grub-install and then grub2-mkconfig in the previously mentioned manner. If this was successful, then reboot again.
> Wow. I feel like the kid who has slowly inched out to the end of the springboard and finally took the dive!! Thanks Bob, that really made me chuckle. Glad I was able to help. Enjoy the water.
(In reply to Claude Frantz from comment #40) > After this reboot resulting in the run of the "old" kernel, I suggest to run > again grub-install and then grub2-mkconfig in the previously mentioned > manner. If this was successful, then reboot again. The grub2-install is only needed for legacy BIOS where the GRUB core.img isn't updated, for EFI is not necessary since the bootloader is updated by the grub2 RPM package when updating the EFI binary in the ESP.
Looks like the problem is solved. Closing.