migrating existing desktop to EFI bios

[bad sector]

Since Intel have decided to fianally kill legacy BIOS in 2025 I have no
choice left. Knowing this day would come I've already created an EFI #1
partition, formatted with

# mkfs.fat -F 32 /dev/sda1


The current OS partitions are 10-17

Device Start End Sectors Size Type
/dev/sda1 2048 2099199 2097152 1G EFI System
/dev/sda2 1348483072 1350580223 2097152 1G BIOS boot
/dev/sda3 4196352 16779263 12582912 6G Linux swap
/dev/sda4 16779264 16781311 2048 1M Linux filesystem
/dev/sda5 16781312 16783359 2048 1M Linux filesystem
/dev/sda6 16783360 16785407 2048 1M Linux filesystem
/dev/sda7 16785408 16787455 2048 1M Linux filesystem
/dev/sda8 16787456 16789503 2048 1M Linux filesystem
/dev/sda9 16789504 16791551 2048 1M Linux filesystem
/dev/sda10 16791552 593508351 576716800 275G Linux filesystem
/dev/sda11 593508352 761280511 167772160 80G Linux filesystem
/dev/sda12 761280512 929052671 167772160 80G Linux filesystem
/dev/sda13 929052672 1096824831 167772160 80G Linux filesystem
/dev/sda14 1096824832 1264596991 167772160 80G Linux filesystem
/dev/sda15 1350580224 1518352383 167772160 80G Linux filesystem
/dev/sda16 1518352384 1686124543 167772160 80G Linux filesystem
/dev/sda17 1686124544 1853896703 167772160 80G Linux filesystem

My current motherboard supports Legacy BIOS only but I'm getting a new
board that supports EFI (only I think). How do I get the new motherboard
started up using my existing boot disk above?

What happens when the disk fails? What's the BIOS and boot recovery
after I restore all partitions form images? Can I also keep an image of
the EFI partition and run again with that after a recovery?

TIA

[Phillip Frabott]

Post by bad sector
Since Intel have decided to fianally kill legacy BIOS in 2025 I have no
choice left. Knowing this day would come I've already created an EFI #1
partition, formatted with
# mkfs.fat -F 32 /dev/sda1
The current OS partitions are 10-17
Device          Start        End   Sectors  Size Type
/dev/sda1        2048    2099199   2097152    1G EFI System
/dev/sda2  1348483072 1350580223   2097152    1G BIOS boot
/dev/sda3     4196352   16779263  12582912    6G Linux swap
/dev/sda4    16779264   16781311      2048    1M Linux filesystem
/dev/sda5    16781312   16783359      2048    1M Linux filesystem
/dev/sda6    16783360   16785407      2048    1M Linux filesystem
/dev/sda7    16785408   16787455      2048    1M Linux filesystem
/dev/sda8    16787456   16789503      2048    1M Linux filesystem
/dev/sda9    16789504   16791551      2048    1M Linux filesystem
/dev/sda10   16791552  593508351 576716800  275G Linux filesystem
/dev/sda11  593508352  761280511 167772160   80G Linux filesystem
/dev/sda12  761280512  929052671 167772160   80G Linux filesystem
/dev/sda13  929052672 1096824831 167772160   80G Linux filesystem
/dev/sda14 1096824832 1264596991 167772160   80G Linux filesystem
/dev/sda15 1350580224 1518352383 167772160   80G Linux filesystem
/dev/sda16 1518352384 1686124543 167772160   80G Linux filesystem
/dev/sda17 1686124544 1853896703 167772160   80G Linux filesystem
My current motherboard supports Legacy BIOS only but I'm getting a new
board that supports EFI (only I think). How do I get the new motherboard
started up using my existing boot disk above?
What happens when the disk fails? What's the BIOS and boot recovery
after I restore all partitions form images? Can I also keep an image of
the EFI partition and run again with that after a recovery?
TIA

