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

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

Yet another UEFI/BIOS question

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

Contents

  Yet another UEFI/BIOS question steve <dlist@bluewin.ch> - 2018-09-19 17:00 +0200
    Re: Yet another UEFI/BIOS question Darac Marjal <mailinglist@darac.org.uk> - 2018-09-19 17:30 +0200
      Re: Yet another UEFI/BIOS question steve <dlist@bluewin.ch> - 2018-09-19 18:00 +0200
    Re: Yet another UEFI/BIOS question Pascal Hambourg <pascal@plouf.fr.eu.org> - 2018-09-19 23:40 +0200
      Re: Yet another UEFI/BIOS question steve <dlist@bluewin.ch> - 2018-09-20 09:00 +0200
        Re: Yet another UEFI/BIOS question Pascal Hambourg <pascal@plouf.fr.eu.org> - 2018-09-20 20:30 +0200
          [SOLVED] Re: Yet another UEFI/BIOS question steve <dlist@bluewin.ch> - 2018-09-21 08:40 +0200
            Re: [SOLVED] Re: Yet another UEFI/BIOS question Pascal Hambourg <pascal@plouf.fr.eu.org> - 2018-09-21 20:30 +0200
              Re: [SOLVED] Re: Yet another UEFI/BIOS question steve <dlist@bluewin.ch> - 2018-09-22 07:00 +0200
                Re: [SOLVED] Re: Yet another UEFI/BIOS question Pascal Hambourg <pascal@plouf.fr.eu.org> - 2018-09-22 10:10 +0200
                  Re: [SOLVED] Re: Yet another UEFI/BIOS question steve <dlist@bluewin.ch> - 2018-09-22 10:50 +0200
              And yet another UEFI/BIOS question: Work on both. Wayne Sallee <Wayne@WayneSallee.com> - 2018-09-23 17:00 +0200
                Re: And yet another UEFI/BIOS question: Work on both. Patrick Bartek <nemommxiv@gmail.com> - 2018-09-23 18:20 +0200
                  Re: And yet another UEFI/BIOS question: Work on both. Wayne Sallee <Wayne@WayneSallee.com> - 2018-09-23 23:30 +0200
                    Re: And yet another UEFI/BIOS question: Work on both. Patrick Bartek <nemommxiv@gmail.com> - 2018-09-24 03:00 +0200
                      Re: And yet another UEFI/BIOS question: Work on both. David Wright <deblis@lionunicorn.co.uk> - 2018-09-24 21:20 +0200
                        Re: And yet another UEFI/BIOS question: Work on both. Michael Stone <mstone@debian.org> - 2018-09-24 21:30 +0200
                  Re: And yet another UEFI/BIOS question: Work on both. Pascal Hambourg <pascal@plouf.fr.eu.org> - 2018-09-27 15:10 +0200
                Re: And yet another UEFI/BIOS question: Work on both. David Wright <deblis@lionunicorn.co.uk> - 2018-09-23 20:40 +0200

#200300 — Yet another UEFI/BIOS question

Hi there,

Just bought a new Mother Board and transfered all of my sdd's from my
old box to the new one. New box boots almost normally (I'll come back
there later). I then installed Win10 on a new sdd, which boots also
correctly. 

Now when booting Debian Stretch, I get the following messages, and the
system takes ages too continue the process:

[    0.185353] Error parsing PCC subspaces from PCCT
[    0.275838] ACPI Error: [INTS] Namespace lookup failure, AE_ALREADY_EXISTS (20170831/dswload-378)
[    0.319628] ACPI Error: [SDS0] Namespace lookup failure, AE_NOT_FOUND (20170831/psargs-364)
[    0.319685] ACPI Error: Method parse/execution failed \SHAD._STA, AE_NOT_FOUND (20170831/psparse-550)
[    0.319749] ACPI Error: [SDS0] Namespace lookup failure, AE_NOT_FOUND (20170831/psargs-364)
[    0.319804] ACPI Error: Method parse/execution failed \SHAD._STA, AE_NOT_FOUND (20170831/psparse-550)
[   33.170504] ACPI Error: [SDS0] Namespace lookup failure, AE_NOT_FOUND (20170831/psargs-364)
[   33.170575] ACPI Error: Method parse/execution failed \SHAD._STA, AE_NOT_FOUND (20170831/psparse-550)
[   33.195221] ACPI Error: [SDS0] Namespace lookup failure, AE_NOT_FOUND (20170831/psargs-364)
[   33.195279] ACPI Error: Method parse/execution failed \SHAD._STA, AE_NOT_FOUND (20170831/psparse-550)
[   33.977492] ACPI Error: [SDS0] Namespace lookup failure, AE_NOT_FOUND (20170831/psargs-364)
[   33.977584] ACPI Error: Method parse/execution failed \SHAD._STA, AE_NOT_FOUND (20170831/psparse-550)


Googling around, I suspect that these errors come from the fact that the
BIOS is configured to but in Legacy mode (aka Bios mode) rather than in
the more modern UEFI mode. Just an hypothesis.

But the problem is that my old sdd's have all (except /dev/sdd, which I just
noticed) a msdos partition table:

root@box:~# parted /dev/sda print | grep -i partition
Partition Table: msdos
root@box:~# parted /dev/sdb print | grep -i partition
Partition Table: msdos
root@box:~# parted /dev/sdc print | grep -i partition
Partition Table: msdos
root@box:~# parted /dev/sdd print | grep -i partition
Partition Table: gpt
root@box:~# parted /dev/sde print | grep -i partition
Partition Table: msdos
root@box:~# parted /dev/sdf print | grep -i partition
Partition Table: msdos
root@box:~# parted /dev/sdg print | grep -i partition
Partition Table: gpt
 1      1049kB  524MB  523MB   ntfs         Basic data partition          hidden, diag
 2      524MB   629MB  105MB   fat32        EFI system partition          boot, esp
 3      629MB   646MB  16.8MB               Microsoft reserved partition  msftres
 4      646MB   250GB  249GB   ntfs         Basic data partition          msftdata


Grub-pc is currently installed on /dev/sda1 (/boot) and /dev/sda. 

Disks sdb, sdc and sdf are raid1:

cat /proc/mdstat 
Personalities : [linear] [multipath] [raid0] [raid1] [raid6] [raid5] [raid4] [raid10] 
md1 : active raid1 sdb5[2](S) sdf5[3] sdc5[1]
      117120896 blocks super 1.2 [2/2] [UU]
      
md2 : active raid1 sdf6[3] sdb6[2](S) sdc6[1]
      97589120 blocks super 1.2 [2/2] [UU]
      
md0 : active raid1 sdf1[3] sdb1[2](S) sdc1[1]
      19514240 blocks super 1.2 [2/2] [UU]


My questions are rather simple. Is it conceivable to convert the sdd's to gpt
partition table without reformatting/reinstalling the whole disks? Or maybe
only sda (which contains /, /usr, /boot and /tmp) so I can switch my BIOS to
UEFI? Am I stuck with those msdos partition tables?


