Micro OS problems with snapper and grub plguin

zuo · March 29, 2024, 1:10pm

I try to upgrade the system but I have a problem with Snapper
The partial log is the following:

...
Server-side plugin '/usr/lib/snapper/plugins/grub' failed.
ERROR: `snapper create --from 43 --read-write --cleanup-algorithm number --print-number --description 'Snapshot Update of #43' --userdata 'transactional-update-in-progress=yes'` returned with error code 1.

after run sudo transactional-update up or any other commands that need snapper.
By running snapper --debug create --from 43 --read-write --cleanup-algorithm number --print-number --description 'Snapshot Update of #43' --userdata 'transactional-update-in-progress=yes' manually I obtain the following:

constructing ProxySnapper object
executing command
58
server: /usr/lib/snapper/plugins/grub --refresh exit-status: 1
Server-side plugin '/usr/lib/snapper/plugins/grub' failed.
exit-status: 1

So I try to run /usr/lib/snapper/plugins/grub --refresh but nothing is logged.

How can I fix that situation?

The full log is:

Checking for newer version.
New version found - updating...
Loading repository data...
Reading installed packages...
Retrieving: transactional-update-4.6.0-2.1.x86_64 (openSUSE-Tumbleweed-Oss)                                                                                                (1/1),  71.2 KiB    
Retrieving: transactional-update-4.6.0-2.1.x86_64.rpm ...................................................................................................................................[done]
(1/1) /tmp/transactional-update.jFBTf5rObb/repo-oss/x86_64/transactional-update-4.6.0-2.1.x86_64.rpm ....................................................................................[done]
Loading repository data...
Reading installed packages...
Retrieving: libtukit4-4.6.0-2.1.x86_64 (openSUSE-Tumbleweed-Oss)                                                                                                           (1/2), 165.7 KiB    
Retrieving: libtukit4-4.6.0-2.1.x86_64.rpm ................................................................................................................................[done (279.3 KiB/s)]
(1/2) /tmp/transactional-update.jFBTf5rObb/repo-oss/x86_64/libtukit4-4.6.0-2.1.x86_64.rpm ...............................................................................................[done]
Retrieving: tukit-4.6.0-2.1.x86_64 (openSUSE-Tumbleweed-Oss)                                                                                                               (2/2),  69.1 KiB    
Retrieving: tukit-4.6.0-2.1.x86_64.rpm ......................................................................................................................................[done (2.5 KiB/s)]
(2/2) /tmp/transactional-update.jFBTf5rObb/repo-oss/x86_64/tukit-4.6.0-2.1.x86_64.rpm ...................................................................................................[done]
transactional-update 4.6.0 started
Options: up
Separate /var detected.
2024-03-29 14:02:34 tukit 4.6.0 started
2024-03-29 14:02:34 Options: -c43 open 
Server-side plugin '/usr/lib/snapper/plugins/grub' failed.
ERROR: `snapper create --from 43 --read-write --cleanup-algorithm number --print-number --description 'Snapshot Update of #43' --userdata 'transactional-update-in-progress=yes'` returned with error code 1.
transactional-update finished

malcolmlewis · March 29, 2024, 1:14pm

@zuo just to confirm, your using transactional-update dup not up? Have you edited grub config at all, if you did did your run transactional-update grub.cfg afterwards and reboot?

Disk space ok?

arvidjaar · March 29, 2024, 5:06pm

It is not the full log. At least the command invocation is missing.

zuo · April 1, 2024, 4:52pm

I have the same errore with dup,up and grub.cfg

userwithoutname · April 15, 2024, 8:28pm

I seem to be experiencing the same situation with openSUSE Aeon.

To provide a bit of context:
A few days ago, right after the very first menu screen, where one can choose to either start Aeon normally or with advanced options or boot into UEFI instead, I got a black screen with a cryptic error message I cannot remember anymore. As I would love to provide some helpful logs here, is it safe to use “transactional-update status”, despite it being marked as experimental? And if so, how can I override the experimental flag?

