Live USB persist-save/live-remaster fail: /dev/mapper/liveb doesn’t exist

[Member bci]

I’m running AntiX 19.2 Runit edition (full) off of a Live persistent USB, using persist-root, and the toram boot-code.

After running ‘persist-save’ or ‘live-remaster’ once, future attempts to run either of the same commands fail with:

persist-save error:
/dev/mapper/liveb is not a device or a file

or

live-remaster error:
/dev/mapper/liveb is not a device or a file

I also have:

$ ls /dev/mapper/
control live-remaster

(For I had already remastered once in the current boot. Before remastering, the directory only had the ‘control’ entry in it.)

Upon rebooting, the problem is fixed. Nevertheless, it can be inconvenient if someone stumbles across this after having committed a lot of work, and went
to, say, persist-save, only to run into this! Hence, is there a way to recover /dev/mapper/liveb for a subsequent live-remaster or persist-save?

Of course, knowing and avoiding the triggering situation is sufficient to avoid the problem; nevertheless, this feels like a bug? (Unless it’s an inevitable feature of how persistence works; I don’t know enough about the subject to be sure.)

In case, here’s my inxi -Fz:

System:
Host: antix1 Kernel: 4.9.212-antix.1-amd64-smp x86_64 bits: 64
Desktop: IceWM 1.8.3
Distro: antiX-19.2-runit_x64-full Hannie Schaft 28 March 2020
Machine:
Type: Laptop System: LENOVO product: 2985FCU v: ThinkPad X201 Tablet
serial: <filter>
Mobo: LENOVO model: 2985FCU serial: <filter> BIOS: LENOVO
v: 6QET70WW (1.40 ) date: 10/11/2012
Battery:
ID-1: BAT0 charge: 40.4 Wh condition: 41.8/66.2 Wh (63%)
CPU:
Topology: Dual Core model: Intel Core i5 U 520 bits: 64 type: MT MCP
L2 cache: 3072 KiB
Speed: 1067 MHz min/max: 666/1067 MHz Core speeds (MHz): 1: 666 2: 666
3: 933 4: 799
Graphics:
Device-1: Intel Core Processor Integrated Graphics driver: i915 v: kernel
Display: x11 server: X.Org 1.20.4 driver: intel resolution: 1280×800~60Hz
OpenGL: renderer: Mesa DRI Intel Ironlake Mobile v: 2.1 Mesa 18.3.6
Audio:
Device-1: Intel 5 Series/3400 Series High Definition Audio
driver: snd_hda_intel
Sound Server: ALSA v: k4.9.212-antix.1-amd64-smp
Network:
Device-1: Intel 82577LM Gigabit Network driver: e1000e
IF: eth1 state: down mac: <filter>
Device-2: Intel Centrino Advanced-N 6200 driver: iwlwifi
IF: wlan1 state: up mac: <filter>
Drives:
Local Storage: total: 57.75 GiB used: 72.8 MiB (0.1%)
ID-1: /dev/sdb type: USB vendor: PNY model: USB 3.1 FD size: 57.75 GiB
Partition:
ID-1: / size: 3.01 GiB used: 68.5 MiB (2.2%) fs: overlay source: ERR-102
Sensors:
System Temperatures: cpu: 60.0 C mobo: 0.0 C
Fan Speeds (RPM): cpu: 4579
Info:
Processes: 187 Uptime: 19m Memory: 5.63 GiB used: 858.7 MiB (14.9%)
Shell: bash inxi: 3.0.36

• This topic was modified 2 years, 7 months ago by bci.

[Anonymous]

Helpful

Up

0

::

AntiX 19.2 Runit edition (full) off of a Live persistent USB, using persist-root, and the toram boot-code.

As part of the remastering operation, rootfs content is captured into the newly-created linuxfs
and (preserved, in case of needed rollback) rootfs is renamed to rootfs.old.
During the remaster operation, you should have been prompted “Root persistence is enabled. Wanna setup new persistence?”
If you forego the option to setup fresh persistence during the remaster operation, you’re free to do so following reboot (or during any later boot).

So, did you choose “no”, and wound up with persist-save unable find a currently non-existent rootfs?
If so, possibly (you’re welcome to test and post back to report the result) at that juncture you could run the “persist-makefs” command (labeled “setup live persistence” or somesuch if you are launching via ControlCentre gui) and immediately regain the ability to perform a save.

[Member bci]

Helpful

Up

0

::

I see what the problem is now. I decided to give skipping the toram boot code a go, and lo, I can do multiple remasters and persists. I’m not sure why this is the case, though.

I should point out that, upon a little further investigation, the problem had occurred even when I ignored the possibility of remastering – that is, I ran into the same issue even when performing more than one persist-save. Hence, it didn’t look like it came about because I decided to defer creating a new rootfs file.

Thanks for telling me about persist-makefs – it looks pretty handy. I tried stuff there, and it didn’t work, sadly – though
it did have tons of options to explore. 🙂

– Brandon

[Anonymous]

Helpful

Up

0

::

possibly [..] at that juncture you could run the “persist-makefs” command [..] and immediately regain the ability to perform a save.

No, sorry, that was a poor suggestion.
All things considered, I should have replied to the original post by stating “yes, it’s an inevitable feature” and by further advising that an immediate reboot right after performing a live-remaster operation is the recommended practice.

If you inspect the files residing in /live/boot-dev/antiX/
immediately after having run live-remaster
(immediately, as in right away ~~ during the same live session)
I expect you’ll find linuxfs and linuxfs.new and — depending on whether you had been using root_persist and had chosen “yes” when asked “wanna create new?” — a rootfs and rootfs.new file

During the next boot, the live init will detect the presence of linuxfs.new (indicating first boot following a live-remaster operation)… and it renames linuxfs to linuxfs.old, renames linuxfs.new to linuxfs, performs some other checks, then proceeds with the boot process.

Even if you are able to successfully perform persist-save again (same session, following a remaster operation), changes woould be written to “rootfs”, a file which will not be read during the next boot, and cannot be used with the newly created “linuxfs.new”. The init checks (compares a “versionID” embedded within the each linuxfs file and rootfs file) to ensure a given rootfs file belongs with a given linuxfs file.

[Author]

Posts