Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.user > #266549 > unrolled thread

Automatically installing GRUB on multiple drives

Back to article view | Back to linux.debian.user

Contents

  Automatically installing GRUB on multiple drives Nicolas George <george@nsup.org> - 2024-01-24 11:20 +0100
    Re: Automatically installing GRUB on multiple drives "Thomas Schmitt" <scdbackup@gmx.net> - 2024-01-24 12:50 +0100
      Re: Automatically installing GRUB on multiple drives Nicolas George <george@nsup.org> - 2024-01-24 21:10 +0100
        Re: Automatically installing GRUB on multiple drives "Thomas Schmitt" <scdbackup@gmx.net> - 2024-01-24 22:00 +0100
          Re: Automatically installing GRUB on multiple drives Nicolas George <george@nsup.org> - 2024-01-26 10:30 +0100
            Re: Automatically installing GRUB on multiple drives "Thomas Schmitt" <scdbackup@gmx.net> - 2024-01-26 11:10 +0100
        Re: Automatically installing GRUB on multiple drives Tim Woodall <debianuser@woodall.me.uk> - 2024-01-26 04:40 +0100
          Re: Automatically installing GRUB on multiple drives Nicolas George <george@nsup.org> - 2024-01-26 08:50 +0100
            Re: Automatically installing GRUB on multiple drives Andy Smith <andy@strugglers.net> - 2024-01-26 09:40 +0100
              Re: Automatically installing GRUB on multiple drives Nicolas George <george@nsup.org> - 2024-01-26 10:20 +0100
                Re: Automatically installing GRUB on multiple drives "Thomas Schmitt" <scdbackup@gmx.net> - 2024-01-26 10:50 +0100
                Re: Automatically installing GRUB on multiple drives Andy Smith <andy@strugglers.net> - 2024-01-26 11:00 +0100
                Re: Automatically installing GRUB on multiple drives Tim Woodall <debianuser@woodall.me.uk> - 2024-01-26 14:20 +0100
                  Re: Automatically installing GRUB on multiple drives Tim Woodall <debianuser@woodall.me.uk> - 2024-01-26 14:30 +0100
                  Re: Automatically installing GRUB on multiple drives gene heskett <gheskett@shentel.net> - 2024-01-26 14:50 +0100
                    Re: Automatically installing GRUB on multiple drives Andy Smith <andy@strugglers.net> - 2024-01-26 15:40 +0100
                  Re: Automatically installing GRUB on multiple drives Andy Smith <andy@strugglers.net> - 2024-01-26 15:20 +0100
        Re: Automatically installing GRUB on multiple drives hw <hw@adminart.net> - 2024-01-26 17:00 +0100
          Re: Automatically installing GRUB on multiple drives Nicolas George <george@nsup.org> - 2024-01-26 17:00 +0100
            Re: Automatically installing GRUB on multiple drives hw <hw@adminart.net> - 2024-01-28 17:20 +0100
              Re: Automatically installing GRUB on multiple drives Andy Smith <andy@strugglers.net> - 2024-01-28 17:50 +0100
                Re: Automatically installing GRUB on multiple drives hw <hw@adminart.net> - 2024-01-28 21:10 +0100
                  Re: Automatically installing GRUB on multiple drives Andy Smith <andy@strugglers.net> - 2024-01-28 23:00 +0100
              Re: Automatically installing GRUB on multiple drives Dan Ritter <dsr@randomstring.org> - 2024-01-28 18:20 +0100
                Re: Automatically installing GRUB on multiple drives Andy Smith <andy@strugglers.net> - 2024-01-28 18:40 +0100
                  Re: Automatically installing GRUB on multiple drives hw <hw@adminart.net> - 2024-01-28 21:10 +0100
                    Re: Automatically installing GRUB on multiple drives Andy Smith <andy@strugglers.net> - 2024-01-28 23:00 +0100
                      Re: Automatically installing GRUB on multiple drives hw <hw@adminart.net> - 2024-01-29 17:30 +0100
                        Re: Automatically installing GRUB on multiple drives Andy Smith <andy@strugglers.net> - 2024-01-30 01:00 +0100
                          Re: Automatically installing GRUB on multiple drives hw <hw@adminart.net> - 2024-01-30 22:00 +0100
                            Re: Automatically installing GRUB on multiple drives Andy Smith <andy@strugglers.net> - 2024-01-31 16:20 +0100
                              Re: Automatically installing GRUB on multiple drives hw <hw@adminart.net> - 2024-01-31 23:00 +0100
                                Re: Automatically installing GRUB on multiple drives Franco Martelli <martellif67@gmail.com> - 2024-02-02 14:50 +0100
                                  Re: Automatically installing GRUB on multiple drives hw <hw@adminart.net> - 2024-02-02 20:00 +0100
                                  Re: Automatically installing GRUB on multiple drives Andy Smith <andy@strugglers.net> - 2024-02-03 19:30 +0100
              Re: Automatically installing GRUB on multiple drives Franco Martelli <martellif67@gmail.com> - 2024-01-29 14:50 +0100
                Re: Automatically installing GRUB on multiple drives hw <hw@adminart.net> - 2024-01-29 18:00 +0100
                  Re: Automatically installing GRUB on multiple drives Nicolas George <george@nsup.org> - 2024-01-29 18:10 +0100
                    Re: Automatically installing GRUB on multiple drives Nicolas George <george@nsup.org> - 2024-01-30 21:40 +0100
                      Re: Automatically installing GRUB on multiple drives hw <hw@adminart.net> - 2024-01-31 23:30 +0100
                        Re: Automatically installing GRUB on multiple drives Nicolas George <george@nsup.org> - 2024-01-31 23:30 +0100
                          Re: Automatically installing GRUB on multiple drives hw <hw@adminart.net> - 2024-02-02 04:50 +0100
                    Re: Automatically installing GRUB on multiple drives hw <hw@adminart.net> - 2024-01-30 21:40 +0100
                  Re: Automatically installing GRUB on multiple drives <tomas@tuxteam.de> - 2024-01-29 18:50 +0100
                    Re: Automatically installing GRUB on multiple drives hw <hw@adminart.net> - 2024-01-30 21:50 +0100
                      Re: Automatically installing GRUB on multiple drives <tomas@tuxteam.de> - 2024-01-31 06:40 +0100
                        Re: Automatically installing GRUB on multiple drives hw <hw@adminart.net> - 2024-01-31 23:50 +0100
                          Re: Automatically installing GRUB on multiple drives Max Nikulin <manikulin@gmail.com> - 2024-02-02 03:50 +0100
          Re: Automatically installing GRUB on multiple drives Andy Smith <andy@strugglers.net> - 2024-01-26 17:00 +0100
    Re: Automatically installing GRUB on multiple drives Charles Curley <charlescurley@charlescurley.com> - 2024-01-24 15:30 +0100
      Re: Automatically installing GRUB on multiple drives Nicolas George <george@nsup.org> - 2024-01-24 15:50 +0100
        Re: Automatically installing GRUB on multiple drives Felix Miata <mrmazda@earthlink.net> - 2024-01-24 17:10 +0100
          Re: Automatically installing GRUB on multiple drives Nicolas George <george@nsup.org> - 2024-01-24 21:00 +0100
            Re: Automatically installing GRUB on multiple drives Felix Miata <mrmazda@earthlink.net> - 2024-01-25 00:10 +0100
    Re: Automatically installing GRUB on multiple drives Franco Martelli <martellif67@gmail.com> - 2024-01-24 17:40 +0100
      Re: Automatically installing GRUB on multiple drives Nicolas George <george@nsup.org> - 2024-01-24 21:00 +0100
    Re: Automatically installing GRUB on multiple drives Andy Smith <andy@strugglers.net> - 2024-01-24 21:30 +0100