Anyway, I managed to get into a “recovery mode” and there I ran “sudo transactional-update rollback last”. Apparently, it worked and Aeon booted successfully. I felt like a genius.

However, since then I’ve been missing update notifications about applications and new system images, that would otherwise pop up almost daily. I hoped to fix all of this with “sudo transactional-update dup” and Aeon tells me this:

##Checking for newer version.
transactional-update 4.6.0 started
Options: dup
Separate /var detected.
2024-04-15 21:03:20 tukit 4.6.0 started
2024-04-15 21:03:20 Options: -c12 open
Server-side plugin ‘/usr/lib/snapper/plugins/grub’ failed.
ERROR: snapper create --from 12 --read-write --cleanup-algorithm number --print-number --description 'Snapshot Update of #12' --userdata 'transactional-update-in-progress=yes' returned with error code 1.
transactional-update finished

Of course, GRUB itself appears to be installed:

S | Name | Summary | Type
—±------------------------±------------------------------------------------------±-----
i | grub2 | Bootloader with support for Linux, Multiboot and more | Paket
i | grub2-branding-openSUSE | openSUSE Tumbleweed branding for GRUB2 | Paket
i | grub2-i386-pc | Bootloader with support for Linux, Multiboot and more | Paket
i | grub2-snapper-plugin | Grub2’s snapper plugin | Paket
i+ | grub2-x86_64-efi | Bootloader with support for Linux, Multiboot and more | Paket

After that, I tried “sudo transactional-update bootloader” and “sudo transactional-update grub.cfg”, with and without the “–continue” option. Both results in the aforementioned error, only altering the third line “Options”, by replacing the “dup” parameter accordingly. The same goes for “sudo transactional-update pkg update grub”.

And trying “sudo transactional-update apply” leads to this output:

Checking for newer version.
transactional-update 4.6.0 started
Options: apply
Separate /var detected.

Using default snapshot 12 to replace running system…
Applying /usr…
Applying /etc…
Applying /boot…
Executing systemctl daemon-reexec…
Executing create_dirs_from_rpmdb…
Executing systemd-tmpfiles --create…
=> Applied default snapshot as new base for running system!
Running processes will not be restarted automatically.
transactional-update finished

If I then reboot, the challenges seem to persist. GNOME Software still lets me update Flatpaks manually, but I’d rather have the base system be updated as well. And of course, I’d love it all to happen automatically as it did before.

Is there a way of fixing the system without performing a fresh installation? And if so, how could it be done?

PS: Recently I set up some udev rules for a USB device to work, but there are no random RPMs installed from within “transactional-update”. I only use Flatpaks, a Tumbleweed Distrobox and one single AppImage from within that particular Distrobox instead. I presume the error was caused by some corrupted system update. For example: The energysaver / balanced / performance modes were removed from GNOME by such a previous update for whatever reason. I hope they’ll somehow magically re-appear, though.

Some rudimentary system information:

Systemdetailsbericht

Berichtdetails

Erstellungsdatum: 2024-04-15 21:22:02

Hardware-Informationen:

Hardware-Modell: TUXEDO TUXEDO Aura 14 Gen3

Speicher: 16,0 GiB

Prozessor: 12th Gen Intel® Core™ i5-1235U × 12

Grafik: Intel® Graphics (ADL GT2)

Festplattenkapazität: 1,0 TB

Software-Informationen:

Firmware-Version: 1.07.09RTR

Name des Betriebssystems: openSUSE MicroOS

Betriebssystem-Build: (null)

Betriebssystem-Typ: 64-bit

GNOME-Version: 46

Fenstermanager: Wayland

Kernel-Version: Linux 6.8.2-1-default

If I can help by providing any more detailed or specific logs to resolve this, please, let me know where to find them and I’ll provide. Thanks in advance!

malcolmlewis · April 15, 2024, 8:48pm

@userwithoutname asking the Aeon folks on Matrix, not had any issues here on HP Hardware…

malcolmlewis · April 15, 2024, 8:54pm

@userwithoutname Can you post your udev rules created?

