a_freed_man wrote: Tue Apr 05, 2022 4:43 pm
Poor choice of words on my part. I meant when I start the remaster program. I don't recall precisely when, definitely after authenticating root password, and probably right when I click the remaster button (lower left of group of 4 buttons) and definitely before it starts the remaster process.
Perhaps, post the captured window involved as picture(s) to avoid misunderstanding.
Also suggest, to post "Quick System Info" to reduce guessing of your used system and boot parameter,
otherwise it can become a long thread of misinterpreting , mis-formulating and misunderstandings.
Thanks
Ok, will do next time. I'm onto next concern, much more serious. I don't think this will require any such info.
Must I use the mx-live-usb-maker tool to create bootable media with persistence?
After creating the ISO with snapshot I use sha256sum to create a hash of it. I copy that ISO to another system & verify the hash is the same.
I used balenaEtcher-1.7.8-x64.AppImage and dd to copy that ISO to a USB-3 SSD drive. Either method produces a bootable device, but without persistence. However if I use mx-live-usb-maker to copy the image to the USB-3 drive it boots with my persistence defaults. Can't easily capture what I see if I wanted to show you the boot sequence booting from the balena or dd produced USB devices, I'd need to setup a camera, get the lighting right and all that jazz for BIOS capture.
I hope there's a good explanation b/c it means nobody can create a Live USB from my ISO unless they already have mx linux or the live usb maker.
With LUM the drive has 7 items and only 5 with dd or balena. The difference is the folders named "made-by-live-usb-maker" and "lost+found".
What a quandry, since I just went live to distribute these ISOs with instructions to use balena etcher, rufus dd etc to create a booable Live device. I know LUM is available as an appImage, but that is no good for people with Windows or Mac.
I thought everything was encapsulated in the ISO and all I needed. Was I wrong? In all that I've read I don't recall seeing any statements LUM was a required tool to achieve a persistent Live USB device. I didn't see anything on the "LUM now available as AppImage" webpage that leads me to think I had to use LUM to get persistence.
I'll readily admit I have been in a big hurry to get the code on this respin completed, the website to promote it and the documentation to support it. I probably have overlooked this crucial info about persistence in the volume of info I've had to consume.
a_freed_man wrote: Sat Apr 09, 2022 12:15 am
I hope there's a good explanation b/c it means nobody can create a Live USB from my ISO unless they already have mx linux or the live usb maker.
LUM is available on the ISO. Which means if needed, you can create a "writeable" LiveUSB to be able to save changes persistentely on that LiveUSB by running LUM with option "clone" running Live system onto an USB-key.
You can either select as clone-target another plugged-in USB-key or the same LiveUSB you booted from. In the later case (with only one USB-key involved) it is suggested to have been booted with boot option "toram", which allows LUM to unmount current USB and create a freshly "cloned" but writable LiveUSB.
I need to rewrite my instructions entirely. Windows & Mac users don't have an option to create a Live USB with persistence. Their only option as I see it is to create a Live USB from my or another MX Live image and use that to create or update their read only image that doesn't have persistence.
Thank you for your last reply, I will include that in my revised instructions.
a_freed_man wrote: Sat Apr 09, 2022 2:15 pm
Thank you.
I need to rewrite my instructions entirely. Windows & Mac users don't have an option to create a Live USB with persistence. Their only option as I see it is to create a Live USB from my or another MX Live image and use that to create or update their read only image that doesn't have persistence.
I havn't used Rufus for a while, but you can create a LiveUSB with Rufus, which is writable and hence allows to write the persistence files rootfs or homefs. The default filesystem using Rufus would be FAT32, which limits the max size of persistence files to about 4GiB. In addition FAT32 may not be as resilient in regards to filesystem repair as the ext4 filesystem used when creating the LiveUSB with "MX Live USB Maker". So user may suddenly have their persistence file on a Rufus-made LiveUSB corrupted e.g. after a hard crash. Rufus offers in addition NTFS, but fs-journaling (to allow file system repair) is really only used by the OS natively using NTFS.
So, in theory you can offer to user Rufus, but you may mention that someone else would strongly recommend to "migrate" to a "MX Live USB Maker" created Live USB in order to allow reliable persistence to work.
ttfn
Thank you. To simplify things, I rewrote my quickstart guide saying to get a Live USB with persistence LUM is required. I provided a link to the AppImage for it and said for Windows or Mac users create a Live USB of my MX respin without persistence and then boot that to use LUM to flash a different USB.
I elected to go with simple vs explain the toram option which it's usefulness depends on how much RAM they have which for some is even a stretch.