Page 1 of 3  [1] 2 3  Next page →

#266549 — Automatically installing GRUB on multiple drives

Hi.

We have drives in mdadm RAID1.

Since they are potential boot drives, we have to put a GPT on them.

Since mdadm can only put its superblock at the end of the device (1.0),
at the beginning of the device (1.1) and 4 Ko from the beginning (1.2),
but they still have not invented 1.3 to have the metadata 17 Ko from the
beginning or the end, which would be necessary to be compatible with
GPT, we have to partition them and put the EFI system partition outside
them.

To keep things logical, we have the same partitions on all drives,
including the EFI one. And GRUB is perfectly capable of booting the
system (inside the LVM) inside the RAID inside the partition.

Which leads me to wonder if there is an automated way to install GRUB on
all the EFI partitions.

The manual way is not that bad, but automated would be nice.

Regards,

-- 
  Nicolas George

[toc] | [next] | [standalone]

#266551

Hi,

i cannot make qualified proposals for the GRUB question, but stumble over
your technical statements.

Nicolas George wrote:
> Since mdadm can only put its superblock at the end of the device (1.0),
> at the beginning of the device (1.1) and 4 Ko from the beginning (1.2),
> but they still have not invented 1.3 to have the metadata 17 Ko from the
> beginning or the end, which would be necessary to be compatible with
> GPT,