arvidjaar · April 16, 2024, 4:13am

Yes - find out why snaper plugin fails. It is rather simple script that just edits files in /.snapshots. It does not do any logging, so I see as the only way to debug - change the current snapshot to read-write, edit /usr/lib/snapper/plugins/grub, add set -x on top to get execution trace, change the current snapshot back to read-only and try to create new snapshot. Post complete command invocation and its full output.

userwithoutname · April 16, 2024, 10:00am

@malcolmlewis Sure, here is the content of “/etc/udev/rules.d/51-trezor.rules”:

> # Trezor: The Original Hardware Wallet
> # https://trezor.io/
> #
> # Put this file into /etc/udev/rules.d
> #
> # If you are creating a distribution package,
> # put this into /usr/lib/udev/rules.d or /lib/udev/rules.d
> # depending on your distribution
> 
> # Trezor
> SUBSYSTEM=="usb", ATTR{idVendor}=="534c", ATTR{idProduct}=="0001", MODE="0660", GROUP="plugdev", TAG+="uaccess", TAG+="udev-acl", SYMLINK+="trezor%n"
> KERNEL=="hidraw*", ATTRS{idVendor}=="534c", ATTRS{idProduct}=="0001", MODE="0660", GROUP="plugdev", TAG+="uaccess", TAG+="udev-acl"
> 
> # Trezor v2
> SUBSYSTEM=="usb", ATTR{idVendor}=="1209", ATTR{idProduct}=="53c0", MODE="0660", GROUP="plugdev", TAG+="uaccess", TAG+="udev-acl", SYMLINK+="trezor%n"
> SUBSYSTEM=="usb", ATTR{idVendor}=="1209", ATTR{idProduct}=="53c1", MODE="0660", GROUP="plugdev", TAG+="uaccess", TAG+="udev-acl", SYMLINK+="trezor%n"
> KERNEL=="hidraw*", ATTRS{idVendor}=="1209", ATTRS{idProduct}=="53c1", MODE="0660", GROUP="plugdev", TAG+="uaccess", TAG+="udev-acl"

For the device (“Trezor Safe 3”) to work, I also set up a Tumbleweed Distrobox and therein installed at least some libnss packages, as well as fuse2. The AppImage (“Trezor Suite”) I use to interact with it, is marked as executable from within that particular container and from within the host. Also, I added a RPM (“Trezor Bridge”) to the container, downloaded from “Trezor Bridge”, see below.

> S  | Name        | Summary               | Type
> ---+-------------+-----------------------+--------
> i+ | trezor-udev | Udev rules for TREZOR | package

Since I added no RPMs to the host itself and the mentioned additions / changes actually work fine for a few weeks now, I hope none of the actions above are the cause for GRUB suddenly going crazy.

Despite that hope, I have to confess, that there are two more Tumbleweed containers to which I tried to do the same treatments before, representing the first iterations of my final solution for getting the Trezor Safe 3 to work. But these other containers are somehow broken (for whatever reason) and literally cannot be deleted (at least with the Distrobox commands I tried so far). So, they just exist, being inactive, doing absolutely nothing.

However, I hope all provided information is actually relevant and does neither overwhelm, nor distract from the actual cause. Therefore, if I digress too much in any way, please, let me know. ^^

userwithoutname · April 16, 2024, 1:42pm

@arvidjaar To set a snapshot to “read-write”, I presume you suggest cd /.snapshots && chmod +rw snapshotname, right?

I can find the “.snapshots” folder with cd / && ls -a.
But if trying to cd into it, bash tells me, that I lack permissions:
bash: cd: /.snapshots: Keine Berechtigung.

However, if I use sudo cd /.snapshots, bash throws the following lines at me:

sudo: cd: Befehl nicht gefunden sudo: »cd"« ist ein Shell-internes Kommando, das nicht direkt gestartet werden kann. sudo: Die Option »-s« kann zum Start einer privilegierten Shell verwendet werden. sudo: Die Option »-D« kann zum Start des Programms im angegebenen Verzeichnis verwendet werden.

