EFI updates, /var cleanup and gnome-shell integration

Project Discussion
1

Hi everyone!
I finally got some time to give Silverblue a test as a daily driver machine, and of course there are some doubts I have.

  1. EFI partition updates. So, I installed SB 30, and everytime I boot, for a second an error message from GRUB appears before the drive password prompt (It disappears way too fast for me to read it). Since one of the key features of SB is that even if an update breaks the system you can always go into GRUB and load the previous state of the OS… How does Silverblue handle EFI partition updates? Can it even update the EFI to fix this error message? But at the same time, what if there is a problem with the latest GRUB update? Is the only way to update the EFI formatting with a new version? (This would be ridiculous because one of the key points of SB is the rebasing)

  2. So whatever is under /var, is the stateful installation, everything outside this dir is the pure and clean OS image, if someday I wish to do a whole cleanup by whatever reason, I guess that deleting /var contents and restarting would give me the welcome prompt and would have a new clean system regarding /var or would that break the system?

  3. Couldn’t find any info regarding integration of Gnome Weather (Which doesn’t even match the system language) with gnome-shell. I actually miss this feature.

Thanks in advance!

2

  1. I’m going to guess the error message you’re getting is 1699761 – 'error: ../../grub-core/fs/fat.c:447:not a FAT filesystem' displayed briefly during boot . It’s non-critical and just a bug. I’m not sure if grub can be updated yet, given the offline deployment can’t see /boot/efi.

  2. In theory it should work, systemd-tmpfiles should re-recreate the needed folders/files in there on the next boot.

  3. See Weather and Clocks integration do no work with sandboxed apps (#1158) · Issues · GNOME / gnome-shell · GitLab

1 Like
3

For the first thing I did the manual copying they comment at the end and that seems to have fixed it, though I don’t get why /boot is not read-only too.

That seems nice. Could even provide some sort of “System Defaults” restoration options on Gnome Settings that would just wipe that directory (Now that I think of it, what about /etc?)

Nice to see there are some ideas around it!

Checking /etc, found this:

Captura%20de%20pantalla%20de%202019-07-01%2017-44-48
Captura%20de%20pantalla%20de%202019-07-01%2017-44-48988×43 10.2 KB

Is this normal?

4

image
image1361×109 19 KB

On my machine.