Although it would be unusually small, it is possible to have a GPT of
only 4 KiB of size:
- 512 bytes for Protective MBR (the magic number of GPT)
- 512 bytes for the GPT header block
- 3 KiB for an array of 24 partition entries.

Question is of course, whether any partition editor is willing to create
such a small GPT. The internet says that sfdisk has "table-length" among
its input "Header lines". So it would be a matter of learning and
experimenting.
(Possibly i would be faster with writing the first header blocks by
hand, following UEFI specs or my cheat sheet in libisofs.)


> we have to partition them and put the EFI system partition outside
> them.

Do you mean you partition them DOS-style ?
If so, then a partition of type 0xEF could be used as system partition.
Probably any partition type will do, because EFI is very eager to look
into any partition with FAT filesystem.


Have a nice day :)

Thomas

[toc] | [prev] | [next] | [standalone]

#266570

Thomas Schmitt (12024-01-24):
> i cannot make qualified proposals for the GRUB question, but stumble over
> your technical statements.

It was by far the most interesting reply. Better somebody who really
understood the question, realized their limitations and knowingly
replies with an interesting tangential than the opposite.

> Although it would be unusually small, it is possible to have a GPT of
> only 4 KiB of size:
> - 512 bytes for Protective MBR (the magic number of GPT)
> - 512 bytes for the GPT header block
> - 3 KiB for an array of 24 partition entries.
> 
> Question is of course, whether any partition editor is willing to create
> such a small GPT. The internet says that sfdisk has "table-length" among
> its input "Header lines". So it would be a matter of learning and
> experimenting.

Interesting. Indeed, “table-length: 4” causes sfdisk to only write 3
sectors at the beginning and 2 at the end. I checked it really does not
write elsewhere.

That makes it possible to use full-disk RAID on a UEFI boot drive. Very
good news.

> > we have to partition them and put the EFI system partition outside
> > them.
> Do you mean you partition them DOS-style ?

No, GPT. More and more firmwares will only boot with GPT. I think I met
only once a firmware that booted UEFI, 32 bits, with a MBR.

GPT
 ├─EFI
 └─RAID
    └─LVM (of course)

Now, thanks to you, I know I can do:

GPT   
 ┊  RAID
 └───┤
     ├─EFI
     └─LVM

It is rather ugly to have the same device be both a RAID with its
superblock in the hole between GPT and first partition and the GPT in
the hole before the RAID superblock, but it serves its purpose: the EFI
partition is kept in sync over all devices.

It still requires setting the non-volatile variables, though.

Thanks.

Regards,

-- 
  Nicolas George

[toc] | [prev] | [next] | [standalone]

#266575

Hi,

Nicolas George wrote:
> Interesting. Indeed, “table-length: 4” causes sfdisk to only write 3
> sectors at the beginning and 2 at the end. I checked it really does not
> write elsewhere.
> That makes it possible to use full-disk RAID on a UEFI boot drive. Very
> good news.

\o/

(Nearly as good as Stefan Monnier's crystal ball. And that without
understanding the dirty details which cause the need for a small partition
table.)


> More and more firmwares will only boot with GPT. I think I met
> only once a firmware that booted UEFI, 32 bits, with a MBR