Do I have to use rescue mode for this to work or perhaps entirely different commands? Thanks again.

arvidjaar · April 16, 2024, 1:55pm

No.

btrfs property set /.snapshots ro false

check with

btrfs property get /.snapshots

You need to be root.

As the message says - you cannot start internal shell command, you can only start the shell itself. And the right way to do it is either

sudo -i

or

su -

userwithoutname · April 16, 2024, 6:25pm

@arvidjaar Thanks for your help! As far as I can tell, it seems to work now.

First, I ran the suggested btrfs commands with sudo -i.
The second step was sudo -i vim /usr/lib/snapper/plugins/grub, adding the -x to the file. But after telling Vim to :wq!, it returned, that the file was read-only.
So, I hoped to fix this by executing sudo -i chmod +w on that particular file. The error persisted. I rebooted the machine and gave it another shot. Still, Vim refused to overwrite it.

But regardless, I successfully updated the system with sudo transactional-update dup, followed by sudo transactional-update cleanup and sudo transactional-update reboot. GNOME immediately showed a notification about the success of this update.

During the following reboot, less error messages appeared, especially those regarding ACPI.

Anyway, back in GNOME I ran sudo -i btrfs property set /.snapshots ro true.

And I noticed something rather nice:
All power modes are available again, from both within the GNOME system settings and the taskbar menu on the upper right as well, letting me enable energy saving mode again.

I will continue to observe and check, whether the system is updating itself automatically and as reliably as right after installing Aeon. I hope GNOME software does its job and just keeps working.

And thanks again! I really appreciate you taking your time to help. The same goes for @malcolmlewis, of course.

Namaste.

userwithoutname · April 20, 2024, 6:55pm

Update: As of now, I still don’t get any notifications about new updates to be installed, regardless of which energy mode GNOME is in. Updates only work by manually running sudo transactional-update dup.

I again wanted to provide some helpful logs, but still can’t figure out how to get /usr/lib/snapper/plugins/grub to be writable.
That said, both chmod +w and btrfs property set ro false seem to have zero effect on this, even if used with sudo -i or even su.
So, I recursively checked, on what parent directory of said file they would work. Apparently, it would do so on /. But, of course, I avoided giving into it.

Then, searching the web, I found this site here: https://documentation.suse.com/smart/systems-management/html/Micro-transactional-updates/index.html

On that very site, the command sudo systemctl --now disable transactional-update.timer is mentioned, in the context of disabling automatic updates. I figured, why not do the opposite then? sudo systemctl --now enable transactional-update.timer seems to have done exactly that. I tried it on another machine, having lacked automatic updates as well.

After this, systemctl status transactional-update.timer outputs:

● transactional-update.timer - Daily update of the system
Loaded: loaded (/usr/lib/systemd/system/transactional-update.timer; enable>
Active: active (waiting) since Sat 2024-04-20 19:21:26 CEST; 27min ago
Trigger: Sun 2024-04-21 01:00:43 CEST; 5h 11min left
Triggers: ● transactional-update.service
Docs: man:transactional-update(8)

Warning: some journal files were not opened due to insufficient permissions.
lines 1-8/8 (END)

Since the outputted date implies, that the automatic update service is only active as of now, because I just toggled it, I strongly believe this to be the final solution.

I’ll keep observing and posting updates about this, should there be are any.

userwithoutname · April 21, 2024, 3:01pm

Today, I noticed automatic updates working again on my main rig…

oh_yes

So, the same should be true for my laptop, which I shall verify later.
Consider it so, if I refrain from adding further updates to this thread.

Now, to hold back people from just re-installing Aeon / Kalpa in case something unexpected happens, I hereby propose displaying an obtrusive pop-up right after installing the distro and of course also, just before overwriting any installed instance, asserting: “If something’s broken, at least try to fix it. It’s probably possible.”

But jokes aside and despite this little challenge we experienced, Aeon still is the most reliable OS I’ve ever used; Which is quite respectable, considering it’s RC state and also, being a rolling release.

Anyway, enjoy your day.
Peace out.