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 2 of 3 — ← Prev page 1 [2] 3  Next page →

#266679

Hi,

On Sun, Jan 28, 2024 at 05:17:14PM +0100, hw wrote:
> Ok if Andy and you are right, you could reasonably boot machines with
> an UEFI BIOS when using mdadm RAID :)

I've been doing it for more than two decades, though not with UEFI.

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

ESP have to be vfat so why are you bringing up btrfs?

If you want to use btrfs, use btrfs. UEFI firmware isn't going to
care as long as your ESP is not inside that.

Thanks,
Andy

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

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

#266689

On Sun, 2024-01-28 at 16:46 +0000, Andy Smith wrote:
> Hi,
> 
> On Sun, Jan 28, 2024 at 05:17:14PM +0100, hw wrote:
> > Ok if Andy and you are right, you could reasonably boot machines with
> > an UEFI BIOS when using mdadm RAID :)
> 
> I've been doing it for more than two decades, though not with UEFI.
> 
> > 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.
> 
> ESP have to be vfat so why are you bringing up btrfs?
> 
> If you want to use btrfs, use btrfs. UEFI firmware isn't going to
> care as long as your ESP is not inside that.

It's easy to boot from btrfs software RAID without further ado.  These
nasty and annoying UEFI partitions get in the way of that since they
are not kept in sync with each other when you have several without
further ado.

That easily leads to situations in which you can't boot after a disk
has failed despite you have RAID.  That is something that must not
happen; it defeats the RAID.  It's bad enough when you have access to
the machine and it's a total nightmare when not because you'll have to
somehow go there to fix this.  If the disk having the UEFI partition
has failed and there's no redundance that's at least sufficently in
sync, it's even worse.

Show me any installer for Linux distributions that handles this
sufficently without further ado.

When you don't use btrfs, you have either hardware RAID or
mdraid.  With harware RAID, the problem doesn't come up.  With mdadm
RAID, it isn't much better than with btrfs since without further ado,
you still don't have redundant UEFI partitions.  With btrfs and mdadm
RAID, it's basically worse because you have to deploy another variant
of software RAID in addition to the software built into btrfs.

So at least for boot disks, I'll go for hardware RAID whenever
possible, especially with btrfs, until this problem is fixed.  Or do
you have a better option?

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

#266700

Hello,

On Sun, Jan 28, 2024 at 09:03:50PM +0100, hw wrote:
> Show me any installer for Linux distributions that handles this
> sufficently without further ado.

That was the question I posed several posts back: what do people do
for redundant ESP.

> When you don't use btrfs, you have either hardware RAID or
> mdraid.

…or zfs or bcachefs or no redundancy at all…

> With mdadm RAID, it isn't much better than with btrfs since
> without further ado, you still don't have redundant UEFI
> partitions.

As mentioned, people do try it, and we don't yet have any reports
of catastrophe.

I'm not sure I am brave enough though.

> With btrfs and mdadm RAID, it's basically worse because you have
> to deploy another variant of software RAID in addition to the
> software built into btrfs.

I see, so this is basically a philosophical objection. You already
have software that provides redundancy (btrfs), but since UEFI
firmware can't read it and insists that ESP be vfat, it would mean
providing redundancy another way. This need to have two means of
redundancy is an affront to you.

In practical terms, having md driver just for a small ESP array is
not going to be a big deal, but just the idea of configuring this
extra form of redundancy, having that extra driver loaded etc., is
unpleasant.

> So at least for boot disks, I'll go for hardware RAID whenever
> possible, especially with btrfs, until this problem is fixed.  Or do
> you have a better option?

Right, so your answer is hardware RAID. If you're happy with that,
that's great, but I've left hardware RAID behind nearly ten years
ago and this issue isn't enough for me to welcome it back. Though it
leaves a bad taste, I still would rather go with either syncing ESPs
by script or putting ESP in MD RAID and hoping firmware never write
to it.

I just wondered if there were more options (yet).

Thanks,
Andy

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

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

#266681

hw wrote: 
> 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.


You can add hooks to update-initramfs or update-grub.

To a first approximation:

firstbootpart = wwn-0x5006942feedbee1-part1
extrabootparts = wwn-0x5004269deafbead-part1\
 wwn-0x5001234adefabe-part1 \
 wwn-0x5005432faebeeda-part1

