- This topic has 16 replies, 3 voices, and was last updated Apr 22-8:55 am by m4r35n357.
-
Posts
-
m4r35n357
It is “finishing” in 19 seconds on my system, and creating a 56Mb ISO! I think this looks suspect:
Calculating total size of excluded files... du -sxc {} 2>/dev/null |tail -1 |cut -f1 0 Calculating size of root... du -sx /.bind-root 2>/dev/null |tail -1 |cut -f1 4 SIZE 4 SIZE ROOT 4 SIZE EXCLUDES 0 COMPRESSION 35 SIZE NEEDED 1 SIZE FREE 218443500The “units” of FREE seems out of whack with the others. Interpreting other sizes as GB is about right. I found it on FMWM, tried it from a terminal, then did the same thing in icewm.
At least it is not leaving bind-mounts lying around afterwards 😉
- This topic was modified 5 months, 2 weeks ago by m4r35n357. Reason: spelling
- This topic was modified 5 months, 2 weeks ago by m4r35n357.
- This topic was modified 5 months, 1 week ago by m4r35n357.
anticapitalista
Not broken here.
I just did a Personal snapshot of a fully dist-upgraded antiX-26-full booted to herbstluftwm and s6-rc.
I didn’t make any changes to iso-snapshot configs/options.
Result, snapshot.iso boots without issue running s6-rc into herbstluftwm.Philosophers have interpreted the world in many ways; the point is to change it.
antiX with runit - leaner and meaner.
OK, thanks for checking! I shall investigate . . . I added an exclusion (without leading /!) but commented it out when I spotted the problem. Other than that, head-scratching time!
TL;DR: Reboot 😉
After reverting the exclusion and the change of compression to zstd, it still wasn’t working (unsurprisingly), so I decided to reboot. Turned out I could not reboot from FVWM, so I dropped to the console, and CTRL-ALT-DEL didn’t do anything either, so I logged in and sure enough, sudo shutdown -r now did nothing either (there was an message something like INIT 016 but nothing else). So magic SysRq time, and fortunately that DID work. Tried a snapshot straight away and it just worked!
As to the cause, the only thing I can think of that I have done recently is that command I used to delete the bind-mounts on a previous version of iso-snapshot. There might have been consequences that I am not aware of. This is what I did, but it is not a command I usually need, so I relied on the man page 😉
sudo umount --recursive --all-targets /.bind-rootThere was no visible change to the mounts (other than the deletions), and I have backups so I have verified that over the past few days since the last snapshot. So, that is really all I can add!
Oh right, sysVinit, because I need spamd for claws-mail (my live USB is still runit though!).
- This reply was modified 5 months, 2 weeks ago by m4r35n357.
- This reply was modified 5 months, 2 weeks ago by m4r35n357. Reason: additions
Hmm, the bind-mounts are back too. Trying again:
$ sudo umount --recursive --all-targets /.bind-root umount: /tmp: target is busy.Does not look good, seems the umount is targeting /tmp, as well as NFS.
ATM the only safe way I know to get rid of those bind mounts is to reboot afterwards (MX snapshot does not have this problem).
- This reply was modified 5 months, 1 week ago by m4r35n357. Reason: comma
anticapitalista
Why is it a problem?
Do you keep your computer ‘on’ for weeks/months without rebooting or shutting down?Philosophers have interpreted the world in many ways; the point is to change it.
antiX with runit - leaner and meaner.
Tidiness, and the fact that I know from experience that my MX laptop can be snapshotted without it crapping all over the mount table.
OK pardon me, I needed to get that off my chest. It is a bug, so I am asking about it and looking for solutions (not an argument!).
If it were a script, I would be investigating myself . . .
This is where I am coming from: you guys have come up with a solution to the init problem that makes the Debian & Devuan projects look like a bunch of jokers. You have a well-integrated set of desktops and tools. To me, this trivial but unsightly little issue appears “out of character” with the rest of antiX. I hope I have now explained fully!
[UPDATE] I just tried another snapshot after running that umount command above, and can confirm that iso-snapshot writes an essentially empty ISO file afterwards. In addition (regarding your reboot question), I selected the “reboot when finished” button, and it did not reboot (this is not a consequential problem, I have seen it before but wanted to verify).
- This reply was modified 5 months, 1 week ago by m4r35n357. Reason: explanation
- This reply was modified 5 months, 1 week ago by m4r35n357.
- This reply was modified 5 months, 1 week ago by m4r35n357.
Wallon
Dear @m4r35n357
Would you please post the output of this command?
df -h -t tmpfsBest,
WallonHere it is:
$ df -h -t tmpfs Filesystem Size Used Avail Use% Mounted on tmpfs 785M 608K 784M 1% /run tmpfs 5.0M 12K 5.0M 1% /run/lock tmpfs 1.6G 0 1.6G 0% /dev/shm tmpfs 3.9G 444K 3.9G 1% /tmpand (for comparison) after another SysRq-assisted reboot:
$ df -h -t tmpfs Filesystem Size Used Avail Use% Mounted on tmpfs 785M 600K 784M 1% /run tmpfs 5.0M 12K 5.0M 1% /run/lock tmpfs 1.6G 0 1.6G 0% /dev/shm tmpfs 3.9G 4.0K 3.9G 1% /tmpsnapshot now running OK again.
- This reply was modified 5 months, 1 week ago by m4r35n357. Reason: post-reboot
- This reply was modified 5 months, 1 week ago by m4r35n357.
Wallon
Dear @m4r35n357,
Thanks for the output. It confirms that your /tmp directory is mounted in RAM (tmpfs).
I have noticed a similar behavior on my own system: having /tmp in RAM often prevents the Snapshot tool from working correctly. It seems the script struggles with mount points and exclusions when /tmp is not on the physical drive.
However, I don’t know what type of installation you are using. Is it a standard installation on a hard drive, a Frugal install, or a Live USB with persistence?
In Live or Frugal modes, /tmp is usually mounted in RAM by default to protect the USB drive and improve speed. If that’s the case, trying to manually run umount –recursive on /.bind-root while the session is active will inevitably break the file system hierarchy. This explains why the resulting ISO is empty (56Mb) and why the system refuses to reboot (the link to the init process is lost).
If you are on a standard disk installation, you could try to temporarily disable the /tmp line in your /etc/fstab, reboot, and see if the snapshot works then.
I suspect this is a specific conflict between the Snapshot tool’s mounting logic and the tmpfs configuration. Knowing your installation type would definitely help in identifying if this is a bug that needs to be reported for specific antiX setups.
Best regards,
WallonYes, I have been using tmpfs on /tmp since the early raspberry Pi days. You probably know this, but (to other readers) if you are compiling with /tmp on a HD or SSD you really should try tmpfs – it absolutely flies, and does not thrash the disk.
The system is a full installation on an i5 NUC that was previously running Debian Bullseye.
This is the fstab line that I use on all my systems (particularly since the first Raspberry Pis); Debian, Alpine, MX, and now antiX:
tmpfs /tmp tmpfs noatime,nosuid,mode=1777 0 0My understanding (correct me if I am wrong) is that the snapshot tool is an MX project, but I cannot bring this up with them because it works flawlessly on MX, with no traces left behind.
When all is said and done, rebooting is not the end of the world (it is certainly preferable to seeing that mount table), but I do try to avoid getting into that pattern of working if at all possible 😉
I will try without the /tmp mount & report back though.
- This reply was modified 5 months, 1 week ago by m4r35n357. Reason: emphasis
Bad news I am afraid; it is as bad or perhaps even worse with /tmp on the SSD, and I also tried the logout feature which closed the application but did not log out.
/dev/sda1 ext4 234G 21G 202G 10% /.bind-root /dev/sda1 ext4 234G 21G 202G 10% /.bind-root/usr/lib/udev/rules.d/92-console-font.rules /dev/sda1 ext4 234G 21G 202G 10% /.bind-root/etc/s6-rc/rc.local /dev/sda1 ext4 234G 21G 202G 10% /.bind-root/etc/init.d/console-setup.sh /dev/sda1 ext4 234G 21G 202G 10% /.bind-root/etc/init.d/lm-sensors /dev/sda1 ext4 234G 21G 202G 10% /.bind-root/etc/init.d/checkfs.sh /dev/sda1 ext4 234G 21G 202G 10% /.bind-root/etc/init.d/debian/console-setup.sh /dev/sda1 ext4 234G 21G 202G 10% /.bind-root/etc/init.d/debian/lm-sensors /dev/sda1 ext4 234G 21G 202G 10% /.bind-root/etc/init.d/debian/checkfs.sh /dev/sda1 ext4 234G 21G 202G 10% /.bind-root/etc/init.d/debian/init.d/console-setup.sh /dev/sda1 ext4 234G 21G 202G 10% /.bind-root/etc/init.d/debian/init.d/checkfs.sh /dev/sda1 ext4 234G 21G 202G 10% /.bind-root/etc/init.d/debian/init.d/sendsigs /dev/sda1 ext4 234G 21G 202G 10% /.bind-root/etc/init.d/debian/init.d/cron /dev/sda1 ext4 234G 21G 202G 10% /.bind-root/etc/init.d/debian/init.d/slimski /dev/sda1 ext4 234G 21G 202G 10% /.bind-root/etc/init.d/debian/init.d/gpm /dev/sda1 ext4 234G 21G 202G 10% /.bind-root/etc/init.d/debian/init.d/keyboard-setup.sh /dev/sda1 ext4 234G 21G 202G 10% /.bind-root/etc/init.d/debian/init.d/umountfs /dev/sda1 ext4 234G 21G 202G 10% /.bind-root/etc/init.d/debian/sendsigs /dev/sda1 ext4 234G 21G 202G 10% /.bind-root/etc/init.d/debian/cron /dev/sda1 ext4 234G 21G 202G 10% /.bind-root/etc/init.d/debian/hwclock.sh /dev/sda1 ext4 234G 21G 202G 10% /.bind-root/etc/init.d/debian/gpm /dev/sda1 ext4 234G 21G 202G 10% /.bind-root/etc/init.d/debian/keyboard-setup.sh /dev/sda1 ext4 234G 21G 202G 10% /.bind-root/etc/init.d/debian/kmod /dev/sda1 ext4 234G 21G 202G 10% /.bind-root/etc/init.d/debian/umountfs /dev/sda1 ext4 234G 21G 202G 10% /.bind-root/etc/init.d/sendsigs /dev/sda1 ext4 234G 21G 202G 10% /.bind-root/etc/init.d/udev /dev/sda1 ext4 234G 21G 202G 10% /.bind-root/etc/init.d/cron /dev/sda1 ext4 234G 21G 202G 10% /.bind-root/etc/init.d/hwclock.sh /dev/sda1 ext4 234G 21G 202G 10% /.bind-root/etc/init.d/slimski /dev/sda1 ext4 234G 21G 202G 10% /.bind-root/etc/init.d/gpm /dev/sda1 ext4 234G 21G 202G 10% /.bind-root/etc/init.d/keyboard-setup.sh /dev/sda1 ext4 234G 21G 202G 10% /.bind-root/etc/init.d/kmod /dev/sda1 ext4 234G 21G 202G 10% /.bind-root/etc/init.d/umountfs /dev/sda1 ext4 234G 21G 202G 10% /.bind-root/etc/grub.d/README /dev/sda1 ext4 234G 21G 202G 10% /.bind-root/etc/grub.d/41_custom /dev/sda1 ext4 234G 21G 202G 10% /.bind-root/etc/grub.d/30_os-prober /dev/sda1 ext4 234G 21G 202G 10% /.bind-root/etc/grub.d/20_memtest86+ /dev/sda1 ext4 234G 21G 202G 10% /.bind-root/etc/grub.d/05_debian_theme /dev/sda1 ext4 234G 21G 202G 10% /.bind-root/etc/grub.d/25_bli /dev/sda1 ext4 234G 21G 202G 10% /.bind-root/etc/grub.d/30_uefi-firmware /dev/sda1 ext4 234G 21G 202G 10% /.bind-root/etc/grub.d/10_linux /dev/sda1 ext4 234G 21G 202G 10% /.bind-root/etc/grub.d/20_linux_xen /dev/sda1 ext4 234G 21G 202G 10% /.bind-root/etc/grub.d/00_header /dev/sda1 ext4 234G 21G 202G 10% /.bind-root/etc/grub.d/40_custom /dev/sda1 - - - - - /.bind-root/etc/udev/rules.d/90-fstab-automount.rules /dev/sda1 ext4 234G 21G 202G 10% /.bind-root/etc/skel/.fluxbox/menu /dev/sda1 ext4 234G 21G 202G 10% /.bind-root/etc/skel/.icewm/menu /dev/sda1 ext4 234G 21G 202G 10% /.bind-root/etc/skel/.jwm/menu /dev/sda1 ext4 234G 21G 202G 10% /.bind-root/etc/desktop-session/startup /dev/sda1 ext4 234G 21G 202G 10% /.bind-root/etc/fstab /dev/sda1 ext4 234G 21G 202G 10% /.bind-root/etc/66/rc.local /dev/sda1 ext4 234G 21G 202G 10% /.bind-root/etc/antix-version /dev/sda1 ext4 234G 21G 202G 10% /.bind-root/etc/rc.local /dev/sda1 ext4 234G 21G 202G 10% /.bind-root/etc/lsb-release /dev/sda1 ext4 234G 21G 202G 10% /.bind-root/etc/live/version/linuxfs.ver /dev/sda1 ext4 234G 21G 202G 10% /.bind-root/etc/adjtimeI am about to test logging out manually to see if I need SysRq this time . . .
- This reply was modified 5 months, 1 week ago by m4r35n357.
The answer is “yes”, but that reminds me that I am using sysV init, and when I try to do CTRL-ALT-DEL it says:
usage /sbin/init 0|6and then I have to use SysRq. I am using sysV init because I need spamd for claws and it was not available as a service in runit at installation time. I will try again in runit etc. etc. 😉
- This reply was modified 5 months, 1 week ago by m4r35n357. Reason: path
OK just tried runit with /tmp on tmpfs, and the bind mounts are still there (on top of all the cgroups – very busy!). CTRL-ALT-DEL did something this time, but it shut down rather than rebooting. I am not going to be distracted by that 😉 Now about to test with /tmp on disk with runit . . .
[EDIT] again, the bind mounts are left behind, and no logout at the end. So regardless of /tmp, and runit/sysV, the results are the same. Incidentally, runit shuts down rather than rebooting with CRTL-ALT-DEL, but I don’t think I want to go there right now – I need a cuppa!
- This reply was modified 5 months, 1 week ago by m4r35n357.
This seems to be OK now, I suspect it was my attempt to “fix” the mount issue that caused the problem, as I tested it before today’s update with /tmp still on tmpfs. So feel free to mark as “solved”, “user error” or whatever 😉
The reboot problem is real, but I will take that up in a new topic . . .
- This reply was modified 5 months, 1 week ago by m4r35n357.
- You must be logged in to reply to this topic.