Least I'm mistaken, the only real change you'll need will be to grub2.
(I'm assuming your bootloader. YMMV). EFI partition will need to be
mounted (either to /efi or to /boot but standards will say /efi is the
way to go. Regardless of what you choose be sure that grub2 is updated
and you will probably need the efi boot manager (efibootmgr) and efivar
installed for grub2. (Assuming you use a package manager, those will be
present, otherwise use the directions from BLFS handbook)

You also need some kernel changes. This page includes the kernel changes
you need to make:

https://linuxfromscratch.org/blfs/view/stable-systemd/postlfs/grub-setup.html

Look at section "Kernel Configuration for UEFI support" section (it's
the first one.) Also you need secure boot off unless you sign your files
(out of scope for your question).

Execute command

[ grub-install --target=x86_64-efi --efi-directory=/efi
--bootloader-id=GRUB ]

you'll likely need to run

[ grub-mkconfig -o /boot/grub/grub.cfg ]

That should be everything. Be sure to update your /etc/fstab with the
EFI partition details. UEFI does not use any boot sectors or special
areas of the drive. It will simply look for a partition FAT32/VFAT of
type EFI and then look for a specific efi file in a specific directory
(/efi/EFI/bootx64.efi or /efi/EFI/grubx64.efi usually) and execute the
code in the efi binary. That gets the boot process started before it
hands it to the normal linux boot process from there.


Phillip Frabott
----------
- Adam: Is a void really a void if it returns?
- Jack: No, it's just nullspace at that point.
----------

[bad sector]

Post by Phillip Frabott

Post by bad sector
Since Intel have decided to fianally kill legacy BIOS in 2025 I have
no choice left. Knowing this day would come I've already created an
EFI #1 partition, formatted with
# mkfs.fat -F 32 /dev/sda1
The current OS partitions are 10-17
Device          Start        End   Sectors  Size Type
/dev/sda1        2048    2099199   2097152    1G EFI System
/dev/sda2  1348483072 1350580223   2097152    1G BIOS boot
/dev/sda3     4196352   16779263  12582912    6G Linux swap
/dev/sda4    16779264   16781311      2048    1M Linux filesystem
/dev/sda5    16781312   16783359      2048    1M Linux filesystem
/dev/sda6    16783360   16785407      2048    1M Linux filesystem
/dev/sda7    16785408   16787455      2048    1M Linux filesystem
/dev/sda8    16787456   16789503      2048    1M Linux filesystem
/dev/sda9    16789504   16791551      2048    1M Linux filesystem
/dev/sda10   16791552  593508351 576716800  275G Linux filesystem
/dev/sda11  593508352  761280511 167772160   80G Linux filesystem
/dev/sda12  761280512  929052671 167772160   80G Linux filesystem
/dev/sda13  929052672 1096824831 167772160   80G Linux filesystem
/dev/sda14 1096824832 1264596991 167772160   80G Linux filesystem
/dev/sda15 1350580224 1518352383 167772160   80G Linux filesystem
/dev/sda16 1518352384 1686124543 167772160   80G Linux filesystem
/dev/sda17 1686124544 1853896703 167772160   80G Linux filesystem
My current motherboard supports Legacy BIOS only but I'm getting a new
board that supports EFI (only I think). How do I get the new
motherboard started up using my existing boot disk above?
What happens when the disk fails? What's the BIOS and boot recovery
after I restore all partitions form images? Can I also keep an image
of the EFI partition and run again with that after a recovery?
TIA

Least I'm mistaken, the only real change you'll need will be to grub2.
(I'm assuming your bootloader. YMMV). EFI partition will need to be
mounted (either to /efi or to /boot but standards will say /efi is the
way to go.

I confuse real easy, especislly by facts, so I'll make it /efi to
minimise all incindence of confusion :-)

Post by Phillip Frabott
Regardless of what you choose be sure that grub2 is updated
and you will probably need the efi boot manager (efibootmgr) and efivar
installed for grub2. (Assuming you use a package manager, those will be
present, otherwise use the directions from BLFS handbook)
You also need some kernel changes. This page includes the kernel changes
https://linuxfromscratch.org/blfs/view/stable-systemd/postlfs/grub-
setup.html
Look at section "Kernel Configuration for UEFI support" section (it's
the first one.) Also you need secure boot off unless you sign your files
(out of scope for your question).
Execute command
[ grub-install --target=x86_64-efi --efi-directory=/efi --bootloader-
id=GRUB ]
you'll likely need to run
[ grub-mkconfig -o /boot/grub/grub.cfg ]
That should be everything. Be sure to update your /etc/fstab with the
EFI partition details. UEFI does not use any boot sectors or special
areas of the drive. It will simply look for a partition FAT32/VFAT of
type EFI and then look for a specific efi file in a specific directory
(/efi/EFI/bootx64.efi or /efi/EFI/grubx64.efi usually) and execute the
code in the efi binary. That gets the boot process started before it
hands it to the normal linux boot process from there.

Thanks, I'm saving this out for my 2be-used notes, also read my reply to
Paul who invariably favors me with learning curves I never knew existed!

Post by Phillip Frabott
Phillip Frabott
----------
- Adam: Is a void really a void if it returns?
- Jack: No, it's just nullspace at that point.
----------

[Paul]

Since Intel have decided to fianally kill legacy BIOS in 2025 I have no choice left. Knowing this day would come I've already created an EFI #1 partition, formatted with
# mkfs.fat -F 32 /dev/sda1
The current OS partitions are 10-17
Device          Start        End   Sectors  Size Type
/dev/sda1        2048    2099199   2097152    1G EFI System
/dev/sda2  1348483072 1350580223   2097152    1G BIOS boot
/dev/sda3     4196352   16779263  12582912    6G Linux swap
/dev/sda4    16779264   16781311      2048    1M Linux filesystem
/dev/sda5    16781312   16783359      2048    1M Linux filesystem
/dev/sda6    16783360   16785407      2048    1M Linux filesystem
/dev/sda7    16785408   16787455      2048    1M Linux filesystem
/dev/sda8    16787456   16789503      2048    1M Linux filesystem
/dev/sda9    16789504   16791551      2048    1M Linux filesystem
/dev/sda10   16791552  593508351 576716800  275G Linux filesystem
/dev/sda11  593508352  761280511 167772160   80G Linux filesystem
/dev/sda12  761280512  929052671 167772160   80G Linux filesystem
/dev/sda13  929052672 1096824831 167772160   80G Linux filesystem
/dev/sda14 1096824832 1264596991 167772160   80G Linux filesystem
/dev/sda15 1350580224 1518352383 167772160   80G Linux filesystem
/dev/sda16 1518352384 1686124543 167772160   80G Linux filesystem
/dev/sda17 1686124544 1853896703 167772160   80G Linux filesystem
My current motherboard supports Legacy BIOS only but I'm getting a new board that supports EFI (only I think). How do I get the new motherboard started up using my existing boot disk above?
What happens when the disk fails? What's the BIOS and boot recovery after I restore all partitions form images? Can I also keep an image of the EFI partition and run again with that after a recovery?
TIA

On a brand new disk, install a "teaser OS" as a means
of updating the key store on the new system.

Allow the teaser OS to run the show long enough, for a
new kernel to come in, and for the distro packages to be
updated.

Upon the reboot, the MOKUTIL will appear, and it will
try to update *two* things. Do not stop it, because you
will only have info about the first thing it is trying
to update. You will need a second machine, to consult
Google as to what to do, or what the possible responses
might be.

Once the teaser OS is stable, clone over the remaining OSes.
Do an upgrade-grub, so OS-prober adds them to the menu.

When one of the cloned OSes updates its kernel, it might
well assert MOKUTIL on the next reboot too.

It's at this point, you might notice the EFI messages change
from two lines to three lines. And then you might wonder
about the health of the thing.

As far as I know, for serious Secure Boot issues, it will
stop dead. Warnings from EFI don't prevent you from running,
so I suppose that "makes it OK". I would personally prefer
though, that the same two line status appear each time,
as proof the multi-boot is "living in harmony". The threads
I can pick up in a Google, are not suggestive that anyone
thinks multi-boot is well supported as such.

These are two examples of recorded messages, just to show
what hairballs come out of the thing.

EFI stub: WARNING: Failed to measure data for event 1: 0x80000000
EFI stub: Loaded initrd from LINUX_EFI_INITRD_MEDIA_GUID device path
EFI stub: WARNING: Failed to measure data for event 0: 0x80000000
EFI stub: UEFI Secure Boot is enabled.

and after a teaser install

EFI stub: Loaded initrd from LINUX_EFI_INITRD_MEDIA_GUID device path
EFI stub: Measured initrd data into PCR 9
EFI stub: UEFI Secure Boot is enabled.

I have also seen references to PCR 7. Am I using up a resource ? Dunno.

Paul

[bad sector]

Post by Paul

Since Intel have decided to fianally kill legacy BIOS in 2025 I have no choice left. Knowing this day would come I've already created an EFI #1 partition, formatted with
# mkfs.fat -F 32 /dev/sda1
The current OS partitions are 10-17
Device          Start        End   Sectors  Size Type
/dev/sda1        2048    2099199   2097152    1G EFI System
/dev/sda2  1348483072 1350580223   2097152    1G BIOS boot
/dev/sda3     4196352   16779263  12582912    6G Linux swap
/dev/sda4    16779264   16781311      2048    1M Linux filesystem
/dev/sda5    16781312   16783359      2048    1M Linux filesystem
/dev/sda6    16783360   16785407      2048    1M Linux filesystem
/dev/sda7    16785408   16787455      2048    1M Linux filesystem
/dev/sda8    16787456   16789503      2048    1M Linux filesystem
/dev/sda9    16789504   16791551      2048    1M Linux filesystem
/dev/sda10   16791552  593508351 576716800  275G Linux filesystem
/dev/sda11  593508352  761280511 167772160   80G Linux filesystem
/dev/sda12  761280512  929052671 167772160   80G Linux filesystem
/dev/sda13  929052672 1096824831 167772160   80G Linux filesystem
/dev/sda14 1096824832 1264596991 167772160   80G Linux filesystem
/dev/sda15 1350580224 1518352383 167772160   80G Linux filesystem
/dev/sda16 1518352384 1686124543 167772160   80G Linux filesystem
/dev/sda17 1686124544 1853896703 167772160   80G Linux filesystem
My current motherboard supports Legacy BIOS only but I'm getting a new board that supports EFI (only I think). How do I get the new motherboard started up using my existing boot disk above?
What happens when the disk fails? What's the BIOS and boot recovery after I restore all partitions form images? Can I also keep an image of the EFI partition and run again with that after a recovery?
TIA

On a brand new disk, install a "teaser OS" as a means
of updating the key store on the new system.
Allow the teaser OS to run the show long enough, for a
new kernel to come in, and for the distro packages to be
updated.
Upon the reboot, the MOKUTIL will appear, and it will
try to update *two* things. Do not stop it, because you
will only have info about the first thing it is trying
to update. You will need a second machine, to consult
Google as to what to do, or what the possible responses
might be.
Once the teaser OS is stable, clone over the remaining OSes.
Do an upgrade-grub, so OS-prober adds them to the menu.
When one of the cloned OSes updates its kernel, it might
well assert MOKUTIL on the next reboot too.
It's at this point, you might notice the EFI messages change
from two lines to three lines. And then you might wonder
about the health of the thing.
As far as I know, for serious Secure Boot issues, it will
stop dead. Warnings from EFI don't prevent you from running,
so I suppose that "makes it OK". I would personally prefer
though, that the same two line status appear each time,
as proof the multi-boot is "living in harmony". The threads
I can pick up in a Google, are not suggestive that anyone
thinks multi-boot is well supported as such.
These are two examples of recorded messages, just to show
what hairballs come out of the thing.
EFI stub: WARNING: Failed to measure data for event 1: 0x80000000
EFI stub: Loaded initrd from LINUX_EFI_INITRD_MEDIA_GUID device path
EFI stub: WARNING: Failed to measure data for event 0: 0x80000000
EFI stub: UEFI Secure Boot is enabled.
and after a teaser install
EFI stub: Loaded initrd from LINUX_EFI_INITRD_MEDIA_GUID device path
EFI stub: Measured initrd data into PCR 9
EFI stub: UEFI Secure Boot is enabled.
I have also seen references to PCR 7. Am I using up a resource ? Dunno.
Paul

Both of you are kind enough to help me learn how to land on Mars but
what I need first is how to get into Earth orbit.

After physically installing my new board and having given myself a crash
course in the "Ab Initio" EFI-Boot* (formerly BIOS) manual, I would
start by turning the box ON. But even that won't work because this EFI
horror gets its stuff from the hard drive and not from a chip ...the
way I think it works.

That teaser OS might be a good idea, although Suse uses systemd their
Tumbleweed provisionally remains my go2 OS and it offers a management
module for installing things, grub2 included. All my OSes are backed up
so I could also just run grub after successfully booting one of them
(except Slack which uses no grub). Until I change it grub still rules
the underworld on my drive so will it at least give a grub prompt on
that first boot?

My current board supports no EFI, can I still do the cited edits/changes
preemptively? what I ned is a step-by-step from the time I unbox and
install the board.


* I've read somewhere that 'BIOS' is still being used because it's a
familiar expression as opposed to "Extensible Fubar Interface Boot
Framework". EFIB could stand for EFI-Boot but that sounds too much like
a shit-stuffing chimney-sweep so I think I'll suggest BEFI standing for
"Boot Extensible Fubar Interface", or FBI for short, "Firmware Boot
Interface" (hint).

[Paul]

Post by Paul

Since Intel have decided to fianally kill legacy BIOS in 2025 I have no choice left. Knowing this day would come I've already created an EFI #1 partition, formatted with
# mkfs.fat -F 32 /dev/sda1
The current OS partitions are 10-17
Device          Start        End   Sectors  Size Type
/dev/sda1        2048    2099199   2097152    1G EFI System
/dev/sda2  1348483072 1350580223   2097152    1G BIOS boot
/dev/sda3     4196352   16779263  12582912    6G Linux swap
/dev/sda4    16779264   16781311      2048    1M Linux filesystem
/dev/sda5    16781312   16783359      2048    1M Linux filesystem
/dev/sda6    16783360   16785407      2048    1M Linux filesystem
/dev/sda7    16785408   16787455      2048    1M Linux filesystem
/dev/sda8    16787456   16789503      2048    1M Linux filesystem
/dev/sda9    16789504   16791551      2048    1M Linux filesystem
/dev/sda10   16791552  593508351 576716800  275G Linux filesystem
/dev/sda11  593508352  761280511 167772160   80G Linux filesystem
/dev/sda12  761280512  929052671 167772160   80G Linux filesystem
/dev/sda13  929052672 1096824831 167772160   80G Linux filesystem
/dev/sda14 1096824832 1264596991 167772160   80G Linux filesystem
/dev/sda15 1350580224 1518352383 167772160   80G Linux filesystem
/dev/sda16 1518352384 1686124543 167772160   80G Linux filesystem
/dev/sda17 1686124544 1853896703 167772160   80G Linux filesystem
My current motherboard supports Legacy BIOS only but I'm getting a new board that supports EFI (only I think). How do I get the new motherboard started up using my existing boot disk above?
What happens when the disk fails? What's the BIOS and boot recovery after I restore all partitions form images? Can I also keep an image of the EFI partition and run again with that after a recovery?
TIA

On a brand new disk, install a "teaser OS" as a means
of updating the key store on the new system.
Allow the teaser OS to run the show long enough, for a
new kernel to come in, and for the distro packages to be
updated.
Upon the reboot, the MOKUTIL will appear, and it will
try to update *two* things. Do not stop it, because you
will only have info about the first thing it is trying
to update. You will need a second machine, to consult
Google as to what to do, or what the possible responses
might be.
Once the teaser OS is stable, clone over the remaining OSes.
Do an upgrade-grub, so OS-prober adds them to the menu.
When one of the cloned OSes updates its kernel, it might
well assert MOKUTIL on the next reboot too.
It's at this point, you might notice the EFI messages change
from two lines to three lines. And then you might wonder
about the health of the thing.
As far as I know, for serious Secure Boot issues, it will
stop dead. Warnings from EFI don't prevent you from running,
so I suppose that "makes it OK". I would personally prefer
though, that the same two line status appear each time,
as proof the multi-boot is "living in harmony". The threads
I can pick up in a Google, are not suggestive that anyone
thinks multi-boot is well supported as such.
These are two examples of recorded messages, just to show
what hairballs come out of the thing.
    EFI stub: WARNING: Failed to measure data for event 1: 0x80000000
    EFI stub: Loaded initrd from LINUX_EFI_INITRD_MEDIA_GUID device path
    EFI stub: WARNING: Failed to measure data for event 0: 0x80000000
    EFI stub: UEFI Secure Boot is enabled.
and after a teaser install
    EFI stub: Loaded initrd from LINUX_EFI_INITRD_MEDIA_GUID device path
    EFI stub: Measured initrd data into PCR 9
    EFI stub: UEFI Secure Boot is enabled.
I have also seen references to PCR 7. Am I using up a resource ? Dunno.
    Paul

Both of you are kind enough to help me learn how to land on Mars but what I need first is how to get into Earth orbit.
After physically installing my new board and having given myself a crash course in the "Ab Initio" EFI-Boot* (formerly BIOS) manual, I would start by turning the box ON. But even that won't work because this EFI horror gets its stuff from the hard drive and not from a chip  ...the way I think it works.
That teaser OS might be a good idea, although Suse uses systemd their Tumbleweed provisionally remains my go2 OS and it offers a management module for installing things, grub2 included. All my OSes are backed up so I could also just run grub after successfully booting one of them (except Slack which uses no grub). Until I change it grub still rules the underworld on my drive so will it at least give a grub prompt on that first boot?
My current board supports no EFI, can I still do the cited edits/changes preemptively? what I ned is a step-by-step from the time I unbox and install the board.
* I've read somewhere that 'BIOS' is still being used because it's a familiar expression as opposed to "Extensible Fubar Interface Boot Framework". EFIB could stand for EFI-Boot but that sounds too much like a shit-stuffing chimney-sweep so I think I'll suggest BEFI standing for "Boot Extensible Fubar Interface", or FBI for short, "Firmware Boot Interface" (hint).

I did my practicing on a dual mode machine (UEFI and CSM Legacy).
I switched that machine to UEFI-only, to emulate a year 2025 type
machine that only does UEFI. Some of the messages on the screen,
the offset from the edge of the screen and the appearance,
are suggestive of the EFI era.

By using a dual mode machine, I get to "sample" what working in
a UEFI-only environment would be like.

Yes, it takes more than one setting in the BIOS screen, to
successfully enable UEFI plus the Secure Boot option. and when
the installer detects this, your teaser OS install knows it needs
to install Linux Shim support. Both Microsoft and Linux have worked
to modify the boot materials. The keys are stored in NVRAM in
the motherboard BIOS chip (a 4MB area of NOR flash). A lot of that
flash area, is given to "boot path storage".

Microsoft revoked their original certificate and has installed
a second one. In a Linux only environment then, there might
be some related operations the MOKUTIL is doing on a reboot.
It may be trying to install the Microsoft material as the "base coat"
for the shim. And some aspect of the signed shim that rests on top
is the rest of it.

I wasn't attempting to understand all of it, when I did mine. I just
wanted to see if I could get something/anything to work. and based
on the PCR "register number", I can't really tell how many
resources in my fTPM are left. Only one machine has a real TPM here,
the others have the firmware fakery in its place. And the fTPM has
PCR registers like a real TPM has.

What I was doing, is sort of a "fire drill". seeing if I could
get out, in the event of a fire... It seemed to be working, but
I could never be sure, exactly how many of the distros were moving
in the same direction I was moving. There is never any overview
indicating you could be doing a better job of it.

Paul

[bad sector]

Post by Paul

Post by Paul

Since Intel have decided to fianally kill legacy BIOS in 2025 I have no choice left. Knowing this day would come I've already created an EFI #1 partition, formatted with
# mkfs.fat -F 32 /dev/sda1
The current OS partitions are 10-17
Device          Start        End   Sectors  Size Type
/dev/sda1        2048    2099199   2097152    1G EFI System
/dev/sda2  1348483072 1350580223   2097152    1G BIOS boot
/dev/sda3     4196352   16779263  12582912    6G Linux swap
/dev/sda4    16779264   16781311      2048    1M Linux filesystem
/dev/sda5    16781312   16783359      2048    1M Linux filesystem
/dev/sda6    16783360   16785407      2048    1M Linux filesystem
/dev/sda7    16785408   16787455      2048    1M Linux filesystem
/dev/sda8    16787456   16789503      2048    1M Linux filesystem
/dev/sda9    16789504   16791551      2048    1M Linux filesystem
/dev/sda10   16791552  593508351 576716800  275G Linux filesystem
/dev/sda11  593508352  761280511 167772160   80G Linux filesystem
/dev/sda12  761280512  929052671 167772160   80G Linux filesystem
/dev/sda13  929052672 1096824831 167772160   80G Linux filesystem
/dev/sda14 1096824832 1264596991 167772160   80G Linux filesystem
/dev/sda15 1350580224 1518352383 167772160   80G Linux filesystem
/dev/sda16 1518352384 1686124543 167772160   80G Linux filesystem
/dev/sda17 1686124544 1853896703 167772160   80G Linux filesystem
My current motherboard supports Legacy BIOS only but I'm getting a new board that supports EFI (only I think). How do I get the new motherboard started up using my existing boot disk above?
What happens when the disk fails? What's the BIOS and boot recovery after I restore all partitions form images? Can I also keep an image of the EFI partition and run again with that after a recovery?
TIA

On a brand new disk, install a "teaser OS" as a means
of updating the key store on the new system.
Allow the teaser OS to run the show long enough, for a
new kernel to come in, and for the distro packages to be
updated.
Upon the reboot, the MOKUTIL will appear, and it will
try to update *two* things. Do not stop it, because you
will only have info about the first thing it is trying
to update. You will need a second machine, to consult
Google as to what to do, or what the possible responses
might be.
Once the teaser OS is stable, clone over the remaining OSes.
Do an upgrade-grub, so OS-prober adds them to the menu.
When one of the cloned OSes updates its kernel, it might
well assert MOKUTIL on the next reboot too.
It's at this point, you might notice the EFI messages change
from two lines to three lines. And then you might wonder
about the health of the thing.
As far as I know, for serious Secure Boot issues, it will
stop dead. Warnings from EFI don't prevent you from running,
so I suppose that "makes it OK". I would personally prefer
though, that the same two line status appear each time,
as proof the multi-boot is "living in harmony". The threads
I can pick up in a Google, are not suggestive that anyone
thinks multi-boot is well supported as such.
These are two examples of recorded messages, just to show
what hairballs come out of the thing.
    EFI stub: WARNING: Failed to measure data for event 1: 0x80000000
    EFI stub: Loaded initrd from LINUX_EFI_INITRD_MEDIA_GUID device path
    EFI stub: WARNING: Failed to measure data for event 0: 0x80000000
    EFI stub: UEFI Secure Boot is enabled.
and after a teaser install
    EFI stub: Loaded initrd from LINUX_EFI_INITRD_MEDIA_GUID device path
    EFI stub: Measured initrd data into PCR 9
    EFI stub: UEFI Secure Boot is enabled.
I have also seen references to PCR 7. Am I using up a resource ? Dunno.
    Paul

Both of you are kind enough to help me learn how to land on Mars but what I need first is how to get into Earth orbit.
After physically installing my new board and having given myself a crash course in the "Ab Initio" EFI-Boot* (formerly BIOS) manual, I would start by turning the box ON. But even that won't work because this EFI horror gets its stuff from the hard drive and not from a chip  ...the way I think it works.
That teaser OS might be a good idea, although Suse uses systemd their Tumbleweed provisionally remains my go2 OS and it offers a management module for installing things, grub2 included. All my OSes are backed up so I could also just run grub after successfully booting one of them (except Slack which uses no grub). Until I change it grub still rules the underworld on my drive so will it at least give a grub prompt on that first boot?
My current board supports no EFI, can I still do the cited edits/changes preemptively? what I ned is a step-by-step from the time I unbox and install the board.
* I've read somewhere that 'BIOS' is still being used because it's a familiar expression as opposed to "Extensible Fubar Interface Boot Framework". EFIB could stand for EFI-Boot but that sounds too much like a shit-stuffing chimney-sweep so I think I'll suggest BEFI standing for "Boot Extensible Fubar Interface", or FBI for short, "Firmware Boot Interface" (hint).

I did my practicing on a dual mode machine (UEFI and CSM Legacy).
I switched that machine to UEFI-only, to emulate a year 2025 type
machine that only does UEFI. Some of the messages on the screen,
the offset from the edge of the screen and the appearance,
are suggestive of the EFI era.
By using a dual mode machine, I get to "sample" what working in
a UEFI-only environment would be like.
Yes, it takes more than one setting in the BIOS screen, to
successfully enable UEFI plus the Secure Boot option. and when
the installer detects this, your teaser OS install knows it needs
to install Linux Shim support. Both Microsoft and Linux have worked
to modify the boot materials. The keys are stored in NVRAM in
the motherboard BIOS chip (a 4MB area of NOR flash). A lot of that
flash area, is given to "boot path storage".

OK, so I was mistaken in thinking that this UEFI rig was entirely disk
based, that's a relief :-)

Post by Paul
Microsoft revoked their original certificate and has installed
a second one. In a Linux only environment then, there might
be some related operations the MOKUTIL is doing on a reboot.
It may be trying to install the Microsoft material as the "base coat"
for the shim. And some aspect of the signed shim that rests on top
is the rest of it.

There seems to be a lot of strange footprint tracks lurking in the
shadows both by Intel and Microcancer and their whores, I put them all
in the same bag

uuid
systemd
keyrings
EFI
Secure-Boot

Post by Paul
I wasn't attempting to understand all of it, when I did mine. I just
wanted to see if I could get something/anything to work. and based
on the PCR "register number", I can't really tell how many
resources in my fTPM are left. Only one machine has a real TPM here,
the others have the firmware fakery in its place. And the fTPM has
PCR registers like a real TPM has.
What I was doing, is sort of a "fire drill". seeing if I could
get out, in the event of a fire... It seemed to be working, but
I could never be sure, exactly how many of the distros were moving
in the same direction I was moving. There is never any overview
indicating you could be doing a better job of it.

I have no idea how many distros are really free, as in unattached to
vermin, I'd like to see one started by the guru himself, call it *Linus'
Finger*

[Anssi Saari]

Post by bad sector
After physically installing my new board and having given myself a
crash course in the "Ab Initio" EFI-Boot* (formerly BIOS) manual, I
would start by turning the box ON. But even that won't work because
this EFI horror gets its stuff from the hard drive and not from a chip
...the way I think it works.

So what's make and model of the new motherboard? Are you sure it doesn't
have BIOS emulation, it's commonly also called CSM for compatibility
support module. It seems my few years old Asrock motherboard for example
isn't even seriously expecting anyone to run EFI only, they outright
recommend leaving CSM on. In practice, the EFI USB keyboard support
doesn't work much at all in Grub if I turn it off.

Anyways, if your new motherboard *has* BIOS emulation, things are fairly
easy. At least I managed to convert from BIOS boot and old school MS-DOS
partition table to EFI and GPT without issue, adapting the instructions
here:

https://www.rojtberg.net/1032/converting-a-ubuntu-and-windows-dual-boot-installation-to-uefi/

But that has extra fluff for your case since it considers converting a
Windows/Ubuntu dual boot system and also it worries about Secure Boot
which can well be skipped. But the simple instructions worked fine also
in my case with a Windows 10/Debian/Arch setup. The Linux specific
conversion in my case was just booting Debian and Arch from a USB stick,
then installing grub-efi in a chroot.

OTOH, I'm not sure what's wrong with installing whatever OS(es) you want
and restoring data from backups? That'd be more like the getting into orbit
before landing on Mars solution I think.

[bad sector]

Post by Anssi Saari

Post by bad sector
After physically installing my new board and having given myself a
crash course in the "Ab Initio" EFI-Boot* (formerly BIOS) manual, I
would start by turning the box ON. But even that won't work because
this EFI horror gets its stuff from the hard drive and not from a chip
...the way I think it works.

So what's make and model of the new motherboard? Are you sure it doesn't
have BIOS emulation, it's commonly also called CSM for compatibility
support module. It seems my few years old Asrock motherboard for example
isn't even seriously expecting anyone to run EFI only, they outright
recommend leaving CSM on. In practice, the EFI USB keyboard support
doesn't work much at all in Grub if I turn it off.
Anyways, if your new motherboard *has* BIOS emulation, things are fairly
easy. At least I managed to convert from BIOS boot and old school MS-DOS
partition table to EFI and GPT without issue, adapting the instructions
https://www.rojtberg.net/1032/converting-a-ubuntu-and-windows-dual-boot-installation-to-uefi/
But that has extra fluff for your case since it considers converting a
Windows/Ubuntu dual boot system and also it worries about Secure Boot
which can well be skipped. But the simple instructions worked fine also
in my case with a Windows 10/Debian/Arch setup. The Linux specific
conversion in my case was just booting Debian and Arch from a USB stick,
then installing grub-efi in a chroot.
OTOH, I'm not sure what's wrong with installing whatever OS(es) you want
and restoring data from backups? That'd be more like the getting into orbit
before landing on Mars solution I think.

Never in my life have I spent as much time to decide hardware as in this
last round, the decision to go with an Asrock x870e Taichi "LITE"
(anything but LED shows thank you!) landed soon after I posted so your
remarks about emulation sound like good news. Thank you. So long as they
keep Legacy BIOS as a workable option I'll certainly buy their stuff and
use Legacy-BIOS but knowing your enemy adds to the romance of mauling it
to shreds so that the EFI/SecureBoot learning curve is inevitable. Last
night I only had time to download the manual, haven't seen the separate
board-specific BIOS manual yet (being used to the Asus way of doing it).
The motherboard is out of stock at the very few retail stores I would
consider trusting so the bird isn't in the hand just yet and much can
change between now and then.

Long term, I would do everything I can to avoid both EFI and Secure-Boot
because to my nose both smell putrid cubed, but that's for later. For
now I'll try the fresh dummy OS install and then recover my existing
OSes in turn. That seems to be the simplest approach as per most of the
advice received. BTW I had Ubuntu-Studio running for a long time, until
they lost me with that snap or whatever it was called, it would not
respect my way of using a complex of links to my home and sub home
folders :-(

[Dan Purgert]

Post by bad sector
Since Intel have decided to fianally kill legacy BIOS in 2025 I have no
choice left. Knowing this day would come I've already created an EFI #1
partition, formatted with
# mkfs.fat -F 32 /dev/sda1
[...]
My current motherboard supports Legacy BIOS only but I'm getting a new
board that supports EFI (only I think). How do I get the new motherboard
started up using my existing boot disk above?
What happens when the disk fails? What's the BIOS and boot recovery
after I restore all partitions form images? Can I also keep an image of
the EFI partition and run again with that after a recovery?

The disk fails.

The "EFI System Partition" isn't really all that functionally different
than the MBR of HDD on a BIOS-boot computer. I *BELIEVE* you have to
specifically format this as "EFI System Partition" instead of just FAT32
(but I've never done it manually).

I *BELIEVE* that this system partition is required to be stuffed
somewhere within the first 2 TiB of a GPT-formatted drive, such that it
is backwards compatible with MBR.

Primary UEFI configuration (e.g. date/time, hardware config, etc.) all
lives on battery-backed RAM of some sort or other, same as it always has
under BIOS.

[Paul]

Post by Dan Purgert

Post by bad sector
Since Intel have decided to fianally kill legacy BIOS in 2025 I have no
choice left. Knowing this day would come I've already created an EFI #1
partition, formatted with
# mkfs.fat -F 32 /dev/sda1
[...]
My current motherboard supports Legacy BIOS only but I'm getting a new
board that supports EFI (only I think). How do I get the new motherboard
started up using my existing boot disk above?
What happens when the disk fails? What's the BIOS and boot recovery
after I restore all partitions form images? Can I also keep an image of
the EFI partition and run again with that after a recovery?

The disk fails.
The "EFI System Partition" isn't really all that functionally different
than the MBR of HDD on a BIOS-boot computer. I *BELIEVE* you have to
specifically format this as "EFI System Partition" instead of just FAT32
(but I've never done it manually).
I *BELIEVE* that this system partition is required to be stuffed
somewhere within the first 2 TiB of a GPT-formatted drive, such that it
is backwards compatible with MBR.
Primary UEFI configuration (e.g. date/time, hardware config, etc.) all
lives on battery-backed RAM of some sort or other, same as it always has
under BIOS.

The GPT table has two kinds of numbers in it

GUID which functions as a block ID

GUID which functions as a partition type declaration

In Linux GDisk, they have a nice feature, where the second 128 bit number
is encoded as a four digit hex number. For example, if GDISK uses
0x0700 that is the old NTFS in a sense (0x07). But that is actually
a "Basic Data Partition" or ebd0a0a2-b9e5-4433-87c0-68b6b72699c7.
Linux uses that shorthand, mainly to not scare the shit out of the user :-)

https://en.wikipedia.org/wiki/Microsoft_basic_data_partition

"A basic data partition can be formatted with any file system,
although most commonly BDPs are formatted with the NTFS, exFAT,
or FAT32 file systems."

OK, so consider for a moment, that the ESP has a custom declaration.
This means there are custom properties, such as a "hands off, pal"
property. You cannot format it.

But there is a cheat :-) I know you'll like this. You can "dd"
over top of it.

sudo dd if=bunk.img of=/dev/sda1

and now it's ruined. Easy, peasy. Similarly, you can make
a copy of the /dev/sda1, loopback mount it, format it FAT32,
unmount, dd over top of /dev/sda1. But there is still something
weird about that FAT32, that I haven't been able to put my finger on.

It's a brave new world. Lots of fun awaits :-) It took
me a while to find a weakness to exploit. I didn't know that
the first day I made a GPT. it might have been a year later.

Even figuring out the size of the partition table, was a menace.
Originally, I thought the partition table was 128MB.
It just might be 16KB (128*128) or so. A *lot* smaller than my pathetic
first info gleaned from some thread I was reading. You can take
your hex editor, scroll over the last cylinder of your disk
drive, and see the secondary partition table. If only
a few entries are occupied, the table looks very short indeed.
You could easily miss it.

[Picture]

Loading Image...

DISKPART> list partition

Partition ### Type Size Offset
------------- ---------------- ------- -------
Partition 1 System 100 MB 1024 KB \
Partition 2 Reserved 16 MB 101 MB \
Partition 3 Primary 118 GB 117 MB \___ These are in the above picture
Partition 4 Recovery 649 MB 118 GB /
Partition 5 Primary 128 GB 119 GB /
Partition 6 Recovery 1025 MB 248 GB
Partition 7 Primary 682 GB 249 GB

DISKPART> select partition 3

Partition 3 is now the selected partition.

DISKPART> detail partition

Partition 3
Type : ebd0a0a2-b9e5-4433-87c0-68b6b72699c7
Hidden : No
Required: No
Attrib : 0000000000000000
Offset in Bytes: 122683392

Volume ### Ltr Label Fs Type Size Status Info
---------- --- ----------- ----- ---------- ------- --------- --------
* Volume 0 C W11HOME NTFS Partition 118 GB Healthy Boot

DISKPART>

Paul

[Carlos E.R.]

Post by bad sector
Since Intel have decided to fianally kill legacy BIOS in 2025 I have no
choice left. Knowing this day would come I've already created an EFI #1
partition, formatted with
# mkfs.fat -F 32 /dev/sda1
The current OS partitions are 10-17
Device          Start        End   Sectors  Size Type
/dev/sda1        2048    2099199   2097152    1G EFI System
/dev/sda2  1348483072 1350580223   2097152    1G BIOS boot
/dev/sda3     4196352   16779263  12582912    6G Linux swap
/dev/sda4    16779264   16781311      2048    1M Linux filesystem
/dev/sda5    16781312   16783359      2048    1M Linux filesystem
/dev/sda6    16783360   16785407      2048    1M Linux filesystem
/dev/sda7    16785408   16787455      2048    1M Linux filesystem
/dev/sda8    16787456   16789503      2048    1M Linux filesystem
/dev/sda9    16789504   16791551      2048    1M Linux filesystem
/dev/sda10   16791552  593508351 576716800  275G Linux filesystem
/dev/sda11  593508352  761280511 167772160   80G Linux filesystem
/dev/sda12  761280512  929052671 167772160   80G Linux filesystem
/dev/sda13  929052672 1096824831 167772160   80G Linux filesystem
/dev/sda14 1096824832 1264596991 167772160   80G Linux filesystem
/dev/sda15 1350580224 1518352383 167772160   80G Linux filesystem
/dev/sda16 1518352384 1686124543 167772160   80G Linux filesystem
/dev/sda17 1686124544 1853896703 167772160   80G Linux filesystem

Get better information this way (one line):

lsblk --output
NAME,KNAME,RA,RM,RO,PARTFLAGS,SIZE,TYPE,FSTYPE,LABEL,PARTLABEL,PTTYPE,MOUNTPOINT,UUID,PARTUUID,WWN,MODEL,ALIGNMENT

Post by bad sector
My current motherboard supports Legacy BIOS only but I'm getting a new
board that supports EFI (only I think). How do I get the new motherboard
started up using my existing boot disk above?

There is an important detail missing: what distribution are you using?

[...]

Reading further ahead in the thread I find that it is openSUSE Tumbleweed.

Then the EFI partition is mounted on /boot/efi, and it has this structure:

***@Telcontar:~> tree -d /boot/efi
/boot/efi
├── EFI
│   ├── auxiliary
│   ├── boot
│   └── main-os
└── quitados
├── boot
├── main_opensuse
└── no_opensuse

8 directories
***@Telcontar:~>

Ignore "quitados", that's and old one I removed manually.

The directories there each reflect one operating system, and they are
arbitrary.

What I would do is install first a small opensuse system on your new
machine, for the purpose of having a running system and seeing how it
does things.

The default name of the directory under EFI is "opensuse" (if memory
serves). It uses that name for all installs, so they overwrite one
another. So you have to change the name. The name is defined in file
/etc/default/grub, variable "GRUB_DISTRIBUTOR":

# If you change this file, run 'grub2-mkconfig -o
/boot/grub2/grub.cfg' afterwards to update
# /boot/grub2/grub.cfg.

# Uncomment to set your own custom distributor. If you leave it unset
or empty, the default
# policy is to determine the value from /etc/os-release
GRUB_DISTRIBUTOR="main-os"


Once you edit the name there, do what the comments above say. There is a
second step needed, "mkinitrd", but the utility has been deprecated and
is missing in Tumbleweed. The equivalent concoction I have been told it is:

dracut -f --regenerate-all --logfile /var/log/YaST2/mkinitrd.log
update-bootloader --refresh


What I would do, though, is start up yast (text) or yast2 (graphical),
go to "System/Boot Loader" and in the section "Bootloader Options"
change the "Timeout in Seconds" onse second up or down, and tap the "Ok"
button. This trick forces YaST to write up, refresh, the entire boot
system files.

Then verify the name

tree -d /boot/efi

Verify by rebooting. You will see that the name you created is used in
the grub menu.

WARNING: Not every char is accepted here, and I don't know the rules. My
computer accepts "-" but not "_", go figure. The errors are strange and
misleading.




Clone your old computer to the new one. You can use this small system to
create the partitions and rsync them, for instance.


Now, what I would do to boot your cloned system is to
mount its "/", /boot (if it exists as separate partition) and /boot/efi
partitions somewhere, say "/new", then chroot to that /new partition.
Before issuing the chroot command, do:

mount --bind /proc /new/proc
mount --bind /sys /new/sys
mount --bind /dev /new/dev

chroot /new
yast

Verify:

:~# grep GRUB_DISTRIBUTOR /etc/default/grub
GRUB_DISTRIBUTOR="opensuse"
:~ #


It should say the name of your old system.


Notice that "yast" starts in text mode. Do not try to run the graphical
version (yast2). Go to the boot module. Under the tab "Boot Code
Options", change the "Boot loader" to "Grub2 for EFI".

And that's it.

Check that every other option is correct. I did this years ago, so I am
not fully sure there is something else to change, but basically that's all.

Press OK, exit the chroot, and reboot.


If there are errors, correct them as appropriate. I use Leap, not
Tumbleweed, so there might be some differences.



Notice that it is important that you follow the SUSE way of doing
things, or you will have problems any time you run updates that touch
the kernel or the boot system.


I would recommend you change the name of the system (GRUB_DISTRIBUTOR)
to something else, like tumbleweed.

[bad sector]

Post by Carlos E.R.

Post by bad sector
Since Intel have decided to fianally kill legacy BIOS in 2025 I have

no choice left. Knowing this day would come I've already created an EFI
#1 partition, formatted with

Post by Carlos E.R.

Post by bad sector
# mkfs.fat -F 32 /dev/sda1
The current OS partitions are 10-17
Device Start End Sectors Size Type
/dev/sda1 2048 2099199 2097152 1G EFI System
/dev/sda2 1348483072 1350580223 2097152 1G BIOS boot
/dev/sda3 4196352 16779263 12582912 6G Linux swap
/dev/sda4 16779264 16781311 2048 1M Linux filesystem
/dev/sda5 16781312 16783359 2048 1M Linux filesystem
/dev/sda6 16783360 16785407 2048 1M Linux filesystem
/dev/sda7 16785408 16787455 2048 1M Linux filesystem
/dev/sda8 16787456 16789503 2048 1M Linux filesystem
/dev/sda9 16789504 16791551 2048 1M Linux filesystem
/dev/sda10 16791552 593508351 576716800 275G Linux filesystem
/dev/sda11 593508352 761280511 167772160 80G Linux filesystem
/dev/sda12 761280512 929052671 167772160 80G Linux filesystem
/dev/sda13 929052672 1096824831 167772160 80G Linux filesystem
/dev/sda14 1096824832 1264596991 167772160 80G Linux filesystem
/dev/sda15 1350580224 1518352383 167772160 80G Linux filesystem
/dev/sda16 1518352384 1686124543 167772160 80G Linux filesystem
/dev/sda17 1686124544 1853896703 167772160 80G Linux filesystem

lsblk --output

NAME,KNAME,RA,RM,RO,PARTFLAGS,SIZE,TYPE,FSTYPE,LABEL,PARTLABEL,PTTYPE,MOUNTPOINT,UUID,PARTUUID,WWN,MODEL,ALIGNMENT

Post by Carlos E.R.

Post by bad sector
My current motherboard supports Legacy BIOS only but I'm getting a

new board that supports EFI (only I think). How do I get the new
motherboard started up using my existing boot disk above?

Post by Carlos E.R.
There is an important detail missing: what distribution are you using?

Currently Artix, Devuan, Slackware, Tumbleweed, VoidLinux but it has
been up to seven at times, booting a different one every day of the
week. Tumnbleweed is still my go2 system so I usuaklky get Yast to do
the boot setup but when installing another OS I let it install and run
grub also just so as to have all the bits and pieces in place. Slackware
doesn't use grub and I havent really do much with Void yet.

Post by Carlos E.R.
Reading further ahead in the thread I find that it is openSUSE

Tumbleweed.

Post by Carlos E.R.
/boot/efi
├── EFI
│ ├── auxiliary
│ ├── boot
│ └── main-os
└── quitados
├── boot
├── main_opensuse
└── no_opensuse
8 directories
Ignore "quitados", that's and old one I removed manually.
The directories there each reflect one operating system, and they are

arbitrary.

Post by Carlos E.R.
What I would do is install first a small opensuse system on your new

machine, for the purpose of having a running system and seeing how it
does things.

Post by Carlos E.R.
The default name of the directory under EFI is "opensuse" (if memory

serves). It uses that name for all installs, so they overwrite one
another. So you have to change the name. The name is defined in file /

Post by Carlos E.R.
# If you change this file, run 'grub2-mkconfig -o /boot/grub2/

grub.cfg' afterwards to update

Post by Carlos E.R.
# /boot/grub2/grub.cfg.
# Uncomment to set your own custom distributor. If you leave it

unset or empty, the default

Post by Carlos E.R.
# policy is to determine the value from /etc/os-release
GRUB_DISTRIBUTOR="main-os"
Once you edit the name there, do what the comments above say. There

is a second step needed, "mkinitrd", but the utility has been deprecated
and is missing in Tumbleweed. The equivalent concoction I have been told

Post by Carlos E.R.
dracut -f --regenerate-all --logfile /var/log/YaST2/mkinitrd.log
update-bootloader --refresh
What I would do, though, is start up yast (text) or yast2

(graphical), go to "System/Boot Loader" and in the section "Bootloader
Options" change the "Timeout in Seconds" onse second up or down, and tap
the "Ok" button. This trick forces YaST to write up, refresh, the entire
boot system files.

Post by Carlos E.R.
Then verify the name
tree -d /boot/efi
Verify by rebooting. You will see that the name you created is used

in the grub menu.

Post by Carlos E.R.
WARNING: Not every char is accepted here, and I don't know the rules.

My computer accepts "-" but not "_", go figure. The errors are strange
and misleading.

Post by Carlos E.R.
Clone your old computer to the new one. You can use this small system

to create the partitions and rsync them, for instance.

Post by Carlos E.R.
Now, what I would do to boot your cloned system is to
mount its "/", /boot (if it exists as separate partition) and

/boot/efi partitions somewhere, say "/new", then chroot to that /new

Post by Carlos E.R.
mount --bind /proc /new/proc
mount --bind /sys /new/sys
mount --bind /dev /new/dev
chroot /new
yast
:~# grep GRUB_DISTRIBUTOR /etc/default/grub
GRUB_DISTRIBUTOR="opensuse"
:~ #
It should say the name of your old system.
Notice that "yast" starts in text mode. Do not try to run the

graphical version (yast2). Go to the boot module. Under the tab "Boot
Code Options", change the "Boot loader" to "Grub2 for EFI".

Post by Carlos E.R.
And that's it.
Check that every other option is correct. I did this years ago, so I

am not fully sure there is something else to change, but basically
that's all.

Post by Carlos E.R.
Press OK, exit the chroot, and reboot.
If there are errors, correct them as appropriate. I use Leap, not

Tumbleweed, so there might be some differences.

Post by Carlos E.R.
Notice that it is important that you follow the SUSE way of doing

things, or you will have problems any time you run updates that touch
the kernel or the boot system.

Post by Carlos E.R.
I would recommend you change the name of the system

(GRUB_DISTRIBUTOR) to something else, like tumbleweed.


That's a mouthful but I saved it out because from experience I can sense
that the day will come when I'm going apeshit to wrap my brains around
all this, Thanks (I think).

I hate grub2 almost as much as its developers and half the time I prefer
booting manually from the grub shell, I guess that's all going to change
too.

[TJ]

Post by bad sector
Since Intel have decided to fianally kill legacy BIOS in 2025 I have no
choice left. Knowing this day would come I've already created an EFI #1
partition, formatted with
# mkfs.fat -F 32 /dev/sda1
The current OS partitions are 10-17
Device          Start        End   Sectors  Size Type
/dev/sda1        2048    2099199   2097152    1G EFI System
/dev/sda2  1348483072 1350580223   2097152    1G BIOS boot
/dev/sda3     4196352   16779263  12582912    6G Linux swap
/dev/sda4    16779264   16781311      2048    1M Linux filesystem
/dev/sda5    16781312   16783359      2048    1M Linux filesystem
/dev/sda6    16783360   16785407      2048    1M Linux filesystem
/dev/sda7    16785408   16787455      2048    1M Linux filesystem
/dev/sda8    16787456   16789503      2048    1M Linux filesystem
/dev/sda9    16789504   16791551      2048    1M Linux filesystem
/dev/sda10   16791552  593508351 576716800  275G Linux filesystem
/dev/sda11  593508352  761280511 167772160   80G Linux filesystem
/dev/sda12  761280512  929052671 167772160   80G Linux filesystem
/dev/sda13  929052672 1096824831 167772160   80G Linux filesystem
/dev/sda14 1096824832 1264596991 167772160   80G Linux filesystem
/dev/sda15 1350580224 1518352383 167772160   80G Linux filesystem
/dev/sda16 1518352384 1686124543 167772160   80G Linux filesystem
/dev/sda17 1686124544 1853896703 167772160   80G Linux filesystem
My current motherboard supports Legacy BIOS only but I'm getting a new
board that supports EFI (only I think). How do I get the new motherboard
started up using my existing boot disk above?
What happens when the disk fails? What's the BIOS and boot recovery
after I restore all partitions form images? Can I also keep an image of
the EFI partition and run again with that after a recovery?
TIA

Being of limited financial resources, I usually buy used and/or
refurbished hardware. I find it fills my needs more than adequately, at
a much lower cost. It's not for everybody, but I also like the idea of
taking someone else's castoff and returning it to useful life. I suppose
my experience isn't really relevant to your questions about a new
motherboard, but I'm going to post them anyway.

My first EFI machine was an HP Pavilion laptop that I found at a yard
sale for $20 US. It was a Windows 8.1 machine, my first look at that
mess. (I'm sure it was never released - it escaped!)

The BIOS on that machine is the most limited I've ever seen, with "Boot
options" being about the only thing that can be set by the user. Since
my plan was to replace that horrible concoction with Mageia Linux, the
first thing I did was disable secure boot so I could boot a Mageia Live
usb stick, just to see if Mageia would even work on it. That enabled
"Legacy support," and I was able to boot into something non-Microsoft.

There was then more to do before it would be usable. I doubled the RAM
to the 16GB max, and replaced the rust hard drive with an SSD. Now, I
*could* have researched how to clone an existing legacy system and
convert it to EFI, but it took considerably less time and effort to just
install Mageia using our netinstall iso. The installer took care of any
partitioning needs for me. Transferring wanted data(documents, pictures,
music, videos, etc.) from backups was next. Easy.

My second EFI hardware was/is an Asus motherboard for a 7th-generation
Intel processor, an upgrade for my existing production motherboard. It
was used, pulled from a running system by a recycler and sold on eBay.
It has two M.2 slots, where my old board only had SATA ports, so I
bought two NVME drives on Amazon to populate them. The RAM is three
times that of the old one.

My old one had been set up with / and /home on an SSD, with data on a
second rust drive. All I had to do was install Mageia once more on one
of the NVME drives, and transfer the data from the old rust drive to the
other NVME drive. Again, easy, and while not exactly fast, was less
time-consuming than learning how to fully convert a legacy system to
EFI, catching all the potential gotchas waiting to trip me up.

I love it. Of course, YMMV.

TJ

[Paul]

Since Intel have decided to fianally kill legacy BIOS in 2025 I have no choice left. Knowing this day would come I've already created an EFI #1 partition, formatted with
# mkfs.fat -F 32 /dev/sda1
The current OS partitions are 10-17
Device          Start        End   Sectors  Size Type
/dev/sda1        2048    2099199   2097152    1G EFI System
/dev/sda2  1348483072 1350580223   2097152    1G BIOS boot
/dev/sda3     4196352   16779263  12582912    6G Linux swap
/dev/sda4    16779264   16781311      2048    1M Linux filesystem
/dev/sda5    16781312   16783359      2048    1M Linux filesystem
/dev/sda6    16783360   16785407      2048    1M Linux filesystem
/dev/sda7    16785408   16787455      2048    1M Linux filesystem
/dev/sda8    16787456   16789503      2048    1M Linux filesystem
/dev/sda9    16789504   16791551      2048    1M Linux filesystem
/dev/sda10   16791552  593508351 576716800  275G Linux filesystem
/dev/sda11  593508352  761280511 167772160   80G Linux filesystem
/dev/sda12  761280512  929052671 167772160   80G Linux filesystem
/dev/sda13  929052672 1096824831 167772160   80G Linux filesystem
/dev/sda14 1096824832 1264596991 167772160   80G Linux filesystem
/dev/sda15 1350580224 1518352383 167772160   80G Linux filesystem
/dev/sda16 1518352384 1686124543 167772160   80G Linux filesystem
/dev/sda17 1686124544 1853896703 167772160   80G Linux filesystem
My current motherboard supports Legacy BIOS only but I'm getting a new board that supports EFI (only I think). How do I get the new motherboard started up using my existing boot disk above?
What happens when the disk fails? What's the BIOS and boot recovery after I restore all partitions form images? Can I also keep an image of the EFI partition and run again with that after a recovery?
TIA

Being of limited financial resources, I usually buy used and/or refurbished hardware. I find it fills my needs more than adequately, at a much lower cost. It's not for everybody, but I also like the idea of taking someone else's castoff and returning it to useful life. I suppose my experience isn't really relevant to your questions about a new motherboard, but I'm going to post them anyway.
My first EFI machine was an HP Pavilion laptop that I found at a yard sale for $20 US. It was a Windows 8.1 machine, my first look at that mess. (I'm sure it was never released - it escaped!)
The BIOS on that machine is the most limited I've ever seen, with "Boot options" being about the only thing that can be set by the user. Since my plan was to replace that horrible concoction with Mageia Linux, the first thing I did was disable secure boot so I could boot a Mageia Live usb stick, just to see if Mageia would even work on it. That enabled "Legacy support," and I was able to boot into something non-Microsoft.
There was then more to do before it would be usable. I doubled the RAM to the 16GB max, and replaced the rust hard drive with an SSD. Now, I *could* have researched how to clone an existing legacy system and convert it to EFI, but it took considerably less time and effort to just install Mageia using our netinstall iso. The installer took care of any partitioning needs for me. Transferring wanted data(documents, pictures, music, videos, etc.) from backups was next. Easy.
My second EFI hardware was/is an Asus motherboard for a 7th-generation Intel processor, an upgrade for my existing production motherboard. It was used, pulled from a running system by a recycler and sold on eBay. It has two M.2 slots, where my old board only had SATA ports, so I bought two NVME drives on Amazon to populate them. The RAM is three times that of the old one.
My old one had been set up with / and /home on an SSD, with data on a second rust drive. All I had to do was install Mageia once more on one of the NVME drives, and transfer the data from the old rust drive to the other NVME drive. Again, easy, and while not exactly fast, was less time-consuming than learning how to fully convert a legacy system to EFI, catching all the potential gotchas waiting to trip me up.
I love it. Of course, YMMV.
TJ

But some day, the Intel plan is, that motherboards only have UEFI
and they will have Secure Boot. And everyone else will have to
clean up the mess. That's the plan. When you get your gently used
equipment, that is going to be the configuration available to you.
No more legacy boot.

It's like Ford announcing in 2028, vehicles will no longer
ship with steering wheels. Just a shaft with a nut on the end,
and a pair of Vice Grips clamped on the nut.

This is why we are practicing with our Vice Grips today,
so we are ready for the shaft with a nut.

Paul

[bad sector]

Post by Paul

Since Intel have decided to fianally kill legacy BIOS in 2025 I have no choice left. Knowing this day would come I've already created an EFI #1 partition, formatted with
# mkfs.fat -F 32 /dev/sda1
The current OS partitions are 10-17
Device          Start        End   Sectors  Size Type
/dev/sda1        2048    2099199   2097152    1G EFI System
/dev/sda2  1348483072 1350580223   2097152    1G BIOS boot
/dev/sda3     4196352   16779263  12582912    6G Linux swap
/dev/sda4    16779264   16781311      2048    1M Linux filesystem
/dev/sda5    16781312   16783359      2048    1M Linux filesystem
/dev/sda6    16783360   16785407      2048    1M Linux filesystem
/dev/sda7    16785408   16787455      2048    1M Linux filesystem
/dev/sda8    16787456   16789503      2048    1M Linux filesystem
/dev/sda9    16789504   16791551      2048    1M Linux filesystem
/dev/sda10   16791552  593508351 576716800  275G Linux filesystem
/dev/sda11  593508352  761280511 167772160   80G Linux filesystem
/dev/sda12  761280512  929052671 167772160   80G Linux filesystem
/dev/sda13  929052672 1096824831 167772160   80G Linux filesystem
/dev/sda14 1096824832 1264596991 167772160   80G Linux filesystem
/dev/sda15 1350580224 1518352383 167772160   80G Linux filesystem
/dev/sda16 1518352384 1686124543 167772160   80G Linux filesystem
/dev/sda17 1686124544 1853896703 167772160   80G Linux filesystem
My current motherboard supports Legacy BIOS only but I'm getting a new board that supports EFI (only I think). How do I get the new motherboard started up using my existing boot disk above?
What happens when the disk fails? What's the BIOS and boot recovery after I restore all partitions form images? Can I also keep an image of the EFI partition and run again with that after a recovery?
TIA

Being of limited financial resources, I usually buy used and/or refurbished hardware. I find it fills my needs more than adequately, at a much lower cost. It's not for everybody, but I also like the idea of taking someone else's castoff and returning it to useful life. I suppose my experience isn't really relevant to your questions about a new motherboard, but I'm going to post them anyway.
My first EFI machine was an HP Pavilion laptop that I found at a yard sale for $20 US. It was a Windows 8.1 machine, my first look at that mess. (I'm sure it was never released - it escaped!)
The BIOS on that machine is the most limited I've ever seen, with "Boot options" being about the only thing that can be set by the user. Since my plan was to replace that horrible concoction with Mageia Linux, the first thing I did was disable secure boot so I could boot a Mageia Live usb stick, just to see if Mageia would even work on it. That enabled "Legacy support," and I was able to boot into something non-Microsoft.
There was then more to do before it would be usable. I doubled the RAM to the 16GB max, and replaced the rust hard drive with an SSD. Now, I *could* have researched how to clone an existing legacy system and convert it to EFI, but it took considerably less time and effort to just install Mageia using our netinstall iso. The installer took care of any partitioning needs for me. Transferring wanted data(documents, pictures, music, videos, etc.) from backups was next. Easy.
My second EFI hardware was/is an Asus motherboard for a 7th-generation Intel processor, an upgrade for my existing production motherboard. It was used, pulled from a running system by a recycler and sold on eBay. It has two M.2 slots, where my old board only had SATA ports, so I bought two NVME drives on Amazon to populate them. The RAM is three times that of the old one.
My old one had been set up with / and /home on an SSD, with data on a second rust drive. All I had to do was install Mageia once more on one of the NVME drives, and transfer the data from the old rust drive to the other NVME drive. Again, easy, and while not exactly fast, was less time-consuming than learning how to fully convert a legacy system to EFI, catching all the potential gotchas waiting to trip me up.
I love it. Of course, YMMV.
TJ

But some day, the Intel plan is, that motherboards only have UEFI
and they will have Secure Boot. And everyone else will have to
clean up the mess. That's the plan. When you get your gently used
equipment, that is going to be the configuration available to you.
No more legacy boot.
It's like Ford announcing in 2028, vehicles will no longer
ship with steering wheels. Just a shaft with a nut on the end,

That's no way to talk about Trump :-)

Post by Paul
and a pair of Vice Grips clamped on the nut.
This is why we are practicing with our Vice Grips today,
so we are ready for the shaft with a nut.

Attitude is everything

[TJ]

Post by Paul
But some day, the Intel plan is, that motherboards only have UEFI
and they will have Secure Boot. And everyone else will have to
clean up the mess. That's the plan. When you get your gently used
equipment, that is going to be the configuration available to you.
No more legacy boot.
It's like Ford announcing in 2028, vehicles will no longer
ship with steering wheels. Just a shaft with a nut on the end,
and a pair of Vice Grips clamped on the nut.
This is why we are practicing with our Vice Grips today,
so we are ready for the shaft with a nut.
Paul

You do that.

As for me, I'm 75. By the time secure boot is the only option left for
me to use, even on used equipment, I'll be in the Home, forgetting what
I had for breakfast that morning, but remembering what I ate 50 years
before.

TJ

[bad sector]

Post by TJ

Post by Paul
But some day, the Intel plan is, that motherboards only have UEFI
and they will have Secure Boot. And everyone else will have to
clean up the mess. That's the plan. When you get your gently used
equipment, that is going to be the configuration available to you.
No more legacy boot.
It's like Ford announcing in 2028, vehicles will no longer
ship with steering wheels. Just a shaft with a nut on the end,
and a pair of Vice Grips clamped on the nut.
This is why we are practicing with our Vice Grips today,
so we are ready for the shaft with a nut.
    Paul

You do that.
As for me, I'm 75. By the time secure boot is the only option left for
me to use, even on used equipment, I'll be in the Home, forgetting what
I had for breakfast that morning, but remembering what I ate 50 years
before.
TJ

Don't knock it, I'll soon be 81 and am just beginning to enjoy all the
good movies I never saw before. BTW I do my share of restoration, it's
just that my inevitably compuke-centric guitar studio is not where I
want to have issues :-)

Loading Image...

[bad sector]

Post by TJ

Post by bad sector
Since Intel have decided to fianally kill legacy BIOS in 2025 I have
no choice left. Knowing this day would come I've already created an
EFI #1 partition, formatted with
# mkfs.fat -F 32 /dev/sda1
The current OS partitions are 10-17
Device          Start        End   Sectors  Size Type
/dev/sda1        2048    2099199   2097152    1G EFI System
/dev/sda2  1348483072 1350580223   2097152    1G BIOS boot
/dev/sda3     4196352   16779263  12582912    6G Linux swap
/dev/sda4    16779264   16781311      2048    1M Linux filesystem
/dev/sda5    16781312   16783359      2048    1M Linux filesystem
/dev/sda6    16783360   16785407      2048    1M Linux filesystem
/dev/sda7    16785408   16787455      2048    1M Linux filesystem
/dev/sda8    16787456   16789503      2048    1M Linux filesystem
/dev/sda9    16789504   16791551      2048    1M Linux filesystem
/dev/sda10   16791552  593508351 576716800  275G Linux filesystem
/dev/sda11  593508352  761280511 167772160   80G Linux filesystem
/dev/sda12  761280512  929052671 167772160   80G Linux filesystem
/dev/sda13  929052672 1096824831 167772160   80G Linux filesystem
/dev/sda14 1096824832 1264596991 167772160   80G Linux filesystem
/dev/sda15 1350580224 1518352383 167772160   80G Linux filesystem
/dev/sda16 1518352384 1686124543 167772160   80G Linux filesystem
/dev/sda17 1686124544 1853896703 167772160   80G Linux filesystem
My current motherboard supports Legacy BIOS only but I'm getting a new
board that supports EFI (only I think). How do I get the new
motherboard started up using my existing boot disk above?
What happens when the disk fails? What's the BIOS and boot recovery
after I restore all partitions form images? Can I also keep an image
of the EFI partition and run again with that after a recovery?
TIA

Being of limited financial resources, I usually buy used and/or
refurbished hardware. I find it fills my needs more than adequately, at
a much lower cost. It's not for everybody, but I also like the idea of
taking someone else's castoff and returning it to useful life. I suppose
my experience isn't really relevant to your questions about a new
motherboard, but I'm going to post them anyway.
My first EFI machine was an HP Pavilion laptop that I found at a yard
sale for $20 US. It was a Windows 8.1 machine, my first look at that
mess. (I'm sure it was never released - it escaped!)
The BIOS on that machine is the most limited I've ever seen, with "Boot
options" being about the only thing that can be set by the user. Since
my plan was to replace that horrible concoction with Mageia Linux, the
first thing I did was disable secure boot so I could boot a Mageia Live
usb stick, just to see if Mageia would even work on it. That enabled
"Legacy support," and I was able to boot into something non-Microsoft.
There was then more to do before it would be usable. I doubled the RAM
to the 16GB max, and replaced the rust hard drive with an SSD. Now, I
*could* have researched how to clone an existing legacy system and
convert it to EFI, but it took considerably less time and effort to just
install Mageia using our netinstall iso. The installer took care of any
partitioning needs for me. Transferring wanted data(documents, pictures,
music, videos, etc.) from backups was next. Easy.
My second EFI hardware was/is an Asus motherboard for a 7th-generation
Intel processor, an upgrade for my existing production motherboard. It
was used, pulled from a running system by a recycler and sold on eBay.
It has two M.2 slots, where my old board only had SATA ports, so I
bought two NVME drives on Amazon to populate them. The RAM is three
times that of the old one.
My old one had been set up with / and /home on an SSD, with data on a
second rust drive. All I had to do was install Mageia once more on one
of the NVME drives, and transfer the data from the old rust drive to the
other NVME drive. Again, easy, and while not exactly fast, was less
time-consuming than learning how to fully convert a legacy system to
EFI, catching all the potential gotchas waiting to trip me up.
I love it. Of course, YMMV.
TJ

I bought a refurb Lenovo T480 for couple of hundred a while back and
I've been very happy with it. It's almost as good (in my use) as the
16" ROG it replaced (that had blown itself to ratshit). I bought my
desktop deathstar nearly 15 years ago and (because I now definitely need
4k) am obliged to rebuild an entire system. With no regrets about what
was then just as expensive and just as good for its time as my new one
will be today I have no issues with it.

One of VERY few reasons for me having a computer at all is my guitar
sessions without which I could be brushing my teeth with a 9mm. They
mean everything to me, and it's already frustrating enough when I sit
down for a couple of hours of jamming and improvising or backing track
creation I first have to do an hour's worth of hardware or software
maintenance and tweaking by the end of which I'm too tired and have
'lost it' (you need to be with it to do music or forget it). So at least
once every decade and a half I need up to date reliable and solid iron.

The biggest problem is that nearly everything has changed since the last
redux. I threw that previous system together in half a day with
absolutely no difficulties. That kind of shopping has become a thing of
the past. Today one has to check via multiple paths EVERY SINGLE
COMPONENT for compatibility with what has already been chosen and I've
been at this fucking CIRCUS(!) for several months now. It's totally
ridiculous but maybe designed to be so. Just half an hour ago did I
commit to a monitor as another example. I also want speed and end-to-end
ECC and there again buying used could mean too many unknowns.

I'll never buy used stuff on-line again and even in the case of brand
new I have learned to be very careful. Living in the sticks on the
eastern coast, actual for-sale used machines in my corner of the woods
are so rare and so rudimentary that there is absoluteky no chance of
finding one worth slowing down for :-(

[TJ]

Post by bad sector
I bought a refurb Lenovo T480 for couple of hundred a while back and
I've been very happy with it. It's almost as good (in my use) as the
16" ROG it replaced (that had blown itself to ratshit). I bought my
desktop deathstar nearly 15 years ago and (because I now definitely need
4k) am obliged to rebuild an entire system. With no regrets about what
was then just as expensive and just as good for its time as my new one
will be today I have no issues with it.
One of VERY few reasons for me having a computer at all is my guitar
sessions without which I could be brushing my teeth with a 9mm. They
mean everything to me, and it's already frustrating enough when I sit
down for a couple of hours of jamming and improvising or backing track
creation I first have to do an hour's worth of hardware or software
maintenance and tweaking by the end of which I'm too tired and have
'lost it' (you need to be with it to do music or forget it). So at least
once every decade and a half I need up to date reliable and solid iron.
The biggest problem is that nearly everything has changed since the last
redux. I threw that previous system together in half a day with
absolutely no difficulties. That kind of shopping has become a thing of
the past. Today one has to check via multiple paths EVERY SINGLE
COMPONENT for compatibility with what has already been chosen and I've
been at this fucking CIRCUS(!) for several months now. It's totally
ridiculous but maybe designed to be so. Just half an hour ago did I
commit to a monitor as another example. I also want speed and end-to-end
ECC and there again buying used could mean too many unknowns.
I'll never buy used stuff on-line again and even in the case of brand
new I have learned to be very careful. Living in the sticks on the
eastern coast, actual for-sale used machines in my corner of the woods
are so rare and so rudimentary that there is absoluteky no chance of
finding one worth slowing down for 🙁

I too live in an eastern U.S. state, not on the coast but within 300
miles of it. And, being a third-generation farmer, I'm also in "the
sticks," though I'm in the same county as a moderate-sized city.

I too see almost no used stuff at garage/yard/church sales worth even a
first glance. I've suspected for years that those that have such
castoffs are selling them at places like eBay, rather than put it in
such a sale, if they sell it at all. Most stuff simply goes to a
recycler when no longer considered useful. The laptop I described was an
exception, thrown on the sale at the previous owner's last minute whim.

I need my computers for several things related to the farm, none of it
particularly taxing, so my equipment need not be as specialized as
yours. At the same time, while my oldest laptop will still do what I ask
of it, the newer one does it faster.

But we all have our hobbies, and rescuing someone else's castoff from
oblivion is one of mine.

TJ