• Install usb layout mga9

    From William Unruh@2:250/0 to All on Sat Jan 6 17:53:29 2024
    I tried to create an install usb stick for Mga9. I did it both using dd
    and using isodumper (too bad that there is no man page for the latter--
    there really should be).
    The resultant usb was weird. It had apparently two partition, as
    evidenced by the /dev/sda{,1,2} listings. If I ran gparted on it I
    simply got a blank as if there was nothing on the usb stick. No
    partitions, or anything. If I mounted /dev/sda1, I got a mounted
    partition with lots in it. If I ran fdisk on it, I got that there were
    two partitions, which gparted never saw. I also got a warning from fdisk
    that it had detected and iso format and a write would overwrite it. (Ie,
    and incomprehensible to me warning. I finally used fdisk to create a
    third partion of Linux type to take up the extra 25GB or soon the usb
    stick.
    Now gparted suddenly saw three partitions, and empty one of about 4GB, a
    small one of about 4 MiB fat16 MGAISO-ESP name and a 25GB unknown type.

    Is it a bug in gparted that it saw nothing in the first instance?
    Is it a bug that it sees the 4GB partition as unallocated when it
    clearly is allocated.
    Did my putting on a third partition to use the excess space on the USB
    ruin it as a boot install usb stick?

    --- MBSE BBS v1.0.8.4 (Linux-x86_64)
    * Origin: A noiseless patient Spider (2:250/0@fidonet)
  • From David W. Hodgins@2:250/0 to All on Sat Jan 6 20:10:50 2024
    On Sat, 06 Jan 2024 12:53:29 -0500, William Unruh <unruh@invalid.ca> wrote:

    I tried to create an install usb stick for Mga9. I did it both using dd
    and using isodumper (too bad that there is no man page for the latter--
    there really should be).
    The resultant usb was weird. It had apparently two partition, as
    evidenced by the /dev/sda{,1,2} listings. If I ran gparted on it I
    simply got a blank as if there was nothing on the usb stick. No
    partitions, or anything. If I mounted /dev/sda1, I got a mounted
    partition with lots in it. If I ran fdisk on it, I got that there were
    two partitions, which gparted never saw. I also got a warning from fdisk
    that it had detected and iso format and a write would overwrite it. (Ie,
    and incomprehensible to me warning. I finally used fdisk to create a
    third partion of Linux type to take up the extra 25GB or soon the usb
    stick.
    Now gparted suddenly saw three partitions, and empty one of about 4GB, a small one of about 4 MiB fat16 MGAISO-ESP name and a 25GB unknown type.

    Is it a bug in gparted that it saw nothing in the first instance?
    Is it a bug that it sees the 4GB partition as unallocated when it
    clearly is allocated.
    Did my putting on a third partition to use the excess space on the USB
    ruin it as a boot install usb stick?

    It's due to the install images being iso hybrid images that can be burnt to
    an optical disk, or copied to a usb stick.

    For example with the netinstall iso ...
    $ file Mageia-9-netinstall-nonfree-x86_64.iso Mageia-9-netinstall-nonfree-x86_64.iso: ISO 9660 CD-ROM filesystem data (DOS/MBR boot sector) 'Mageia-9-x86_64-netinstall' (bootable)

    Regular partitioning software does not handle iso 9660 images, whether in a file on disk, or after having been copied/burnt to a usb stick or optical disk.

    When it boots, the mbr partition table entry is used to select the iso9660 image,
    or to select the esp which is then used to select the iso9660 image in uefi mode.

    Once that starts, the partition table inside of the iso9660 gets used to boot the installer.

    I recommend using isodumper. Select the Write image option, the actual iso image to be copied, and the Create partition option, using the dropdown for the type to select Persistent partition. Then select the Execute button.

    Regards, Dave Hodgins

    --- MBSE BBS v1.0.8.4 (Linux-x86_64)
    * Origin: A noiseless patient Spider (2:250/0@fidonet)
  • From William Unruh@2:250/0 to All on Sun Jan 7 04:55:49 2024
    On 2024-01-06, David W. Hodgins <dwhodgins@nomail.afraid.org> wrote:
    On Sat, 06 Jan 2024 12:53:29 -0500, William Unruh <unruh@invalid.ca> wrote:

    I tried to create an install usb stick for Mga9. I did it both using dd
    and using isodumper (too bad that there is no man page for the latter--
    there really should be).
    The resultant usb was weird. It had apparently two partition, as
    evidenced by the /dev/sda{,1,2} listings. If I ran gparted on it I
    simply got a blank as if there was nothing on the usb stick. No
    partitions, or anything. If I mounted /dev/sda1, I got a mounted
    partition with lots in it. If I ran fdisk on it, I got that there were
    two partitions, which gparted never saw. I also got a warning from fdisk
    that it had detected and iso format and a write would overwrite it. (Ie,
    and incomprehensible to me warning. I finally used fdisk to create a
    third partion of Linux type to take up the extra 25GB or soon the usb
    stick.
    Now gparted suddenly saw three partitions, and empty one of about 4GB, a
    small one of about 4 MiB fat16 MGAISO-ESP name and a 25GB unknown type.

    Is it a bug in gparted that it saw nothing in the first instance?
    Is it a bug that it sees the 4GB partition as unallocated when it
    clearly is allocated.
    Did my putting on a third partition to use the excess space on the USB
    ruin it as a boot install usb stick?

    It's due to the install images being iso hybrid images that can be burnt to an optical disk, or copied to a usb stick.

    For example with the netinstall iso ...
    $ file Mageia-9-netinstall-nonfree-x86_64.iso Mageia-9-netinstall-nonfree-x86_64.iso: ISO 9660 CD-ROM filesystem data (DOS/MBR boot sector) 'Mageia-9-x86_64-netinstall' (bootable)

    Regular partitioning software does not handle iso 9660 images, whether in a file on disk, or after having been copied/burnt to a usb stick or optical disk.

    When it boots, the mbr partition table entry is used to select the iso9660 image,
    or to select the esp which is then used to select the iso9660 image in uefi mode.

    Once that starts, the partition table inside of the iso9660 gets used to boot the installer.

    I recommend using isodumper. Select the Write image option, the actual iso image to be copied, and the Create partition option, using the dropdown for the
    type to select Persistent partition. Then select the Execute button.

    I did use isodumper but then also used fdisk to make the rest of theUSB
    into an ext partition. gparted then saw the three partitions, but it
    hung toward the end of the boot process.
    So I tried your suggestion and gparted now saw the three partitions, and
    it booted. and started the installation procedure, so adding the extra partition with fdisk seems to have damaged it.

    My next question is that I had two partitions that I had created
    earlier, and I copied the Mga8 root partition onto the spare, hoping to
    use it for upgrading, so my working mga8 was presered as a spare in case
    the Mga9 update had problems. However I could not boot into it, since
    its /boot/grub2/grub.cfg still pointed at the other's root partition.

    Will the updating of that partition work and mga9 installation now
    allowing both partitions to be booted from?

    Regards, Dave Hodgins

    --- MBSE BBS v1.0.8.4 (Linux-x86_64)
    * Origin: A noiseless patient Spider (2:250/0@fidonet)
  • From David W. Hodgins@2:250/0 to All on Sun Jan 7 18:15:58 2024
    On Sat, 06 Jan 2024 23:55:49 -0500, William Unruh <unruh@invalid.ca> wrote:

    On 2024-01-06, David W. Hodgins <dwhodgins@nomail.afraid.org> wrote:
    On Sat, 06 Jan 2024 12:53:29 -0500, William Unruh <unruh@invalid.ca> wrote: >>
    I tried to create an install usb stick for Mga9. I did it both using dd
    and using isodumper (too bad that there is no man page for the latter--
    there really should be).
    The resultant usb was weird. It had apparently two partition, as
    evidenced by the /dev/sda{,1,2} listings. If I ran gparted on it I
    simply got a blank as if there was nothing on the usb stick. No
    partitions, or anything. If I mounted /dev/sda1, I got a mounted
    partition with lots in it. If I ran fdisk on it, I got that there were
    two partitions, which gparted never saw. I also got a warning from fdisk >>> that it had detected and iso format and a write would overwrite it. (Ie, >>> and incomprehensible to me warning. I finally used fdisk to create a
    third partion of Linux type to take up the extra 25GB or soon the usb
    stick.
    Now gparted suddenly saw three partitions, and empty one of about 4GB, a >>> small one of about 4 MiB fat16 MGAISO-ESP name and a 25GB unknown type. >>>
    Is it a bug in gparted that it saw nothing in the first instance?
    Is it a bug that it sees the 4GB partition as unallocated when it
    clearly is allocated.
    Did my putting on a third partition to use the excess space on the USB
    ruin it as a boot install usb stick?

    It's due to the install images being iso hybrid images that can be burnt to >> an optical disk, or copied to a usb stick.

    For example with the netinstall iso ...
    $ file Mageia-9-netinstall-nonfree-x86_64.iso
    Mageia-9-netinstall-nonfree-x86_64.iso: ISO 9660 CD-ROM filesystem data (DOS/MBR boot sector) 'Mageia-9-x86_64-netinstall' (bootable)

    Regular partitioning software does not handle iso 9660 images, whether in a >> file on disk, or after having been copied/burnt to a usb stick or optical disk.

    When it boots, the mbr partition table entry is used to select the iso9660 image,
    or to select the esp which is then used to select the iso9660 image in uefi mode.

    Once that starts, the partition table inside of the iso9660 gets used to boot
    the installer.

    I recommend using isodumper. Select the Write image option, the actual iso >> image to be copied, and the Create partition option, using the dropdown for the
    type to select Persistent partition. Then select the Execute button.

    I did use isodumper but then also used fdisk to make the rest of theUSB
    into an ext partition. gparted then saw the three partitions, but it
    hung toward the end of the boot process.
    So I tried your suggestion and gparted now saw the three partitions, and
    it booted. and started the installation procedure, so adding the extra partition with fdisk seems to have damaged it.

    The iso images are created to make them suitable for burning to an optical
    disk that can be booted in either bios or uefi firmware mode. They are then modified to make them bootable from a usb drive (hybrid iso images).

    Altering the partition table using fdisk makes changes in a way that the
    boot loader can not be found. Using fdisk works for standard partition
    tables, but doesn't work when the boot loader is inside of an iso 9660 image.

    My next question is that I had two partitions that I had created
    earlier, and I copied the Mga8 root partition onto the spare, hoping to
    use it for upgrading, so my working mga8 was presered as a spare in case
    the Mga9 update had problems. However I could not boot into it, since
    its /boot/grub2/grub.cfg still pointed at the other's root partition.

    Will the updating of that partition work and mga9 installation now
    allowing both partitions to be booted from?

    Having multiple Mageia installs on the same hard drive was supported before support for uefi was added, but is no longer supported by the installer.
    It can be done but is extremely difficult.

    The copying of the mga8 system to a new location, altering it to make it bootable, and then upgrading that to mga9 can be done.

    Extreme care must the taken when copying the mga8 system to a new location.

    Do NOT use dd or similar low level tools to copy the install.

    Using dd or similar tools would mean having a duplicate "Universally Unique Identifier" that is no longer UNIQUE.

    Having a duplicate uuid values means that which partition gets mounted can not be controlled. Sometimes it will be one, sometimes it will be the other, and not necessarily the one that is selected from the bios or uefi boot menu.

    Similarly it will create duplicate disk signature's for mbr style partition tables and duplicate ids in gpt partition tables.

    The steps involved to do it properly involve:

    - create the new partitions using standard partitioning software, taking
    care not to create duplicate labels, etc.

    - copy the contents of the existing partitions being sure to preserve things like symlinks, and extended attributes, typically by careful use of rsync or similar system level file copy utilities. Use a live iso or yet another install when doing the copying so that no files being copied are open for writing.

    - alter all occurrences of partition identifying strings in the copy. This includes places such as /etc/default/grub, and fstab, but may include other places depending on what software is being used.

    - Either add the boot entries to the existing boot loader, or use a chroot
    to install the copies' boot loader onto a new drive, and use the system boot menu to select which drive to use to load the boot loader.

    It's much simpler and safer to just do a new install, and then copy the data files (and only the data files) from the old install. Copying config files
    must be done with extreme care as the format of the config files may have changed. It's safer to alter the contents of config files to reflect what
    was present in the old ones, being careful not to alter the layout.

    Regards, Dave Hodgins

    --- MBSE BBS v1.0.8.4 (Linux-x86_64)
    * Origin: A noiseless patient Spider (2:250/0@fidonet)
  • From William Unruh@2:250/0 to All on Sun Jan 7 21:49:30 2024
    On 2024-01-07, David W. Hodgins <dwhodgins@nomail.afraid.org> wrote:
    On Sat, 06 Jan 2024 23:55:49 -0500, William Unruh <unruh@invalid.ca> wrote:

    On 2024-01-06, David W. Hodgins <dwhodgins@nomail.afraid.org> wrote:
    On Sat, 06 Jan 2024 12:53:29 -0500, William Unruh <unruh@invalid.ca> wrote: >>>
    I tried to create an install usb stick for Mga9. I did it both using dd >>>> and using isodumper (too bad that there is no man page for the latter-- >>>> there really should be).
    The resultant usb was weird. It had apparently two partition, as
    evidenced by the /dev/sda{,1,2} listings. If I ran gparted on it I
    simply got a blank as if there was nothing on the usb stick. No
    partitions, or anything. If I mounted /dev/sda1, I got a mounted
    partition with lots in it. If I ran fdisk on it, I got that there were >>>> two partitions, which gparted never saw. I also got a warning from fdisk >>>> that it had detected and iso format and a write would overwrite it. (Ie, >>>> and incomprehensible to me warning. I finally used fdisk to create a
    third partion of Linux type to take up the extra 25GB or soon the usb
    stick.
    Now gparted suddenly saw three partitions, and empty one of about 4GB, a >>>> small one of about 4 MiB fat16 MGAISO-ESP name and a 25GB unknown type. >>>>
    Is it a bug in gparted that it saw nothing in the first instance?
    Is it a bug that it sees the 4GB partition as unallocated when it
    clearly is allocated.
    Did my putting on a third partition to use the excess space on the USB >>>> ruin it as a boot install usb stick?

    It's due to the install images being iso hybrid images that can be burnt to >>> an optical disk, or copied to a usb stick.

    For example with the netinstall iso ...
    $ file Mageia-9-netinstall-nonfree-x86_64.iso
    Mageia-9-netinstall-nonfree-x86_64.iso: ISO 9660 CD-ROM filesystem data (DOS/MBR boot sector) 'Mageia-9-x86_64-netinstall' (bootable)

    Regular partitioning software does not handle iso 9660 images, whether in a >>> file on disk, or after having been copied/burnt to a usb stick or optical disk.

    When it boots, the mbr partition table entry is used to select the iso9660 image,
    or to select the esp which is then used to select the iso9660 image in uefi mode.

    Once that starts, the partition table inside of the iso9660 gets used to boot
    the installer.

    I recommend using isodumper. Select the Write image option, the actual iso >>> image to be copied, and the Create partition option, using the dropdown for the
    type to select Persistent partition. Then select the Execute button.

    I did use isodumper but then also used fdisk to make the rest of theUSB
    into an ext partition. gparted then saw the three partitions, but it
    hung toward the end of the boot process.
    So I tried your suggestion and gparted now saw the three partitions, and
    it booted. and started the installation procedure, so adding the extra
    partition with fdisk seems to have damaged it.

    The iso images are created to make them suitable for burning to an optical disk that can be booted in either bios or uefi firmware mode. They are then modified to make them bootable from a usb drive (hybrid iso images).

    Altering the partition table using fdisk makes changes in a way that the
    boot loader can not be found. Using fdisk works for standard partition tables, but doesn't work when the boot loader is inside of an iso 9660 image.

    Actually it worked and did boot up but then froze at the point that the
    X stuff was being loaded (just after postfix was loaded).



    My next question is that I had two partitions that I had created
    earlier, and I copied the Mga8 root partition onto the spare, hoping to
    use it for upgrading, so my working mga8 was presered as a spare in case
    the Mga9 update had problems. However I could not boot into it, since
    its /boot/grub2/grub.cfg still pointed at the other's root partition.

    Will the updating of that partition work and mga9 installation now
    allowing both partitions to be booted from?

    Having multiple Mageia installs on the same hard drive was supported before support for uefi was added, but is no longer supported by the installer.
    It can be done but is extremely difficult.
    both are on the ssd drive on my laptop. Partition 7 and 8.
    I copied them using rsync, and then I changed the UUID in
    /boot/grub2/grub.cfg.


    The copying of the mga8 system to a new location, altering it to make it bootable, and then upgrading that to mga9 can be done.

    Extreme care must the taken when copying the mga8 system to a new location.

    Do NOT use dd or similar low level tools to copy the install.

    Using dd or similar tools would mean having a duplicate "Universally Unique Identifier" that is no longer UNIQUE.

    Having a duplicate uuid values means that which partition gets mounted can not
    be controlled. Sometimes it will be one, sometimes it will be the other, and not necessarily the one that is selected from the bios or uefi boot menu.

    Similarly it will create duplicate disk signature's for mbr style partition tables and duplicate ids in gpt partition tables.

    The steps involved to do it properly involve:

    - create the new partitions using standard partitioning software, taking
    care not to create duplicate labels, etc.

    Yes, I did that.

    - copy the contents of the existing partitions being sure to preserve things like symlinks, and extended attributes, typically by careful use of rsync or similar system level file copy utilities. Use a live iso or yet another install
    when doing the copying so that no files being copied are open for writing.

    Did that.


    - alter all occurrences of partition identifying strings in the copy. This includes places such as /etc/default/grub, and fstab, but may include other places depending on what software is being used.

    I altered fstab and /boot/grub2/grub.cfg instead of /etc/default/grub

    - Either add the boot entries to the existing boot loader, or use a chroot
    to install the copies' boot loader onto a new drive, and use the system boot menu to select which drive to use to load the boot loader.

    It's much simpler and safer to just do a new install, and then copy the data files (and only the data files) from the old install. Copying config files must be done with extreme care as the format of the config files may have changed. It's safer to alter the contents of config files to reflect what
    was present in the old ones, being careful not to alter the layout.

    That is of course the main problem. There are so many config files
    hidden all over the place, which is why I wanted to use the installer to
    do it. You guys have spent a lot of tie making sure that the config
    files wer changed so as to maintain their compatibility with the new
    update. Why would I want to duplicate that effort. On the other hand, I
    do want that spare of the old installation around.
    The boot table is such that the current installation on partition 8
    which makes the boot table, calls the grub on partition 7 to load the
    partition 7's grub.

    Regards, Dave Hodgins

    --- MBSE BBS v1.0.8.4 (Linux-x86_64)
    * Origin: A noiseless patient Spider (2:250/0@fidonet)
  • From David W. Hodgins@2:250/0 to All on Sun Jan 7 23:01:08 2024
    On Sun, 07 Jan 2024 16:49:30 -0500, William Unruh <unruh@invalid.ca> wrote:

    Actually it worked and did boot up but then froze at the point that the
    X stuff was being loaded (just after postfix was loaded).

    See https://wiki.mageia.org/en/Mageia_9_Errata#Graphics in particular https://bugs.mageia.org/show_bug.cgi?id=27601

    There are multiple places the hostname is specified.

    That is of course the main problem. There are so many config files
    hidden all over the place, which is why I wanted to use the installer to
    do it. You guys have spent a lot of tie making sure that the config
    files wer changed so as to maintain their compatibility with the new
    update. Why would I want to duplicate that effort. On the other hand, I
    do want that spare of the old installation around.
    The boot table is such that the current installation on partition 8
    which makes the boot table, calls the grub on partition 7 to load the partition 7's grub.

    The extreme care in config file changes only applies to updates within a
    stable release, and those needed to be able to boot to a working desktop following an upgrade.

    When necessary during an upgrade, the old config files will be renamed with ..rpmsave added the the file name. The values of those config files should be manually copied from the rpmsave to the new config file, with care.

    Applications with config files in /home don't get altered during update or upgrade, as /home may or may not be accessible during the installation of
    the updated packages.

    Some applications do automatically convert .config files from an old version
    to the current version, when the application first starts after the package
    has been updated, but in many cases the application will not work or will
    have broken features. In those cases (which can be difficult to diagnose),
    it's necessary to delete or rename the old .config file(s) and let the application create new ones, with manually supplying the info needed to generate them.

    During upgrade, the installer assumes the old system is bootable, so keeps quite a few values from it, where possible.

    Regards, Dave Hodgins

    --- MBSE BBS v1.0.8.4 (Linux-x86_64)
    * Origin: A noiseless patient Spider (2:250/0@fidonet)
  • From William Unruh@2:250/0 to All on Sat Jan 13 04:21:11 2024
    On 2024-01-07, David W. Hodgins <dwhodgins@nomail.afraid.org> wrote:
    On Sun, 07 Jan 2024 16:49:30 -0500, William Unruh <unruh@invalid.ca> wrote:
    That is of course the main problem. There are so many config files
    hidden all over the place, which is why I wanted to use the installer to
    do it. You guys have spent a lot of tie making sure that the config
    files wer changed so as to maintain their compatibility with the new
    update. Why would I want to duplicate that effort. On the other hand, I
    do want that spare of the old installation around.
    The boot table is such that the current installation on partition 8
    which makes the boot table, calls the grub on partition 7 to load the
    partition 7's grub.

    The extreme care in config file changes only applies to updates within a stable release, and those needed to be able to boot to a working desktop following an upgrade.

    When necessary during an upgrade, the old config files will be renamed with .rpmsave added the the file name. The values of those config files should be manually copied from the rpmsave to the new config file, with care.

    Applications with config files in /home don't get altered during update or upgrade, as /home may or may not be accessible during the installation of
    the updated packages.

    Some applications do automatically convert .config files from an old version to the current version, when the application first starts after the package has been updated, but in many cases the application will not work or will have broken features. In those cases (which can be difficult to diagnose), it's necessary to delete or rename the old .config file(s) and let the application create new ones, with manually supplying the info needed to generate them.

    During upgrade, the installer assumes the old system is bootable, so keeps quite a few values from it, where possible.

    Regards, Dave Hodgins

    OK, found out why my second installation of MGA8 refused to boot
    properly (or rather it froze at just before the X login came up. It was
    a problem with the idiot sitting in front of the keyboard (me). It
    turned out that my fstab had no / directory line, and two /mga8
    directory mount (both p7 and p8 were being mounted on /mga8, where p7
    was supposed to mount on /, and its UUID was what was entered into the
    grub boot. This meant that while p7 was mounted as / on bootup (its UUID was the root directory in grub). So my assumption was that once the boot had finished and / was supposed to be rmounted as rw, it never happened so
    nothing could write to /, and critical programs (including X) could not
    write to files they were supposed to, and everythign ground to a halt.
    When I changed the line to mount p7 (/dev/nvme0n1p7) on /, suddenly I
    could boot both partitions. So now I have to try your suggestions see if
    I can upgrade to mga9 on p7, leaving p8 to contain mga8.

    I tracked iy down when I found a few programs complaining in
    /var/log/messages that they could not write (as root) to files on /
    which then raised the possibility that / had not been remounted as rw,
    which caused me to look in /etc/fstab on p7.
    Thanks for the help, and I will now try out updating the=at partition.

    How dangerous is it using gparted to expand and move a partition? p7 has
    only 30G of space, but there is swap file just after it, and I would
    like to use the swap file space (I can put swat into another empty space
    on the disk) to epand the mga9 partition to about 40GB.


    --- MBSE BBS v1.0.8.4 (Linux-x86_64)
    * Origin: A noiseless patient Spider (2:250/0@fidonet)
  • From David W. Hodgins@2:250/0 to All on Sat Jan 13 06:03:15 2024
    On Fri, 12 Jan 2024 23:21:11 -0500, William Unruh <unruh@invalid.ca> wrote:

    Glad you figured it out. Thanks for sharing what it was.

    How dangerous is it using gparted to expand and move a partition? p7 has
    only 30G of space, but there is swap file just after it, and I would
    like to use the swap file space (I can put swat into another empty space
    on the disk) to epand the mga9 partition to about 40GB.

    As long as the swap is not listed in fstab, it's safe to delete it and expand it while booted from a live iso or the other boot. Don't try expanding it while booted from that partition or while it's mounted.

    Regards, Dave Hodgins

    --- MBSE BBS v1.0.8.4 (Linux-x86_64)
    * Origin: A noiseless patient Spider (2:250/0@fidonet)
  • From faeychild@2:250/0 to All on Sat Jan 13 22:40:09 2024
    On 13/1/24 15:21, William Unruh wrote:



    OK, found out why my second installation of MGA8 refused to boot
    properly (or rather it froze at just before the X login came up. It was
    a problem with the idiot sitting in front of the keyboard (me). It
    turned out that my fstab had no / directory line, and two /mga8
    directory mount (both p7 and p8 were being mounted on /mga8, where p7
    was supposed to mount on /, and its UUID was what was entered into the
    grub boot. This meant that while p7 was mounted as / on bootup (its UUID was the root directory in grub). So my assumption was that once the boot had finished and / was supposed to be rmounted as rw, it never happened so nothing could write to /, and critical programs (including X) could not
    write to files they were supposed to, and everythign ground to a halt.
    When I changed the line to mount p7 (/dev/nvme0n1p7) on /, suddenly I
    could boot both partitions. So now I have to try your suggestions see if
    I can upgrade to mga9 on p7, leaving p8 to contain mga8.


    I sort of followed that superficially. Any deeper understanding would require more careful reading and mental gymnastics.

    I remember some of it it from the last time and should have kept notes

    It's all a bit disturbing because I would like to shuffle my swap
    around, but I have MGA6 MGA7 and MGA8 lurking on other partitions and
    I'd be uncertain of the repercussions- if any. It's the uncertainty
    that causes me postpone
    I have memories of doing all this stuff previously along with many
    tips from the BitTwister but there are gaps and I keep putting off
    doing anything.

    It will have to be done, fortunately installed on a different partition
    so I wont lose MGA8 in the process and can take my time un-panicked remembering all the stuff I had forgotten.

    I'm getting to old for this

    --
    Running KDE on x86_64 5.15.126-desktop-1.mga8
    Mageia release 8


    --- MBSE BBS v1.0.8.4 (Linux-x86_64)
    * Origin: A noiseless patient Spider (2:250/0@fidonet)
  • From David W. Hodgins@2:250/0 to All on Sat Jan 13 23:24:17 2024
    On Sat, 13 Jan 2024 17:40:09 -0500, faeychild <faeychild@nomail.afraid.org> wrote:
    I sort of followed that superficially. Any deeper understanding would require more careful reading and mental gymnastics.

    It was a typo in the fstab entry. During boot the initrd is loaded by grub,
    but the fstab in the intrd had the wrong mountpoint for / so the boot failed.

    It's all a bit disturbing because I would like to shuffle my swap
    around, but I have MGA6 MGA7 and MGA8 lurking on other partitions and
    I'd be uncertain of the repercussions- if any. It's the uncertainty
    that causes me postpone
    I have memories of doing all this stuff previously along with many
    tips from the BitTwister but there are gaps and I keep putting off
    doing anything.

    To avoid problems related to swap changing uuid, remove the resume parameter
    from the boot command line, and add the nofail option to the swap fstab entries
    and all other file systems except /boot, /, and /home. That way a failure to mount them will not stop the boot to a working desktop.

    For the other installs, their fstab can be edited from the current install,
    but either the initrd has to be updated in a chroot, or when booting the other install, edit the command line to remove the resume parameter.

    Either that or take care not to change the uuid for any of the partitions listed
    in fstab. For example, if you're moving swap from one drive to another, use "lsblk -o +UUID|grep SWAP" or "blkid|grep swap" to get the uuid of the
    existing partition and then use "mkswap --uuid TheValueFromTheOldSwap /dev/sd??"
    so that the new swap file system has the same uuid that the old one had.

    Don't reboot while both swaps exist and have the same value if selecting the swap
    based on uuid, as you can't be sure which will be used.

    Regards, Dave Hodgins

    --- MBSE BBS v1.0.8.4 (Linux-x86_64)
    * Origin: A noiseless patient Spider (2:250/0@fidonet)
  • From faeychild@2:250/0 to All on Mon Jan 15 21:49:04 2024
    On 14/1/24 10:24, David W. Hodgins wrote:

    Don't reboot while both swaps exist and have the same value if selecting
    the swap
    based on uuid, as you can't be sure which will be used.

    Regards, Dave Hodgins


    thanks Dave. That's pasted into the brain file also

    --
    Running KDE on x86_64 5.15.126-desktop-1.mga8
    Mageia release 8


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