for eachpart in $extrabootparts ; \
	do cp /dev/disk/by-id/$firstbootpart /dev/disk/by-id/$eachpart; done

You'll need to provide suitable values for the partitions, and
remember to fix this when you change disks for any reason.

And test it, because I have not even run it once.

-dsr-

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

#266682

Hi,

Keeping all this context because I don't actually see how the
response matches the context and so I might have missed something…

On Sun, Jan 28, 2024 at 11:54:05AM -0500, Dan Ritter wrote:
> hw wrote: 
> > 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.
> 
> You can add hooks to update-initramfs or update-grub.
> 
> To a first approximation:
> 
> firstbootpart = wwn-0x5006942feedbee1-part1
> extrabootparts = wwn-0x5004269deafbead-part1\
>  wwn-0x5001234adefabe-part1 \
>  wwn-0x5005432faebeeda-part1
> 
> for eachpart in $extrabootparts ; \
> 	do cp /dev/disk/by-id/$firstbootpart /dev/disk/by-id/$eachpart; done

I realise that the above is pseudocode, but I have some issues with
it, namely:

a) I don't see what this has to do with btrfs, the subject of the
   message you are replying to. Then again, I also did not see what
   btrfs had to do with the thing that IT was replying to, so
   possibly I am very confused.

b) My best interpretation of your message is that it solves the "how
   to keep ESPs in sync" question, but if it is intended to do that
   then you may as well have just said "just keep the ESPs in sync",
   because what you wrote is literally something like:

   cp /dev/disk/by-id/wwn-0x5002538d425560a4-part1 /dev/disk/by-id/wwn-0x5002538d425560b5-part1

   which …is rather like a "now draw the rest of the owl" sort of
   response given that it doesn't literally work and most of the job
   is in reworking that line of pseudocode into something that will
   actually work.

If someone DOES want a script option that solves that problem, a
couple of actual working scripts were supplied in the link I gave to
the earlier thread:

    https://lists.debian.org/debian-user/2020/11/msg00455.html
    https://lists.debian.org/debian-user/2020/11/msg00458.html

Thanks,
Andy

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

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

#266691

On Sun, 2024-01-28 at 17:32 +0000, Andy Smith wrote:
> Hi,
> 
> Keeping all this context because I don't actually see how the
> response matches the context and so I might have missed something…
> 
> On Sun, Jan 28, 2024 at 11:54:05AM -0500, Dan Ritter wrote:
> > hw wrote: 
> > > 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.
> > 
> > You can add hooks to update-initramfs or update-grub.
> > 
> > To a first approximation:
> > 
> > firstbootpart = wwn-0x5006942feedbee1-part1
> > extrabootparts = wwn-0x5004269deafbead-part1\
> >  wwn-0x5001234adefabe-part1 \
> >  wwn-0x5005432faebeeda-part1
> > 
> > for eachpart in $extrabootparts ; \
> > 	do cp /dev/disk/by-id/$firstbootpart /dev/disk/by-id/$eachpart; done
> 
> I realise that the above is pseudocode, but I have some issues with
> it, namely:
> 
> a) I don't see what this has to do with btrfs, the subject of the
>    message you are replying to. Then again, I also did not see what
>    btrfs had to do with the thing that IT was replying to, so
>    possibly I am very confused.
> 
> b) My best interpretation of your message is that it solves the "how
>    to keep ESPs in sync" question, but if it is intended to do that
>    then you may as well have just said "just keep the ESPs in sync",
>    because what you wrote is literally something like:
> 
>    cp /dev/disk/by-id/wwn-0x5002538d425560a4-part1 /dev/disk/by-id/wwn-0x5002538d425560b5-part1
> 
>    which …is rather like a "now draw the rest of the owl" sort of
>    response given that it doesn't literally work and most of the job
>    is in reworking that line of pseudocode into something that will
>    actually work.
> 
> If someone DOES want a script option that solves that problem, a
> couple of actual working scripts were supplied in the link I gave to
> the earlier thread:
> 
>     https://lists.debian.org/debian-user/2020/11/msg00455.html
>     https://lists.debian.org/debian-user/2020/11/msg00458.html

Huh?  Isn't it simpler to use mdraid RAID1 to keep the UEFI partitions
in sync without extra scripts needed?

(I don't like that option, but it seems like an option when you have
no hardware RAID.)

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

#266699

Hello,

