Livecheck.sh script broken on bookworm

Please excuse the throwaway account. I just want to anonymously report this issue:
After upgrading Whonix (/Kicksecure) from bullseye to bookworm with the release-upgrade script provided, the livecheck.sh script will allways detect that there is something mounted in read-write (and therefore show this in the systray). This is due to the weird fact, that since bookworm, lsblk -all shows empty loop devices from 0-7 that are all read-write and hence trigger livecheck.sh to believe the system is mounted in read-write.
I was not able to understand why these loop devices are present in bookworm.

This all occurs with the system correctly being mounted in read-only and started with grub-live, therefore confusing users.

Confirmed.

I don’t have a solution for this.

Help is needed and welcome.

What are these loop devices from/for?
Firstly I thought of snapd but it’s not installed.

Removing the --all flag from lsblk makes it ignore loop0-7 devices and fixes this. Is there any risk in not checking their RO status?

Before trying to fix this, what are these loop devices when not using snap etc.?

lsblk_output=$(echo “${lsblk_output_unsanitized}” | grep -vPx ‘\S+\s+\d{1,3}:\d{1,3}\s+\d\s+0B\s+0\s+loop\s+’ | sed -r ‘s/^.+\s+([0-9]{1,3}:[0-9]{1,3})\s+([0-9])\s+([0-9]+.?\S{1,2})\s+//g’ | sed -r ‘s/(\s+[^0-9]+\s+\S*)$//g’)

This looks really complex. If this is the right and only solution at all, it should be split into at least 3 lines. This is to keep the ability to be able to debug this, to be able to see in the xtrace the contents after each step of string manipulation.

But before we need to know what these loop devices are so we can check if these can be ignored or not.

--output SIZE,RO,TYPE is a nice idea!

Yes, these are 0B loop devices but these are still read-write and not read-only. So as long we don’t really know their purpose, we don’t really know what we’re doing here. Just hiding a potential issue.

Thease are 0B at time of check as suggested by your pull request but there’s no guarantee that these stay 0B.

Asked just now:

And livecheck.sh currently doesn’t continuously re-check. Not sure it should. But when it detects a 0B read-write device being larger than 0B then the write action was already done and then what we attempted to protect from / inform about is already too late.

Reply received.


Quote lsblk(8) — util-linux — Debian bookworm — Debian Manpages

--all
Disable all built-in filters and list all empty devices and RAM disk devices too.


So it seems safe to drop --all.

This is now in the testers repository.

Also in the stable repository.

https://www.kernel.org/doc/Documentation/admin-guide/devices.txt

sudo --non-interactive /bin/lsblk --exclude 7 --noheadings --raw --output RO

This works better.

But something else needs to be excluded to a booted Kicksecure ISO being detected as read-write.