I like live disto + persistence (of the right kind, not just 'some
data'). In the past I've been happy w/ Linux Mint + dus/mkusb, but
recent LM and mkusb didn't get along, requiring me to shift that to an
install on SSD.

I've been able to put MX on a Ventoy SSD + an SSD persistence and Puppy Bookworm 64 on a combo of Ventoy USB + ssd persistence, but not Easy OS.

Today was my first go at Mageia's and I was disappointed that the
isodumper's file manager wouldn't let me use a Ventoy USB live Mageia 9
XFCE to access its .iso from another device; but I managed to get
things situated after some trial and error by using the partitioned USB
to boot Mageia live and add the isodumper and then write to a different
USB w/ the isodumper. Next I want to figure out how to have the Mageia
..iso on an SSD and its persistence (I guess in the form of a partition)
on SSD.


--- MBSE BBS v1.1.1 (Linux-x86_64)
* Origin: Air Applewood, The Linux Gateway to the UK & Eire (2:250/1@fidonet)

Mike Easter wrote:

Today was my first go at Mageia's

Oops; sig fix.

--
Mike Easter


--- MBSE BBS v1.1.1 (Linux-x86_64)
* Origin: Air Applewood, The Linux Gateway to the UK & Eire (2:250/1@fidonet)

Mike Easter wrote:

Next I want to figure out how to have the Mageia
.iso on an SSD and its persistence (I guess in the form of a partition)
on SSD.

Here's the structure of a persistent live on a 16G USB from diskinfo:

- --- /dev/sdc
Block device, size 14.55 GiB (15623782400 bytes)
GRUB boot loader, unknown compat version 121
DOS/MBR partition map
Partition 2: 4 MiB (4194304 bytes, 8192 sectors from 7083320)
Type 0xEF (EFI System (FAT))
FAT12 file system (hints score 5 of 5)
Volume size 3.977 MiB (4169728 bytes, 2036 clusters of 2 KiB)
Volume name "MGAISO-ESP"
Partition 3: 11.17 GiB (11992563712 bytes, 23422976 sectors from 7092224)
Type 0x83 (Linux)
Ext4 file system
Volume name "mgalive-persist"
UUID 389F85CA-F248-491A-A856-2A7ABAC75F02 (DCE, v4)
Last mounted at "/"
Volume size 11.17 GiB (11992563712 bytes, 2927872 blocks of 4 KiB)
ISO9660 file system
Volume name "Mageia-9-Live-Xfce-x86_64"
Publisher "MAGEIA.ORG"
Preparer "DRAKISO"
Application "GNU XORRISO 1.5.2"
Data size 3.378 GiB (3626659840 bytes, 1770830 blocks of 2 KiB)
El Torito boot record, catalog at 65
Bootable non-emulated image, starts at 66, preloads 2 KiB
Platform 0x00 (x86), System Type 0x00 (Empty)
Bootable non-emulated image, starts at 1770830, preloads 4 MiB
(4194304 bytes)
Platform 0xEF (EFI), System Type 0x00 (Empty)
FAT12 file system (hints score 5 of 5)
Volume size 3.977 MiB (4169728 bytes, 2036 clusters of 2 KiB)
Volume name "MGAISO-ESP"
Joliet extension, volume name "Mageia-9-Live-Xf"
------------------

Of some interest, when Win Rufus (older v on W7) was asked to write the
..iso to a USB, it noted that the Mageia hybrid 'condition' was
unconventional (or some word, maybe not recognized) so it was going to
need to write as dd, one of its options. And, when I try to examine the
USB w/ such as gparted, it just sees the iso9660 partition as that,
without more information; whereas such as 'Disks' in linux mint or the diskdrake in Mageia can see the 9660 part better, such as above diskinfo.

And, I've found a page linked from the wiki on live persistence about
custom peristence.

https://bugs.mageia.org/show_bug.cgi?id=23654#c5
Martin Whitaker 2018-10-09 21:57:58 CEST

It can help if a manual process of the creation of persistence is described >> here.

I've just done it like this:

.... and follows a useful conversation w/ others.


--
Mike Easter

--- MBSE BBS v1.1.1 (Linux-x86_64)
* Origin: Air Applewood, The Linux Gateway to the UK & Eire (2:250/1@fidonet)

Mike Easter wrote:

'Disks' in linux mint

= gnome-disk-utility

--
Mike Easter

--- MBSE BBS v1.1.1 (Linux-x86_64)
* Origin: Air Applewood, The Linux Gateway to the UK & Eire (2:250/1@fidonet)

Mike Easter wrote:

Next I want to figure out how to have the Mageia
.iso on an SSD and its persistence (I guess in the form of a partition)
on SSD.

This is a f/up to a thread I started in May at which time I went thru'
some 'distraction' in learning about some Mageia behaviors in the live.

I decided that the Mag isodumper and the default Mageia behavior in its acceptance/treatment of USB as an /optical/ wasn't going to be
compatible w/ my creating a SSD-loaded Mageia as a persistent live.

But the good news is that I do have a Mag XFCE on USB created w/ Mag's isodumper as persistent, and the persistence is better than some types
of persistence which only 'leave'/save some storage space available, but
do NOT allow one to build a persistent 'system'. Back then I illustrated
that w/ the diskinfo of the isodumper usb

https://al.howardknight.net/?ID=175417191500

From: Mike Easter
Newsgroups: alt.os.linux.mageia
Subject: Re: Isodumper persistence
Date: Fri, 9 May 2025 09:08:06 -0700
Message-ID: <m86nj6Fksu2U1@mid.individual.net>

As I mentioned a coupla' months ago, there are 'tricky' Ventoy methods
for the distro/s which allow persistence such as Puppy and MX to get a *better* persistence than Ventoy's 'simple' storage persistence.

I haven't yet figured out if anything about that strategy can be applied
to Mageia or not.

HK has been having some trouble lately; it isn't that much to paste the diskinfo here again:

- --- /dev/sdc
Block device, size 14.55 GiB (15623782400 bytes)
GRUB boot loader, unknown compat version 121
DOS/MBR partition map
Partition 2: 4 MiB (4194304 bytes, 8192 sectors from 7083320)
Type 0xEF (EFI System (FAT))
FAT12 file system (hints score 5 of 5)
Volume size 3.977 MiB (4169728 bytes, 2036 clusters of 2 KiB)
Volume name "MGAISO-ESP"
Partition 3: 11.17 GiB (11992563712 bytes, 23422976 sectors from 7092224)
Type 0x83 (Linux)
Ext4 file system
Volume name "mgalive-persist"
UUID 389F85CA-F248-491A-A856-2A7ABAC75F02 (DCE, v4)
Last mounted at "/"
Volume size 11.17 GiB (11992563712 bytes, 2927872 blocks of 4 KiB)
ISO9660 file system
Volume name "Mageia-9-Live-Xfce-x86_64"
Publisher "MAGEIA.ORG"
Preparer "DRAKISO"
Application "GNU XORRISO 1.5.2"
Data size 3.378 GiB (3626659840 bytes, 1770830 blocks of 2 KiB)
El Torito boot record, catalog at 65
Bootable non-emulated image, starts at 66, preloads 2 KiB
Platform 0x00 (x86), System Type 0x00 (Empty)
Bootable non-emulated image, starts at 1770830, preloads 4 MiB
(4194304 bytes)
Platform 0xEF (EFI), System Type 0x00 (Empty)
FAT12 file system (hints score 5 of 5)
Volume size 3.977 MiB (4169728 bytes, 2036 clusters of 2 KiB)
Volume name "MGAISO-ESP"
Joliet extension, volume name "Mageia-9-Live-Xf"
------------------

--
Mike Easter

--- MBSE BBS v1.1.1 (Linux-x86_64)
* Origin: Air Applewood, The Linux Gateway to the UK & Eire (2:250/1@fidonet)

Mike Easter wrote:

Next I want to figure out how to have the Mageia .iso on an SSD and
its persistence (I guess in the form of a partition) on SSD.

There's more in the Mag wiki than isodumper:

https://wiki.mageia.org/en/Persistent_live_systems#Creating_persistence_using_only_Live_itself

Use Diskdrake to create an ext4 partition.

--
Mike Easter

--- MBSE BBS v1.1.1 (Linux-x86_64)
* Origin: Air Applewood, The Linux Gateway to the UK & Eire (2:250/1@fidonet)

Mike Easter wrote:

Mike Easter wrote:

Next I want to figure out how to have the Mageia .iso on an SSD and
its persistence (I guess in the form of a partition) on SSD.

There's more in the Mag wiki than isodumper:

https://wiki.mageia.org/en/ Persistent_live_systems#Creating_persistence_using_only_Live_itself

Use Diskdrake to create an ext4 partition.

This isn't working for me yet.

Setup: Ventoyed SSD w/ multiple linux .iso/s on a part
SSD partitioned into the one for the .iso/s, one for MX persistence,
added ext4 part labeled mgalive-persist

The wiki doesn't say anything about booting the live w/ a boot parameter 'persistence' (noquote) but nothing was persisting, so I tried that.

Nojoy.

The wiki doesn't say anything about manually creating a dir on the part
called 'memory', but there wasn't one, so I created that.

Nojoy.

Nothing is persisting. The SSD MX one works; the USB Mageia one created
w/ isodumper works, but not the manually modified SSD.


--
Mike Easter

--- MBSE BBS v1.1.1 (Linux-x86_64)
* Origin: Air Applewood, The Linux Gateway to the UK & Eire (2:250/1@fidonet)

Mike Easter wrote:

Setup: Ventoyed SSD w/ multiple linux .iso/s on a part
SSD partitioned into the one for the .iso/s, one for MX persistence,
added ext4 part labeled mgalive-persist

The wiki doesn't say anything about booting the live w/ a boot parameter 'persistence' (noquote) but nothing was persisting, so I tried that.

The USB w/ working persistence does NOT have a persistence boot
parameter; so the gglAIov that suggested that was hallucinating again.

The wiki doesn't say anything about manually creating a dir on the part called 'memory', but there wasn't one, so I created that.

Nojoy.

Another feature of the USB w/ working Mag persistence is the presence of
a small partition labeled MGAISO-ESP which is formatted 12bit FAT 4.2MB
part type EFI. Of course there is no such thing in the SSD situation.

So I would say that the Mag which boots from an actual Mag grub and a filesystem is behaving different from a Mag which is booting from a
Ventoy + Mag .iso.

--
Mike Easter

--- MBSE BBS v1.1.1 (Linux-x86_64)
* Origin: Air Applewood, The Linux Gateway to the UK & Eire (2:250/1@fidonet)

On Sun, 03 Aug 2025 21:32:26 -0400, Mike Easter <MikeE@ster.invalid> wrote:

Mike Easter wrote:

Setup: Ventoyed SSD w/ multiple linux .iso/s on a part
SSD partitioned into the one for the .iso/s, one for MX persistence,
added ext4 part labeled mgalive-persist

The wiki doesn't say anything about booting the live w/ a boot parameter
'persistence' (noquote) but nothing was persisting, so I tried that.

The USB w/ working persistence does NOT have a persistence boot
parameter; so the gglAIov that suggested that was hallucinating again.

The wiki doesn't say anything about manually creating a dir on the part
called 'memory', but there wasn't one, so I created that.

Nojoy.

Another feature of the USB w/ working Mag persistence is the presence of
a small partition labeled MGAISO-ESP which is formatted 12bit FAT 4.2MB
part type EFI. Of course there is no such thing in the SSD situation.

So I would say that the Mag which boots from an actual Mag grub and a filesystem is behaving different from a Mag which is booting from a
Ventoy + Mag .iso.

Just checked a usb using isodumper to create the persistence partition.

$ blkid /dev/sda*
/dev/sda: BLOCK_SIZE="2048" UUID="2023-08-20-08-42-55-00" LABEL="Mageia-9-Live-Plasma-x86_64" TYPE="iso9660" PTTYPE="dos"
/dev/sda1: BLOCK_SIZE="2048" UUID="2023-08-20-08-42-55-00" LABEL="Mageia-9-Live-Plasma-x86_64" TYPE="iso9660" PTTYPE="dos"
/dev/sda2: SEC_TYPE="msdos" LABEL_FATBOOT="MGAISO-ESP" LABEL="MGAISO-ESP" UUID="05BF-07AA" BLOCK_SIZE="512" TYPE="vfat"
/dev/sda3: LABEL="mgalive-persist" UUID="e7e1a551-2d0a-4c96-a240-895de60d6e88" BLOCK_SIZE="4096" TYPE="ext4"

Inside a running live system ...
$ cat /proc/cmdline
BOOT_IMAGE=/boot/vmlinuz lang= kbd= root=mgalive:LABEL=Mageia-9-Live-Plasma-x86_64 noiswmd audit=0 rd.luks=0 rd.lvm=0 rd.md=0 rd.dm=0 vga=788 splash quiet noxconf xdriver=free

IIRC, the live system needs both the root=mgalive kernel parameter and the partition with the
LABEL="mgalive-persist".

The ESP partition on sda2 is only used if booting in efi mode. If booting in bios mode then it is
ignored.

I don't remember if the persistence partition must be on the same device as it's being booted from.

Regards, Dave Hodgins

--- MBSE BBS v1.1.1 (Linux-x86_64)
* Origin: A noiseless patient Spider (2:250/1@fidonet)

David W. Hodgins wrote:

Just checked a usb using isodumper to create the persistence partition.

$ blkid /dev/sda*
/dev/sda: BLOCK_SIZE="2048" UUID="2023-08-20-08-42-55-00" LABEL="Mageia-9-Live-Plasma-x86_64" TYPE="iso9660" PTTYPE="dos"
/dev/sda1: BLOCK_SIZE="2048" UUID="2023-08-20-08-42-55-00" LABEL="Mageia-9-Live-Plasma-x86_64" TYPE="iso9660" PTTYPE="dos"
/dev/sda2: SEC_TYPE="msdos" LABEL_FATBOOT="MGAISO-ESP" LABEL="MGAISO-
ESP" UUID="05BF-07AA" BLOCK_SIZE="512" TYPE="vfat"
/dev/sda3: LABEL="mgalive-persist" UUID="e7e1a551-2d0a-4c96- a240-895de60d6e88" BLOCK_SIZE="4096" TYPE="ext4"

Inside a running live system ...
$ cat /proc/cmdline
BOOT_IMAGE=/boot/vmlinuz lang= kbd= root=mgalive:LABEL=Mageia-9-Live- Plasma-x86_64 noiswmd audit=0 rd.luks=0 rd.lvm=0 rd.md=0 rd.dm=0 vga=788 splash quiet noxconf xdriver=free

IIRC, the live system needs both the root=mgalive kernel parameter and
the partition with the
LABEL="mgalive-persist".

When I boot Mageia from Ventoy and examine the boot parameters, I see
the identical:

root=mgalive:Label=Mageia-9Live-Plasma-x86_64

However, I do not see BOOT_IMAGE=/boot/vmlinuz; instead it is
'expressed' as $linux $boot/vmlinuz

.... presumably because of the difference in the file structure between
the USB, in which the .iso has been extracted and the Ventoy which has not.

The ESP partition on sda2 is only used if booting in efi mode. If
booting in bios mode then it is
ignored.

I see. Thanks.

I don't remember if the persistence partition must be on the same device
as it's being booted from.

For both the USB and the SSD, the device is the same, different parts;
USB has several parts, SSD has several parts.



--
Mike Easter

--- MBSE BBS v1.1.1 (Linux-x86_64)
* Origin: Air Applewood, The Linux Gateway to the UK & Eire (2:250/1@fidonet)

David W. Hodgins wrote:

Just checked a usb using isodumper to create the persistence partition.

$ blkid /dev/sda*
/dev/sda: BLOCK_SIZE="2048" UUID="2023-08-20-08-42-55-00" LABEL="Mageia-9-Live-Plasma-x86_64" TYPE="iso9660" PTTYPE="dos"
/dev/sda1: BLOCK_SIZE="2048" UUID="2023-08-20-08-42-55-00" LABEL="Mageia-9-Live-Plasma-x86_64" TYPE="iso9660" PTTYPE="dos"
/dev/sda2: SEC_TYPE="msdos" LABEL_FATBOOT="MGAISO-ESP" LABEL="MGAISO-
ESP" UUID="05BF-07AA" BLOCK_SIZE="512" TYPE="vfat"
/dev/sda3: LABEL="mgalive-persist" UUID="e7e1a551-2d0a-4c96- a240-895de60d6e88" BLOCK_SIZE="4096" TYPE="ext4"

This part is 'unconventional' (well, 'uncommon' at least) in terms of
the writing of an .iso to USB for booting live. I think I've mentioned
here before that if one uses such as Rufus to write the .iso (which
Rufus can do either hybrid or dd style write) Rufus 'complains' that the
..iso isn't going to work out in the Rufus default method, so Rufus says
that it is going to use dd, which of course works.

That is 'fine' that isodumper can build the USB however it wants to,
including using the iso9660 file structure, but the wiki says that one
can do this persistence 'separately'/manually w/o isodumper including
creating the mgalive-persist part.

I realize that the wiki didn't 'include' using Ventoy booting and
persistence, which is where I'm at.

--
Mike Easter

--- MBSE BBS v1.1.1 (Linux-x86_64)
* Origin: Air Applewood, The Linux Gateway to the UK & Eire (2:250/1@fidonet)

Mike Easter wrote:

David W. Hodgins wrote:

Just checked a usb using isodumper to create the persistence partition.

$ blkid /dev/sda*
/dev/sda: BLOCK_SIZE="2048" UUID="2023-08-20-08-42-55-00"
LABEL="Mageia-9-Live-Plasma-x86_64" TYPE="iso9660" PTTYPE="dos"
/dev/sda1: BLOCK_SIZE="2048" UUID="2023-08-20-08-42-55-00"
LABEL="Mageia-9-Live-Plasma-x86_64" TYPE="iso9660" PTTYPE="dos"
/dev/sda2: SEC_TYPE="msdos" LABEL_FATBOOT="MGAISO-ESP" LABEL="MGAISO-
ESP" UUID="05BF-07AA" BLOCK_SIZE="512" TYPE="vfat"
/dev/sda3: LABEL="mgalive-persist" UUID="e7e1a551-2d0a-4c96-
a240-895de60d6e88" BLOCK_SIZE="4096" TYPE="ext4"

This part is 'unconventional' (well, 'uncommon' at least) in terms of
the writing of an .iso to USB for booting live. I think I've mentioned
here before that if one uses such as Rufus to write the .iso (which
Rufus can do either hybrid or dd style write) Rufus 'complains' that
the .iso isn't going to work out in the Rufus default method, so Rufus
says that it is going to use dd, which of course works.

Maybe I should clarify; when I'm talking about uncommon, I'm not talking
about the 'extras' that isodumper creates at sda2 & sda3; I'm talking
about sda1 being uncommonly iso9660; in fact the device is considered
iso9660 at sda.

When/After Mag boots, it can see the mgalive-persist part, but for
whatever reason it isn't looking for it when it is booting, and so each
boot is 'brand new' for locale etc.



--
Mike Easter

--- MBSE BBS v1.1.1 (Linux-x86_64)
* Origin: Air Applewood, The Linux Gateway to the UK & Eire (2:250/1@fidonet)

Mike Easter wrote:

Rufus 'complains' that the .iso isn't going to work out in the
Rufus default method, so Rufus says that it is going to use dd,
which of course works.

If one is using Rufus to write the .iso to USB, Rufus alerts:

The image you have selected is an ISOHybrid, but its creators have
not made it compatible with ISO/File copy mode. As a result, DD
image writing mode will be enforced.

.... and in its logs Rufus enters:

Note: DD image mode enforced since this ISOHybrid is not ISO mode compatible.

The closest thing I can find to a discussion of this issue dev/d from a discussion at Pete Batard's github section from a combination of someone asking about this problem or condition w/ a similar Manjaro .iso and mentioning PB's FAQ section discussing his position on dd vs ISOHybrid.

That is, the Rufus dev wants to default to ISOHybrid /if it will work
for the .iso/ but if the app/algo 'sees' that ISOHybrid won't work, it
'auto' configures for dd.

I doubt if anyone here would be interested in PB's opinions for his
Rufus 'design' defaults and options, but if so, it is at: https://github.com/pbatard/rufus/wiki/FAQ#user-content-Why_doesnt_Rufus_recommend_DD_mode_over_ISO_mode_for_ISOHybrid_images_Surely_DD_is_better



--
Mike Easter

--- MBSE BBS v1.1.1 (Linux-x86_64)
* Origin: Air Applewood, The Linux Gateway to the UK & Eire (2:250/1@fidonet)

On Mon, 04 Aug 2025 14:04:46 -0400, Mike Easter <MikeE@ster.invalid> wrote:

Mike Easter wrote:

David W. Hodgins wrote:

Just checked a usb using isodumper to create the persistence partition.

$ blkid /dev/sda*
/dev/sda: BLOCK_SIZE="2048" UUID="2023-08-20-08-42-55-00"
LABEL="Mageia-9-Live-Plasma-x86_64" TYPE="iso9660" PTTYPE="dos"
/dev/sda1: BLOCK_SIZE="2048" UUID="2023-08-20-08-42-55-00"
LABEL="Mageia-9-Live-Plasma-x86_64" TYPE="iso9660" PTTYPE="dos"
/dev/sda2: SEC_TYPE="msdos" LABEL_FATBOOT="MGAISO-ESP" LABEL="MGAISO-
ESP" UUID="05BF-07AA" BLOCK_SIZE="512" TYPE="vfat"
/dev/sda3: LABEL="mgalive-persist" UUID="e7e1a551-2d0a-4c96-
a240-895de60d6e88" BLOCK_SIZE="4096" TYPE="ext4"

This part is 'unconventional' (well, 'uncommon' at least) in terms of
the writing of an .iso to USB for booting live. I think I've mentioned
here before that if one uses such as Rufus to write the .iso (which
Rufus can do either hybrid or dd style write) Rufus 'complains' that
the .iso isn't going to work out in the Rufus default method, so Rufus
says that it is going to use dd, which of course works.

Maybe I should clarify; when I'm talking about uncommon, I'm not talking about the 'extras' that isodumper creates at sda2 & sda3; I'm talking
about sda1 being uncommonly iso9660; in fact the device is considered
iso9660 at sda.

When/After Mag boots, it can see the mgalive-persist part, but for
whatever reason it isn't looking for it when it is booting, and so each
boot is 'brand new' for locale etc.

My understanding is that it must be iso9660 in order for it to be suitable for burning to an
actual dvd. The Mageia iso images can boot from usb or dvd, using either bios or uefi
firmware.

Checking my archive, I experimented with ventoy back in 2020. While it can boot any of
the iso images, I couldn't figure out why persistence wouldn't work and since it wasn't
a Mageia package, gave up trying.

Ventoy was rejected for adding to Mageia as it has a number of closed source binary only
programs included in it. For example Ventoy-1.0.62/VtoyTool/vtoytool/00/vtoytool_64 at
that time.

While an exception allows binary only firmware packages as the hardware will not work
without them, other closed source binary only programs are not allowed in Mageia.

The nonfree packages other then the firmware are patented open source programs, not
closed source.

It's too easy for spyware or other malware to be hidden in any closed source programs.

Regards, Dave Hodgins

--- MBSE BBS v1.1.1 (Linux-x86_64)
* Origin: A noiseless patient Spider (2:250/1@fidonet)

David W. Hodgins wrote:

Ventoy was rejected for adding to Mageia

The files I use for Ventoy do not require any 'porting' for a distro
package.

I use a .gz for 'linux' which contains files which enable me to use a
browser interface. I unpack the .gz and run a .sh script and point a
browser at a local port:

1. run sudo bash VentoyWeb.sh in the terminal
2. open browser and visit http://127.0.0.1:24680

There is a Ventoy linux gui in qt or gtk which is allegedly like the Win ..exe, but I've never used that.

That is, there is one linux gz file containing both/either the linux gui
or the files to enable the browser interface; I've only chosen the
browser interface.

--
Mike Easter

--- MBSE BBS v1.1.1 (Linux-x86_64)
* Origin: Air Applewood, The Linux Gateway to the UK & Eire (2:250/1@fidonet)

Mike Easter wrote:

I realize that the wiki didn't 'include' using Ventoy booting and persistence, which is where I'm at.

I gradually came to accept that I wasn't going to be able to use EasyOS
as a Ventoy .iso, and give it its own usb.

I can live w/ the same type scenario w/ Mageia and persistence.

Both the Puppy and MX .iso/s can Ventoy AND persist, but they both
require special Ventoy handling beyond Ventoy's 'idea' of persistence,
because IMO that kind of standard ventoy storage persistence is no good
for me; I want the system to persist, not just have a persistent storage
spot. Ventoy's persistence plugin doesn't result in that.

--
Mike Easter

--- MBSE BBS v1.1.1 (Linux-x86_64)
* Origin: Air Applewood, The Linux Gateway to the UK & Eire (2:250/1@fidonet)

Mike Easter wrote:

I gradually came to accept that I wasn't going to be able to use EasyOS
as a Ventoy .iso, and give it its own usb.

(sorry, offtopic here, mostly)

Ha! I solved the EasyOS problem w/ Ventoy (while exploring strategies to
try to make Mageia work ventoy SSD + persist).

The Ventoy 'method' for Puppy involves creating an alternate Ventoy
menu, which alternate menu is configured via a grub.cfg file.

In my exploration, I re-visited Barry Kauler's instructions for EasyOS
and determined, "Hmm. I can do that; and I didn't do it right before."

Now the strategy works for both Puppy Bookworm and the newest Aug
EasyOS. In the case of both Puppy & Easy, they are 'natively' setup to
persist in a dir. In the case of MX & Mageia, they would like their own
part. The MX strategy is to optionally tell MX at boot to do the
persistence; Mageia (on the USB) always persists.

This is posted from the Easy 'native' mail/news, SeaMonkey.


--
Mike Easter

--- MBSE BBS v1.1.1 (Linux-x86_64)
* Origin: Air Applewood, The Linux Gateway to the UK & Eire (2:250/1@fidonet)