On Sun, Jan 28, 2024 at 09:09:17PM +0100, hw wrote:
> On Sun, 2024-01-28 at 17:32 +0000, Andy Smith wrote:
> > If someone DOES want a script option that solves that problem, a
> > couple of actual working scripts were supplied in the link I gave to
> > the earlier thread:
> > 
> >     https://lists.debian.org/debian-user/2020/11/msg00455.html
> >     https://lists.debian.org/debian-user/2020/11/msg00458.html
> 
> Huh?  Isn't it simpler to use mdraid RAID1 to keep the UEFI partitions
> in sync without extra scripts needed?

Could you read the first link above.

Thanks,
Andy

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

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

#266724

On Sun, 2024-01-28 at 21:55 +0000, Andy Smith wrote:
> Hello,
> 
> On Sun, Jan 28, 2024 at 09:09:17PM +0100, hw wrote:
> > On Sun, 2024-01-28 at 17:32 +0000, Andy Smith wrote:
> > > If someone DOES want a script option that solves that problem, a
> > > couple of actual working scripts were supplied in the link I gave to
> > > the earlier thread:
> > > 
> > >     https://lists.debian.org/debian-user/2020/11/msg00455.html
> > >     https://lists.debian.org/debian-user/2020/11/msg00458.html
> > 
> > Huh?  Isn't it simpler to use mdraid RAID1 to keep the UEFI partitions
> > in sync without extra scripts needed?
> 
> Could you read the first link above.

I did, and it doesn't explain why you would need a bunch of scripts.

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

#266749

Hi,

On Mon, Jan 29, 2024 at 05:28:56PM +0100, hw wrote:
> On Sun, 2024-01-28 at 21:55 +0000, Andy Smith wrote:
> > On Sun, Jan 28, 2024 at 09:09:17PM +0100, hw wrote:
> > > On Sun, 2024-01-28 at 17:32 +0000, Andy Smith wrote:
> > > > If someone DOES want a script option that solves that problem, a
> > > > couple of actual working scripts were supplied in the link I gave to
> > > > the earlier thread:
> > > > 
> > > >     https://lists.debian.org/debian-user/2020/11/msg00455.html
> > > >     https://lists.debian.org/debian-user/2020/11/msg00458.html
> > > 
> > > Huh?  Isn't it simpler to use mdraid RAID1 to keep the UEFI partitions
> > > in sync without extra scripts needed?
> > 
> > Could you read the first link above.
> 
> I did, and it doesn't explain why you would need a bunch of scripts.

I think you should read it again until you find the part where it
clearly states what the problem is with using MD RAID for this. If
you still can't find that part, there is likely to be a problem I
can't assist with.

Thanks,
Andy

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

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

#266779

On Mon, 2024-01-29 at 23:53 +0000, Andy Smith wrote:
> Hi,
> 
> On Mon, Jan 29, 2024 at 05:28:56PM +0100, hw wrote:
> > On Sun, 2024-01-28 at 21:55 +0000, Andy Smith wrote:
> > > On Sun, Jan 28, 2024 at 09:09:17PM +0100, hw wrote:
> > > > On Sun, 2024-01-28 at 17:32 +0000, Andy Smith wrote:
> > > > > If someone DOES want a script option that solves that problem, a
> > > > > couple of actual working scripts were supplied in the link I gave to
> > > > > the earlier thread:
> > > > > 
> > > > >     https://lists.debian.org/debian-user/2020/11/msg00455.html
> > > > >     https://lists.debian.org/debian-user/2020/11/msg00458.html
> > > > 
> > > > Huh?  Isn't it simpler to use mdraid RAID1 to keep the UEFI partitions
> > > > in sync without extra scripts needed?
> > > 
> > > Could you read the first link above.
> > 
> > I did, and it doesn't explain why you would need a bunch of scripts.
> 
> I think you should read it again until you find the part where it
> clearly states what the problem is with using MD RAID for this. If
> you still can't find that part, there is likely to be a problem I
> can't assist with.

That there may be a problem doesn't automatically mean that you need a
bunch of scripts.

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

#266808

Hi,

On Tue, Jan 30, 2024 at 09:50:23PM +0100, hw wrote:
> On Mon, 2024-01-29 at 23:53 +0000, Andy Smith wrote:
> > I think you should read it again until you find the part where it
> > clearly states what the problem is with using MD RAID for this. If
> > you still can't find that part, there is likely to be a problem I
> > can't assist with.
> 
> That there may be a problem doesn't automatically mean that you need a
> bunch of scripts.

