Updates with YaST fail to install

An update today fails to install on my Desktop with an error message

Subprocess failed. Error: RPM failed: error: can't create transaction lock on /usr/lib/sysimage/rpm/.rpm.lock (Read-only file system)

Because of a previous problem with the installation of Kernel Version 5.3.18-150300.59.43.1-x86_64, I have avoided installing it in the meantime, so that the current update includes a transition from kernel-default *40 directly to *46 (including update corresponding kernel-default-preempt).

How should I proceed?

uname -r 
5.3.18-59.40-preempt 

I think you should not have the preempt kernel, but the default kernel.

Did you install preempt on purpose, or is it something that happened as an incident.

I updated this morning:

henk@boven:~> uname -r
5.3.18-150300.59.46-default
henk@boven:~>

preempt kernel seems to have appeared as a result of the attempts to recover from the faulty *43 installation two weeks ago. I was cautious about removing without risking locking myself out of a working system. Even though the kernel-default version is *40, kernel-default-preempt is loaded at boot-up. The boot-up sequence starts with a warning.

The boot-up warning says “start-up with read-only snapshot” and then defaults to ‘preempt’ However, I can select ‘kernel-default’ manually

uname -r 
5.3.18-59.40-default 

I would say, get rid of that preempt. But maybe wait for others to give advice.

If I select to “start-up with read-only snapshot” then I am offered a long list of *43-preempt" kernels and one that looks like it might be a *36 version. All of which seem to be risky options.

If, on the other hand, I let the start-up option message time out, it proceeds to offer alternatives which lead either to loading the *40-preempt or I can select deliberately the *40-default.

I would appreciate some advice to clean up the boot process, i.e. how to safely install and use the *46-default kernel by default.

If everything seems to work normally on the .59.40 kernel, remove all other kernels, then run zypper up. If you get another readonly error message, it needs to be determined why it’s happening and correct it. I’ve installed .59.46 on multiple installations without incident.

Not quite sure what you mean by ‘run zypper up’. I am used to doing it via YaST Software Manager/update, which must amount to the same thing with graphics, or have you something else in mind?.

I currently have only .59.40 (default) and .59.40 (preempt) installed. Running the YaST update still generates the read-only message.

Are you suggesting that I first remove the preempt?

I haven’t used YaST for updating in many years, so am too unfamiliar with the process to recommend what to do using it except in general terms. If it was mine, I’d be using zypper ro remove the preempt, and zypper to install .59.46 default.

I have no experience with running on BTRFS snapshots. I’m guessing you’ll need to boot rescue mode from installation media, chroot to the installed system, so that your / will mount RW, so that you can then install the good and remove the bad. Alternatively, boot an older snapshot in RW mode and update normally from it.

I suspect the YaST/BTRFS snapshot procedure is probably easier to get familiar with.

uname -r 
5.3.18-59.40-default 

Using YaST, my attempt to remove the .59.40 kernel-preempt kernel first caused a dependency conflict requiring removal of the corresponding preempt-extra and preempt-optional packages as well. However, proceeding with that leads to error message

Subprocess failed. Error: RPM failed: error: can't create transaction lock on /usr/lib/sysimage/rpm/.rpm.lock (Read-only file system)

during the deletion of both those additional packages.

What now?

The immediate problem is not which kernel you are running, but your read-only file system state. That needs correcting before any packages can be added or removed. Are you using the BTRFS filesystem? If you are, you need to attract the attention of someone familiar with it. I am not. Look at /etc/fstab to see whether it has a group of BTRFS entries rather than one EXT4 for the entire / filesystem. The simplest way forward, if using BTRFS, I’m guessing, since it’s the installation default, is probably to reinstate a good snapshot, so that you can boot it in read-write mode and update from there. There are probably threads here that could be found by searching that cover what to do with BTRFS stuck in read-only mode. If you cannot find one, start a new thread with stuck in read-only mode in the message subject.

This is my /etc/fstab. Is that what you mean?

