• Isodumper persistence

    From Mike Easter@2:250/1 to All on Wed May 7 23:47:49 2025
    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)
  • From Mike Easter@2:250/1 to All on Wed May 7 23:56:01 2025
    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)
  • From Mike Easter@2:250/1 to All on Fri May 9 17:08:06 2025
    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)
  • From Mike Easter@2:250/1 to All on Fri May 9 17:25:56 2025
    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)
  • From Mike Easter@2:250/1 to All on Sat Aug 2 23:03:25 2025
    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)
  • From Mike Easter@2:250/1 to All on Sun Aug 3 00:14:54 2025
    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)
  • From Mike Easter@2:250/1 to All on Sun Aug 3 19:02:12 2025
    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)
  • From Mike Easter@2:250/1 to All on Mon Aug 4 18:31:42 2025
    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)
  • From Mike Easter@2:250/1 to All on Mon Aug 4 18:55:21 2025
    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)
  • From Mike Easter@2:250/1 to All on Mon Aug 4 19:04:46 2025
    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)
  • From Mike Easter@2:250/1 to All on Mon Aug 4 20:36:22 2025
    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)
  • From David W. Hodgins@2:250/1 to All on Mon Aug 4 21:03:44 2025
    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)
  • From Mike Easter@2:250/1 to All on Mon Aug 4 21:43:08 2025
    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)
  • From Mike Easter@2:250/1 to All on Mon Aug 4 22:23:31 2025
    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)
  • From Mike Easter@2:250/1 to All on Tue Aug 5 20:08:14 2025
    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)