Sorry for the long message, I hope there is enough info.

Thanks for any help.

Steve


PS: debian stretch with some backports (and an old 4.15 kernel)

[toc] | [next] | [standalone]

#200301

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

On Wed, Sep 19, 2018 at 04:50:14PM +0200, steve wrote:
>Hi there,
>
>Just bought a new Mother Board and transfered all of my sdd's from my
>old box to the new one. New box boots almost normally (I'll come back
>there later). I then installed Win10 on a new sdd, which boots also
>correctly.

I'm not familiar with the acronym "sdd". Did You Mean™
	SSDs - Solid State Disks
	SDDs - SCSI Disk Drives (I'm making something up here)
	/dev/sd* - Disks using the SCSI driver

>
>Now when booting Debian Stretch, I get the following messages, and the
>system takes ages too continue the process:
>
>[    0.185353] Error parsing PCC subspaces from PCCT
>[    0.275838] ACPI Error: [INTS] Namespace lookup failure, AE_ALREADY_EXISTS (20170831/dswload-378)
>[    0.319628] ACPI Error: [SDS0] Namespace lookup failure, AE_NOT_FOUND (20170831/psargs-364)
>[    0.319685] ACPI Error: Method parse/execution failed \SHAD._STA, AE_NOT_FOUND (20170831/psparse-550)
>[    0.319749] ACPI Error: [SDS0] Namespace lookup failure, AE_NOT_FOUND (20170831/psargs-364)
>[    0.319804] ACPI Error: Method parse/execution failed \SHAD._STA, AE_NOT_FOUND (20170831/psparse-550)
>[   33.170504] ACPI Error: [SDS0] Namespace lookup failure, AE_NOT_FOUND (20170831/psargs-364)
>[   33.170575] ACPI Error: Method parse/execution failed \SHAD._STA, AE_NOT_FOUND (20170831/psparse-550)
>[   33.195221] ACPI Error: [SDS0] Namespace lookup failure, AE_NOT_FOUND (20170831/psargs-364)
>[   33.195279] ACPI Error: Method parse/execution failed \SHAD._STA, AE_NOT_FOUND (20170831/psparse-550)
>[   33.977492] ACPI Error: [SDS0] Namespace lookup failure, AE_NOT_FOUND (20170831/psargs-364)
>[   33.977584] ACPI Error: Method parse/execution failed \SHAD._STA, AE_NOT_FOUND (20170831/psparse-550)
>

I don't believe this is a problem. ACPI is a complex beast and sometimes 
the ACPI driver is overly strict about working with ACPI and sometimes 
ACPI is overly strict about working with Linux (actually, I think Linux 
nowadays defaults to pretending to be Windows). The general advice is 
"Do you notice any other issues other than error messages?" If not, 
don't worry about it.

>
>Googling around, I suspect that these errors come from the fact that the
>BIOS is configured to but in Legacy mode (aka Bios mode) rather than in
>the more modern UEFI mode. Just an hypothesis.
>
>But the problem is that my old sdd's have all (except /dev/sdd, which I just
>noticed) a msdos partition table:

Changing Motherboard shouldn't have altered the partition table on your 
disks.

>
>root@box:~# parted /dev/sda print | grep -i partition
>Partition Table: msdos
>root@box:~# parted /dev/sdb print | grep -i partition
>Partition Table: msdos
>root@box:~# parted /dev/sdc print | grep -i partition
>Partition Table: msdos
>root@box:~# parted /dev/sdd print | grep -i partition
>Partition Table: gpt
>root@box:~# parted /dev/sde print | grep -i partition
>Partition Table: msdos
>root@box:~# parted /dev/sdf print | grep -i partition
>Partition Table: msdos
>root@box:~# parted /dev/sdg print | grep -i partition
>Partition Table: gpt
>1      1049kB  524MB  523MB   ntfs         Basic data partition          hidden, diag
>2      524MB   629MB  105MB   fat32        EFI system partition          boot, esp
>3      629MB   646MB  16.8MB               Microsoft reserved partition  msftres
>4      646MB   250GB  249GB   ntfs         Basic data partition          msftdata
>
>
>Grub-pc is currently installed on /dev/sda1 (/boot) and /dev/sda.
>
>Disks sdb, sdc and sdf are raid1:
>
>cat /proc/mdstat Personalities : [linear] [multipath] [raid0] [raid1] 
>[raid6] [raid5] [raid4] [raid10] md1 : active raid1 sdb5[2](S) sdf5[3] 
>sdc5[1]
>     117120896 blocks super 1.2 [2/2] [UU]
>md2 : active raid1 sdf6[3] sdb6[2](S) sdc6[1]
>     97589120 blocks super 1.2 [2/2] [UU]
>md0 : active raid1 sdf1[3] sdb1[2](S) sdc1[1]
>     19514240 blocks super 1.2 [2/2] [UU]
>
>
>My questions are rather simple. Is it conceivable to convert the sdd's to gpt
>partition table without reformatting/reinstalling the whole disks? Or maybe
>only sda (which contains /, /usr, /boot and /tmp) so I can switch my BIOS to
>UEFI? Am I stuck with those msdos partition tables?

Yes. Here's a good write-up on the subject from Rod Smith, the author of 
gdisk, a GPT-only equivalent to fdisk.

http://www.rodsbooks.com/gdisk/mbr2gpt.html

>
>
>Sorry for the long message, I hope there is enough info.
>
>Thanks for any help.
>
>Steve
>
>
>PS: debian stretch with some backports (and an old 4.15 kernel)
>


-- 
For more information, please reread.

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

#200304

Hi Darac,

Thanks answering me.

Le 19-09-2018, à 16:28:51 +0100, Darac Marjal a écrit :