UUID=357c1741-159a-4cb7-ac75-bc52d06c06d4  /                       btrfs  defaults                      0  0 
UUID=357c1741-159a-4cb7-ac75-bc52d06c06d4  /var                    btrfs  subvol=/@/var                 0  0 
UUID=357c1741-159a-4cb7-ac75-bc52d06c06d4  /usr/local              btrfs  subvol=/@/usr/local           0  0 
UUID=357c1741-159a-4cb7-ac75-bc52d06c06d4  /tmp                    btrfs  subvol=/@/tmp                 0  0 
UUID=357c1741-159a-4cb7-ac75-bc52d06c06d4  /srv                    btrfs  subvol=/@/srv                 0  0 
UUID=357c1741-159a-4cb7-ac75-bc52d06c06d4  /root                   btrfs  subvol=/@/root                0  0 
UUID=357c1741-159a-4cb7-ac75-bc52d06c06d4  /opt                    btrfs  subvol=/@/opt                 0  0 
UUID=357c1741-159a-4cb7-ac75-bc52d06c06d4  /home                   btrfs  subvol=/@/home                0  0 
UUID=357c1741-159a-4cb7-ac75-bc52d06c06d4  /boot/grub2/x86_64-efi  btrfs  subvol=/@/boot/grub2/x86_64-efi  0  0 
UUID=357c1741-159a-4cb7-ac75-bc52d06c06d4  /boot/grub2/i386-pc     btrfs  subvol=/@/boot/grub2/i386-pc  0  0 
UUID=67d97dbf-fe17-45e2-9144-6afb0bb64232  swap                    swap   defaults                      0  0 
UUID=357c1741-159a-4cb7-ac75-bc52d06c06d4  /.snapshots             btrfs  subvol=/@/.snapshots          0  0

There is a series of BTRFS snapshots, but all of them, except the very first one (dated 2019*), are from a time after the *.59.43. crash.

So you’re using BTRFS, and need help from someone familiar with turning a read-only BTRFS filesystem readable.

There may be another possible way to get it read/write if your BTRFS isn’t corrupted. In general terms, since I don’t know BTRFS commands, and have nothing to do with BTRFS on a running system to run man pages on:

  1. boot the installation system to rescue mode
  2. perform a filesystem check on the BTRFS filesystem
  3. mount the BTRFS filesystem to /mnt
  4. mount -o bind /dev /mnt/dev
  5. mount -o bind /sys /mnt/sys
  6. mount -o bind /proc /mnt/proc
  7. chroot /mnt
  8. mount -a
  9. remove the .59.43 kernel
  10. install the .59.46 kernel
    *]reboot normally

The message says filesystem went read-only. You need to fix this condition. Run the following commands and show everything as below:

**i3-4130:~ #** btrfs filesystem show  
Label: 'tumbleweed'  uuid: 227128c2-8703-4859-a006-30dccf5b299c 
        Total devices 1 FS bytes used 19.28GiB 
        devid    1 size 134.74GiB used 27.04GiB path /dev/sda2 

Label: 'leap'  uuid: 85d405ec-d559-49a1-b59c-5c5c9f176724 
        Total devices 1 FS bytes used 12.52GiB 
        devid    1 size 48.83GiB used 17.05GiB path /dev/sda3 

**i3-4130:~ #**
**i3-4130:~ #** btrfs filesystem usage -T / 
Overall: 
    Device size:                 134.74GiB 
    Device allocated:             27.04GiB 
    Device unallocated:          107.70GiB 
    Device missing:                  0.00B 
    Used:                         19.28GiB 
    Free (estimated):            114.19GiB      (min: 114.19GiB) 
    Free (statfs, df):           114.19GiB 
    Data ratio:                       1.00 
    Metadata ratio:                   1.00 
    Global reserve:               63.42MiB      (used: 0.00B) 
    Multiple profiles:                  no 

             Data     Metadata  System               
Id Path      single   single    single   Unallocated 
-- --------- -------- --------- -------- ----------- 
 1 /dev/sda2 25.01GiB   2.00GiB 32.00MiB   107.70GiB 
-- --------- -------- --------- -------- ----------- 
   Total     25.01GiB   2.00GiB 32.00MiB   107.70GiB 
   Used      18.52GiB 782.75MiB 16.00KiB             
