- This topic has 13 replies, 5 voices, and was last updated Oct 20-3:36 pm by olsztyn.
-
Posts
-
rayluo
Background and Symptom (the solution below would probably only work if you encounter same symptom):
I use antiX on LiveUSB exclusively for a year or two. Most of the time it worked fine, but there was one time that my LiveUSB still booted and largely worked, but some of the icons on Desktop File Manager could not show up, and displayed as a red cross “x” instead. I ended up re-creating a LiveUSB on the same flash drive and it worked well since then.
Yesterday I encountered same symptom, plus the loss of functionality of Archive Manager (i.e. clicking on an .zip archive, the Archive Manager would be invoked but then automatically closed in less than a second). This time, I know it is presumably a side effect of my otherwise rock-solid 14-year-old laptop suddenly halted and then could not turn back on. (RIP 2006-2020)
Solution:
I could choose to (re)create a new LiveUSB on a different flash drive, and then manually copy all my Live-usb-storage content and accumulated states from the old flash drive to new one.
But then I figure that the damaged data on the flash drive would most likely happen at its single biggest file, the 1 GB “/antiX/linuxfs”. Such hypothesis was confirmed by comparing that file’s md5sum. It did not match. So the solution becomes effortlessly simple: just copy the same file from inside the .iso and override the damaged one on flash drive. All my other data on the same flash drive remain valid. Easy piece!
Hope that helps.
anticapitalista
Good tip rayluo, thanks!
Philosophers have interpreted the world in many ways; the point is to change it.
antiX with runit - leaner and meaner.
olsztyn
But then I figure that the damaged data on the flash drive would most likely happen at its single biggest file, the 1 GB “/antiX/linuxfs”. Such hypothesis was confirmed by comparing that file’s md5sum. It did not match. So the solution becomes effortlessly simple: just copy the same file from inside the .iso and override the damaged one on flash drive. All my other data on the same flash drive remain valid. Easy piece!
Hi Rayluo…
Questions:
– When you are referring to 1GB linuxfs, the size of it seems minimal, with not many applications installed. Are you running Live with root persistence without remastering?
– In reference to ISO, which ISO did you mean – backup created from ISO Snapshot?Thanks and Regards…
Live antiX Boot Options (Previously posted by Xecure):
https://antixlinuxfan.miraheze.org/wiki/Table_of_antiX_Boot_Parametersrayluo
But then I figure that the damaged data on the flash drive would most likely happen at its single biggest file, the 1 GB “/antiX/linuxfs”…
Hi Rayluo…
Questions:
– When you are referring to 1GB linuxfs, the size of it seems minimal, with not many applications installed. Are you running Live with root persistence without remastering?
– In reference to ISO, which ISO did you mean – backup created from ISO Snapshot?Thanks and Regards…
“Running Live with root persistence without remastering”, that WAS my plan, while I was still experimenting different things. But then later when I finalize my tool set, I create my ISO snapshot, and then hardly use any persistence nowadays. But this method should presumably work with whatever ISO, you could possibly even swap in a different linuxfs from a different ISO.
W.R.T. your curiosity about the size, I did add several very small command line tools, plus one big app i.e. the Chromium, into the stock ISO. But, by choosing xz compressing algorithm, the result iso is even smaller than the original antiX ISO. 🙂 @anticapitalista, if you haven’t already, this might help you to keep the antiX base package within 710MB for a little longer.
Running Live with root persistence without remastering”, that WAS my plan, while I was still experimenting different things. But then later when I finalize my tool set, I create my ISO snapshot, and then hardly use any persistence nowadays. But this method should presumably work with whatever ISO, you could possibly even swap in a different linuxfs from a different ISO.
Thanks…
So for myself to be clear, for this instance you are running: There is content of rootfs and/or homefs that is not yet merged by remaster into linuxfs and ISO Snapshot you are referring to is a snapshot of running system composed of linuxfs and rootfs?
What if you discard rootfs, does the system start correctly, although perhaps with incomplete app set?
I am just trying to understand underlying conditions…
Thanks and regards…
Edit:
Sorry for my questions that might seem confusing… What I am driving at is that in my understanding linuxfs should be pretty much static unless remaster has been performed, so I am curious what could have caused corruption of linuxfs…
Thanks and regards…- This reply was modified 2 years, 6 months ago by olsztyn.
Live antiX Boot Options (Previously posted by Xecure):
https://antixlinuxfan.miraheze.org/wiki/Table_of_antiX_Boot_Parametersrayluo
So for myself to be clear, for this instance you are running: There is content of rootfs and/or homefs that is not yet merged by remaster into linuxfs and ISO Snapshot you are referring to is a snapshot of running system composed of linuxfs and rootfs?
What if you discard rootfs, does the system start correctly, although perhaps with incomplete app set?
I am just trying to understand underlying conditions…
Thanks and regards…
Edit:
Sorry for my questions that might seem confusing… What I am driving at is that in my understanding linuxfs should be pretty much static unless remaster has been performed, so I am curious what could have caused corruption of linuxfs…
Thanks and regards…I can understand your questions, and they are all fair and welcome!
* I can see your point of only rootfs and/or homefs would be modified in usual usage, thus more susceptible to accidental dirty write damage. I did not use persistence, so there were no rootfs or homefs in my case. Even if I were using rootfs or homefs, it would be unlikely that I would have a correct copy of them from elsewhere, by their nature.
* Yes, the linuxfs is conceptually readonly during normal antiX liveUSB usage. I’m not sure whether linuxfs is logically readonly in liveUSB implementation. (Is it mounted as a readonly file system, @anticapticalista?). But at least, in my case, now I know it is not physically readonly. To be fair, though, such dirty write happens only once in a life time, at least from my thinkpad X60’s perspective. (More details on that accident: it first halted completely, and then the next reboot results a couple different beeps patterns generates from BIOS, indicating memory malfunction and/or motherboard malfunction. I guess anything could happen in such circumstance. Alas, my rock-solid thinkpad X60 now becomes a solid rock.)
Anonymous
Comparing “md5sum /live/boot-dev/antiX/linuxfs” against “cat /live/boot-dev/antiX/linuxfs.md5” is a reasonable troubleshooting step, but did it also occur to you to perform “stat /live/boot-dev/antiX/linuxfs” ?
If you had done so, I’m 99%+ confident that the LastModified timestamp would have indicated that the linuxfs file had never been “written to, and modified”.
> whether linuxfs is logically readonly in liveUSB implementation
> Is it mounted as a readonly file system?That line of questioning seems moot.
Check “file /live/boot-dev/antiX/linuxfs” and “man mksquashfs” to understand that it is impossible to directly edit a squashfs file. In fact, the word “edit” is entirely absent from the mksquashfs manpage (search within the manpage for “append”, instead). Indirectly, as in ??? someone has livebooted using a stock (not remastered) linuxfs… and some “malware” or a malicious local actor knows the address offset of a critical byterange of data within the linuxfs file and, via hexedit, alters the file then uses the “touch -d” command to alter the file’s mtime attribute… yeah, that’s not a likely scenario.
Although one might describe a mishap like this as “the file got corrupted” it is probably more accurate to say “readback, from certain blocks of the flash storage device, has proven to be unreliable”. Which particular blocks, though? I wouldn’t bother testing to find out. After rescuing the data from the device, I would Sharpie mark it with an X, relegating its future use to solely non-critical “sneakernet” file transfers.
just copy the same file from inside the .iso and override the damaged one on flash drive.
notwithstanding my previous post, that’s still a great tip!
rayluo
Comparing “md5sum /live/boot-dev/antiX/linuxfs” against “cat /live/boot-dev/antiX/linuxfs.md5” is a reasonable troubleshooting step, but did it also occur to you to perform “stat /live/boot-dev/antiX/linuxfs” ?
If you had done so, I’m 99%+ confident that the LastModified timestamp would have indicated that the linuxfs file had never been “written to, and modified”.
> whether linuxfs is logically readonly in liveUSB implementation
> Is it mounted as a readonly file system?That line of questioning seems moot.
Check “file /live/boot-dev/antiX/linuxfs” and “man mksquashfs” to understand that it is impossible to directly edit a squashfs file. In fact, the word “edit” is entirely absent from the mksquashfs manpage (search within the manpage for “append”, instead). Indirectly, as in ??? someone has livebooted using a stock (not remastered) linuxfs… and some “malware” or a malicious local actor knows the address offset of a critical byterange of data within the linuxfs file and, via hexedit, alters the file then uses the “touch -d” command to alter the file’s mtime attribute… yeah, that’s not a likely scenario.
Although one might describe a mishap like this as “the file got corrupted” it is probably more accurate to say “readback, from certain blocks of the flash storage device, has proven to be unreliable”. Which particular blocks, though? I wouldn’t bother testing to find out. After rescuing the data from the device, I would Sharpie mark it with an X, relegating its future use to solely non-critical “sneakernet” file transfers.
Thanks for your input, Skidoo!
It did not occur to me to check the file’s last modified time. Would have been a good exercise. I’ll try to do that if I end up in a similar case again. And also thanks for your description on squashfs. That makes perfect sense in normal scenario. It is just that, in my case, when RAM or motherboard happen to go wrong, perhaps the Linux Kernel behavior is also unpredictable. No need to go deeper in this analysis.
Lastly, your point on “readback, from certain blocks of flash storage device, has proven to be unreliable”, is also equally valid. Thanks for providing a different perspective!
notwithstanding my previous post, that’s still a great tip!
I agree as well, this is a great tip.
Thanks for this discussion rayluo and skidoo. I am learning something new every day…
Although I have not run into reliability failure of USB sticks with antiX Live, I am aware of such possibility and once I have finalized my ultimate system I make multiple copies of such stick so as not to lose much work in case it happens. The cost of stick is minimal comparing to high value of the ultimate antiX Live into which so much work and time has been invested…
Thanks again and Regards…Live antiX Boot Options (Previously posted by Xecure):
https://antixlinuxfan.miraheze.org/wiki/Table_of_antiX_Boot_Parameters
Xecure
I don’t know if you know, but on live USB, antiX DOES save stuff to the linuxfs file (it is not read only).
I am still building the table (and will move it to a new page when finished), but you can see that there is a boot parameter named savestate that is active by default in live-usb. It saves some changes to the linuxfs file. You can disable it with the boot parameter nosavestate
antiX Live system enthusiast.
General Live Boot Parameters for antiX.Hi Xecure…
When it comes to saving state, are you referring to actual linuxfs file or files in folder ‘state’ in /live/boot-dev/antiX, which has folders ‘general’, ‘machine’, ‘user’?
Is this where state information is saved, rather than the actual linuxfs?
Thanks and Regards…Live antiX Boot Options (Previously posted by Xecure):
https://antixlinuxfan.miraheze.org/wiki/Table_of_antiX_Boot_ParametersXecure
When it comes to saving state, are you referring to actual linuxfs file or files in folder ‘state’ in /live/boot-dev/antiX, which has folders ‘general’, ‘machine’, ‘user’?
Is this where state information is saved, rather than the actual linuxfs?You are right. I am feeling so stupid after being myself who is copying and writing that. For some reason I though it also saved it in the linuxfs file.
I will just exit this topic quietly and not come back.
antiX Live system enthusiast.
General Live Boot Parameters for antiX.Hi Xecure…
Your contribution to this topic (as other topics) is very much appreciated. This is a learning process for me. I did not know many of these facts discussed in this topic and thanks to Rayluo, skidoo and you we try to sort them out. It is your mentioning saving state made me realize the answer.
Thanks and Regards…Live antiX Boot Options (Previously posted by Xecure):
https://antixlinuxfan.miraheze.org/wiki/Table_of_antiX_Boot_Parameters
- You must be logged in to reply to this topic.