>On Wed, Sep 19, 2018 at 04:50:14PM +0200, steve wrote:
>>Hi there,
>>
>>Just bought a new Mother Board and transfered all of my sdd's from my
>>old box to the new one. New box boots almost normally (I'll come back
>>there later). I then installed Win10 on a new sdd, which boots also
>>correctly.
>
>I'm not familiar with the acronym "sdd". Did You Mean™
>	SSDs - Solid State Disks
>	SDDs - SCSI Disk Drives (I'm making something up here)
>	/dev/sd* - Disks using the SCSI driver

Sorry, Solid State Disks.

>>
>>Now when booting Debian Stretch, I get the following messages, and the
>>system takes ages too continue the process:
>>
>>[    0.185353] Error parsing PCC subspaces from PCCT
>>[    0.275838] ACPI Error: [INTS] Namespace lookup failure, AE_ALREADY_EXISTS (20170831/dswload-378)
>>[    0.319628] ACPI Error: [SDS0] Namespace lookup failure, AE_NOT_FOUND (20170831/psargs-364)
>>[    0.319685] ACPI Error: Method parse/execution failed \SHAD._STA, AE_NOT_FOUND (20170831/psparse-550)
>>[    0.319749] ACPI Error: [SDS0] Namespace lookup failure, AE_NOT_FOUND (20170831/psargs-364)
>>[    0.319804] ACPI Error: Method parse/execution failed \SHAD._STA, AE_NOT_FOUND (20170831/psparse-550)
>>[   33.170504] ACPI Error: [SDS0] Namespace lookup failure, AE_NOT_FOUND (20170831/psargs-364)
>>[   33.170575] ACPI Error: Method parse/execution failed \SHAD._STA, AE_NOT_FOUND (20170831/psparse-550)
>>[   33.195221] ACPI Error: [SDS0] Namespace lookup failure, AE_NOT_FOUND (20170831/psargs-364)
>>[   33.195279] ACPI Error: Method parse/execution failed \SHAD._STA, AE_NOT_FOUND (20170831/psparse-550)
>>[   33.977492] ACPI Error: [SDS0] Namespace lookup failure, AE_NOT_FOUND (20170831/psargs-364)
>>[   33.977584] ACPI Error: Method parse/execution failed \SHAD._STA, AE_NOT_FOUND (20170831/psparse-550)
>>
>
>I don't believe this is a problem.

Well it is at boot time. System waits for more than 30 secondes before
going on.


> ACPI is a complex beast and 
>sometimes the ACPI driver is overly strict about working with ACPI and
>sometimes ACPI is overly strict about working with Linux (actually, I
>think Linux nowadays defaults to pretending to be Windows). The general
>advice is "Do you notice any other issues other than error messages?"
>If not, don't worry about it.


Haven't noticed other issues yet.



>>
>>Googling around, I suspect that these errors come from the fact that the
>>BIOS is configured to but in Legacy mode (aka Bios mode) rather than in
>>the more modern UEFI mode. Just an hypothesis.
>>
>>But the problem is that my old sdd's have all (except /dev/sdd, which I just
>>noticed) a msdos partition table:
>
>Changing Motherboard shouldn't have altered the partition table on 
>your disks.

It hasn't. The fact that sdd has a gpt one is a happy coincidence :) 
This device holds my virtual machines so no real problems.


>>
>>root@box:~# parted /dev/sda print | grep -i partition
>>Partition Table: msdos
>>root@box:~# parted /dev/sdb print | grep -i partition
>>Partition Table: msdos
>>root@box:~# parted /dev/sdc print | grep -i partition
>>Partition Table: msdos
>>root@box:~# parted /dev/sdd print | grep -i partition
>>Partition Table: gpt
>>root@box:~# parted /dev/sde print | grep -i partition
>>Partition Table: msdos
>>root@box:~# parted /dev/sdf print | grep -i partition
>>Partition Table: msdos
>>root@box:~# parted /dev/sdg print | grep -i partition
>>Partition Table: gpt
>>1      1049kB  524MB  523MB   ntfs         Basic data partition          hidden, diag
>>2      524MB   629MB  105MB   fat32        EFI system partition          boot, esp
>>3      629MB   646MB  16.8MB               Microsoft reserved partition  msftres
>>4      646MB   250GB  249GB   ntfs         Basic data partition          msftdata
>>
>>
>>Grub-pc is currently installed on /dev/sda1 (/boot) and /dev/sda.
>>
>>Disks sdb, sdc and sdf are raid1:
>>
>>cat /proc/mdstat Personalities : [linear] [multipath] [raid0] 
>>[raid1] [raid6] [raid5] [raid4] [raid10] md1 : active raid1 
>>sdb5[2](S) sdf5[3] sdc5[1]
>>    117120896 blocks super 1.2 [2/2] [UU]
>>md2 : active raid1 sdf6[3] sdb6[2](S) sdc6[1]
>>    97589120 blocks super 1.2 [2/2] [UU]
>>md0 : active raid1 sdf1[3] sdb1[2](S) sdc1[1]
>>    19514240 blocks super 1.2 [2/2] [UU]
>>
>>
>>My questions are rather simple. Is it conceivable to convert the sdd's to gpt
>>partition table without reformatting/reinstalling the whole disks? Or maybe
>>only sda (which contains /, /usr, /boot and /tmp) so I can switch my BIOS to
>>UEFI? Am I stuck with those msdos partition tables?
>
>Yes. Here's a good write-up on the subject from Rod Smith, the author 
>of gdisk, a GPT-only equivalent to fdisk.
>
>http://www.rodsbooks.com/gdisk/mbr2gpt.html

I'll read. Thanks for the link.

Steve

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

#200311

Le 19/09/2018 à 16:50, steve a écrit :
> 
> Googling around, I suspect that these errors come from the fact that the
> BIOS is configured to but in Legacy mode (aka Bios mode) rather than in
> the more modern UEFI mode. Just an hypothesis.
> 
> But the problem is that my old sdd's have all (except /dev/sdd, which I 
> just noticed) a msdos partition table:

So what ?

> Partition Table: gpt
> 1      1049kB  524MB  523MB   ntfs         Basic data partition          
> 2      524MB   629MB  105MB   fat32        EFI system partition          
> 3      629MB   646MB  16.8MB               Microsoft reserved partition  
> 4      646MB   250GB  249GB   ntfs         Basic data partition          
> 
> Grub-pc is currently installed on /dev/sda1 (/boot) and /dev/sda.
(...)
> My questions are rather simple. Is it conceivable to convert the sdd's 
> to gpt partition table (...) so I can switch my BIOS to UEFI?
You don't need to convert anything. UEFI can use DOS partition tables. 
All you need is an EFI system partition. As you can see above, Windows 
already created one. You can mount it on /boot/efi and install GRUB EFI.

Note that registering GRUB into the UEFI boot variables requires to boot 
in EFI mode. You can do it with a Debian installation or live image.

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

#200325

Hi Pascal,

Thank you for your answer

Le 19-09-2018, à 23:30:40 +0200, Pascal Hambourg a écrit :

>Le 19/09/2018 à 16:50, steve a écrit :
>>
>>Googling around, I suspect that these errors come from the fact that the
>>BIOS is configured to but in Legacy mode (aka Bios mode) rather than in
>>the more modern UEFI mode. Just an hypothesis.
>>
>>But the problem is that my old sdd's have all (except /dev/sdd, 
>>which I just noticed) a msdos partition table:
>
>So what ?

Nothing, I just noticed that while writing my message.

>
>>Partition Table: gpt
>>1      1049kB  524MB  523MB   ntfs         Basic data partition          
>>2      524MB   629MB  105MB   fat32        EFI system partition          
>>3      629MB   646MB  16.8MB               Microsoft reserved 
>>partition  4      646MB   250GB  249GB   ntfs         Basic data 
>>partition
>>
>>Grub-pc is currently installed on /dev/sda1 (/boot) and /dev/sda.
>(...)
>>My questions are rather simple. Is it conceivable to convert the 
>>sdd's to gpt partition table (...) so I can switch my BIOS to UEFI?
>You don't need to convert anything. UEFI can use DOS partition tables.