**i3-4130:~ #** 
**i3-4130:~ #** journalctl -b -g btrfs --no-pager               
Feb 09 23:51:07 i3-4130 dracut-cmdline[226]: Using kernel command line parameters:  rd.driver.pre=btrfs root=UUID=227128c2-8703-4859-a006-30dccf5b299c rootfstype=btrfs rootflags=rw,relatime,ssd,space_cache,subvolid=1390,subvol=/@/.snapshots/951/snapshot,subvol=@/.snapshots/951/snapshot   BOOT_IMAGE=/boot/vmlinuz-5.16.5-1-default root=UUID=227128c2-8703-4859-a006-30dccf5b299c quiet plymouth.enable=0 net.ifnames=0 mitigations=auto 
Feb 09 23:51:07 i3-4130 kernel: Btrfs loaded, crc32c=crc32c-intel, assert=on, zoned=yes, fsverity=yes 
Feb 09 23:51:07 i3-4130 kernel: BTRFS: device label tumbleweed devid 1 transid 107424 /dev/sda2 scanned by systemd-udevd (330) 
Feb 09 23:51:07 i3-4130 kernel: BTRFS: device label Leap-15.3 devid 1 transid 3932 /dev/sdb6 scanned by systemd-udevd (323) 
Feb 09 23:51:07 i3-4130 kernel: BTRFS: device label leap devid 1 transid 4156 /dev/sda3 scanned by systemd-udevd (344) 
Feb 09 23:51:07 i3-4130 kernel: BTRFS: device fsid 9e9fb019-007e-497d-9ff0-bda6eb2b131e devid 1 transid 9465 /dev/sdb7 scanned by systemd-udevd (356) 
Feb 09 23:51:08 i3-4130 kernel: BTRFS info (device sda2): flagging fs with big metadata feature 
Feb 09 23:51:08 i3-4130 kernel: BTRFS info (device sda2): disk space caching is enabled 
Feb 09 23:51:08 i3-4130 kernel: BTRFS info (device sda2): has skinny extents 
Feb 09 23:51:08 i3-4130 kernel: BTRFS info (device sda2): enabling ssd optimizations 
Feb 09 23:51:08 i3-4130 kernel: BTRFS info (device sda2): disk space caching is enabled 
Feb 09 23:51:09 i3-4130 systemd[1]: Started Watch /etc/sysconfig/btrfsmaintenance. 
Feb 09 23:51:09 i3-4130 systemd[1]: Started Balance block groups on a btrfs filesystem. 
Feb 09 23:51:09 i3-4130 systemd[1]: Started Scrub btrfs filesystem, verify block checksums. 
Feb 10 20:18:18 i3-4130 kernel: BTRFS info (device sda2): qgroup scan completed (inconsistency flag cleared) 
**i3-4130:~ #** 

Is this OK?

btrfs filesystem show 
Label: none  uuid: 357c1741-159a-4cb7-ac75-bc52d06c06d4 
    Total devices 1 FS bytes used 170.14GiB 
    devid    1 size 221.56GiB used 179.05GiB path /dev/sda3
btrfs filesystem usage -T / 
Overall: 
    Device size:         221.56GiB 
    Device allocated:         179.05GiB 
    Device unallocated:          42.52GiB 
    Device missing:             0.00B 
    Used:             170.14GiB 
    Free (estimated):          50.09GiB    (min: 50.09GiB) 
    Data ratio:                  1.00 
    Metadata ratio:              1.00 
    Global reserve:         154.78MiB    (used: 0.00B) 
 
             Data      Metadata  System               
Id Path      single    single    single   Unallocated 
-- --------- --------- --------- -------- ----------- 
 1 /dev/sda3 177.01GiB   2.01GiB 32.00MiB    42.52GiB 
-- --------- --------- --------- -------- ----------- 
   Total     177.01GiB   2.01GiB 32.00MiB    42.52GiB 
   Used      169.43GiB 729.19MiB 48.00KiB  
journalctl -b -g btrfs --no-pager 
-- Logs begin at Thu 2022-02-10 19:04:13 CET, end at Thu 2022-02-10 22:15:21 CET. -- 
Feb 10 19:04:13 linux-lueh dracut-cmdline[164]: Using kernel command line parameters: resume=UUID=67d97dbf-fe17-45e2-9144-6afb0bb64232 root=UUID=357c1741-159a-4cb7-ac75-bc52d06c06d4 rootfstype=btrfs rootflags=rw,relatime,ssd,space_cache,subvolid=268,subvol=/@/.snapshots/1/snapshot,subvol=@/.snapshots/1 
Feb 10 19:04:20 linux-lueh kernel: Btrfs loaded, crc32c=crc32c-generic, assert=on 
Feb 10 19:04:20 linux-lueh kernel: BTRFS: device fsid 357c1741-159a-4cb7-ac75-bc52d06c06d4 devid 1 transid 1126051 /dev/sda3 
Feb 10 19:04:20 linux-lueh kernel: BTRFS info (device sda3): disk space caching is enabled 
Feb 10 19:04:20 linux-lueh kernel: BTRFS info (device sda3): has skinny extents 
Feb 10 19:04:20 linux-lueh kernel: BTRFS info (device sda3): enabling ssd optimizations 
Feb 10 19:04:23 linux-lueh kernel: BTRFS info (device sda3): disk space caching is enabled 
Feb 10 19:04:48 linux-lueh systemd[1]: Started Watch /etc/sysconfig/btrfsmaintenance. 
Feb 10 19:05:06 linux-lueh systemd[1]: Started Balance block groups on a btrfs filesystem. 
Feb 10 19:05:06 linux-lueh systemd[1]: Started Scrub btrfs filesystem, verify block checksums. 
Feb 10 19:14:48 linux-lueh kernel: BTRFS info (device sda3): qgroup scan completed (inconsistency flag cleared) 