The Debian installation and live ISOs have MBR partitions with only a
flimsy echo of GPT. There is a GPT header block and an entries array.
But it does not get announced by a Protective MBR. Rather they have two
partitions of which one is meant to be invisible to EFI ("Empty") and
one is advertised as EFI partition:

$ /sbin/fdisk -l debian-12.2.0-amd64-netinst.iso
...
Disklabel type: dos
...
Device                           Boot Start     End Sectors  Size Id Type
debian-12.2.0-amd64-netinst.iso1 *        0 1286143 1286144  628M  0 Empty
debian-12.2.0-amd64-netinst.iso2       4476   23451   18976  9.3M ef EFI (FAT-12

So any system which boots this ISO from USB stick does not rely on
the presence of a valid GPT.
(The only particular example of GPT addiction i know of are old versions
of OVMF, the EFI used by qemu, which wanted to see the GPT header block,
even without Protective MBR.)

This layout was invented by Matthew J. Garrett for Fedora and is still
the most bootable of all possible weird ways to present boot stuff for
legacy BIOS and EFI on USB stick in the same image. (There are mad legacy
BIOSes which hate EFI's demand for no MBR boot flag. Several distros
abandoned above layout in favor of plain MBR or plain GPT. The price
is that they have to leave behind some of the existing machines.)


> GPT
>  ├─EFI
>  └─RAID
>     └─LVM (of course)
>
> Now, thanks to you, I know I can do:
>
> GPT
>  ┊  RAID
>  └───┤
>      ├─EFI
>      └─LVM

Ah. Now i understand how accidentially useful my technical nitpicking was.
(A consequence of me playing Dr. Pol with the arm in the ISO 9660 cow
up to my shoulder.)


Have a nice day :)

Thomas

[toc] | [prev] | [next] | [standalone]

#266608

Thomas Schmitt (12024-01-24):
> The Debian installation and live ISOs have MBR partitions with only a
> flimsy echo of GPT. There is a GPT header block and an entries array.
> But it does not get announced by a Protective MBR. Rather they have two
> partitions of which one is meant to be invisible to EFI ("Empty") and
> one is advertised as EFI partition:
> 
> $ /sbin/fdisk -l debian-12.2.0-amd64-netinst.iso
> ...
> Disklabel type: dos
> ...
> Device                           Boot Start     End Sectors  Size Id Type
> debian-12.2.0-amd64-netinst.iso1 *        0 1286143 1286144  628M  0 Empty
> debian-12.2.0-amd64-netinst.iso2       4476   23451   18976  9.3M ef EFI (FAT-12
> 
> So any system which boots this ISO from USB stick does not rely on
> the presence of a valid GPT.

You seem to be assuming that the system will first check sector 0 to
parse the MBR and then, if the MBR declares a GPT sector try to use the
GPT.

I think it is the other way around on modern systems: it will first
check sector 1 for a GPT header, and only if it fails check sector 0. Or
not check sector 0 at all if legacy mode has been removed.

> This layout was invented by Matthew J. Garrett for Fedora and is still
> the most bootable of all possible weird ways to present boot stuff for
> legacy BIOS and EFI on USB stick in the same image.

I think I invented independently something similar.

https://nsup.org/~george/comp/live_iso_usb/grub_hybrid.html

Regards,

-- 
  Nicolas George

[toc] | [prev] | [next] | [standalone]

#266611

Hi,

Nicolas George wrote:
> You seem to be assuming that the system will first check sector 0 to
> parse the MBR and then, if the MBR declares a GPT sector try to use the
> GPT.

That's what the UEFI specs prescribe. GPT is defined by UEFI-2.8 in
chapter 5 "GUID Partition Table (GPT) Disk Layout". Especially:

  5.2.3 Protective MBR
  For a bootable disk, a Protective MBR must be located at LBA 0 (i.e.,
  the first logical block) of the disk if it is using the GPT disk layout.
  The Protective MBR precedes the GUID Partition Table Header to maintain
  compatibility with existing tools that do not understand GPT partition
  structures.


> I think it is the other way around on modern systems: it will first
> check sector 1 for a GPT header, and only if it fails check sector 0.

Given the creativity of firmware programmers, this is not impossible.
At least the programmers of older versions of OVMF took the presence of
a GPT header as reason to boot, whereas without it did not boot.
Meanwhile this demand for GPT debris has vanished and OVMF boots from
media with only MBR partitions, too.


I wrote:
> > This layout [used by Debian installation ISOs] was invented by Matthew
> > J. Garrett for Fedora

> I think I invented independently something similar.
> https://www.normalesup.org/~george/comp/live_iso_usb/grub_hybrid.html

Not to forget Vladimir Serbinenko who specified how a grub-mkrescue ISO
shall present its lures for BIOS and EFI on optical media and USB stick.
The ISO has a pure GPT partition table, where the ISO filesystem is not
mountable as partition but only by the base device (like /dev/sdc) or
possibly by its HFS+ directory tree via the Apple Partition Map, if
present.

(To create such an ISO, install grub-common, grub-efi-amd64, grub-efi-ia32,
and grub-pc. Then run grub-mkrescue with some dummy directory as payload.
The ISO will boot to a GRUB prompt.)


Have a nice day :)

