Install usb layout mga9

Discussion:

(too old to reply)

William Unruh

2024-01-06 17:53:29 UTC

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?

David W. Hodgins

2024-01-06 20:10:50 UTC

Permalink

Post by William Unruh
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

William Unruh

2024-01-07 04:55:49 UTC

Permalink

Post by David W. Hodgins

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?

Post by David W. Hodgins
Regards, Dave Hodgins

David W. Hodgins

2024-01-07 18:15:58 UTC

Permalink

Post by William Unruh

Post by David W. Hodgins

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.

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.

Post by William Unruh
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

William Unruh

2024-01-07 21:49:30 UTC

Permalink

Post by David W. Hodgins

Post by William Unruh

Post by David W. Hodgins

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.

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).

Post by David W. Hodgins

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.

Post by David W. Hodgins
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.
- create the new partitions using standard partitioning software, taking
care not to create duplicate labels, etc.

Yes, I did that.

Post by David W. Hodgins
- 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.

Post by David W. Hodgins
- 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

Post by David W. Hodgins
- 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.

Post by David W. Hodgins
Regards, Dave Hodgins

David W. Hodgins

2024-01-07 23:01:08 UTC

Permalink

Post by William Unruh
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.

Post by William Unruh
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

William Unruh

2024-01-13 04:21:11 UTC

Permalink

Post by David W. Hodgins

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.

David W. Hodgins

2024-01-13 06:03:15 UTC

Permalink

On Fri, 12 Jan 2024 23:21:11 -0500, William Unruh <***@invalid.ca> wrote:

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

Post by William Unruh
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

faeychild

2024-01-15 21:49:04 UTC

Permalink

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