Yes. You have free and unallocated space.

Run the following check and maintenance routines:

**Leap-15-3:~ #** btrfs check --force /dev/sda3 
Opening filesystem to check... 
WARNING: filesystem mounted, continuing because of --force 
Checking filesystem on /dev/sda3 
UUID: 85d405ec-d559-49a1-b59c-5c5c9f176724 
[1/7] checking root items 
[2/7] checking extents 
[3/7] checking free space cache 
[4/7] checking fs roots 
[5/7] checking only csums items (without verifying data) 
[6/7] checking root refs 
[7/7] checking quota groups 
found 14197792768 bytes used, no error found 
total csum bytes: 12496788 
total tree bytes: 597819392 
total fs tree bytes: 556285952 
total extent tree bytes: 24985600 
btree space waste bytes: 100340934 
file data blocks allocated: 149810364416 
 referenced 43082620928 
**Leap-15-3:~ #**
**Leap-15-3:~ #** systemctl start btrfs-balance.service  
**Leap-15-3:~ #**
**Leap-15-3:~ #** systemctl start btrfs-scrub.service  
**Leap-15-3:~ #**

Show logs:

**Leap-15-3:~ #** journalctl -b -u btrfs-balance.service  
-- Logs begin at Fri 2021-08-06 10:17:37 CEST, end at Fri 2022-02-11 04:47:50 CET. -- 
Feb 11 04:44:27 Leap-15-3 systemd[1]: Started Balance block groups on a btrfs filesystem. 
Feb 11 04:44:27 Leap-15-3 btrfs-balance.sh[2516]: Before balance of / 
Feb 11 04:44:27 Leap-15-3 btrfs-balance.sh[2516]: Data, single: total=16.01GiB, used=12.67GiB 
Feb 11 04:44:27 Leap-15-3 btrfs-balance.sh[2516]: System, single: total=32.00MiB, used=16.00KiB 
Feb 11 04:44:27 Leap-15-3 btrfs-balance.sh[2516]: Metadata, single: total=1.01GiB, used=570.11MiB 
Feb 11 04:44:27 Leap-15-3 btrfs-balance.sh[2516]: GlobalReserve, single: total=39.50MiB, used=0.00B 
Feb 11 04:44:27 Leap-15-3 btrfs-balance.sh[2516]: Dateisystem    Größe Benutzt Verf. Verw% Eingehängt auf 
Feb 11 04:44:27 Leap-15-3 btrfs-balance.sh[2516]: /dev/sda3        53G     15G   38G   28% / 
Feb 11 04:44:27 Leap-15-3 btrfs-balance.sh[2516]: Done, had to relocate 0 out of 23 chunks 
Feb 11 04:44:27 Leap-15-3 btrfs-balance.sh[2516]: Dumping filters: flags 0x1, state 0x0, force is off 
Feb 11 04:44:27 Leap-15-3 btrfs-balance.sh[2516]:   DATA (flags 0x2): balancing, usage=5 
Feb 11 04:44:27 Leap-15-3 btrfs-balance.sh[2516]: Done, had to relocate 0 out of 23 chunks 
Feb 11 04:44:27 Leap-15-3 btrfs-balance.sh[2516]: Dumping filters: flags 0x1, state 0x0, force is off 
Feb 11 04:44:27 Leap-15-3 btrfs-balance.sh[2516]:   DATA (flags 0x2): balancing, usage=10 
Feb 11 04:44:27 Leap-15-3 btrfs-balance.sh[2516]: Done, had to relocate 0 out of 23 chunks 
Feb 11 04:44:27 Leap-15-3 btrfs-balance.sh[2516]: Done, had to relocate 0 out of 23 chunks 
Feb 11 04:44:27 Leap-15-3 btrfs-balance.sh[2516]: Dumping filters: flags 0x6, state 0x0, force is off 
Feb 11 04:44:27 Leap-15-3 btrfs-balance.sh[2516]:   METADATA (flags 0x2): balancing, usage=3 
Feb 11 04:44:27 Leap-15-3 btrfs-balance.sh[2516]:   SYSTEM (flags 0x2): balancing, usage=3 
Feb 11 04:44:27 Leap-15-3 btrfs-balance.sh[2516]: Done, had to relocate 1 out of 23 chunks 
Feb 11 04:44:27 Leap-15-3 btrfs-balance.sh[2516]: After balance of / 
Feb 11 04:44:27 Leap-15-3 btrfs-balance.sh[2516]: Data, single: total=16.01GiB, used=12.67GiB 
Feb 11 04:44:27 Leap-15-3 btrfs-balance.sh[2516]: System, single: total=32.00MiB, used=16.00KiB 
Feb 11 04:44:27 Leap-15-3 btrfs-balance.sh[2516]: Metadata, single: total=1.01GiB, used=570.17MiB 
Feb 11 04:44:27 Leap-15-3 btrfs-balance.sh[2516]: GlobalReserve, single: total=39.50MiB, used=0.00B 
Feb 11 04:44:27 Leap-15-3 btrfs-balance.sh[2516]: Dateisystem    Größe Benutzt Verf. Verw% Eingehängt auf 
Feb 11 04:44:27 Leap-15-3 btrfs-balance.sh[2516]: /dev/sda3        53G     15G   38G   28% / 
Feb 11 04:44:27 Leap-15-3 systemd[1]: btrfs-balance.service: Succeeded. 
**Leap-15-3:~ #**
**Leap-15-3:~ #** journalctl -b -u btrfs-scrub.service  
-- Logs begin at Fri 2021-08-06 10:17:37 CEST, end at Fri 2022-02-11 04:47:50 CET. -- 
Feb 11 04:45:04 Leap-15-3 systemd[1]: Started Scrub btrfs filesystem, verify block checksums. 
Feb 11 04:45:04 Leap-15-3 btrfs-scrub.sh[2598]: Running scrub on / 
Feb 11 04:45:42 Leap-15-3 btrfs-scrub.sh[2598]: scrub device /dev/sda3 (id 1) done 
Feb 11 04:45:42 Leap-15-3 btrfs-scrub.sh[2598]:         scrub started at Fri Feb 11 04:45:04 2022 and finished after 00:00:38 
Feb 11 04:45:42 Leap-15-3 btrfs-scrub.sh[2598]:         total bytes scrubbed: 13.22GiB with 0 errors 
Feb 11 04:45:42 Leap-15-3 systemd[1]: btrfs-scrub.service: Succeeded. 
**Leap-15-3:~ #** 

