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

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

Best practice for fresh install on UEFI with multiple disks?

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

Contents

  Best practice for fresh install on UEFI with multiple disks? Boyan Penkov <boyan.penkov@gmail.com> - 2024-09-19 02:30 +0200
    Re: Best practice for fresh install on UEFI with multiple disks? Andy Smith <andy@strugglers.net> - 2024-09-19 04:00 +0200
      Re: Best practice for fresh install on UEFI with multiple disks? Florent Rougon <f.rougon@free.fr> - 2024-09-19 12:10 +0200
        Re: Best practice for fresh install on UEFI with multiple disks? Tim Woodall <debianuser@woodall.me.uk> - 2024-09-20 04:30 +0200
          Re: Best practice for fresh install on UEFI with multiple disks? Florent Rougon <f.rougon@free.fr> - 2024-09-20 09:50 +0200
            Re: Best practice for fresh install on UEFI with multiple disks? Tim Woodall <debianuser@woodall.me.uk> - 2024-09-20 12:20 +0200
              Re: Best practice for fresh install on UEFI with multiple disks? Florent Rougon <f.rougon@free.fr> - 2024-09-20 12:50 +0200
                Re: Best practice for fresh install on UEFI with multiple disks? Tim Woodall <debianuser@woodall.me.uk> - 2024-09-20 20:20 +0200
                  Re: Best practice for fresh install on UEFI with multiple disks? Boyan Penkov <boyan.penkov@gmail.com> - 2024-09-30 16:20 +0200
                    Re: Best practice for fresh install on UEFI with multiple disks? Florent Rougon <f.rougon@free.fr> - 2024-09-30 18:30 +0200
                    Re: Best practice for fresh install on UEFI with multiple disks? Boyan Penkov <boyan.penkov@gmail.com> - 2024-11-01 01:10 +0100

#273154 — Best practice for fresh install on UEFI with multiple disks?

Hello folks,

New machine, new opportunity to get up to speed with the contemporary
best practices for multiple disks on UEFI.

The behavior I'd like -- and, I suspect, the behavior we'd all like --
is the machine stays bootable and data is preserved if any disk fails.
Specifically, what I'd like to do if a disk fails (or starts warning
me of possible failure) is shut the machine down at my convenience,
replace the disk, have it re-boot, and re-populate the new disk with
data in the background.

For data, BTRFS works well for my use case, has for some time, and has
been tested on disks dying in the last few years.  However, this is
the first time I have a chance to deal with this for /boot on EFI
partitions, which can't be put on BTRFS.

So, what are folks doing these days to mirror /efi and /boot?
Googling shows that Ubuntu can boot off RAID directly here, but Debian
cant quite yet without manually rsync'ing directories.

Anybody have a firm solution here?

Cheers!

-- 
Boyan Penkov

[toc] | [next] | [standalone]

#273155

Hi,

On Wed, Sep 18, 2024 at 08:21:10PM -0400, Boyan Penkov wrote:
> So, what are folks doing these days to mirror /efi and /boot?

    [ TL;DR: You already found it - have two separate EFI System
      Partitions, sync one to the other manually using e.g. rsync
      whenever one changes, add paths to both in your UEFI firmware. ]

I don't think the answer, on Debian, has changed since I asked the
same question in 2020:

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

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

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

#273156

Hi,

Le 19/09/2024, Andy Smith <andy@strugglers.net> a écrit:

> I don't think the answer, on Debian, has changed since I asked the
> same question in 2020:
>
>     https://lists.debian.org/debian-user/2020/11/msg00455.html

There is a script at [1] to install as, e.g.,
/etc/grub.d/90_copy_to_boot_efi2, so that it is automatically run every
time grub updates its configuration file. I believe the script is fine,
except I would do

  mount /boot/efi2

rather than

  mount /boot/efi2 || :

Maybe the intent is for the script not to return a non-zero exit status
when /boot/efi2 can't be mounted, however in this case I certainly don't
want the rsync command to be run.

Regards

[1] https://wiki.debian.org/UEFI#RAID_for_the_EFI_System_Partition

-- 
Florent

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

#273164

On Thu, 19 Sep 2024, Florent Rougon wrote:

