e if I turn off secure boot, fast boot and
> turn on CSM support with UEFI.
The EFI partition of debian-live-12.0.0-amd64-standard.iso looks like
there is the microsoft-signed shim in /EFI/boot/bootx64.efi . So it
seems at least to strive for Secure Boot compliance.
Maybe it is about SBAT, which c
secure boot, fast boot and turn
on CSM support with UEFI. For other distros like Linux Mint Debian
Edition, Fedora, Ubuntu, can boot without turn off secure boot
and turn on CSM support.
This is my device config:
- Ryzen 7 9700x
- Gigabyte b650m aorus elite ax
- AMD Rx 6600
Many thanks
Lê
UEFI. For other distros like Linux Mint Debian Edition,
Fedora, Ubuntu, can boot without turn off secure boot and turn on CSM
support.
This is my device config:
- Ryzen 7 9700x
- Gigabyte b650m aorus elite ax
- AMD Rx 6600
Many thanks
Lê Trần Ngọc Thành
>>Now I heard of, that a NVME drive will only get to full speed, if UEFI is
>>activated in BIOS. Is this correct?
> No, at least for linux; I can't speak to windows.
+1
Stefan
> New machines may not have "legacy/MBR" options to boot any more.
>
Mine is a used one, a Dell 5400, and luckily it can still use legacy boot.
> A straightforward new installation of Debian should create the ESP and
> appropriate means to install under UEFI. If you're
> Be sure not to reboot after cloning while both source and target remain
> enabled.
I always shut down the device completely. then wait a few seaconds. disconnect
all drives (Lifefile usb drive and storage) and then start the machine again.
In the past I never had any issues doing so.
Cheers
On Thu, Jan 16, 2025 at 04:17:29PM +0100, Hans wrote:
> Hi folks,
>
> I got a new notebook with an NVME drive.
>
> As all my BIOS never needed UEFI, my installation dula boot of Windows and
> Debian are all without UEFI.
>
New machines may not have "legacy/MBR
Hans composed on 2025-01-16 16:57 (UTC+0100):
>> That depends on how you describe partitions in /etc/fstab. If you use
>> the device name, then almost certainly yes. If you use the label or
>> UUID, then no.
> Oh, that is cool, as I am using only UUID in fstab. Thus, just clone the
> drive
> wi
> Those are created at boot time, by udev.
I unde5rstand.
>
> That depends on how you describe partitions in /etc/fstab. If you use
> the device name, then almost certainly yes. If you use the label or
> UUID, then no.
>
Oh, that is cool, as I am using only UUID in fstab. Thus, just clone the d
On Thu, 16 Jan 2025 16:17:29 +0100
Hans wrote:
> Another question, not really important: The device names, like
> "/dev/hdX", "/ dev/sdX" and now "/dev/nvmeX" - who is creating these?
> The kernel? Must /etc/ fstab be manually changed, when changing the
> kind of harddrive?
Those are created at
On Thu, Jan 16, 2025 at 04:17:29PM +0100, Hans wrote:
Now I heard of, that a NVME drive will only get to full speed, if UEFI is
activated in BIOS. Is this correct?
No, at least for linux; I can't speak to windows.
Another question, not really important: The device names, like &quo
On Thu, 16 Jan 2025 16:17:29 +0100
Hans wrote:
> I am asking, because if NOT, than it would spare me a lot of work, to
> create an UEFI partituion, rewrite the bootloaders, fstab,
> configurations and so on.
The Debian installer (the installer on the netinst CD, not the live CD)
will c
Hi folks,
I got a new notebook with an NVME drive.
As all my BIOS never needed UEFI, my installation dula boot of Windows and
Debian are all without UEFI.
Thus, it was easy for me, cloning debian to any other hardware in the past to
a ssd drive.
Now I heard of, that a NVME drive will only
.
sure that unified kernel images will not become default before the user
replaces their drive?
Are you sure that UEFI will not be replaced by something even more
bizarrely inexplicable before that happens?
I am unaware of UEFI replacement, however I have seen some news on UKI
in Fedora perhaps a
mages will not become default before the user
> replaces their drive?
Are you sure that UEFI will not be replaced by something even more
bizarrely inexplicable before that happens?
Regards,
--
Nicolas George
On Mon, Dec 30, 2024 at 10:54 PM Max Nikulin wrote:
>
> On 30/12/2024 16:17, Nicolas George wrote:
> > Max Nikulin (12024-12-30):
> >> Create EFI System Partition: it should have proper partition type UUID and
> >> it is not recommended to make it too small (<500 MB).
> >
> > Only if one wants to
On 30/12/2024 16:17, Nicolas George wrote:
Max Nikulin (12024-12-30):
Create EFI System Partition: it should have proper partition type UUID and
it is not recommended to make it too small (<500 MB).
Only if one wants to have the bootloaders for other systems on it. I
have been using EFI system
Max Nikulin (12024-12-30):
> Create EFI System Partition: it should have proper partition type UUID and
> it is not recommended to make it too small (<500 MB).
Only if one wants to have the bootloaders for other systems on it. I
have been using EFI system partitions of <50 or <80 mega-octets for m
rtition". Assuming from what
you write below that you boot in EFI mode, can you tell us the type
of disk partition table (MBR or GPT), and perhaps what's in this
partition of yours that you reformatted as ext4. That might allow us
to know what you mean.
> My UEFI partition is forma
On Sun 29 Dec 2024 at 20:24:46 (+), Joe wrote:
> The answer is to modify /etc/default/grub and run update-grub again:
>
> To restore the old behavior, open a terminal and issue sudo echo
> GRUB_DISABLE_OS_PROBER=false >> /etc/default/grub && sudo update-grub
>
> Note that you will need to d
On 30/12/2024 00:19, e...@gmx.us wrote:
eben@cerberus:~$ ls /boot/efi
ls: cannot access '/boot/efi': No such file or directory
Create EFI System Partition: it should have proper partition type UUID
and it is not recommended to make it too small (<500 MB). Configure
mounting it to boot/efi, cr
On 12/29/24 12:24, Joe wrote:
On Sun, 29 Dec 2024 11:07:18 -0800
Peter Ehlert wrote:
On 12/29/24 08:26, Eben King wrote:
I think I've done everything reasonable in my firmware to ensure
booting by EFI. I have:
Storage boot option control UEFI only
Other PCI device ROM pri
e...@gmx.us wrote:
> On 12/29/24 12:51, debian-u...@howorth.org.uk wrote:
> > Eben King wrote:
> >
> >> My motherboard is a Gigabyte H170
> >
> > That doesn't seem to be precise enough. They make multiple boards
> > with that general name and
On Sun, 29 Dec 2024 11:07:18 -0800
Peter Ehlert wrote:
> On 12/29/24 08:26, Eben King wrote:
> > I think I've done everything reasonable in my firmware to ensure
> > booting by EFI. I have:
> >
> > Storage boot option control UEFI only
> > Othe
On Sun 29 Dec 2024 at 11:26:38 (-0500), Eben King wrote:
> I think I've done everything reasonable in my firmware to ensure booting by
> EFI. I have:
>
> Storage boot option control UEFI only
> Other PCI device ROM priorityUEFI only
> (other options for bot
On 12/29/24 08:26, Eben King wrote:
I think I've done everything reasonable in my firmware to ensure booting by
EFI. I have:
Storage boot option control UEFI only
Other PCI device ROM priority UEFI only
(other options for both are "Legacy only" and "Disabled&quo
On 12/29/24 13:17, Cindy Sue Causey wrote:
>
> Good luck with yours. FINALLY fixing this a couple years ago was so
> empowering. Without boot, we got no computers. :)
Wow, thanks. I've heard that switching an existing system to EFI can be
disruptive and error-prone, so I'll probably try again whe
On Sun, 2024-12-29 at 11:26 -0500, Eben King wrote:
I think I've done everything reasonable in my firmware to ensure
booting by EFI. I have:
Storage boot option control UEFI only
Other PCI device ROM priority UEFI only
(other options for both are "Legacy only" and "
table, and its first few partitions are
> >>
> >> number size mount point
> ...
>
> > Does UEFI booting not require an EFI System Partition (ESP) of type
> > vfat typically mounted at /boot/efi on Debian?
>
> eben@cerberus:~$ ls /boot/efi
> ls: cannot acces
On 12/29/24 12:51, debian-u...@howorth.org.uk wrote:
> Eben King wrote:
>
>> My motherboard is a Gigabyte H170
>
> That doesn't seem to be precise enough. They make multiple boards with
> that general name and all but one support UEFI. But the GA-H170TN does
> not me
x.x serial:
UEFI-[Legacy]: American Megatrends v: F10 date: 12/14/2018
$
> swear I ran a program that showed me EFI boot vars (if they exist) and it
> showed nothing. But now I can't remember what that program was. How can I
> ensure that I'm actually booted using
Eben King wrote:
> My motherboard is a Gigabyte H170
That doesn't seem to be precise enough. They make multiple boards with
that general name and all but one support UEFI. But the GA-H170TN does
not mention UEFI, although its spec does say "Use of licensed AMI UEFI
BIOS".
On 12/29/24 11:38, Andy Smith wrote:
> Hi,
>
> On Sun, Dec 29, 2024 at 11:26:38AM -0500, Eben King wrote:
>> The boot device is currently /dev/sdb which has a GPT partition table, and
>> its first few partitions are
>>
>> number size mount point
...
>
On 29/12/2024 23:26, Eben King wrote:
I swear I ran a program that showed me EFI boot vars (if they exist) and
it showed nothing.
efibootmgr -v
however you need to boot in UEFI mode at first, e.g. using a live media.
Alternatively if firmware boot menu allows to pick an .efi file then you
On 12/29/24 17:26, Eben King wrote:
How can I
ensure that I'm actually booted using EFI?
"/sys/firmware/efi" if present indicates that you are booted in UEFI mode.
--
John Doe
1 9GB/home
> 13 48GB swap
> 5 953MB unmounted, filesystem="grub2 core.img", flags="bios_grub"
Does UEFI booting not require an EFI System Partition (ESP) of type vfat
typically mounted at /boot/efi on Debian?
> I swear I ran a program that sh
I think I've done everything reasonable in my firmware to ensure booting by
EFI. I have:
Storage boot option control UEFI only
Other PCI device ROM priority UEFI only
(other options for both are "Legacy only" and "Disabled")
The boot device is currently
t; > on the new box.
> > >
> > > Any suggestions as to how I might proceed to making things current and
> > > what other software I might want to include are welcomed...
> > >
> >
> > Straightforwardly - boot from the DVD (if the new machine has
On Thu, Dec 5, 2024 at 2:24 PM Hans wrote:
>
> as promised I send you my experiences with cloning to NVME.
>
> So, today I got my new notebook. As I never used UEFI, I disabled UEFI in BIOS
> (my first mistake!), then cloned everything to the new drive.
>
> Firts reboot wor
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
Hi,
Le 30/09/2024, Boyan Penkov 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 co
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 ca
On Fri, 20 Sep 2024, Florent Rougon wrote:
Le 20/09/2024, Tim Woodall 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
Le 20/09/2024, Tim Woodall 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.
>d
On Fri, 20 Sep 2024, Florent Rougon wrote:
Le 20/09/2024, Tim Woodall 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/ba
Le 20/09/2024, Tim Woodall 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
On Thu, 19 Sep 2024, Florent Rougon wrote:
Hi,
Le 19/09/2024, Andy Smith 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/gru
, 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
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
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, wha
Anssi Saari wrote:
> songbird writes:
>
>> hmm, well i actually use Refind for my normal booting up
>> and install GRUB as a backup. so far i've never needed the
>> backup but i do test it out from time to time.
>
> Um, so how do you choose which boot manage
songbird writes:
> hmm, well i actually use Refind for my normal booting up
> and install GRUB as a backup. so far i've never needed the
> backup but i do test it out from time to time.
Um, so how do you choose which boot manager you want to run? UEFI boot
menu?
Hi,
Felix Miata wrote:
> Which distros ship rEFInd? It's not among packages monitored by distrowatch.
It seems that Debian does since a while:
https://tracker.debian.org/pkg/refind
The tracker page points by its "homepage" link to
https://www.rodsbooks.com/refind/
which shows the name "rEFIn
songbird composed on 2024-09-14 13:07 (UTC-0400):
> Felix Miata wrote:
>> Max Nikulin composed on 2024-09-14 10:59 (UTC+0700):
>>> So multiple loaders from the same vendor is tricky in the case of UEFI
>>> SecureBoot. Behavior of grub may vary across Linux distribut
Felix Miata wrote:
> Max Nikulin composed on 2024-09-14 10:59 (UTC+0700):
>
>> So multiple loaders from the same vendor is tricky in the case of UEFI
>> SecureBoot. Behavior of grub may vary across Linux distributions.
>
> Thus, consider to KISS. Pick one installation&#
Max Nikulin composed on 2024-09-14 10:59 (UTC+0700):
> So multiple loaders from the same vendor is tricky in the case of UEFI
> SecureBoot. Behavior of grub may vary across Linux distributions.
Thus, consider to KISS. Pick one installation's bootloader to depend on. Instal
They have not been included into the upstream repository. Debian
changelog entry is
* Port UEFI based network stack to 2.12 (LP: #2039081)
A couple of problems that I have noticed in bookworm:
1. When /usr/lib/shim/BOOTX64.CSV is installed, bootloader id in it is
not adjusted. As a result
f the way into the file.
Does UEFI secure boot allows modification of some part of a signed .efi
binary without invalidating its signature?
/usr/lib/grub/x86_64-efi-signed/grubx64.efi.signed is copied verbatim to
EFI/*/grubx64.efi. I still believe there is a reason why
"(,gpt7)/boot/grub&q
Max Nikulin composed on 2024-08-30 23:09 (UTC+0700):
> How does grubx64.efi find where grub.cfg is located?
I don't know what doc might report this, but in a file viewer I see a string
like
(,gpt7)/boot/grub) embedded in a vast sea of nulls 98% of the way into the file.
--
Evolution as taught i
ect that Debian and Ubuntu may
diverge in so subtle way. I believed fixed .cfg path is a UEFI
limitation or at best an inherent grub limitation.
Max Nikulin composed on 2024-08-23 10:09 (UTC+0700):
> Felix Miata wrote:
>> That is written by any process that
>> reads GRUB_DISTRIBUTOR= to determine where to do its writing on the ESP.
> To avoid confusion of those who may notice this thread in search engine
> results:
> In Debian GRUB_D
On 22/08/2024 16:44, Felix Miata wrote:
That is written by any process that
reads GRUB_DISTRIBUTOR= to determine where to do its writing on the ESP.
To avoid confusion of those who may notice this thread in search engine
results:
In Debian GRUB_DISTRIBUTOR value is *not* passed to "grub-inst
Max Nikulin composed on 2024-08-22 22:56 (UTC+0700):
> Felix Miata wrote:
>> # ls -gG/boot/efi/EFI/opensusetw/
>> total 148
>> -rwxr-xr-x 1 151552 Aug 21 16:08 grubx64.efi
> Am I right that you either do not use Secure Boot or generated a local
> key instead of/in addition to Microsoft and SUSE
" is fixed in the EFI/debian/grub.cfg path
when grubx64.efi is taken from grub-efi-amd64-signed. I have no idea if
EFI binaries can determine their own location to implement relative path
for the configuration file. Depending on that hardcoded .cfg path is
either grub or UEFI limitation.
.cfg
#
>> Do we know that the update-grub command normally writes to /boot/efi/EFI/,
>> and NVRAM (optional?)?
> Actually I tried dpkg-reconfigure for grub and shim packages and your
> message made me thinking that you may correct me and may provide proper
> commands to config
s 100% managed by me.
[...]
This is KISS applied to multibooting with UEFI.
Sorry, but this time I would prefer to leave aside grub configuration
unrelated to UEFI. I have never had intention to dispute that it is
possible to configure multiboot using grub. Multiboot using UEFI
facilities directl
Max Nikulin composed on 2024-08-21 23:17 (UTC+0700):
> Felix Miata wrote:
>> Max Nikulin composed on 2024-08-21 10:54 (UTC+0700):
>>> I was experimenting trying to get 2
>>> entries from the same vendor in the UEFI (firmware) boot menu and found
>>> it tri
Max Nikulin (12024-08-21):
> Have I missed something or GRUB_DISTRIBUTOR affects *grub* menu, but not
> *UEFI* boot menu?
Indeed, it is not just as simple as that.
>I still suspect it is a UEFI+SecureBoot design
> shortcoming that it is not possible to install the
On 21/08/2024 11:25, Felix Miata wrote:
Max Nikulin composed on 2024-08-21 10:54 (UTC+0700):
I was experimenting trying to get 2
entries from the same vendor in the UEFI (firmware) boot menu and found
it tricky and inconvenient.
How so? I found it quite simple to edit /etc/default/grub and
On Wed, 21 Aug 2024 08:45:05 +0200
Nicolas George wrote:
> Max Nikulin (12024-08-21):
> > Do you mean 3rd party bootloader (e.g. grub)?
>
> There is nothing “3rd party” about GRUB.
>
> > I was responding to
> > &q
Max Nikulin (12024-08-21):
> Do you mean 3rd party bootloader (e.g. grub)?
There is nothing “3rd party” about GRUB.
> I was responding to "AIUI
> UEFI/GPT were designed to support multi-boot".
Yes, and so was I. If you want hal
Max Nikulin composed on 2024-08-21 10:54 (UTC+0700):
> I was experimenting trying to get 2
> entries from the same vendor in the UEFI (firmware) boot menu and found
> it tricky and inconvenient.
How so? I found it quite simple to edit /etc/default/grub and replace the
default
install and/or configure the bootloader manually.
Do you mean 3rd party bootloader (e.g. grub)? I was responding to "AIUI
UEFI/GPT were designed to support multi-boot". Custom configuration of
grub (earlier lilo) was possible before UEFI and GPT.
Erwan posted directory tree for deb
On 8/20/24 12:29, Jeffrey Walton wrote:
On Tue, Aug 20, 2024 at 11:51 AM Nicolas George wrote:
[...]
EFI files are signed
for Secure Boot, so vendor paths can not be easily adjusted.
Secure boot is a joke when it comes to security, it
On Tue, Aug 20, 2024 at 11:51 AM Nicolas George wrote:
>
> [...]
> > EFI files are signed
> > for Secure Boot, so vendor paths can not be easily adjusted.
>
> Secure boot is a joke when it comes to security, its only “merit” is to
> prevent l
Max Nikulin (12024-08-20):
> Single EFI System Partition may contain loaders from different vendors, but
> not 2 Debian systems installed on different partitions.
This is not true. The only problem you will have with this setup is that
you will need to install and/or configure the bootloader manua
On Tue, Aug 20, 2024 at 05:17:43PM CEST, Max Nikulin said:
> On 20/08/2024 11:27, David Christensen wrote:
> > AIUI UEFI/GPT were designed to support multi-boot
>
> Single EFI System Partition may contain loaders from different vendors, but
> not 2 Debian systems inst
On 20/08/2024 11:27, David Christensen wrote:
AIUI UEFI/GPT were designed to support multi-boot
Single EFI System Partition may contain loaders from different vendors,
but not 2 Debian systems installed on different partitions. EFI files
are signed for Secure Boot, so vendor paths can not be
the secure boot
> > gets enabled (hence bios and everything else seems to be fine with the
> > same UEFI loader).
> > However, when I boot the compiled kernel I get
> >
> > $ dmesg | grep -i secure
> > [0.007085] Secure boot could not be determined
> &g
ould someone tell me what am I doing wrong please ?
>
> Below is the status (I am using loader.efi from linuxfoundation)
> When i boot debian stock kernel signed, i see that the secure boot
> gets enabled (hence bios and everything else seems to be fine with the
> same UEFI loa
boot
gets enabled (hence bios and everything else seems to be fine with the
same UEFI loader).
However, when I boot the compiled kernel I get
$ dmesg | grep -i secure
[0.007085] Secure boot could not be determined
$ sbverify --list bootx64.efi
warning: data remaining[91472 vs 101160]: gaps
Le 28/05/2024, Harald Dunkel a écrit:
> Full thread is on debian-boot mailing list.
I've read it now, thanks for the info, Harald!
Regards
--
Florent
Full thread is on debian-boot mailing list.
Hi,
Le 24/05/2024, Harald Dunkel a écrit:
> if I migrate from grub-pc to grub-uefi, then grub-pc.postrm
> removes /etc/default/grub on the final purge.
I confirm the behavior, have been bitten by this. IMHO, it is a nasty
bug: suppose your rely on your kernel command line to disable, sa
Hi folks,
if I migrate from grub-pc to grub-uefi, then grub-pc.postrm
removes /etc/default/grub on the final purge.
grub2 doesn't provide much information in its man pages, but
AFAICT /etc/default/grub is still processed for UEFI, so why
is it deleted?
Regards
Harri
On 03/12/2023 02:15, Stefan Monnier wrote:
Interesting. I have memtest86+ 6.10-4, for amd64, on the machine.
Then AFAIK it is not a known problem (IOW, it should work).
The package contains /boot/memtest86+x64.efi, so it is intended to work
with UEFI. I am less sure that it can work when
> Interesting. I have memtest86+ 6.10-4, for amd64, on the machine.
Then AFAIK it is not a known problem (IOW, it should work).
> Maybe I'll try a USB stick version.
IIRC the memtest86+ Debian package comes with .iso files which you can
(manually) put into /boot/images/ and which boot in a slig
> For the curious, I occasionally need to run Microchip MPLAB, the old
> pre-Java version which doesn't do Linux. It only just about does
> Windows... I used to think Serif software was buggy until I tried
> Microchip stuff.
Setting it up might take some work (especially if you need it to have
dir
On Thu, 30 Nov 2023 13:27:59 +0100
Arno Lehmann wrote:
>
> ... have you ever tried
>
> bcdedit /bootsequence
>
> In general, the built-in help of bcdedit is not bad, needs a bit of
> patience, though.
>
> And of course we lack the flexibility of tools such as awk or sed on
> Windows, to a
On 30/11/2023 19:27, Arno Lehmann wrote:
Am 30.11.2023 um 12:52 schrieb Joe:
I have a
netbook which, left to its own devices, will always boot to Windows,
and cannot be made to boot to anything else from the UEFI part of
whatever we're supposed to call the BIOS these days.
... have you
Bit of a digression here, probably better not to pursue *this* on the
mailing list, but...
Am 30.11.2023 um 12:52 schrieb Joe:
On Wed, 29 Nov 2023 18:34:30 -0500
Jeffrey Walton wrote:
As I understand things, a well functioning UEFI system does not need
to use GRUB. The entries for Linux
On 2/23/23 11:05, Tim Woodall wrote:
On Wed, 22 Feb 2023, Nicolas George wrote:
Is there a solution to have a whole-disk RAID (software, mdadm) that is
also partitioned in GPT and bootable in UEFI?
I've wanted this ...
I think only hardware raid where the bios thinks it's a s
On Wed, 22 Feb 2023, Nicolas George wrote:
Hi.
Is there a solution to have a whole-disk RAID (software, mdadm) that is
also partitioned in GPT and bootable in UEFI?
I've wanted this but settled for using dd to copy the start of the disk,
fdisk to rewrite the GPT properly then mda
Hello,
I have seen some installations with following setup:
GPT
sda1 sdb1 bios_grub md1 0.9
sda2 sdb2 efi md2 0.9
sda3 sdb3 /boot md3 0.9
sda4 sdb4 / md? 1.1
on such installations it's important, that grub installation is made
with "grub-install --removable"
I mean it was some grub bugs about
Am 22.02.2023 um 17:07 schrieb Nicolas George:
> Unfortunately, that puts the partition table
> and EFI partition outside the RAID: if you have to add/replace a disk,
> you need to partition and reinstall GRUB, that makes a few more
> manipulations on top of syncing the RAID.
Yes, i get it. AFAIK,
Nicolas George wrote:
> Hi.
>
> Is there a solution to have a whole-disk RAID (software, mdadm) that is
> also partitioned in GPT and bootable in UEFI?
Not that I know of. An EFI partition needs to be FAT32 or VFAT.
What I think you could do:
Partition the disks with GPT: 2 par
o make an USB
stick that was bootable in legacy mode, bootable in UEFI mode and usable
as a regular USB stick (spoiler: it worked, until I tried it with
Windows.)
But it will not help for this issue.
> The only issue, i have had a look at, was the problem to have a raid,
> that is bootable
MBR
with pointers to up to four partitons, in order to make a system
bootable without UEFI. I understand, that your use case is somewhat
different. But maybe you can use the idea anyway. The hybrid formatting
has some restrictions, like you should not have standard MBR tools mess
this configuration
Hi.
Is there a solution to have a whole-disk RAID (software, mdadm) that is
also partitioned in GPT and bootable in UEFI?
What I imagine:
- RAID1, mirroring: if you ignore the RAID, the data is there.
- The GPT metadata is somewhere not too close to the beginning of the
drive nor too close
Hi hw,
Having followed through the steps I outlined:
> I'm about to try this on a VM with two disks. I'm going to initially partition
> as if I were using LVM and all in one partition on one disk, then on the other
> That should give me identically sized partitions.
> At that point, I'll change
1 - 100 of 902 matches
Mail list logo
