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?

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

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

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.

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

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