> Hi,
>
> Le 19/09/2024, Andy Smith <andy@strugglers.net> a ?crit:
>
>> I don't think the answer, on Debian, has changed since I asked the
>> same question in 2020:
>>
>>     https://lists.debian.org/debian-user/2020/11/msg00455.html
>
> There is a script at [1] to install as, e.g.,
> /etc/grub.d/90_copy_to_boot_efi2, so that it is automatically run every
> time grub updates its configuration file. I believe the script is fine,
> except I would do
>
>  mount /boot/efi2
>
> rather than
>
>  mount /boot/efi2 || :
>
> Maybe the intent is for the script not to return a non-zero exit status
> when /boot/efi2 can't be mounted, however in this case I certainly don't
> want the rsync command to be run.
>

Haven't looked at the script but assuming it's run set -e, then your
suggestion will fail if it's already mounted.

Best would be to check that, and unmount again only if the script
mounted.

Tim.

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

#273166

Le 20/09/2024, Tim Woodall <debianuser@woodall.me.uk> a écrit:

> Haven't looked at the script but assuming it's run set -e, then your
> suggestion will fail if it's already mounted.

Why?

-- 
Florent

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

#273171

On Fri, 20 Sep 2024, Florent Rougon wrote:

> Le 20/09/2024, Tim Woodall <debianuser@woodall.me.uk> a ?crit:
>
>> Haven't looked at the script but assuming it's run set -e, then your
>> suggestion will fail if it's already mounted.
>
> Why?
>
>
Because the script will abort after the mount fails.

root@dirac:~# cat test.sh
#!/bin/bash

set -e

mount /boot/efi2

echo "do important stuff"

root@dirac:~# ./test.sh
mount: /boot/efi2: /dev/sda2 already mounted on /boot/efi2.
        dmesg(1) may have more information after failed mount system call.


Note that do important stuff is never reached.

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

#273173

Le 20/09/2024, Tim Woodall <debianuser@woodall.me.uk> a écrit:

> Because the script will abort after the mount fails.
>
> root@dirac:~# cat test.sh
> #!/bin/bash
>
> set -e
>
> mount /boot/efi2
>
> echo "do important stuff"
>
> root@dirac:~# ./test.sh
> mount: /boot/efi2: /dev/sda2 already mounted on /boot/efi2.
>        dmesg(1) may have more information after failed mount system call.
>
>
> Note that do important stuff is never reached.

That's interesting because my system doesn't behave the same. I had of
course checked, before writing my first message, that 'mount /boot/efi2'
returns exit status 0 even when /boot/efi2 is already mounted. With your
script (called foo.sh here), here is what I get:

# mount | grep efi2
/dev/sda1 on /boot/efi2 type vfat (rw,relatime,fmask=0022,dmask=0022,codepage=437,iocharset=ascii,shortname=mixed,utf8,errors=remount-ro)
# /tmp/foo.sh
do important stuff
# mount | grep efi2
/dev/sda1 on /boot/efi2 type vfat (rw,relatime,fmask=0022,dmask=0022,codepage=437,iocharset=ascii,shortname=mixed,utf8,errors=remount-ro)
/dev/sda1 on /boot/efi2 type vfat (rw,relatime,fmask=0022,dmask=0022,codepage=437,iocharset=ascii,shortname=mixed,utf8,errors=remount-ro)
#

Every invocation adds a new, duplicate entry in the output of 'mount'.

This is Debian sid amd64; /usr/bin/mount is from 'mount' package version
2.40.2-8.

Regards

-- 
Florent

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

#273180

[Multipart message — attachments visible in raw view] — view raw

On Fri, 20 Sep 2024, Florent Rougon wrote:

> Le 20/09/2024, Tim Woodall <debianuser@woodall.me.uk> a écrit:
>
>> Because the script will abort after the mount fails.
>>
>> root@dirac:~# cat test.sh
>> #!/bin/bash
>>
>> set -e
>>
>> mount /boot/efi2
>>
>> echo "do important stuff"
>>
>> root@dirac:~# ./test.sh
>> mount: /boot/efi2: /dev/sda2 already mounted on /boot/efi2.
>>        dmesg(1) may have more information after failed mount system call.
>>
>>
>> Note that do important stuff is never reached.
>
> That's interesting because my system doesn't behave the same. I had of
> course checked, before writing my first message, that 'mount /boot/efi2'
> returns exit status 0 even when /boot/efi2 is already mounted. With your
> script (called foo.sh here), here is what I get:
>
> # mount | grep efi2
> /dev/sda1 on /boot/efi2 type vfat (rw,relatime,fmask=0022,dmask=0022,codepage=437,iocharset=ascii,shortname=mixed,utf8,errors=remount-ro)
> # /tmp/foo.sh
> do important stuff
> # mount | grep efi2
> /dev/sda1 on /boot/efi2 type vfat (rw,relatime,fmask=0022,dmask=0022,codepage=437,iocharset=ascii,shortname=mixed,utf8,errors=remount-ro)
> /dev/sda1 on /boot/efi2 type vfat (rw,relatime,fmask=0022,dmask=0022,codepage=437,iocharset=ascii,shortname=mixed,utf8,errors=remount-ro)
> #
>
> Every invocation adds a new, duplicate entry in the output of 'mount'.
>
> This is Debian sid amd64; /usr/bin/mount is from 'mount' package version
> 2.40.2-8.
>

That's very interesting and looks like it's probably a kernel change.

Tim.

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

#273375

Hello folks,

Thanks kindly -- and my apologies for picking this up after a while;
fell sick here...

A few questions:

-- If I have multiple drives, do I modify the script to have multiple
efi2, efi3, ..., efiX ?

-- it seems that the script above privileges /boot/efi over /boot/efi2
-- in this case, if /boot/efi becomes corrupted, won't this just copy
the errors to /boot/efi2 and thus destroy it as well, on the next run?

Cheers!

On Fri, Sep 20, 2024 at 2:12 PM Tim Woodall <debianuser@woodall.me.uk> wrote:
>
> On Fri, 20 Sep 2024, Florent Rougon wrote:
>
> > Le 20/09/2024, Tim Woodall <debianuser@woodall.me.uk> a écrit:
> >
> >> Because the script will abort after the mount fails.
> >>
> >> root@dirac:~# cat test.sh
> >> #!/bin/bash
> >>
> >> set -e
> >>
> >> mount /boot/efi2
> >>
> >> echo "do important stuff"
> >>
> >> root@dirac:~# ./test.sh
> >> mount: /boot/efi2: /dev/sda2 already mounted on /boot/efi2.
> >>        dmesg(1) may have more information after failed mount system call.
> >>
> >>
> >> Note that do important stuff is never reached.
> >
> > That's interesting because my system doesn't behave the same. I had of
> > course checked, before writing my first message, that 'mount /boot/efi2'
> > returns exit status 0 even when /boot/efi2 is already mounted. With your
> > script (called foo.sh here), here is what I get:
> >
> > # mount | grep efi2
> > /dev/sda1 on /boot/efi2 type vfat (rw,relatime,fmask=0022,dmask=0022,codepage=437,iocharset=ascii,shortname=mixed,utf8,errors=remount-ro)
> > # /tmp/foo.sh
> > do important stuff
> > # mount | grep efi2
> > /dev/sda1 on /boot/efi2 type vfat (rw,relatime,fmask=0022,dmask=0022,codepage=437,iocharset=ascii,shortname=mixed,utf8,errors=remount-ro)
> > /dev/sda1 on /boot/efi2 type vfat (rw,relatime,fmask=0022,dmask=0022,codepage=437,iocharset=ascii,shortname=mixed,utf8,errors=remount-ro)
> > #
> >
> > Every invocation adds a new, duplicate entry in the output of 'mount'.
> >
> > This is Debian sid amd64; /usr/bin/mount is from 'mount' package version
> > 2.40.2-8.
> >
>
> That's very interesting and looks like it's probably a kernel change.
>
> Tim.



-- 
Boyan Penkov

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

#273379

Hi,

Le 30/09/2024, Boyan Penkov <boyan.penkov@gmail.com> a écrit:

> -- If I have multiple drives, do I modify the script to have multiple
> efi2, efi3, ..., efiX ?

I think yes.

> -- it seems that the script above privileges /boot/efi over /boot/efi2
> -- in this case, if /boot/efi becomes corrupted, won't this just copy
> the errors to /boot/efi2 and thus destroy it as well, on the next run?