Thomas

[toc] | [prev] | [next] | [standalone]

#266601

On Wed, 24 Jan 2024, Nicolas George wrote:

> It is rather ugly to have the same device be both a RAID with its
> superblock in the hole between GPT and first partition and the GPT in
> the hole before the RAID superblock, but it serves its purpose: the EFI
> partition is kept in sync over all devices.
>
Until your UEFI bios writes to the disk before the system has booted.

I'll be interested to hear how this goes and whether it's reliable.

I tried it years ago, using a no-superblock raid and custom initrd
(initramfs as I think it was then) to start it, but upgrades, and even
kernel updates, became 'terrifying'. Now I use dd to copy the start of
the disk...

[toc] | [prev] | [next] | [standalone]

#266605

Tim Woodall (12024-01-26):
> Until your UEFI bios writes to the disk before the system has booted.

Hi. Have you ever observed an UEFI firmware doing that? Without explicit
admin instructions?

Regards,

-- 
  Nicolas George

[toc] | [prev] | [next] | [standalone]

#266606

Hi Nicolas,

On Fri, Jan 26, 2024 at 08:49:06AM +0100, Nicolas George wrote:
> Tim Woodall (12024-01-26):
> > Until your UEFI bios writes to the disk before the system has booted.
> 
> Hi. Have you ever observed an UEFI firmware doing that? Without explicit
> admin instructions?

Going back to my question from 2020 about what people do to provide
redundancy for EFI System Partition, do I take it then that you
have had no issues with just putting ESP in MD RAID-1?

The "firmware may write to it" thing was raised as a concern by a
few people,but always a theoretical one from what I could see.

Thanks,
Andy

-- 
https://bitfolk.com/ -- No-nonsense VPS hosting

[toc] | [prev] | [next] | [standalone]

#266607

Andy Smith (12024-01-26):
> Going back to my question from 2020 about what people do to provide
> redundancy for EFI System Partition, do I take it then that you
> have had no issues with just putting ESP in MD RAID-1?

I have not had the occasion to test since two days ago when Thomas's
remarks made me realize it was possible.

> The "firmware may write to it" thing was raised as a concern by a
> few people,but always a theoretical one from what I could see.

Now that I think a little more, this concern is not only unconfirmed,
it is rather absurd. The firmware would never write in parts of the
drive that might contain data.

At worst, it is possible to cover the RAID header with a dummy
partition:

label: gpt
unit: sectors
table-length: 24
sector-size: 512
first-lba: 8
1 : start=8, size=2040, type=00000000-0000-0000-0000-000000000000
2 : start=2048, size=30712, type=lvm

Regards,

-- 
  Nicolas George

[toc] | [prev] | [next] | [standalone]

#266609

Hi,

i hate to put in question the benefit of my proposal, but:

Nicolas George wrote:
> The firmware would never write in parts of the
> drive that might contain data.

See

  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1056998
  "cdrom: Installation media changes after booting it"