I know since that's what I'm currently doing. But as mentioned in my
first message, I suspect the ACPI issues arising during boot time might
be linked to that fact. So that's why I'd like to try to be 100% UEFI
compliant. 

>All you need is an EFI system partition. As you can see above, Windows 
>already created one. You can mount it on /boot/efi and install GRUB 
>EFI.

Do you mean that I can use the Windows disk to dual boot and leave alone
the sda disk where I have the GNU/Linux system installed on?


>Note that registering GRUB into the UEFI boot variables requires to 
>boot in EFI mode. You can do it with a Debian installation or live 
>image.

Does that mean that I cannot

1) mount /boot/efi on windows disk on Debian's /mnt
2) install grub-efi on it
3) shutdown
4) modify the BIOS to load only in UEFI mode 
5) reboot

Thanks,

Steve

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

#200350

Le 20/09/2018 à 08:53, steve a écrit :
> 
> Le 19-09-2018, à 23:30:40 +0200, Pascal Hambourg a écrit :
> 
>> Le 19/09/2018 à 16:50, steve a écrit :
>>>
>>> Googling around, I suspect that these errors come from the fact that the
>>> BIOS is configured to but in Legacy mode (aka Bios mode) rather than in
>>> the more modern UEFI mode. Just an hypothesis.
>>>
>>> But the problem is that my old sdd's have all (except /dev/sdd, which 
>>> I just noticed) a msdos partition table:
>>
>> So what ?
> 
> Nothing, I just noticed that while writing my message.

Why then did you mention the DOS partition tables as a problem ?

>>> My questions are rather simple. Is it conceivable to convert the 
>>> sdd's to gpt partition table (...) so I can switch my BIOS to UEFI?
>>
>> You don't need to convert anything. UEFI can use DOS partition tables.
> 
> I know since that's what I'm currently doing.

Doing what ?
I am not talking about you doing anything. I am saying that native UEFI 
boot (NOT legacy boot) can use a disk with a DOS partition table, 
provided that it has an EFI system partition (Id 0xef).

> But as mentioned in my
> first message, I suspect the ACPI issues arising during boot time might
> be linked to that fact. So that's why I'd like to try to be 100% UEFI
> compliant.

Linked to what fact ? That the disks have DOS partition tables ? No way 
ACPI cares about that.

>> All you need is an EFI system partition. As you can see above, Windows 
>> already created one. You can mount it on /boot/efi and install GRUB EFI.
> 
> Do you mean that I can use the Windows disk to dual boot and leave alone
> the sda disk where I have the GNU/Linux system installed on?

Yes.

>> Note that registering GRUB into the UEFI boot variables requires to 
>> boot in EFI mode. You can do it with a Debian installation or live image.
> 
> Does that mean that I cannot
> 
> 1) mount /boot/efi on windows disk on Debian's /mnt

You cannot mount a directory on a disk. You can mount a filesystem on a 
directory. You can bind-mount a directory on another directory.
What do you mean about /mnt ? You don't need it.

> 2) install grub-efi on it
> 3) shutdown
> 4) modify the BIOS to load only in UEFI mode 5) reboot

Step 2 will fail if you booted in legacy mode. The final action is to 
inform the EFI firmware that you installed GRUB in the EFI partition, 
but this requires that EFI services are available. They are not when 
booting in legacy mode.

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

#200367 — [SOLVED] Re: Yet another UEFI/BIOS question

Le 20-09-2018, à 20:25:26 +0200, Pascal Hambourg a écrit :

>>>You don't need to convert anything. UEFI can use DOS partition tables.
>>
>>I know since that's what I'm currently doing.
>
>Doing what ?

Using msdos partition tables.

>I am not talking about you doing anything. I am saying that native 
>UEFI boot (NOT legacy boot) can use a disk with a DOS partition table, 
>provided that it has an EFI system partition (Id 0xef).

Isn't it ef00?

>>But as mentioned in my
>>first message, I suspect the ACPI issues arising during boot time might
>>be linked to that fact. So that's why I'd like to try to be 100% UEFI
>>compliant.
>
>Linked to what fact ? That the disks have DOS partition tables ? No 
>way ACPI cares about that.

That's what I confirmed succeeding in my entreprise :)

Because what I finally did is install a fresh Debian on another device
(using GPT) and the ACPI errors still were there.

I used the opportunity of having another Debian to convert my sda disk
to GPT tables, and change the BIOS setting to UEFI only (just for the
sake of it). So all my disk have a GPT partition table except for the 3
ones for the RAID1 array. Not sure whether I can use the same
manipulations to convert them to GPT also. But since they work fine, I
might leave it as it is.

I used http://www.linuxtopic.com/2017/08/convert-mbr-to-gpt.html to help
me, might be useful to others.

Thanks for time taken to answer.

Best,
Steve

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

#200396 — Re: [SOLVED] Re: Yet another UEFI/BIOS question

Le 21/09/2018 à 08:34, steve a écrit :
> Le 20-09-2018, à 20:25:26 +0200, Pascal Hambourg a écrit :
> 
>>>> You don't need to convert anything. UEFI can use DOS partition tables.
>>>
>>> I know since that's what I'm currently doing.
>>
>> Doing what ?
> 
> Using msdos partition tables.

This is irrelevant because until now you were booting Debian in legacy 
(BIOS) mode.

>> I am not talking about you doing anything. I am saying that native 
>> UEFI boot (NOT legacy boot) can use a disk with a DOS partition table, 
>> provided that it has an EFI system partition (Id 0xef).
> 
> Isn't it ef00?

No. ef00 is a gdisk specific mnemonic for the EFI system partition type 
identifier in a GPT partition table. The actual GUID is 
C12A7328-F81F-11D2-BA4B-00A0C93EC93B.
(0x)ef is the partition type identifier for an EFI system partition in a 
DOS partition table.

> Because what I finally did is install a fresh Debian on another device
> (using GPT) and the ACPI errors still were there.

In legacy mode (with a BIOS boot partition) or EFI mode (with an EFI 
system partition) ?

> I used the opportunity of having another Debian to convert my sda disk
> to GPT tables, and change the BIOS setting to UEFI only (just for the
> sake of it). So all my disk have a GPT partition table except for the 3
> ones for the RAID1 array. Not sure whether I can use the same
> manipulations to convert them to GPT also. But since they work fine, I
> might leave it as it is.

You can, but IMO it provides little value. GPT is useful in the 
following cases :
- disk bigger that 2 TiB
- more that 4 partition without the extended/logical partition kludge
- need to use PARTLABEL or PARTUUD (but RAID uses its own UUID)
- system disk for Windows in EFI mode