Thank you so much for pick up that baton.
The results of the first steps are similar to yours, i.e. btrfs-check on /dev/sda3 succeeded, systemctl services btrfs-balance and btrfs-scrub services both started without error.
journalctl of balance.service ended with

-- Logs begin at Fri 2022-02-11 10:35:34 CET, end at Fri 2022-02-11 11:07:35 CET. -- 
Feb 11 11:07:18 linux-lueh systemd[1]: Started Balance block groups on a btrfs filesystem. 
Feb 11 11:07:18 linux-lueh btrfs-balance.sh[4527]: Before balance of / 
Feb 11 11:07:18 linux-lueh btrfs-balance.sh[4527]: Data, single: total=177.01GiB, used=169.44GiB 
Feb 11 11:07:18 linux-lueh btrfs-balance.sh[4527]: System, single: total=32.00MiB, used=48.00KiB 
Feb 11 11:07:18 linux-lueh btrfs-balance.sh[4527]: Metadata, single: total=2.01GiB, used=729.06MiB 
Feb 11 11:07:18 linux-lueh btrfs-balance.sh[4527]: GlobalReserve, single: total=154.55MiB, used=0.00B 
Feb 11 11:07:18 linux-lueh btrfs-balance.sh[4527]: Filesystem      Size  Used Avail Use% Mounted on 
Feb 11 11:07:18 linux-lueh btrfs-balance.sh[4527]: /dev/sda3       238G  183G   54G  78% / 
Feb 11 11:07:18 linux-lueh btrfs-balance.sh[4527]: Done, had to relocate 0 out of 182 chunks 
Feb 11 11:07:18 linux-lueh btrfs-balance.sh[4527]: Dumping filters: flags 0x1, state 0x0, force is off 
Feb 11 11:07:18 linux-lueh btrfs-balance.sh[4527]:   DATA (flags 0x2): balancing, usage=5 
Feb 11 11:07:18 linux-lueh btrfs-balance.sh[4527]: Done, had to relocate 0 out of 182 chunks 
Feb 11 11:07:18 linux-lueh btrfs-balance.sh[4527]: Dumping filters: flags 0x1, state 0x0, force is off 
Feb 11 11:07:18 linux-lueh btrfs-balance.sh[4527]:   DATA (flags 0x2): balancing, usage=10 
Feb 11 11:07:18 linux-lueh btrfs-balance.sh[4527]: Done, had to relocate 0 out of 182 chunks 
Feb 11 11:07:18 linux-lueh btrfs-balance.sh[4527]: Done, had to relocate 0 out of 182 chunks 
Feb 11 11:07:18 linux-lueh btrfs-balance.sh[4527]: Dumping filters: flags 0x6, state 0x0, force is off 
Feb 11 11:07:18 linux-lueh btrfs-balance.sh[4527]:   METADATA (flags 0x2): balancing, usage=3 
Feb 11 11:07:18 linux-lueh btrfs-balance.sh[4527]:   SYSTEM (flags 0x2): balancing, usage=3 
Feb 11 11:07:18 linux-lueh btrfs-balance.sh[4527]: Done, had to relocate 1 out of 182 chunks 
Feb 11 11:07:18 linux-lueh btrfs-balance.sh[4527]: After balance of / 
Feb 11 11:07:18 linux-lueh btrfs-balance.sh[4527]: Data, single: total=177.01GiB, used=169.44GiB 
Feb 11 11:07:18 linux-lueh btrfs-balance.sh[4527]: System, single: total=32.00MiB, used=48.00KiB 
Feb 11 11:07:18 linux-lueh btrfs-balance.sh[4527]: Metadata, single: total=2.01GiB, used=729.06MiB 
Feb 11 11:07:18 linux-lueh btrfs-balance.sh[4527]: GlobalReserve, single: total=154.55MiB, used=0.00B 
Feb 11 11:07:18 linux-lueh btrfs-balance.sh[4527]: Filesystem      Size  Used Avail Use% Mounted on 
Feb 11 11:07:18 linux-lueh btrfs-balance.sh[4527]: /dev/sda3       238G  183G   54G  78% / 
Feb 11 11:07:18 linux-lueh systemd[1]: btrfs-balance.service: Succeeded. 