Two occasions were shown in this bug where the EFI system partition of
a Debian installation ISO on USB stick changed. One was caused by a
Microsoft operating system, writing a file named WPSettings.dat. But the
other was from Lenovo firmware writing /efi/Lenovo/BIOS/SelfHealing.fd .

One may doubt that the success of these operations is desirable at all.
The ISO was also tested with a not-anymore-writable DVD. In that case the
Lenovo firmware did not raise protest over the fact that it was not
possible to write to the EFI partition.


Have a nice day :)

Thomas

[toc] | [prev] | [next] | [standalone]

#266610

Hello,

On Fri, Jan 26, 2024 at 10:09:53AM +0100, Nicolas George wrote:
> Andy Smith (12024-01-26):
> > The "firmware may write to it" thing was raised as a concern by a
> > few people,but always a theoretical one from what I could see.
> 
> Now that I think a little more, this concern is not only unconfirmed,
> it is rather absurd. The firmware would never write in parts of the
> drive that might contain data.

I suppose my concern with that is that a firmware developer might
feel justified in poking about in the ESP, which they might consider
is there "for them".

I have seen quite a few first hand reports of motherboard firmware
that writes empty GPT when it sees a drive with no GPT, which I had
previously considered unthinkable, so I do worry about trusting in
the firmware developers.

Thanks,
Andy

-- 
https://bitfolk.com/ -- No-nonsense VPS hosting

[toc] | [prev] | [next] | [standalone]

#266615

On Fri, 26 Jan 2024, Nicolas George wrote:


> Now that I think a little more, this concern is not only unconfirmed,
> it is rather absurd. The firmware would never write in parts of the
> drive that might contain data.
>
UEFI understands the EFI system filesystem so it can "safely" write new
files there.

The danger then is that a write via mdadm corrupts the filesystem. I'm
not sure if mdadm will detect the inconsistent data or assume both
sources are the same.

Hardware raid that the bios cannot subvert is obviously one solution.

[toc] | [prev] | [next] | [standalone]

#266617

On Fri, 26 Jan 2024, Tim Woodall wrote:

> On Fri, 26 Jan 2024, Nicolas George wrote:
>
>
>> Now that I think a little more, this concern is not only unconfirmed,
>> it is rather absurd. The firmware would never write in parts of the
>> drive that might contain data.
>> 
> UEFI understands the EFI system filesystem so it can "safely" write new
> files there.
>
> The danger then is that a write via mdadm corrupts the filesystem. I'm
> not sure if mdadm will detect the inconsistent data or assume both
> sources are the same.
>
> Hardware raid that the bios cannot subvert is obviously one solution.
>
>
https://stackoverflow.com/questions/32324109/can-i-write-on-my-local-filesystem-using-efi

[toc] | [prev] | [next] | [standalone]

#266618

On 1/26/24 08:19, Tim Woodall wrote:
> On Fri, 26 Jan 2024, Nicolas George wrote:
> 
> 
>> Now that I think a little more, this concern is not only unconfirmed,
>> it is rather absurd. The firmware would never write in parts of the
>> drive that might contain data.
>>
> UEFI understands the EFI system filesystem so it can "safely" write new
> files there.
> 
> The danger then is that a write via mdadm corrupts the filesystem. I'm
> not sure if mdadm will detect the inconsistent data or assume both
> sources are the same.
> 
> Hardware raid that the bios cannot subvert is obviously one solution.
> 
Is nearly the only solution, but it needs to have a hard specified 
format that guarantees 100% compatibility across all makers or they 
cannot use the word raid in their advertising. I am sick of proprietary 
makers doing a job that subverts the method with full intentions of 
locking the customer to only their product.  Let there be competition 
based on the quality of their product.
> .

Cheers, Gene Heskett.
-- 
"There are four boxes to be used in defense of liberty:
  soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author, 1940)
If we desire respect for the law, we must first make the law respectable.
  - Louis D. Brandeis

[toc] | [prev] | [next] | [standalone]

#266624

Hello,

On Fri, Jan 26, 2024 at 08:40:42AM -0500, gene heskett wrote:
> On 1/26/24 08:19, Tim Woodall wrote:
> > Hardware raid that the bios cannot subvert is obviously one solution.
> > 
> Is nearly the only solution,