AFAICS none of these conditions apply to your RAID disks. However I 
noticed that 2 out of the 3 RAID partition on each disk are logical 
partitions. This is not necessary if there are only 3 partitions per 
disk. So in order to get rid of the extended partition kludge, you could 
either convert the logical partitions into primary partitions or convert 
the partition table to GPT.

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

#200410 — Re: [SOLVED] Re: Yet another UEFI/BIOS question

Le 21-09-2018, à 20:21:06 +0200, Pascal Hambourg a écrit :

>Le 21/09/2018 à 08:34, steve a écrit :
>>Le 20-09-2018, à 20:25:26 +0200, Pascal Hambourg a écrit :
>>
>>>>>You don't need to convert anything. UEFI can use DOS partition tables.
>>>>
>>>>I know since that's what I'm currently doing.
>>>
>>>Doing what ?
>>
>>Using msdos partition tables.
>
>This is irrelevant because until now you were booting Debian in legacy 
>(BIOS) mode.

Absolutely correct.

>>>I am not talking about you doing anything. I am saying that native 
>>>UEFI boot (NOT legacy boot) can use a disk with a DOS partition 
>>>table, provided that it has an EFI system partition (Id 0xef).
>>
>>Isn't it ef00?
>
>No. ef00 is a gdisk specific mnemonic for the EFI system partition 
>type identifier in a GPT partition table. The actual GUID is 
>C12A7328-F81F-11D2-BA4B-00A0C93EC93B.
>(0x)ef is the partition type identifier for an EFI system partition in 
>a DOS partition table.

Thank you for the clarification.

>>Because what I finally did is install a fresh Debian on another device
>>(using GPT) and the ACPI errors still were there.
>
>In legacy mode (with a BIOS boot partition) or EFI mode (with an EFI 
>system partition) ?

In EFI mode. The "Bios" is now fully in EFI mode and it sees all my boot
disks.

>>I used the opportunity of having another Debian to convert my sda disk
>>to GPT tables, and change the BIOS setting to UEFI only (just for the
>>sake of it). So all my disk have a GPT partition table except for the 3
>>ones for the RAID1 array. Not sure whether I can use the same
>>manipulations to convert them to GPT also. But since they work fine, I
>>might leave it as it is.
>
>You can, but IMO it provides little value. GPT is useful in the 
>following cases :
>- disk bigger that 2 TiB

Might come sooner or later.

>- more that 4 partition without the extended/logical partition kludge
>- need to use PARTLABEL or PARTUUD (but RAID uses its own UUID)
>- system disk for Windows in EFI mode

I have but it's on it's own disk, so already in GPT.

>AFAICS none of these conditions apply to your RAID disks. However I 
>noticed that 2 out of the 3 RAID partition on each disk are logical 
>partitions. This is not necessary if there are only 3 partitions per 
>disk. So in order to get rid of the extended partition kludge, you 
>could either convert the logical partitions into primary partitions or 
>convert the partition table to GPT.

I think I'll do that so to have 100% GPT disks and leave the past where
it is and prepare the future. But this step worries me a bit because I
have all my personal data on one of the RAID1 and really don't want to
loose them. I think best would be to backup those data elsewhere in case
things go wrong.


Thanks a lot for all your very useful insights.

Have a nice week-end

Steve

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

#200418 — Re: [SOLVED] Re: Yet another UEFI/BIOS question

Le 22/09/2018 à 06:58, steve a écrit :
> 
>>> Because what I finally did is install a fresh Debian on another device
>>> (using GPT) and the ACPI errors still were there.
>>
>> In legacy mode (with a BIOS boot partition) or EFI mode (with an EFI 
>> system partition) ?
> 
> In EFI mode. The "Bios" is now fully in EFI mode and it sees all my boot
> disks.

Ok. I expected (with little hope though) that the errors might have 
disappeared when booting in native EFI mode, not because you converted 
disks to GPT.

>>> I used the opportunity of having another Debian to convert my sda disk
>>> to GPT tables, and change the BIOS setting to UEFI only (just for the
>>> sake of it). So all my disk have a GPT partition table except for the 3
>>> ones for the RAID1 array. Not sure whether I can use the same
>>> manipulations to convert them to GPT also. But since they work fine, I
>>> might leave it as it is.
>>
>> You can, but IMO it provides little value. GPT is useful in the 
>> following cases :
>> - disk bigger that 2 TiB
> 
> Might come sooner or later.

When it comes you'll use GPT on the new big disks. No need to convert 
the old smaller ones.

> I think I'll do that so to have 100% GPT disks and leave the past where
> it is and prepare the future. But this step worries me a bit because I
> have all my personal data on one of the RAID1 and really don't want to
> loose them. I think best would be to backup those data elsewhere in case
> things go wrong.

1) Backup valuable data. RAID does not replace backups.

2) Hey ! This is RAID 1. You have redundancy. You can convert one disk 
at a time, and if things go wrong, you can just rebuild it.

Note however that there is a small chance that a disk cannot be 
converted to GPT as is. The GPT primary and backup partition tables 
requires a few unallocated sectors (33 for a default 128-entry table) at 
the beginning and at the end of the disk. If sectors in these areas are 
allocated to partitions, the conversion is not possible.

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

#200420 — Re: [SOLVED] Re: Yet another UEFI/BIOS question

Le 22-09-2018, à 10:07:36 +0200, Pascal Hambourg a écrit :

>Le 22/09/2018 à 06:58, steve a écrit :
>>
>>>>Because what I finally did is install a fresh Debian on another device
>>>>(using GPT) and the ACPI errors still were there.
>>>
>>>In legacy mode (with a BIOS boot partition) or EFI mode (with an 
>>>EFI system partition) ?
>>
>>In EFI mode. The "Bios" is now fully in EFI mode and it sees all my boot
>>disks.
>
>Ok. I expected (with little hope though) that the errors might have 
>disappeared when booting in native EFI mode, not because you converted 
>disks to GPT.

Me too, but no chance, always the same errors. I guess it's not related
to kernel (4.18 from backports) but to Bios firmware (up to date). All I
can hope now is that they correct it. Nevertheless it doesn't to affect
the system (or if it does, it's so subtil that I just can't notice it).


>>>>I used the opportunity of having another Debian to convert my sda disk
>>>>to GPT tables, and change the BIOS setting to UEFI only (just for the
>>>>sake of it). So all my disk have a GPT partition table except for the 3
>>>>ones for the RAID1 array. Not sure whether I can use the same
>>>>manipulations to convert them to GPT also. But since they work fine, I
>>>>might leave it as it is.
>>>
>>>You can, but IMO it provides little value. GPT is useful in the 
>>>following cases :
>>>- disk bigger that 2 TiB
>>
>>Might come sooner or later.
>
>When it comes you'll use GPT on the new big disks. No need to convert 
>the old smaller ones.

Well I did, with no problem. Now all my 8 disks have GPT partition
tables.