This is getting quite tedious.

Multiple people have said that there is a concern that UEFI firmware
might write to an ESP, which would invalidate the use of software
RAID for the ESP.

Multiple people have suggested instead syncing ESP partitions in
userland. If you're going to do that then you'll need a script to do
it.

I don't understand what you find so difficult to grasp about this.
If it's that you have some other proposal for solving this, it would
be helpful for you to say so, instead of just repeating "why do you
need scripts, you don't need scripts", because if you just repeat
that, all I can do is repeat what I've already said until I become
bored and stop.

If your suggested solution is "use hardware RAID", no need to repeat
that one though: I see you said it in a few other messages, and that
suggestions has been received. Assume the conversation continues
amongst people who don't like that suggestion.

Otherwise, I don't think anyone knows what you have spent several
messages trying to say. All we got was, "you don't need scripts".

Thanks,
Andy

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

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

#266821

On Wed, 2024-01-31 at 15:16 +0000, Andy Smith wrote:
> Hi,
> 
> On Tue, Jan 30, 2024 at 09:50:23PM +0100, hw wrote:
> > On Mon, 2024-01-29 at 23:53 +0000, Andy Smith wrote:
> > > I think you should read it again until you find the part where it
> > > clearly states what the problem is with using MD RAID for this. If
> > > you still can't find that part, there is likely to be a problem I
> > > can't assist with.
> > 
> > That there may be a problem doesn't automatically mean that you need a
> > bunch of scripts.
> 
> This is getting quite tedious.
> 
> Multiple people have said that there is a concern that UEFI firmware
> might write to an ESP, which would invalidate the use of software
> RAID for the ESP.
> 
> Multiple people have suggested instead syncing ESP partitions in
> userland. If you're going to do that then you'll need a script to do
> it.
> 
> I don't understand what you find so difficult to grasp about this.

You kept only saying 'read the link'.  Well, read the link!  It points
out 4 choices and none of them says 'you need a bunch of scripts'.

> If it's that you have some other proposal for solving this, it would
> be helpful for you to say so

I already said my solution is using hardware raid or fixing the
problem in all the UEFI BIOSs.

I'd also say that the BIOS must never write to the storage, be it to
an UEFI partition or anywhere else.  But that's a different topic.

> [...]
> If your suggested solution is "use hardware RAID", no need to repeat
> that one though: I see you said it in a few other messages, and that
> suggestions has been received. Assume the conversation continues
> amongst people who don't like that suggestion.

Well, too late, I already said it again since you asked.  Do you have
a better solution?  It's ok not to like this solution, but do you have
a better one?

> Otherwise, I don't think anyone knows what you have spent several
> messages trying to say. All we got was, "you don't need scripts".

What do you expect when you keep repeating 'read the link'.

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

#266870

On 31/01/24 at 22:51, hw wrote:
>> [...]
>> If your suggested solution is "use hardware RAID", no need to repeat
>> that one though: I see you said it in a few other messages, and that
>> suggestions has been received. Assume the conversation continues
>> amongst people who don't like that suggestion.

> Well, too late, I already said it again since you asked.  Do you have
> a better solution?  It's ok not to like this solution, but do you have
> a better one?

There is an alternative to hardware RAID if you want a Linux RAID: you 
can disable UEFI in the BIOS and delete the ESP as I did when I bought 
my gaming PC several years ago.

I created my software RAID level 5 using debian-installer and it works 
perfectly without ESP, you have to choose "Expert install" in "Advanced 
options". I installed Bookworm when it was released in this way.

Cheers,
-- 
Franco Martelli

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

#266884

On Fri, 2024-02-02 at 14:41 +0100, Franco Martelli wrote:
> On 31/01/24 at 22:51, hw wrote:
> > > [...]
> > > If your suggested solution is "use hardware RAID", no need to repeat
> > > that one though: I see you said it in a few other messages, and that
> > > suggestions has been received. Assume the conversation continues
> > > amongst people who don't like that suggestion.
> 
> > Well, too late, I already said it again since you asked.  Do you have
> > a better solution?  It's ok not to like this solution, but do you have
> > a better one?
> 
> There is an alternative to hardware RAID if you want a Linux RAID: you 
> can disable UEFI in the BIOS and delete the ESP as I did when I bought 
> my gaming PC several years ago.
> 
> I created my software RAID level 5 using debian-installer and it works 
> perfectly without ESP, you have to choose "Expert install" in "Advanced 
> options". I installed Bookworm when it was released in this way.