However, the journalclt from the scrub.service exited earlier than yours

journalctl -b -u btrfs-scrub.service 
-- Logs begin at Fri 2022-02-11 10:35:34 CET, end at Fri 2022-02-11 11:07:35 CET. -- 
Feb 11 11:07:35 linux-lueh systemd[1]: Started Scrub btrfs filesystem, verify block checksums. 
Feb 11 11:07:35 linux-lueh btrfs-scrub.sh[4555]: Running scrub on /

What does that mean?

  1. You are too fast. Above scrub is still running. Run again “journalctl -b -u btrfs-scrub.service” and show full output.
  2. Show full output of “btrfs check --force /dev/sda3”.

I rebooted and repeated the whole sequence. Everything is as before. Here are the two outputs you request.

linux-lueh:/ # btrfs check --force /dev/sda3 
Opening filesystem to check... 
WARNING: filesystem mounted, continuing because of --force 
Checking filesystem on /dev/sda3 
UUID: 357c1741-159a-4cb7-ac75-bc52d06c06d4 
[1/7] checking root items 
[2/7] checking extents 
[3/7] checking free space cache 
[4/7] checking fs roots 
[5/7] checking only csums items (without verifying data) 
[6/7] checking root refs 
[7/7] checking quota groups 
found 182692823040 bytes used, no error found 
total csum bytes: 90605524 
total tree bytes: 764379136 
total fs tree bytes: 602062848 
total extent tree bytes: 45662208 
btree space waste bytes: 138568600 
file data blocks allocated: 198264967168 
 referenced 190080778240 
linux-lueh:/ # 

linux-lueh:/ # journalctl -b -u btrfs-scrub.service 
-- Logs begin at Fri 2022-02-11 15:18:00 CET, end at Fri 2022-02-11 15:29:29 CET. -- 
Feb 11 15:28:34 linux-lueh systemd[1]: Started Scrub btrfs filesystem, verify block checksums. 
Feb 11 15:28:34 linux-lueh btrfs-scrub.sh[4018]: Running scrub on / 
linux-lueh:/ #

As you can see the scrub.service journal exits at this early line.