>>I think I'll do that so to have 100% GPT disks and leave the past where
>>it is and prepare the future. But this step worries me a bit because I
>>have all my personal data on one of the RAID1 and really don't want to
>>loose them. I think best would be to backup those data elsewhere in case
>>things go wrong.
>
>1) Backup valuable data. RAID does not replace backups.

I know, but I rely on that, and I have a spare disk in case things go
the bad way. I have to put in place a procedure to do a real backup on
my freenas.

>2) Hey ! This is RAID 1. You have redundancy. You can convert one disk 
>at a time, and if things go wrong, you can just rebuild it.
>
>Note however that there is a small chance that a disk cannot be 
>converted to GPT as is. The GPT primary and backup partition tables 
>requires a few unallocated sectors (33 for a default 128-entry table) 
>at the beginning and at the end of the disk. If sectors in these areas 
>are allocated to partitions, the conversion is not possible.

Well, they didn't, all went fine.

Thanks for your help !

Have a nice week-end.

Steve

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

#200495 — And yet another UEFI/BIOS question: Work on both.

What do you recommend for setting up a system that will boot in either UEFI or BIOS mode, so if it is moved back and 
forth between UEFI and BIOS, it will boot every time?

Wayne Sallee
Wayne@WayneSallee.com
http://www.WayneSallee.com



On 09/21/2018 02:21 PM, Pascal Hambourg wrote:
> Le 21/09/2018 à 08:34, steve a écrit :
>> Le 20-09-2018, à 20:25:26 +0200, Pascal Hambourg a écrit :
>>
>>>>> You don't need to convert anything. UEFI can use DOS partition tables.
>>>>
>>>> I know since that's what I'm currently doing.
>>>
>>> Doing what ?
>>
>> Using msdos partition tables.
>
> This is irrelevant because until now you were booting Debian in legacy (BIOS) mode.
>
>>> I am not talking about you doing anything. I am saying that native UEFI boot (NOT legacy boot) can use a disk with a 
>>> DOS partition table, provided that it has an EFI system partition (Id 0xef).
>>
>> Isn't it ef00?
>
> No. ef00 is a gdisk specific mnemonic for the EFI system partition type identifier in a GPT partition table. The 
> actual GUID is C12A7328-F81F-11D2-BA4B-00A0C93EC93B.
> (0x)ef is the partition type identifier for an EFI system partition in a DOS partition table.
>
>> Because what I finally did is install a fresh Debian on another device
>> (using GPT) and the ACPI errors still were there.
>
> In legacy mode (with a BIOS boot partition) or EFI mode (with an EFI system partition) ?
>
>> I used the opportunity of having another Debian to convert my sda disk
>> to GPT tables, and change the BIOS setting to UEFI only (just for the
>> sake of it). So all my disk have a GPT partition table except for the 3
>> ones for the RAID1 array. Not sure whether I can use the same
>> manipulations to convert them to GPT also. But since they work fine, I
>> might leave it as it is.
>
> You can, but IMO it provides little value. GPT is useful in the following cases :
> - disk bigger that 2 TiB
> - more that 4 partition without the extended/logical partition kludge
> - need to use PARTLABEL or PARTUUD (but RAID uses its own UUID)
> - system disk for Windows in EFI mode
>
> AFAICS none of these conditions apply to your RAID disks. However I noticed that 2 out of the 3 RAID partition on each 
> disk are logical partitions. This is not necessary if there are only 3 partitions per disk. So in order to get rid of 
> the extended partition kludge, you could either convert the logical partitions into primary partitions or convert the 
> partition table to GPT.
>
>

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

#200502 — Re: And yet another UEFI/BIOS question: Work on both.

On Sun, 23 Sep 2018 10:58:54 -0400
Wayne Sallee <Wayne@WayneSallee.com> wrote:

> What do you recommend for setting up a system that will boot in
> either UEFI or BIOS mode, so if it is moved back and forth between
> UEFI and BIOS, it will boot every time?

I recommend you learn how to use Google or DuckDuckGo, etc. searches for
such basic queries. The following was the first result in the list of my
search. Total time spent: about 15 seconds.

https://truthseekers.io/everything-you-need-to-know-to-dual-boot-uefi-gpt-bios-mbr-partitions-swap-space-and-more/

Also, read up on "chainloading."

B

> Wayne Sallee
> Wayne@WayneSallee.com
> http://www.WayneSallee.com
> 
> 
> 
> On 09/21/2018 02:21 PM, Pascal Hambourg wrote:
> > Le 21/09/2018 à 08:34, steve a écrit :  
> >> Le 20-09-2018, à 20:25:26 +0200, Pascal Hambourg a écrit :
> >>  
> >>>>> You don't need to convert anything. UEFI can use DOS partition
> >>>>> tables.  
> >>>>
> >>>> I know since that's what I'm currently doing.  
> >>>
> >>> Doing what ?  
> >>
> >> Using msdos partition tables.  
> >
> > This is irrelevant because until now you were booting Debian in
> > legacy (BIOS) mode. 
> >>> I am not talking about you doing anything. I am saying that
> >>> native UEFI boot (NOT legacy boot) can use a disk with a DOS
> >>> partition table, provided that it has an EFI system partition (Id
> >>> 0xef).  
> >>
> >> Isn't it ef00?  
> >
> > No. ef00 is a gdisk specific mnemonic for the EFI system partition
> > type identifier in a GPT partition table. The actual GUID is
> > C12A7328-F81F-11D2-BA4B-00A0C93EC93B. (0x)ef is the partition type
> > identifier for an EFI system partition in a DOS partition table. 
> >> Because what I finally did is install a fresh Debian on another
> >> device (using GPT) and the ACPI errors still were there.  
> >
> > In legacy mode (with a BIOS boot partition) or EFI mode (with an
> > EFI system partition) ? 
> >> I used the opportunity of having another Debian to convert my sda
> >> disk to GPT tables, and change the BIOS setting to UEFI only (just
> >> for the sake of it). So all my disk have a GPT partition table
> >> except for the 3 ones for the RAID1 array. Not sure whether I can
> >> use the same manipulations to convert them to GPT also. But since
> >> they work fine, I might leave it as it is.  
> >
> > You can, but IMO it provides little value. GPT is useful in the
> > following cases :
> > - disk bigger that 2 TiB
> > - more that 4 partition without the extended/logical partition
> > kludge
> > - need to use PARTLABEL or PARTUUD (but RAID uses its own UUID)
> > - system disk for Windows in EFI mode
> >
> > AFAICS none of these conditions apply to your RAID disks. However I
> > noticed that 2 out of the 3 RAID partition on each disk are logical
> > partitions. This is not necessary if there are only 3 partitions
> > per disk. So in order to get rid of the extended partition kludge,
> > you could either convert the logical partitions into primary
> > partitions or convert the partition table to GPT.
> >
> >  
> 

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

#200519 — Re: And yet another UEFI/BIOS question: Work on both.

Thank you for the 15 seconds of time that you spent. But that page that you linked to is useless.

