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.
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.
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.