Right, I forgot about that.  Is that always an option?

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

#266933

Hi,

On Fri, Feb 02, 2024 at 02:41:38PM +0100, Franco Martelli wrote:
> There is an alternative to hardware RAID if you want a Linux RAID: you can
> disable UEFI in the BIOS and delete the ESP as I did when I bought my gaming
> PC several years ago.

I have storage devices which legacy BIOS cannot see for booting
purposes. In past years these would require an "option ROM", Today,
they require UEFI firmware. They aren't exotic devices; just
enterprise NVMe.

Thanks,
Andy

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

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

#266713

On 28/01/24 at 17:17, hw wrote:
> 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 :)

There is a sort of HOWTO [1] published in the archLinux wiki [2] but I 
don't advise it because there are many things that could go wrong.

Cheers,

[1] https://outflux.net/blog/archives/2018/04/19/uefi-booting-and-raid1/
[2] 
https://wiki.archlinux.org/title/EFI_system_partition#ESP_on_software_RAID1

-- 
Franco Martelli

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

#266726

On Mon, 2024-01-29 at 14:45 +0100, Franco Martelli wrote:
> On 28/01/24 at 17:17, hw wrote:
> > 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 :)
> 
> There is a sort of HOWTO [1] published in the archLinux wiki [2] but I 
> don't advise it because there are many things that could go wrong.
> 
> Cheers,
> 
> [1] https://outflux.net/blog/archives/2018/04/19/uefi-booting-and-raid1/
> [2] 
> https://wiki.archlinux.org/title/EFI_system_partition#ESP_on_software_RAID1

Ok in that case, hardware RAID is a requirement for machines with UEFI
BIOS since otherwise their reliability is insufficient.

I didn't plan on using hardware RAID for my next server, and now
things are getting way more complicated than they already are because
I can't just keep using the disks from my current one :(  Hmm ...

But I'm glad that I looked into this.

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

#266728

hw (12024-01-29):
> Ok in that case, hardware RAID is a requirement for machines with UEFI

That is not true, you can still put the RAID in a partition and keep the
boot partitions in sync manually or with scripts.

-- 
  Nicolas George

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

#266774

hw (12024-01-30):
> Yes, and how much effort and how reliable is doing that?

Very little effort and probably more reliable than hardware RAID with
closed-source hardware.

-- 
  Nicolas George

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

#266824

On Tue, 2024-01-30 at 21:35 +0100, Nicolas George wrote:
> hw (12024-01-30):
> > Yes, and how much effort and how reliable is doing that?
> 
> Very little effort and probably more reliable than hardware RAID with
> closed-source hardware.

Well, I doubt it.  After all you need to copy a whole partition and
must make sure that it doesn't fail through distribution upgrades and
all kinds of possible changes and even when someone shuts down or
reboots the computer or pulls the plug while the copying is still in
progress.  You also must make sure that the boot manager is installed
on multiple disks.

And when you're going to do it?  When shutting the machine down?
Might not happen and when it does happen, maybe you don't want to wait
on it.

When rebooting it?  Perhaps you don't want to overwrite the copy at
that time, or perhaps it's too late then because there were software
updates before you rebooted and one of the disks failed when
rebooting.

Do you suggest to install backup batteries or capacitors to keep the
machine running until the copying process has completed when the power
goes out?

Or do you want to do it all manually at a time convenient for you?
What if you forgot to do it?


I'm not so silly that you could convince me that you can do it more
reliably than the hardware RAID does it whith a bunch of scripts you
put together yourself, especially not by implying that the hardware
raid which has been tested in many datacenters with who knows how many
hundreds of thousands of machines over many years uses closed source
software which has been maintained and therefore must be unreliable.

The lowest listed MTBF of hardware RAID is over 260000 hours
(i. e. about 30 years) on [1].  Can you show that you can do it more
reliably with your bunch of scripts?


[1]: https://www.intel.com/content/www/us/en/support/articles/000007641/server-products/sasraid.html

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

Page 2 of 3 — ← Prev page 1 [2] 3  Next page →

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

csiph-web