Wayne Sallee
Wayne@WayneSallee.com
http://www.WayneSallee.com

On 09/23/2018 12:18 PM, Patrick Bartek wrote:
> On Sun, 23 Sep 2018 10:58:54 -0400
> Wayne Sallee <Wayne@WayneSallee.com> wrote:
>
>> What do you recommend for setting up a system that will boot in
>> either UEFI or BIOS mode, so if it is moved back and forth between
>> UEFI and BIOS, it will boot every time?
> I recommend you learn how to use Google or DuckDuckGo, etc. searches for
> such basic queries. The following was the first result in the list of my
> search. Total time spent: about 15 seconds.
>
> https://truthseekers.io/everything-you-need-to-know-to-dual-boot-uefi-gpt-bios-mbr-partitions-swap-space-and-more/
>
> Also, read up on "chainloading."
>
> B
>
>> Wayne Sallee
>> Wayne@WayneSallee.com
>> http://www.WayneSallee.com
>>
>>
>>
>> On 09/21/2018 02:21 PM, Pascal Hambourg wrote:
>>> Le 21/09/2018 à 08:34, steve a écrit :
>>>> Le 20-09-2018, à 20:25:26 +0200, Pascal Hambourg a écrit :
>>>>   
>>>>>>> You don't need to convert anything. UEFI can use DOS partition
>>>>>>> tables.
>>>>>> I know since that's what I'm currently doing.
>>>>> Doing what ?
>>>> Using msdos partition tables.
>>> This is irrelevant because until now you were booting Debian in
>>> legacy (BIOS) mode.
>>>>> I am not talking about you doing anything. I am saying that
>>>>> native UEFI boot (NOT legacy boot) can use a disk with a DOS
>>>>> partition table, provided that it has an EFI system partition (Id
>>>>> 0xef).
>>>> Isn't it ef00?
>>> No. ef00 is a gdisk specific mnemonic for the EFI system partition
>>> type identifier in a GPT partition table. The actual GUID is
>>> C12A7328-F81F-11D2-BA4B-00A0C93EC93B. (0x)ef is the partition type
>>> identifier for an EFI system partition in a DOS partition table.
>>>> Because what I finally did is install a fresh Debian on another
>>>> device (using GPT) and the ACPI errors still were there.
>>> In legacy mode (with a BIOS boot partition) or EFI mode (with an
>>> EFI system partition) ?
>>>> I used the opportunity of having another Debian to convert my sda
>>>> disk to GPT tables, and change the BIOS setting to UEFI only (just
>>>> for the sake of it). So all my disk have a GPT partition table
>>>> except for the 3 ones for the RAID1 array. Not sure whether I can
>>>> use the same manipulations to convert them to GPT also. But since
>>>> they work fine, I might leave it as it is.
>>> You can, but IMO it provides little value. GPT is useful in the
>>> following cases :
>>> - disk bigger that 2 TiB
>>> - more that 4 partition without the extended/logical partition
>>> kludge
>>> - need to use PARTLABEL or PARTUUD (but RAID uses its own UUID)
>>> - system disk for Windows in EFI mode
>>>
>>> AFAICS none of these conditions apply to your RAID disks. However I
>>> noticed that 2 out of the 3 RAID partition on each disk are logical
>>> partitions. This is not necessary if there are only 3 partitions
>>> per disk. So in order to get rid of the extended partition kludge,
>>> you could either convert the logical partitions into primary
>>> partitions or convert the partition table to GPT.
>>>
>>>   
>

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

#200521 — Re: And yet another UEFI/BIOS question: Work on both.

On Sun, 23 Sep 2018 17:20:05 -0400
Wayne Sallee <Wayne@WayneSallee.com> wrote:

> Thank you for the 15 seconds of time that you spent. But that page
> that you linked to is useless.

That link is where you start: First, by building a foundation on the
techniques of multi-booting; then expand on that with additional and
more specific articles until you achieve understanding and can fulfill
your task. This process has always worked great for me.  Takes longer,
yes; but you end up knowing what you're doing and can anticipate
potential problems. Using techniques and shortcuts others recommend
without knowing what they really do is a recipe for disaster.  Or just
folly.

Good luck with your quest.

B

> Wayne Sallee
> Wayne@WayneSallee.com
> http://www.WayneSallee.com
> 
> On 09/23/2018 12:18 PM, Patrick Bartek wrote:
> > On Sun, 23 Sep 2018 10:58:54 -0400
> > Wayne Sallee <Wayne@WayneSallee.com> wrote:
> >  
> >> What do you recommend for setting up a system that will boot in
> >> either UEFI or BIOS mode, so if it is moved back and forth between
> >> UEFI and BIOS, it will boot every time?  
> > I recommend you learn how to use Google or DuckDuckGo, etc.
> > searches for such basic queries. The following was the first result
> > in the list of my search. Total time spent: about 15 seconds.
> >
> > https://truthseekers.io/everything-you-need-to-know-to-dual-boot-uefi-gpt-bios-mbr-partitions-swap-space-and-more/
> >
> > Also, read up on "chainloading."
> >
> > B

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

#200564 — Re: And yet another UEFI/BIOS question: Work on both.

On Sun 23 Sep 2018 at 17:58:08 (-0700), Patrick Bartek wrote:
> On Sun, 23 Sep 2018 17:20:05 -0400 Wayne Sallee <Wayne@WayneSallee.com> wrote:
> 
> > Thank you for the 15 seconds of time that you spent. But that page
> > that you linked to is useless.
> 
> That link is where you start: First, by building a foundation on the
> techniques of multi-booting; then expand on that with additional and
> more specific articles until you achieve understanding and can fulfill
> your task. This process has always worked great for me.  Takes longer,
> yes; but you end up knowing what you're doing and can anticipate
> potential problems. Using techniques and shortcuts others recommend
> without knowing what they really do is a recipe for disaster.  Or just
> folly.

You might think that from the name of the link, but the page fails to
live up to its promise. Some quotations:

"BIOS lives inside a chip on your computers motherboard. Inside the
BIOS, is a small section called “MBR”, which stands for “Master Boot
Record” and is often called “Boot record” or “Boot Sector” or
something like it."

"The BIOS/MBR is a TINY slice at the BEGINNING of your hard disk that
gets run as soon as you startup your computer."

"If you must have the improved UEFI/GPT, then either buy a new computer
(easier) or check if your existing computer is compatible with
UEFI/GPT, and have fun trying to convert it.

"Luckily for beginners, most of the Linux installers are pretty smart,
and you can let the installer do most of the partitioning if you just
create enough free space."

I fail to see how that kind of "information" starts to address what
the OP is trying to do.

