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
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
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,
On Wed, 2024-01-31 at 23:28 +0100, Nicolas George wrote:
> hw (12024-01-31):
> > Well, I doubt it.
>
> Well, doubt it all you want. In the meantime, we will continue to use
> it.
>
> Did not read the rest, not interested in red herring nightmare
> scenarios.
>
You'll figure it out eventually.
On 01/02/2024 05:45, hw wrote:
It would make sense that all the UEFI BIOSs would be fixed so that
they do not create this problem in the first place like they
shouldn't.
Besides regular boots, sometimes it is necessary to update firmware and
.efi files loaded for this purpose may write logs
On Wed, 2024-01-31 at 06:33 +0100, to...@tuxteam.de wrote:
> On Tue, Jan 30, 2024 at 09:47:35PM +0100, hw wrote:
> > On Mon, 2024-01-29 at 18:41 +0100, to...@tuxteam.de wrote:
> > > On Mon, Jan 29, 2024 at 05:52:38PM +0100, hw wrote:
> > >
> > > [...]
> > >
> > > > Ok in that case, hardware RAID
hw (12024-01-31):
> Well, I doubt it.
Well, doubt it all you want. In the meantime, we will continue to use
it.
Did not read the rest, not interested in red herring nightmare
scenarios.
--
Nicolas George
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
On Wed, 2024-01-31 at 15:16 +, Andy Smith wrote:
> Hi,
>
> On Tue, Jan 30, 2024 at 09:50:23PM +0100, hw wrote:
> > On Mon, 2024-01-29 at 23:53 +, 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
Hi,
On Tue, Jan 30, 2024 at 09:50:23PM +0100, hw wrote:
> On Mon, 2024-01-29 at 23:53 +, 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
On Tue, Jan 30, 2024 at 09:47:35PM +0100, hw wrote:
> On Mon, 2024-01-29 at 18:41 +0100, to...@tuxteam.de wrote:
> > On Mon, Jan 29, 2024 at 05:52:38PM +0100, hw wrote:
> >
> > [...]
> >
> > > Ok in that case, hardware RAID is a requirement for machines with UEFI
> > > BIOS since otherwise their
On Mon, 2024-01-29 at 23:53 +, Andy Smith wrote:
> Hi,
>
> On Mon, Jan 29, 2024 at 05:28:56PM +0100, hw wrote:
> > On Sun, 2024-01-28 at 21:55 +, Andy Smith wrote:
> > > On Sun, Jan 28, 2024 at 09:09:17PM +0100, hw wrote:
> > > > On Sun, 2024-01-28 at 17:32 +, Andy Smith wrote:
> > >
On Mon, 2024-01-29 at 18:41 +0100, to...@tuxteam.de wrote:
> On Mon, Jan 29, 2024 at 05:52:38PM +0100, hw wrote:
>
> [...]
>
> > Ok in that case, hardware RAID is a requirement for machines with UEFI
> > BIOS since otherwise their reliability is insufficient.
>
> The price you pay for hardware
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
On Mon, 2024-01-29 at 18:00 +0100, Nicolas George wrote:
> 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.
Yes, and how
Hi,
On Mon, Jan 29, 2024 at 05:28:56PM +0100, hw wrote:
> On Sun, 2024-01-28 at 21:55 +, Andy Smith wrote:
> > On Sun, Jan 28, 2024 at 09:09:17PM +0100, hw wrote:
> > > On Sun, 2024-01-28 at 17:32 +, Andy Smith wrote:
> > > > If someone DOES want a script option that solves that problem,
On Mon, Jan 29, 2024 at 05:52:38PM +0100, hw wrote:
[...]
> Ok in that case, hardware RAID is a requirement for machines with UEFI
> BIOS since otherwise their reliability is insufficient.
The price you pay for hardware RAID is that you need a compatible controller
if you take your disks
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
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
On Sun, 2024-01-28 at 21:55 +, Andy Smith wrote:
> Hello,
>
> On Sun, Jan 28, 2024 at 09:09:17PM +0100, hw wrote:
> > On Sun, 2024-01-28 at 17:32 +, Andy Smith wrote:
> > > If someone DOES want a script option that solves that problem, a
> > > couple of actual working scripts were
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
Hello,
On Sun, Jan 28, 2024 at 09:09:17PM +0100, hw wrote:
> On Sun, 2024-01-28 at 17:32 +, 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:
> >
> >
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
On Sun, 2024-01-28 at 17:32 +, 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
On Sun, 2024-01-28 at 16:46 +, 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
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
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:
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
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
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
Hello,
On Fri, Jan 26, 2024 at 04:50:00PM +0100, hw wrote:
> How do you make the BIOS read the EFI partition when it's on mdadm
> RAID?
If MD superblock is at a part of device not used by filesystem (e.g.
the end) and it is a RAID-1, each member device is indistinguishable
from FAT filesystem
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
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
Hello,
On Fri, Jan 26, 2024 at 01:18:53PM +, 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
--
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
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
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
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
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
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
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
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
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
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
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.
Nicolas George composed on 2024-01-24 20:50 (UTC+0100):
> Felix Miata composed:
>> Technically, quite true. However, OS and user data are very different. User
>> data
>> recreation and/or restoration can be as painful as impossible, justifying
>> RAID. OS
>> can be reinstalled rather easily in
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
Hi,
On Wed, Jan 24, 2024 at 11:17:34AM +0100, 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
>
On 24/01/2024 10:17, Nicolas George wrote:
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),
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
Franco Martelli (12024-01-24):
> If I run "grub-install" with multiple device I got
>
> # LCALL=C grub-install /dev/sd[a-d]
> grub-install: error: More than one install device?.
>
> maybe it is a deprecated action for grub to install to multiple device, so
> this should it be investigated?
Do
Felix Miata (12024-01-24):
> Technically, quite true. However, OS and user data are very different. User
> data
> recreation and/or restoration can be as painful as impossible, justifying
> RAID. OS
> can be reinstalled rather easily in a nominal amount of time. A 120G SSD can
> hold
> multiple
On 24/01/24 at 11:17, Nicolas George wrote:
Which leads me to wonder if there is an automated way to install GRUB on
all the EFI partitions.
If I run "grub-install" with multiple device I got
# LCALL=C grub-install /dev/sd[a-d]
grub-install: error: More than one install device?.
maybe it is
Nicolas George composed on 2024-01-24 15:39 (UTC+0100):
> Charles Curley (12024-01-24):
>> Although I found it simpler (and faster) to have all my system stuff on
>> an SSD, and the RAID on four HDDs. Grub goes on the SSD and that's that.
> If the SSD dies, your system does not boot. Somewhat
Charles Curley (12024-01-24):
> Perhaps a script based on:
Thanks, I know how to make scripts. My question ported specifically on
making it automatic.
> Although I found it simpler (and faster) to have all my system stuff on
> an SSD, and the RAID on four HDDs. Grub goes on the SSD and that's
On Wed, 24 Jan 2024 11:17:34 +0100
Nicolas George wrote:
> Which leads me to wonder if there is an automated way to install GRUB
> on all the EFI partitions.
I'm not aware of any existing solutions.
Perhaps a script based on:
for i in a b c d e ; do echo /dev/sd$i ; grub-install /dev/sd$i ;
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
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
58 matches
Mail list logo