My understanding of how the script was designed is the following:
  - if the disk containing /boot/efi is fine, no problem using it as the
    “master copy”;
  - if it has a silent corruption problem, we're screwed and the
    corruption may be copied to other disks, but that's already the case
    with other partitions in a raid (nowadays there are consistency
    checks...);
  - if it has a problem that is visible enough for the md layer to
    remove the disk from the array, then /boot/efi won't be a mount
    point anymore, so the script will do nothing from this point on.
    Thus, you can boot from another disk until you have a replacement
    drive; during this time (and unless you changed /etc/fstab), the
    script won't sync anything.

HTH, regards

-- 
Florent

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

#274229

Hello folks,

Just to follow up on this thread, here's how it played out:

-- I gave up on EFI, and use just BIOS boot
-- each drive has three partitions: a space for grub-install, am mdadm
md0 /boot and a btrfs raid1c3 root partition
-- grub-install on each dev manually, and I probably need an apt grub hook here

This setup was tested almost immediately, since one of the nvmes died
very soon after the install, and I was able to boot off each of the
three remaining devices.

About the only thing that I think could be different (besides the grub
apt hook) is I could probably lose the RAID /boot and do that directly
on the btrfs.

Either way, thanks to all the wiki contributors over the years, and cheers!

On Mon, Sep 30, 2024 at 10:14 AM Boyan Penkov <boyan.penkov@gmail.com> wrote:
>
> Hello folks,
>
> Thanks kindly -- and my apologies for picking this up after a while;
> fell sick here...
>
> A few questions:
>
> -- If I have multiple drives, do I modify the script to have multiple
> efi2, efi3, ..., efiX ?
>
> -- it seems that the script above privileges /boot/efi over /boot/efi2
> -- in this case, if /boot/efi becomes corrupted, won't this just copy
> the errors to /boot/efi2 and thus destroy it as well, on the next run?
>
> Cheers!
>
> On Fri, Sep 20, 2024 at 2:12 PM Tim Woodall <debianuser@woodall.me.uk> wrote:
> >
> > On Fri, 20 Sep 2024, Florent Rougon wrote:
> >
> > > Le 20/09/2024, Tim Woodall <debianuser@woodall.me.uk> a écrit:
> > >
> > >> Because the script will abort after the mount fails.
> > >>
> > >> root@dirac:~# cat test.sh
> > >> #!/bin/bash
> > >>
> > >> set -e
> > >>
> > >> mount /boot/efi2
> > >>
> > >> echo "do important stuff"
> > >>
> > >> root@dirac:~# ./test.sh
> > >> mount: /boot/efi2: /dev/sda2 already mounted on /boot/efi2.
> > >>        dmesg(1) may have more information after failed mount system call.
> > >>
> > >>
> > >> Note that do important stuff is never reached.
> > >
> > > That's interesting because my system doesn't behave the same. I had of
> > > course checked, before writing my first message, that 'mount /boot/efi2'
> > > returns exit status 0 even when /boot/efi2 is already mounted. With your
> > > script (called foo.sh here), here is what I get:
> > >
> > > # mount | grep efi2
> > > /dev/sda1 on /boot/efi2 type vfat (rw,relatime,fmask=0022,dmask=0022,codepage=437,iocharset=ascii,shortname=mixed,utf8,errors=remount-ro)
> > > # /tmp/foo.sh
> > > do important stuff
> > > # mount | grep efi2
> > > /dev/sda1 on /boot/efi2 type vfat (rw,relatime,fmask=0022,dmask=0022,codepage=437,iocharset=ascii,shortname=mixed,utf8,errors=remount-ro)
> > > /dev/sda1 on /boot/efi2 type vfat (rw,relatime,fmask=0022,dmask=0022,codepage=437,iocharset=ascii,shortname=mixed,utf8,errors=remount-ro)
> > > #
> > >
> > > Every invocation adds a new, duplicate entry in the output of 'mount'.
> > >
> > > This is Debian sid amd64; /usr/bin/mount is from 'mount' package version
> > > 2.40.2-8.
> > >
> >
> > That's very interesting and looks like it's probably a kernel change.
> >
> > Tim.
>
>
>
> --
> Boyan Penkov



-- 
Boyan Penkov

[toc] | [prev] | [standalone]

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

csiph-web