If the problem to be solved is defined as redundancy for the ESP,
there are a bunch of solutions as already discussed. All of them
come with upsides and downsides. The downsides of hardware RAID for
this, for me, are too big.

> [hardware RAID] needs to have a hard specified format that
> guarantees 100% compatibility across all makers

If that happened, mdadm could support it, and then I would continue
to use mdadm. In fact it already has happened, in that Intel came up
with a standard for its "fake RAID" data layout and mdadm does
support it already. But of course, none of the other vendors of
hardware RAID took that on.

    https://www.intel.com/content/dam/www/public/us/en/documents/white-papers/rst-linux-paper.pdf

It has also been pointed out that there is no technical reason why
EFI firmware can't support MD RAID, since MD is open source.

But on the whole, we can't wait around for any of that to happen.

> full intentions of locking the customer to only their product.

There was a time when hardware RAID was really the only game in
town, and the ability it gave to lock in the customer was just the
cost of doing business.

That time has passed, but I don't think the UEFI firmware developers
are interested in helping out.

Thanks,
Andy

-- 
https://bitfolk.com/ -- No-nonsense VPS hosting

[toc] | [prev] | [next] | [standalone]

#266622

Hello,

On Fri, Jan 26, 2024 at 01:18:53PM +0000, Tim Woodall wrote:
> Hardware raid that the bios cannot subvert is obviously one solution.

These days the different trade-offs for HW RAID are IMHO worse. I
left it behind in 2014 and don't intend to go back. 😀

Thanks,
Andy

-- 
https://bitfolk.com/ -- No-nonsense VPS hosting

[toc] | [prev] | [next] | [standalone]

#266632

On Wed, 2024-01-24 at 21:05 +0100, Nicolas George wrote:
> [...]
> GPT
>  ├─EFI
>  └─RAID
>     └─LVM (of course)
> 
> Now, thanks to you, I know I can do:
> 
> GPT   
>  ┊  RAID
>  └───┤
>      ├─EFI
>      └─LVM
> 
> It is rather ugly to have the same device be both a RAID with its
> superblock in the hole between GPT and first partition and the GPT in
> the hole before the RAID superblock, but it serves its purpose: the EFI
> partition is kept in sync over all devices.
> 
> It still requires setting the non-volatile variables, though.

How do you make the BIOS read the EFI partition when it's on mdadm
RAID?

It seems you have to have an EFI partition directly, outside sofware
RAID, on each storage device, and that indeed raises the question how
you keep them up to date so you can still boot when a disk has failed.
It's a nasty problem.

I use hardware RAID to avoid this problem ...

[toc] | [prev] | [next] | [standalone]

#266634

hw (12024-01-26):
> How do you make the BIOS read the EFI partition when it's on mdadm
> RAID?

I have not yet tested but my working hypothesis is that the firmware
will just ignore the RAID and read the EFI partition: with the scheme I
described, the GPT points to the EFI partition and the EFI partition
just contains the data.

Of course, it only works with RAID1, where the data on disk is the data
in RAID.

Regards,

-- 
  Nicolas George

[toc] | [prev] | [next] | [standalone]

#266678

On Fri, 2024-01-26 at 16:57 +0100, Nicolas George wrote:
> hw (12024-01-26):
> > How do you make the BIOS read the EFI partition when it's on mdadm
> > RAID?
> 
> I have not yet tested but my working hypothesis is that the firmware
> will just ignore the RAID and read the EFI partition: with the scheme I
> described, the GPT points to the EFI partition and the EFI partition
> just contains the data.
> 
> Of course, it only works with RAID1, where the data on disk is the data
> in RAID.

Ok if Andy and you are right, you could reasonably boot machines with
an UEFI BIOS when using mdadm RAID :)

How is btrfs going to deal with this problem when using RAID?  Require
hardware RAID?

Having to add mdadm RAID to a setup that uses btrfs just to keep efi
partitions in sync would suck.

[toc] | [prev] | [next] | [standalone]

Page 1 of 3  [1] 2 3  Next page →

Back to top | Article view | linux.debian.user

csiph-web