Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.
Sign upgrubby fatal error occurred on fedora-28-minimal #4074
Comments
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
Aekez
Jul 13, 2018
Two clues here make me curious, you mention the use of -y, and also grubby is currently included in the "dnf autoremove". Did you by any chance run -y on autoremove at any point of time? or force the update/upgrade?
Last metadata expiration check: 0:05:42 ago on Fri Jul 13 18:08:58 2018.
Dependencies resolved.
================================================================================
Package Arch Version Repository Size
================================================================================
Removing:
gnupg x86_64 1.4.23-1.fc28 @updates 5.4 M
grub2-tools-efi x86_64 1:2.02-38.fc28 @updates 1.9 M
grubby x86_64 8.40-11.fc28 @fedora 123 k
libusb x86_64 1:0.1.5-12.fc28 @fedora 67 k
Transaction Summary
================================================================================
Remove 4 Packages
Freed space: 7.5 M
Is this ok [y/N]:
Could you try make a new copy of the minimal template, and try without autoremoval or force replacing updates?
Aekez
commented
Jul 13, 2018
•
edited
Edited 1 time
-
Aekez
edited Jul 13, 2018 (most recent)
-
Aekez
created Jul 13, 2018
edited
-
Jul 13, 2018 (most recent) -
Jul 13, 2018
|
Two clues here make me curious, you mention the use of -y, and also grubby is currently included in the "dnf autoremove". Did you by any chance run -y on autoremove at any point of time? or force the update/upgrade? Could you try make a new copy of the minimal template, and try without autoremoval or force replacing updates? |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
Polygonbugs
Jul 14, 2018
Yes, I always use "sudo dnf check-update" and "sudo dnf upgrade -y && sudo dnf autoremove -y && sudo dnf clean all && sudo fstrim -v /" to upgrade template. It seems like I accidentally remove grubby by using autoremove. I'll try fresh minimal template later as you suggested.
Polygonbugs
commented
Jul 14, 2018
|
Yes, I always use "sudo dnf check-update" and "sudo dnf upgrade -y && sudo dnf autoremove -y && sudo dnf clean all && sudo fstrim -v /" to upgrade template. It seems like I accidentally remove grubby by using autoremove. I'll try fresh minimal template later as you suggested. |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
Polygonbugs
Jul 14, 2018
No, still I can see "grubby fatal error : unable to find suitable template" on first update when issuing [bash-4.4]# dnf update -y && dnf clean all from fresh fedora-28-minimal. I can't find other error yet.
Polygonbugs
commented
Jul 14, 2018
•
edited
Edited 2 times
-
Polygonbugs
edited Jul 14, 2018 (most recent)
-
Polygonbugs
edited Jul 14, 2018
-
Polygonbugs
created Jul 14, 2018
edited
-
Jul 14, 2018 (most recent) -
Jul 14, 2018 -
Jul 14, 2018
|
No, still I can see |
andrewdavidwong
added
bug
C: Fedora
labels
Jul 14, 2018
andrewdavidwong
added this to the Release 4.0 updates milestone
Jul 14, 2018
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
Aekez
Jul 14, 2018
ow, too bad. Maybe we can try something else to cast more light on the issue.
1) Did you download the newest template version? Which template version are you running? The thinking here is that my fedora-28-minimal doesn't get the grubby bug, so perhaps there is a version difference. You can see my version listed down below. Try compare it with your own version to see if there is a difference. Also this is the current same version that should be in the ITL Template repository atm, which can also be browsed here https://yum.qubes-os.org/r4.0/templates-itl/rpm/ so it's pretty likely you got this version as well if you just re-installed the template by freshly downloading it. But just to be sure, try compare the version.
[user@dom0 ~ ]$ rpm -qa qubes-template-fedora-28-minimal
qubes-template-fedora-28-minimal-4.0.0-201805212212.noarch
I wish I could quickly re-install the minimal template to try it again and see if I can encounter the same error as you do, since my template is already fully updated, so it won't serve well to try reproducing your steps.
2) Something else you can try is to compare your grubby version with my fedora-28-minimal grubby version (fully updated atm).
[user@fedora-28-minimal ~]$ rpm -qa grubby
grubby-8.40-11.fc28.x86_64
3) This one is a long-shot. But there may be a difference in running "sudo dnf update" and "dnf update" in the minimal template. Below is the lines I use in my autonomouse template update-script for comparison. I'm currently building the script, that's why it has both "-u root" and "sudo" redudancy, but this is what I used at the time when I was tweaking the script to minimal updates (and forgot to remove sudo), so it may be worth a try if you got time to try trial and errors.
Essentially it could be how you run the commands, try use these two in a script instead.
#!/bin/bash
### Executed from dom0, or alternatively run it from a VM with proper Qubes-RPC (Policies) adjustments.
qvm-run -u root fedora-28-minimal "xterm -e 'sudo dnf update --refresh'"
qvm-run -u root fedora-28-minimal "xterm -e 'sudo dnf upgrade'"
Also, this part might possibly be slightly off-topic, but while at it try notice how I skip the --clean option, and instead go fo the --refresh option, and I only use it once at the first step. This also removes any risk for repository changes between your two commands, so only running it once is not only faster saving you time, it's also safer, imho.
While it turns out this isn't the case for your grubby, I would still recommend you to avoid using autoremoval in general, especially with the -y argument. There are multiple searchable stories on the internet of people loosing their system/app stability, or even being fully unable to boot, breaking their system, after they ran autoremove. It's probably less harmful to just let them stay, if they're not being used then they probably won't do much else than taking up disk space anyway, and usually it's minor disk space. I'm no expert on this though, however I do believe its much safer to just ignore them, rather than using autoremove. Alternatively you could also try look up the package dependencies yourself.
Aekez
commented
Jul 14, 2018
•
edited
Edited 3 times
-
Aekez
edited Jul 14, 2018 (most recent)
-
Aekez
edited Jul 14, 2018
-
Aekez
edited Jul 14, 2018
-
Aekez
created Jul 14, 2018
edited
-
Jul 14, 2018 (most recent) -
Jul 14, 2018 -
Jul 14, 2018 -
Jul 14, 2018
|
ow, too bad. Maybe we can try something else to cast more light on the issue. 1) Did you download the newest template version? Which template version are you running? The thinking here is that my fedora-28-minimal doesn't get the grubby bug, so perhaps there is a version difference. You can see my version listed down below. Try compare it with your own version to see if there is a difference. Also this is the current same version that should be in the ITL Template repository atm, which can also be browsed here https://yum.qubes-os.org/r4.0/templates-itl/rpm/ so it's pretty likely you got this version as well if you just re-installed the template by freshly downloading it. But just to be sure, try compare the version. I wish I could quickly re-install the minimal template to try it again and see if I can encounter the same error as you do, since my template is already fully updated, so it won't serve well to try reproducing your steps. 2) Something else you can try is to compare your grubby version with my fedora-28-minimal grubby version (fully updated atm). 3) This one is a long-shot. But there may be a difference in running " Essentially it could be how you run the commands, try use these two in a script instead. Also, this part might possibly be slightly off-topic, but while at it try notice how I skip the --clean option, and instead go fo the --refresh option, and I only use it once at the first step. This also removes any risk for repository changes between your two commands, so only running it once is not only faster saving you time, it's also safer, imho. While it turns out this isn't the case for your grubby, I would still recommend you to avoid using autoremoval in general, especially with the -y argument. There are multiple searchable stories on the internet of people loosing their system/app stability, or even being fully unable to boot, breaking their system, after they ran autoremove. It's probably less harmful to just let them stay, if they're not being used then they probably won't do much else than taking up disk space anyway, and usually it's minor disk space. I'm no expert on this though, however I do believe its much safer to just ignore them, rather than using autoremove. Alternatively you could also try look up the package dependencies yourself. |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
marmarek
Jul 15, 2018
Member
Can you simply remove grubby? As seen above dnf autoremove would do that (which means it isn't required by anything installed). The grubby+grub2 idea is utterly broken, it tries to edit grub2.cfg file, which is a generated file and changes there would be overridden anyway. It isn't needed to install a kernel, nor configure grub (grub comes with its own configuration generator - grub2-mkconfig).
|
Can you simply remove grubby? As seen above |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
Polygonbugs
Jul 15, 2018
@Aekez
Here are answer of your questions 1),2),3)
(1)
[user@dom0 ~ ]$ rpm -qa qubes-template-fedora-28-minimal
qubes-template-fedora-28-minimal-4.0.0-2018052112212.noarch
I think we are using identical version of fedora-28-minimal.
(2)
[user@fedora-28-minimal-clone-1 ~]$ rpm -qa grubby
grubby-8.40-11.fc28.x86_64
Same as well
(3)
Sorry, I don't understand what is difference between two commands, qvm-run -u root fedora-28-minimal "xterm -e 'sudo dnf update --refresh'" and qvm-run -u root fedora-28-minimal "xterm -e 'sudo dnf upgrade'". Also I don't understand the difference between adding sudo next to the commands vs commands issued by root account.
@marmarek ,
Grubby successfully removed (as well as grub2-tools-efi) by autoremove command. Let's see if next update give error messages
Polygonbugs
commented
Jul 15, 2018
|
@Aekez I think we are using identical version of fedora-28-minimal. (2) Same as well (3) @marmarek , |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
Aekez
Jul 15, 2018
Grubby successfully removed (as well as grub2-tools-efi) by autoremove command. Let's see if next update give error messages
Marek seem to have nailed it, so that definitely sounds like a plan. It might only happen the next time you get a kernel update though? So it'll probably be whenever fedora puts out a new kernel version.
Sorry, I don't understand what is difference between two commands, qvm-run -u root fedora-28-minimal "xterm -e 'sudo dnf update --refresh'" and qvm-run -u root fedora-28-minimal "xterm -e 'sudo dnf upgrade'". Also I don't understand the difference between adding sudo next to the commands vs commands issued by root account.
I'm more than happy to help answer and discuss this as I also find it interesting and I'm happy to help too, but it might go off-topic here. If you would like to discuss running these commands, i.e. in a shell or even a more advanced bash script to make updating easier, then your more than welcome to open an issue over at the volunteer-run independent Qubes Community Collaboration (QCC) https://github.com/Qubes-Community/Contents/issues I'll continue the discussion with you there if you choose to open an issue.
So if you got everyday user questions the Qubes-user mailing list is best https://groups.google.com/forum/#!forum/qubes-users, but if you got questions or suggestions related to scripts, code or Qubes docs, which doesn't fit the official QubesOS GitHub development focus, then you can always open an issue to discuss it over at QCC which is more focused on the minor things and user experiences, with docs and code (typically scripts) :)
Aekez
commented
Jul 15, 2018
•
edited
Edited 1 time
-
Aekez
edited Jul 15, 2018 (most recent)
-
Aekez
created Jul 15, 2018
edited
-
Jul 15, 2018 (most recent) -
Jul 15, 2018
Marek seem to have nailed it, so that definitely sounds like a plan. It might only happen the next time you get a kernel update though? So it'll probably be whenever fedora puts out a new kernel version.
I'm more than happy to help answer and discuss this as I also find it interesting and I'm happy to help too, but it might go off-topic here. If you would like to discuss running these commands, i.e. in a shell or even a more advanced bash script to make updating easier, then your more than welcome to open an issue over at the volunteer-run independent Qubes Community Collaboration (QCC) https://github.com/Qubes-Community/Contents/issues I'll continue the discussion with you there if you choose to open an issue. So if you got everyday user questions the Qubes-user mailing list is best https://groups.google.com/forum/#!forum/qubes-users, but if you got questions or suggestions related to scripts, code or Qubes docs, which doesn't fit the official QubesOS GitHub development focus, then you can always open an issue to discuss it over at QCC which is more focused on the minor things and user experiences, with docs and code (typically scripts) :) |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
Polygonbugs
Jul 19, 2018
Now I can't find any issue after removing grubby. Kernel update (though actually not needed) doesn't give error message.
Polygonbugs
commented
Jul 19, 2018
|
Now I can't find any issue after removing grubby. Kernel update (though actually not needed) doesn't give error message. |
Polygonbugs commentedJul 13, 2018
Qubes OS version:
R4.0
Affected component(s):
grubby, kernel(?)
Steps to reproduce the behavior:
Expected behavior:
It shouldn't give any error message.
Actual behavior:
It gives following error messages.
grubby fatal error: unable to find a suitable template
grubby: doing this would leave no kernel entries. Not writing out new config.
warning: file /lib/modules/4.16.14-300.fc28.x86_64/updates: remove failed: No such file or directory
Additional Information
Here is more verbose information.