> > On 09/23/2018 12:18 PM, Patrick Bartek wrote:
> > > On Sun, 23 Sep 2018 10:58:54 -0400 Wayne Sallee <Wayne@WayneSallee.com> wrote:
> > >  
> > >> What do you recommend for setting up a system that will boot in
> > >> either UEFI or BIOS mode, so if it is moved back and forth between
> > >> UEFI and BIOS, it will boot every time?  
> > > I recommend you learn how to use Google or DuckDuckGo, etc.
> > > searches for such basic queries. The following was the first result
> > > in the list of my search. Total time spent: about 15 seconds.
> > >
> > > https://truthseekers.io/everything-you-need-to-know-to-dual-boot-uefi-gpt-bios-mbr-partitions-swap-space-and-more/
> > >
> > > Also, read up on "chainloading."

Cheers,
David.

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

#200568 — Re: And yet another UEFI/BIOS question: Work on both.

On Mon, Sep 24, 2018 at 02:11:44PM -0500, David Wright wrote:
>You might think that from the name of the link, but the page fails to
>live up to its promise. Some quotations:
>
>"BIOS lives inside a chip on your computers motherboard. Inside the
>BIOS, is a small section called “MBR”, which stands for “Master Boot
>Record” and is often called “Boot record” or “Boot Sector” or
>something like it."
>
>"The BIOS/MBR is a TINY slice at the BEGINNING of your hard disk that
>gets run as soon as you startup your computer."
>
>"If you must have the improved UEFI/GPT, then either buy a new computer
>(easier) or check if your existing computer is compatible with
>UEFI/GPT, and have fun trying to convert it.

Yeah, that's pretty bad.

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

#200675 — Re: And yet another UEFI/BIOS question: Work on both.

Le 23/09/2018 à 18:18, Patrick Bartek a écrit :
> On Sun, 23 Sep 2018 10:58:54 -0400
> Wayne Sallee <Wayne@WayneSallee.com> wrote:
> 
>> What do you recommend for setting up a system that will boot in
>> either UEFI or BIOS mode, so if it is moved back and forth between
>> UEFI and BIOS, it will boot every time?
> 
> I recommend you learn how to use Google or DuckDuckGo, etc. searches for
> such basic queries.

This is not a basic query. I have spend quite some time doing 
experiments and have not come up with a perfect universal solution yet.

If you want your system to work with old 32-bit CPUs, you must install 
the i386 architecture. After the installation you can add the amd64 
architecture with dpkg and install a 64-bit kernel. Note that a 32-bit 
kernel can work with a 64-bit UEFI firmware but EFI variables will be 
available only with a 64-bit kernel. A 64-bit kernel can work with a 
32-bit UEFI firmware (if the CPU is 64-bit of course) and EFI variables 
will be available.

You must choose the partition table format between GPT and DOS/MBR.
I read that some broken BIOS may not boot a disk with a GPT partition 
table, although I haven't seen any yet.
I also read that some broken UEFI implementations may force boot in 
native EFI mode when a GPT partition table is present, and in 
BIOS/legacy mode when a DOS/MBR partition table is present, although I 
haven't see any either yet.

However I have observed that quite many BIOS or UEFI implementations 
operating in legacy mode won't boot a disk (either GPT or DOS/MBR) if no 
partition in the DOS partition table/protective MBR has the boot flag 
set. But setting the boot flag on the protective GPT partition is 
against the GPT specification, and I have one example of a UEFI 
implementation which will not boot such a disk in native EFI mode.

So I guess you get a better chance with a DOS/MBR partition table. Note 
that this is what the Debian installer/live ISO-hybrid images use.

If you choose GPT anyway, it is recommended to create a 1 MiB 
unformatted "BIOS boot" partition for GRUB BIOS.

Create a 10 to 100 MB EFI system partition formatted as FAT and mount it 
on /boot/efi.

In order to boot either in BIOS or EFI mode, you have to install both 
BIOS and EFI boot loaders. If you choose GRUB for both, the packages are
- grub-pc to install GRUB for PC with BIOS
- grub-efi-amd64 to install GRUB for PC with 64-bit UEFI firmware
- grub-efi-ia32 to install GRUB for PC with 32-bit UEFI firmware

But these packages conflict with one another so are mutually exclusive. 
You could install one and run grub-install, then uninstall it, install 
the next one and run grub-install again and so on. But I suggest to 
install one, say grub-pc, and install grub-efi-{amd64,ia32}-bin instead, 
which do not conflict with each other.

Now you can install the different GRUB boot loaders for each platform :
# BIOS
grub-install --target=i386-pc /dev/sda
# EFI 32 bit
grub-install --target=i386-efi --removable
# EFI 64 bit
grub-install --target=x86_64-efi --removable

These commands work regardless of whether the system was booted in EFI 
or BIOS mode or EFI variables are available.
The --removable option will install the boot loader in the "removable 
device" path /boot/efi/EFI/BOOT/boot{arch}.efi.

> The following was the first result in the list of my
> search. Total time spent: about 15 seconds.
> 
> https://truthseekers.io/everything-you-need-to-know-to-dual-boot-uefi-gpt-bios-mbr-partitions-swap-space-and-more/
> 
> Also, read up on "chainloading."

Dual boot and chainloading have nothing to do with Wayne's query.

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

#200511 — Re: And yet another UEFI/BIOS question: Work on both.

On Sun 23 Sep 2018 at 10:58:54 (-0400), Wayne Sallee wrote:
> What do you recommend for setting up a system that will boot in either
> UEFI or BIOS mode, so if it is moved back and forth between UEFI and
> BIOS, it will boot every time?

I have no idea whether this would work as I haven't tried it. The only
EFI system I have access to needs a working W10 system at all times,
so I wasn't prepared to disturb it when I installed linux alongside.

I would start with a GPT disk, set up with the first partition
starting at sector 2048 (for 512-byte sectors), ie 1MB alignment.
Obviously it will need a protective MBR.

I would follow that with a ~8MB partition containing no filesystem,
and having the partition type EF02 (BIOS-Boot). This is where Grub
can put most of its boot code for BIOS booting.

Next would come a ~250MB partition with a type of EF00 for the ESP.

The rest of the partitions would have a type of 8300 except for the
swap partition which is 8200. I'd start with a perhaps ~500MB for
a separate /boot partition, and then would follow /home, swap and
(for me) a couple of ~30-40GB root partitions. (I like a spare OS.)
I don't normally separate /boot, but I think it might be wise to
try and limit damage to a "containment zone" while doing this
experiment.

That gives you your playground, and here's where I leave my comfort
zone, as my linux system runs in BIOS mode. I would start by
installing in EFI mode so you get its ESP sorted out.

Then comes the bit where I have no idea if it will work and what
obstacles you will encounter. I'd boot in BIOS mode from a USB
stick and attempt to make Grub install itself in the MBR (using
the BIOS-Boot partition for the remainder of its boot code).
If you achieve that, you can now see whether either of the
booting methods still works, and let us know.

No doubt there'll be people ready to pick holes in all this, and I
welcome any feedback.

Cheers,
David.

[toc] | [prev] | [standalone]

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

csiph-web