#1

I did a rebase to try out SB30 yesterday and it went well except I am getting an error message during boot.
Error /EFI/fedora/x86_64-efi/increment.mod file not found
I can login and use the system without any problem. I did some checking about the error and it looks like the new grub.cfg file added a new line “insmod increment” that was not there in the old config and it may be the cause for this error. I don’t see any other module files in the path to this missing module, so I think the path may be wrong. Where are the grub modules loaded from?
Also, I do not get the grub menu showing anymore so I cannot rollback to my SB29 instance. I think that is probably related to this error message.

#2

Hello, and welcome to the forum! Sorry it is for a problem you are having with Silverblue. The BLS changed the layout a bit for grub. If you look in /boot/loader/entries/ you’ll find .conf files which are actually your menu entries for the grub menu you see at boot. These files are named ostree-1-fedora-workstation.conf, and ostree-2-fedora-workstation.conf normally. If you don’t have any there you would get no entry. Here is the results of cat on one of mine

Screenshot%20from%202019-03-31%2008-55-59
Screenshot from 2019-03-31 08-55-59.png1356×158 29.5 KB

My initrd is here initrd /ostree/fedora-workstation-5b43ecdd038eb5389d7c2967f9d90f0e1f496c07a63de4e8bc642548c016bda1/initramfs-5.0.0-300.fc30.x86_64.img
and my kernel is here linux /ostree/fedora-workstation-5b43ecdd038eb5389d7c2967f9d90f0e1f496c07a63de4e8bc642548c016bda1/vmlinuz-5.0.0-300.fc30.x86_64
You can see that rpm-ostree uses the directory /ostree/fedora-worstation-ID as the name of where it stores these files for that particular commit. I’ll do some digging into possible commands to use to fix entries, I think grubby has something.
[Edit]: Just poking around my /boot I notice the initrd image for my old F29SB is sitting there.

#3

So I found there is a module file at
/usr/lib/grub/i386-pc/increment.mod
but I am not sure if this is the correct file or not. It looks like these are for 32-bit system.

#4

Just out of curiosity, have you tried to do a cleanup on rpm-ostree with rpm-ostree cleanup -m? this should get your metadata in line.

#5

Yes, I tried that just a little while ago. I saw that in the other discussion about forbidden package replacement. It seems like I may be missing the package for grub2-efi-modules. When I try to install it I get this…

[root@mustang lib]# rpm-ostree install grub2-efi-modules
Checking out tree d8acade… done
Enabled rpm-md repositories: jdoss-atomic-wireguard updates-testing updates fedora
rpm-md repo ‘jdoss-atomic-wireguard’ (cached); generated: 2019-03-12T12:28:30Z
rpm-md repo ‘updates-testing’ (cached); generated: 2019-03-31T01:01:33Z
rpm-md repo ‘updates’ (cached); generated: 2018-02-20T19:18:14Z
rpm-md repo ‘fedora’ (cached); generated: 2019-03-31T01:35:52Z
Importing rpm-md… done
⠁ Resolving dependencies…
Forbidden base package replacements:
grub2-tools 1:2.02-72.fc30 -> 1:2.02-75.fc30 (updates-testing)
grub2-efi-x64 1:2.02-72.fc30 -> 1:2.02-75.fc30 (updates-testing)
grub2-common 1:2.02-72.fc30 -> 1:2.02-75.fc30 (updates-testing)
grub2-tools-extra 1:2.02-72.fc30 -> 1:2.02-75.fc30 (updates-testing)
grub2-pc-modules 1:2.02-72.fc30 -> 1:2.02-75.fc30 (updates-testing)
grub2-tools-minimal 1:2.02-72.fc30 -> 1:2.02-75.fc30 (updates-testing)
grub2-pc 1:2.02-72.fc30 -> 1:2.02-75.fc30 (updates-testing)
This likely means that some of your layered packages have requirements on newer or older versions of some base packages. `rpm-ostree cleanupResolving dependencies… done
error: Some base packages would be replaced

#6

You definitely have them. That message is warning of the downgrade 1:2.02-72.fc30 replacing 1:2.02-75.fc30 (updates-testing) as well as the other downgrades. What does the output of rpm-ostree status report?

#7

[root@mustang lib]# rpm-ostree status
State: idle
AutomaticUpdates: disabled
Deployments:
● ostree://fedora-workstation:fedora/30/x86_64/silverblue
Version: 30.20190330.n.3 (2019-03-31T00:54:53Z)
Commit: d8acadecba2e4e62599328944f1ce7fd67afab193d7cf7624dac411eed13cd29
GPGSignature: Valid signature by F1D8EC98F241AAF20DF69420EF3C111FCFC659B9

ostree://fedora-workstation:fedora/30/x86_64/silverblue
Version: 30.20190330.n.3 (2019-03-31T00:54:53Z)
BaseCommit: d8acadecba2e4e62599328944f1ce7fd67afab193d7cf7624dac411eed13cd29
GPGSignature: Valid signature by F1D8EC98F241AAF20DF69420EF3C111FCFC659B9
LayeredPackages: brasero gparted gstreamer1-plugins-ugly-free minicom mumble nano xsane
[root@mustang lib]# rpm-ostree db list d8acadecba2e4e62599328944f1ce7fd67afab193d7cf7624dac411eed13cd29 | grep grub2
grub2-common-1:2.02-72.fc30.noarch
grub2-efi-x64-1:2.02-72.fc30.x86_64
grub2-pc-1:2.02-72.fc30.x86_64
grub2-pc-modules-1:2.02-72.fc30.noarch
grub2-tools-1:2.02-72.fc30.x86_64
grub2-tools-extra-1:2.02-72.fc30.x86_64
grub2-tools-minimal-1:2.02-72.fc30.x86_64
ostree-grub2-2019.1-5.fc30.x86_64

This is what I currently have installed.

#8

It seems odd that the layered packages you have installed are not shown on your running commit but are on your previous commit. There is an ostree command that you run as sudo ostree admin cleanup which is supposed to delete unused tags and repository items. I haven’t used it before but I am assuming it is what lies behind rpm-ostree cleanup.

#9

Those layered packages were from my previous tree. I uninstalled them to see if that would allow me to get the grub2 modules but it made no difference. It seems that the grub2 module packages must be in the base ostree image and cannot be layered. I think that is why I am getting the message that they are forbidden base package replacements which makes sense if you think about it. So I guess I need to wait for a future update to the base that will include these modules. Should probable be soon I would think since release time is getting close.

#10

Yes they are a part of the base image and to use another version you would have to use rpm-ostree override with the replace command. I have done it for Podman and Buildah with previous commits, it proved problematic for me when it came time to reset them. Of course that is not to say it would for you. I’m curious why the effort to replace the grub2 modules? If you already have the layered packages removed just do a rpm-ostree reset -l and it should “remove all mutations”.

#11

Well, I still have the increment.mod file not found error on the bootup splash screen and still no grub menu items are showing. I was thinking the grub menu items not showing could be caused by this error. The error seems to indicate that it cannot find the grub2 increment.mod module file, so grub can’t load the module. I really don’t want to override base packages just for the reason that you stated that it can be unpredictable. I will wait for the SB developers to get the bootup process figured out and updated. Thanks for all you help though, I really appreciate your feedback.

#12

You’re welcome,
With the release of beta SB30 you can rebase to it and that will very likely solve your issues. I’m not sure what menu you’re referring to in this case with respect to bash menu.

#13

I meant to say the grub menu. Sorry for the confusion. I edited my previous post. BTW, I am using the EFI boot and not the traditional bios. Not sure how much testing has been done on EFI boot for SB yet.

#14

I think the grub menu not showing is because of this change that I was not aware of in Fedora 29. I guess they are bringing it to Silverblue 30 now too.

https://fedoraproject.org/wiki/Changes/HiddenGrubMenu

#15

The grub menu now will automatically disappear after I think only one second, so pretty fast, press any alphanumeric key at startup to get the menu to stay up. EFI bios and booting with it has been working on Fedora for some time, I think since F26 or F25, I’m not certain exactly. I don’t think being on silverblue is any different from the POV of grub, it still expects to see certain config files at certain locations. Aside from that, you can adjust the delay on the grub menu with … I’m sorry I can’t seem to find that info. Things are a bit in flux it would seem with how we can modify the grub configuration (on Fedora). You used to be able to change the length of time the menu stayed, I know I set mine for 10 seconds some time ago since I could never catch it at boot up. It is a grub environment variable if you are searching for it.

#16

Sorry to necro this thread, but I have this error message jumping up for ages and this is the only reference I can find. Did you manage to fix this?

#17

No, I still have this error. It has been there since I upgraded from Silverblue 29. I have not reinstalled my system since then, (why would I need to) so I don’t know if that would remove the error or not. I have learned to ignore it now, but it would be nice if someone had a solution to fix it without reinstall. I tried to look into it myself but I don’t know enough about the boot process.

#18

Looks like this problem is no longer present on my SB 31 system as of late. Don’t know what has changed but a recent update must have fixed it. But now I see the grub menu every time I boot, which was not the case before. I am going to rebase to SB 32 soon, so maybe I will try to find a way to hide the menu again. If anyone knows how to do that, please reply.