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

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

USB Install Fails, Complains about CD-ROM

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

Contents

  USB Install Fails, Complains about CD-ROM Kent West <westk@acu.edu> - 2018-05-11 18:20 +0200
    Re: USB Install Fails, Complains about CD-ROM Robert Menes <viewtiful.icchan@gmail.com> - 2018-05-11 18:40 +0200
      Re: USB Install Fails, Complains about CD-ROM Rick Thomas <rbthomas@pobox.com> - 2018-05-12 01:10 +0200
        Re: USB Install Fails, Complains about CD-ROM Kenneth Parker <sea7kenp@gmail.com> - 2018-05-12 03:40 +0200
        Re: USB Install Fails, Complains about CD-ROM Pascal Hambourg <pascal@plouf.fr.eu.org> - 2018-05-12 19:40 +0200
    Re: USB Install Fails, Complains about CD-ROM "Thomas Schmitt" <scdbackup@gmx.net> - 2018-05-11 18:40 +0200
    Re: USB Install Fails, Complains about CD-ROM Curt <curty@free.fr> - 2018-05-11 19:10 +0200
      Re: USB Install Fails, Complains about CD-ROM Kent West <westk@acu.edu> - 2018-05-11 20:40 +0200
    Re: USB Install Fails, Complains about CD-ROM songbird <songbird@anthive.com> - 2018-05-11 19:50 +0200
      Re: USB Install Fails, Complains about CD-ROM Kent West <westk@acu.edu> - 2018-05-11 20:40 +0200
        Re: USB Install Fails, Complains about CD-ROM Kent West <westk@acu.edu> - 2018-05-11 21:30 +0200
        Re: USB Install Fails, Complains about CD-ROM Pascal Hambourg <pascal@plouf.fr.eu.org> - 2018-05-11 22:00 +0200
          Re: USB Install Fails, Complains about CD-ROM Kent West <westk@acu.edu> - 2018-05-11 22:20 +0200
            Re: USB Install Fails, Complains about CD-ROM "Thomas Schmitt" <scdbackup@gmx.net> - 2018-05-11 22:40 +0200
              Re: USB Install Fails, Complains about CD-ROM Kent West <westk@acu.edu> - 2018-05-11 23:00 +0200
                Re: USB Install Fails, Complains about CD-ROM "Thomas Schmitt" <scdbackup@gmx.net> - 2018-05-12 00:00 +0200
                Re: USB Install Fails, Complains about CD-ROM Brian <ad44@cityscape.co.uk> - 2018-05-12 12:30 +0200
              Re: USB Install Fails, Complains about CD-ROM Pascal Hambourg <pascal@plouf.fr.eu.org> - 2018-05-12 19:50 +0200
                Re: USB Install Fails, Complains about CD-ROM "Thomas Schmitt" <scdbackup@gmx.net> - 2018-05-12 21:40 +0200
                  Re: USB Install Fails, Complains about CD-ROM Pascal Hambourg <pascal@plouf.fr.eu.org> - 2018-05-13 10:20 +0200
                    Re: Block sizes in ISOs. was: USB Install Fails, Complains about CD-ROM "Thomas Schmitt" <scdbackup@gmx.net> - 2018-05-13 11:30 +0200
            UEFI/"BIOS" booting, was Re: USB Install Fails, Complains about  CD-ROM David Wright <deblis@lionunicorn.co.uk> - 2018-05-13 17:20 +0200
              Re: UEFI/"BIOS" booting, was Re: USB Install Fails, Complains about  CD-ROM Pascal Hambourg <pascal@plouf.fr.eu.org> - 2018-05-13 19:10 +0200
                Re: UEFI/"BIOS" booting, was Re: USB Install Fails, Complains about  CD-ROM David Wright <deblis@lionunicorn.co.uk> - 2018-05-14 02:10 +0200
                  Re: UEFI/"BIOS" booting, was Re: USB Install Fails, Complains about  CD-ROM Pascal Hambourg <pascal@plouf.fr.eu.org> - 2018-05-14 23:40 +0200
                    Re: UEFI/"BIOS" booting, was Re: USB Install Fails, Complains about  CD-ROM David Wright <deblis@lionunicorn.co.uk> - 2018-05-15 04:00 +0200
                Re: UEFI/"BIOS" booting, was Re: USB Install Fails, Complains about  CD-ROM songbird <songbird@anthive.com> - 2018-05-14 12:40 +0200
                  Re: UEFI/"BIOS" booting, was Re: USB Install Fails, Complains about  CD-ROM Chris Ramsden <chris.ramsden@gmail.com> - 2018-05-14 14:40 +0200
                    Re: UEFI/"BIOS" booting, was Re: USB Install Fails, Complains about  CD-ROM David Wright <deblis@lionunicorn.co.uk> - 2018-05-14 16:00 +0200
                      Re: UEFI/"BIOS" booting, was Re: USB Install Fails, Complains about  CD-ROM Chris Ramsden <chris.ramsden@gmail.com> - 2018-05-14 17:00 +0200
                    Re: UEFI/"BIOS" booting, was Re: USB Install Fails, Complains about  CD-ROM songbird <songbird@anthive.com> - 2018-05-15 02:50 +0200
              Re: UEFI/"BIOS" booting, was Re: USB Install Fails, Complains about CD-ROM Stefan Monnier <monnier@iro.umontreal.ca> - 2018-05-14 15:20 +0200
                Re: UEFI/"BIOS" booting, was Re: USB Install Fails, Complains about  CD-ROM David Wright <deblis@lionunicorn.co.uk> - 2018-05-14 16:40 +0200
                  Re: UEFI/"BIOS" booting "Thomas Schmitt" <scdbackup@gmx.net> - 2018-05-14 18:00 +0200
                    Re: UEFI/"BIOS" booting Pascal Hambourg <pascal@plouf.fr.eu.org> - 2018-05-14 23:50 +0200
                      Re: UEFI/"BIOS" booting "Thomas Schmitt" <scdbackup@gmx.net> - 2018-05-15 09:00 +0200
                        Re: UEFI/"BIOS" booting Pascal Hambourg <pascal@plouf.fr.eu.org> - 2018-05-16 00:20 +0200
                          Re: UEFI/"BIOS" booting Pascal Hambourg <pascal@plouf.fr.eu.org> - 2018-05-16 23:50 +0200
                            Re: UEFI/"BIOS" booting "Thomas Schmitt" <scdbackup@gmx.net> - 2018-05-17 13:00 +0200
                  Re: UEFI/"BIOS" booting, was Re: USB Install Fails, Complains about CD-ROM Stefan Monnier <monnier@iro.umontreal.ca> - 2018-05-14 18:00 +0200
                    Re: UEFI/"BIOS" booting, was Re: USB Install Fails, Complains about  CD-ROM David Wright <deblis@lionunicorn.co.uk> - 2018-05-15 03:30 +0200
                      Re: UEFI/"BIOS" booting, was Re: USB Install Fails, Complains about  CD-ROM Pascal Hambourg <pascal@plouf.fr.eu.org> - 2018-05-16 00:40 +0200
                        Re: UEFI/"BIOS" booting, was Re: USB Install Fails, Complains about  CD-ROM David Wright <deblis@lionunicorn.co.uk> - 2018-05-18 20:40 +0200
                  Re: UEFI/"BIOS" booting Pascal Hambourg <pascal@plouf.fr.eu.org> - 2018-05-14 23:50 +0200
                    Re: UEFI/"BIOS" booting David Wright <deblis@lionunicorn.co.uk> - 2018-05-15 03:40 +0200
                      Re: UEFI/"BIOS" booting Pascal Hambourg <pascal@plouf.fr.eu.org> - 2018-05-16 00:40 +0200
                        Re: UEFI/"BIOS" booting mess-mate <eric.m.c.declerck@gmail.com> - 2018-05-16 15:20 +0200
                        Re: UEFI/"BIOS" booting David Wright <deblis@lionunicorn.co.uk> - 2018-05-18 20:50 +0200
    Re: USB Install Fails, Complains about CD-ROM Mike Kupfer <mkupfer@alum.berkeley.edu> - 2018-05-13 04:20 +0200
      Re: USB Install Fails, Complains about CD-ROM Curt <curty@free.fr> - 2018-05-13 10:30 +0200
        Re: USB Install Fails, Complains about CD-ROM "Thomas Schmitt" <scdbackup@gmx.net> - 2018-05-13 12:10 +0200
          Re: USB Install Fails, Complains about CD-ROM Curt <curty@free.fr> - 2018-05-13 14:10 +0200
            Re: USB Install Fails, Complains about CD-ROM "Thomas Schmitt" <scdbackup@gmx.net> - 2018-05-13 14:50 +0200
          Re: USB Install Fails, Complains about CD-ROM Mike Kupfer <mkupfer@alum.berkeley.edu> - 2018-05-13 19:00 +0200
            Re: USB Install Fails, Complains about CD-ROM "Thomas Schmitt" <scdbackup@gmx.net> - 2018-05-13 20:20 +0200
              Re: USB Install Fails, Complains about CD-ROM Mike Kupfer <mkupfer@alum.berkeley.edu> - 2018-05-14 00:40 +0200
                Re: USB Install Fails, Complains about CD-ROM "Thomas Schmitt" <scdbackup@gmx.net> - 2018-05-14 13:30 +0200
                  Re: USB Install Fails, Complains about CD-ROM Mike Kupfer <mkupfer@alum.berkeley.edu> - 2018-05-14 16:50 +0200
                    Re: USB Install Fails, Complains about CD-ROM "Thomas Schmitt" <scdbackup@gmx.net> - 2018-05-14 18:20 +0200
                      Re: USB Install Fails, Complains about CD-ROM David Wright <deblis@lionunicorn.co.uk> - 2018-05-14 20:10 +0200
                        Re: USB Install Fails, Complains about CD-ROM "Thomas Schmitt" <scdbackup@gmx.net> - 2018-05-14 22:10 +0200
                          Re: USB Install Fails, Complains about CD-ROM Mike Kupfer <mkupfer@alum.berkeley.edu> - 2018-05-14 23:00 +0200
                            Re: USB Install Fails, Complains about CD-ROM Mike Kupfer <mkupfer@alum.berkeley.edu> - 2018-05-15 01:20 +0200
                              Re: USB Install Fails, Complains about CD-ROM "Thomas Schmitt" <scdbackup@gmx.net> - 2018-05-15 09:10 +0200
                                Re: USB Install Fails, Complains about CD-ROM Mike Kupfer <mkupfer@alum.berkeley.edu> - 2018-05-17 23:40 +0200
                                  Re: USB Install Fails, Complains about CD-ROM "Thomas Schmitt" <scdbackup@gmx.net> - 2018-05-18 08:50 +0200
                      Re: USB Install Fails, Complains about CD-ROM Mike Kupfer <mkupfer@alum.berkeley.edu> - 2018-05-15 01:10 +0200

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

#195671 — Re: Block sizes in ISOs. was: USB Install Fails, Complains about CD-ROM

Hi,

Pascal Hambourg wrote:
> I have never seen a hard disk or flash drive with a sector size of 2048
> (only 512 or 4096) so the kernel must be correct and the Apple partition
> table must be wrong.

Both are correct. The kernel reports what it perceives as hardware block
size ("physical"). The Apple Partition Map is free to use one of several
block sizes. (In case of a "mjg" isohybrid it is 2048 in order to give
room for the GPT header block at byte 512 to 1023. The first APM entry
then begins at byte 2048.)

It is the partition editor who is clueless. (One wonders how those editors
get to their hunchbacked representations from quite clear partition table
specs.)


> Can you please explain why the wrong block size does not matter ?

Block size matters in various aspects. But these aspects refer to own info
sources which do not necessarily tell the same number.
In a Debian x86 isohybrid we have the following block sizes:

- The MBR partition table assumes block size 512. To be used when converting
  Logical Block Address and block count to the byte offsets of partitions.

- The El Torito Sector Count assumes block size 512. To be used when loading
  the BIOS boot image into memory, or when accepting the EFI boot image as
  EFI System Partition.

- The El Torito Load RBA (start block of the boot image) assumes block size
  2048. To be used when loading or accepting the boot image.

- The Apple Partition Map announces block size 2048. To be used when
  converting block addresses and counts of the APM to byte offsets.

- The ISO 9660 filesystem announces a block size of 2048. To be used when
  converting block addresses and counts of the ISO metadata to byte offsets.

- Then we have the FAT filesystem in the EFI boot image. Probably it uses
  a block size of 512 bytes.

Each interpreter of those structures needs to get told the matching block
size or needs to assume it correctly without being told.


> The only storage media with a bloc size of 2048 I know about are optical
> media such as CD and DVD.

Readers of ISO 9660 should obey the block size given in the Primary Volume
Descriptor. But all i know (including mine) will only work with logical
block size 2048.

The block size used with filesystem or partition table is quite independent
of the block size which the device assumes for its Logical Block Addresses.
(I think Linux demands multiples of 512 by a power of two: 512, 1024, 2048,
4096, ...)
The kernel converts the logical block addressies of filesystem or partition
table to the logical block addresses of the storage device.

(Many storage devices expose a logical block size of 512 while really having
 larger storage chunks.)


> Could the Apple partition map in the image be used when booting from an
> optical disk on a Mac ?

Hardly. One can never be sure with firmware behavior, though.

Matthew J. Garrett ("mjg") introduced the APM into Fedora isohybrids in
order to mark a small HFS+ filesystem image file inside the ISO.
But Debian has no such HFS+ image, and thus does not serve that obscure
class of Apple machines which probably predate Apple's adoption of EFI.

In Fedora-Workstation-netinst-x86_64-23.iso one can see:

  MBR partition table:   N Status  Type        Start       Blocks
  MBR partition      :   1   0x80  0x00            0       845824
  MBR partition      :   2   0x00  0xef          180        10780
  MBR partition      :   3   0x00  0x00       684488        43168
  MBR partition path :   2  /images/efiboot.img
  MBR partition path :   3  /images/macboot.img
  ...
  APM                :   N  Info
  APM block size     :      2048
  APM gap fillers    :      0
  APM partition name :   1  EFI
  APM partition type :   1  Apple_HFS
  APM start and size :   1  45  2695
  APM partition path :   1  /images/efiboot.img
  APM partition name :   2  EFI
  APM partition type :   2  Apple_HFS
  APM start and size :   2  171122  10792
  APM partition path :   2  /images/macboot.img
  ...

Both partition tables mark the ISO files efiboot.img and macboot.img as
partitions. The addresses match when interpreted by appropriate block sizes:
  180 = 45 * 4
  684488 = 171122 * 4

When debian-cd adopted this layout, the HFS+ image was omitted, but the
option to mark the EFI image in Apple Partition Map staid with the xorriso
run. So we still see an APM in debian-cd amd64 and i386 ISOs.
E.g. in debian-9.4.0-amd64-xfce-CD-1.iso :

  APM                :   N  Info
  APM block size     :      2048
  APM gap fillers    :      0
  APM partition name :   1  EFI
  APM partition type :   1  Apple_HFS
  APM start and size :   1  1835  208
  APM partition path :   1  /boot/grub/efi.img


Matthew described his invention in
  http://mjg59.dreamwidth.org/11285.html


Have a nice day :)

Thomas

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

#195681 — UEFI/"BIOS" booting, was Re: USB Install Fails, Complains about CD-ROM

On Fri 11 May 2018 at 15:13:04 (-0500), Kent West wrote:
> On Fri, May 11, 2018 at 2:59 PM, Pascal Hambourg <pascal@plouf.fr.eu.org>
> wrote:
> 
> > Le 11/05/2018 à 20:33, Kent West a écrit :
> >
> >>
> >> I learned that EFI boot drives need to have a GPT partition table. On a
> >>
> >
> > This is not correct. The UEFI specification supports boot from a drive
> > with an MSDOS partition table. Otherwise why would there be an "EFI system
> > partition" type identifier (0xef) for MSDOS partition tables ? The Debian
> > installer hybrid image has an MSDOS partition table. (It also has Apple and
> > GPT partition tables, but they are bogus)
> 
> 
> That's good to know. I guess my source material (
> https://www.happyassassin.net/2014/01/25/uefi-boot-how-does-that-actually-work-then/)
> is wrong. Or I misunderstood it.

While a lot of the detail on that long page might be correct, there
are also statements there that don't seem to agree with reality.

It does make a statement that agrees with Pascal's:

    "and the UEFI spec requires that UEFI-compliant firmwares be
    capable of interpreting GPT (it also requires them to be capable
    of interpreting MBR, for backwards compatibility)." (under "The
    GPT (GUID partition table) format").

That said, there are other statements that are odd:

    "I really can’t recommend strongly enough that you do not attempt
    to mix UEFI-native and BIOS-compatible booting of
    permanently-installed operating systems on the same computer, and
    especially not on the same disk. It is a terrible terrible idea
    and will cause you heartache and pain. If you decide to do it,
    don’t come crying to me." (under "UEFI booting: background").
--
    "Disk formats (MBR vs. GPT)

      Here’s another very important consideration:

      If you want to do a ‘BIOS compatibility’ type installation, you
    probably want to install to an MBR formatted disk. If you want to
    do a UEFI native installation, you probably want to install to a
    GPT formatted disk."
--
    "A specific example

    To boil down the above: if you bought a Windows 8 or later system,
    you almost certainly have a UEFI native install of Windows to a
    GPT-formatted disk. This means that if you want to install another
    OS alongside that Windows install, you almost certainly want to do
    a UEFI-native installation of your other OS. If you don’t like all
    this UEFI nonsense and want to go back to the good old world
    you’re familiar with, you will, I’m afraid, have to blow away the
    UEFI-native Windows installation, and it would be a good idea to
    reformat the disk to MBR."

I can't reconcile that with the system here, a Windows 8→10 UEFI laptop
and GPT disk running linux in BIOS compatibility mode (here called
Legacy mode by Lenovo) booting from an MBR on an ATA disk:

# gdisk -l /dev/sda
GPT fdisk (gdisk) version 1.0.1

Partition table scan:
  MBR: protective
  BSD: not present
  APM: not present
  GPT: present

Found valid GPT with protective MBR; using GPT.
Disk /dev/sda: 976773168 sectors, 465.8 GiB
Logical sector size: 512 bytes
Disk identifier (GUID): 2653F13F-2CD0-406F-B004-6AFFDBE18127
Partition table holds up to 128 entries
First usable sector is 34, last usable sector is 976773134
Partitions will be aligned on 2048-sector boundaries
Total free space is 4077 sectors (2.0 MiB)

Number  Start (sector)    End (sector)  Size       Code  Name
   1            2048         2050047   1000.0 MiB  2700  Basic data partition
   2         2050048         2582527   260.0 MiB   EF00  EFI system partition
   3         2582528         4630527   1000.0 MiB  ED01  Basic data partition
   4         4630528         4892671   128.0 MiB   0C01  Microsoft reserved ...
   5         4892672       347348991   163.3 GiB   0700  Basic data partition
   6       347348992       429268991   39.1 GiB    8300  Linux-A
   7       429268992       511188991   39.1 GiB    8300  Linux-B
   8       511188992       883275775   177.4 GiB   8300  Linux-Home
   9       883275776       883292159   8.0 MiB     EF02  Linux-BIOS-Boot
  10       883292160       892084223   4.2 GiB     8200  Linux-Swap
  11       892086272       892803071   350.0 MiB   2700  
  12       892803072       894900223   1024.0 MiB  0700  Basic data partition
  13       894900224       947329023   25.0 GiB    0700  Basic data partition
  14       947329024       976773119   14.0 GiB    2700  Basic data partition
# 

 => Grub2 (v1.99) is installed in the MBR of /dev/sda and looks at sector 
    883275776 of the same hard drive for core.img. core.img is at this 
    location and looks in partition 85 for . [from bootinfoscript].

The original sda5 was shrunk, and five new partitions added, all by
windows. Then the machine was booted in compatibility mode and linux
was installed. Finally, I told windows not to assign a drive letter
to the linux partitions (so that it does not keep offering to reformat
them at every encounter).

The result is a laptop that boots windows in UEFI Boot Mode and
linux in Legacy Mode. Windows knows nothing about the linux
installation except to ignore those partitions. Linux mounts
what it can of the windows installation, but in readonly mode.
Switching over involves going through the "BIOS Setup", reached
by a separate button (almost recessed).

All this makes me treat the information on that page with suspicion.
Perhaps the statement quoted here is self-referential (but lower than
95%, I hope): "You’ve probably read a lot of stuff on the internet
about UEFI. Here is something important you should understand: 95% of
it was probably garbage."

Cheers,
David.

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

#195683 — Re: UEFI/"BIOS" booting, was Re: USB Install Fails, Complains about CD-ROM

Le 13/05/2018 à 17:18, David Wright a écrit :
> On Fri 11 May 2018 at 15:13:04 (-0500), Kent West wrote:
>>
>> That's good to know. I guess my source material (
>> https://www.happyassassin.net/2014/01/25/uefi-boot-how-does-that-actually-work-then/)
>> is wrong. Or I misunderstood it.
> 
> While a lot of the detail on that long page might be correct, there
> are also statements there that don't seem to agree with reality.

Most of the statements you quoted agree with my (admittedly limited) 
experience with UEFI. There is a difference between the theory 
(specifications) and the reality (implementations), and some pieces of 
software may have extra requirements beyond the sole UEFI specification.

>      "I really can’t recommend strongly enough that you do not attempt
>      to mix UEFI-native and BIOS-compatible booting of
>      permanently-installed operating systems on the same computer, and
>      especially not on the same disk. It is a terrible terrible idea
>      and will cause you heartache and pain. If you decide to do it,
>      don’t come crying to me." (under "UEFI booting: background").

I would not be as much adamant as the author, but my experience says : 
it can work, but expect trouble.

Most of my early experience with UEFI boot comes from a rather old Intel 
motherboard. Beside crippled UEFI support (no UEFI boot from USB or SATA 
in AHCI mode), it had a couple of annoying requirements :
- boot in legacy mode only if the MBR contains a partition entry with 
the boot flag set, regardless of whether the disk has a MSDOS or GPT 
partition table. This behaviour is beyond any common BIOS standard, but 
I have observed it on many other systems, mostly Dell and HP ;
- boot in EFI mode from GPT only if the protective partition entry in 
the MBR has the boot flag unset. I admit this requirement is part of the 
GPT specification, but really do not see the point in enforcing such a 
minor detail.

Anyway, these two requirements put together make it impossible to boot 
in both legacy and EFI mode from the same GPT disk with this 
motherboard. However they allow to boot in both modes from the same 
MSDOS disk. But who still wants to use MSDOS format nowadays ?

>      "Disk formats (MBR vs. GPT)
> 
>        Here’s another very important consideration:
> 
>        If you want to do a ‘BIOS compatibility’ type installation, you
>      probably want to install to an MBR formatted disk. If you want to
>      do a UEFI native installation, you probably want to install to a
>      GPT formatted disk."

I do not agree so much with this one when it comes to install GNU/Linux. 
But it is an absolute requirement when installing Windows.

>      "A specific example
> 
>      To boil down the above: if you bought a Windows 8 or later system,
>      you almost certainly have a UEFI native install of Windows to a
>      GPT-formatted disk. This means that if you want to install another
>      OS alongside that Windows install, you almost certainly want to do
>      a UEFI-native installation of your other OS. If you don’t like all
>      this UEFI nonsense and want to go back to the good old world
>      you’re familiar with, you will, I’m afraid, have to blow away the
>      UEFI-native Windows installation, and it would be a good idea to
>      reformat the disk to MBR."

I agree with the author. If you want to keep the existing EFI Windows 
installation and have a convenient dual boot with GRUB, you'll have to 
set up your favourite distribution to boot in EFI mode. If you want to 
go back to legacy boot, including for Windows, you'll have to 
repartition the disk to MSDOS format and reinstall Windows.

> I can't reconcile that with the system here, a Windows 8→10 UEFI laptop
> and GPT disk running linux in BIOS compatibility mode (here called
> Legacy mode by Lenovo) booting from an MBR on an ATA disk:

That is not very convenient, is it ? You cannot boot Windows boot 
manager from GRUB nor you can boot GRUB from Windows boot manager and 
must select the boot mode in the UEFI firmware setup whenever you want 
to switch the operating system.

> Switching over involves going through the "BIOS Setup", reached
> by a separate button (almost recessed).

As expected.

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

#195693 — Re: UEFI/"BIOS" booting, was Re: USB Install Fails, Complains about CD-ROM

On Sun 13 May 2018 at 19:08:48 (+0200), Pascal Hambourg wrote:
> Le 13/05/2018 à 17:18, David Wright a écrit :
> >On Fri 11 May 2018 at 15:13:04 (-0500), Kent West wrote:
> >>
> >>That's good to know. I guess my source material (
> >>https://www.happyassassin.net/2014/01/25/uefi-boot-how-does-that-actually-work-then/)
> >>is wrong. Or I misunderstood it.
> >
> >While a lot of the detail on that long page might be correct, there
> >are also statements there that don't seem to agree with reality.
> 
> Most of the statements you quoted agree with my (admittedly limited)
> experience with UEFI. There is a difference between the theory
> (specifications) and the reality (implementations), and some pieces
> of software may have extra requirements beyond the sole UEFI
> specification.
> 
> >     "I really can’t recommend strongly enough that you do not attempt
> >     to mix UEFI-native and BIOS-compatible booting of
> >     permanently-installed operating systems on the same computer, and
> >     especially not on the same disk. It is a terrible terrible idea
> >     and will cause you heartache and pain. If you decide to do it,
> >     don’t come crying to me." (under "UEFI booting: background").
> 
> I would not be as much adamant as the author, but my experience says :
> it can work, but expect trouble.
> 
> Most of my early experience with UEFI boot comes from a rather old
> Intel motherboard. Beside crippled UEFI support (no UEFI boot from
> USB or SATA in AHCI mode), it had a couple of annoying requirements :
> - boot in legacy mode only if the MBR contains a partition entry
> with the boot flag set, regardless of whether the disk has a MSDOS
> or GPT partition table. This behaviour is beyond any common BIOS
> standard, but I have observed it on many other systems, mostly Dell
> and HP ;

In the case of GPT, I assume the partition entry with the boot flag set
is the protective MBR.

> - boot in EFI mode from GPT only if the protective partition entry
> in the MBR has the boot flag unset. I admit this requirement is part
> of the GPT specification, but really do not see the point in
> enforcing such a minor detail.
> 
> Anyway, these two requirements put together make it impossible to
> boot in both legacy and EFI mode from the same GPT disk with this
> motherboard. However they allow to boot in both modes from the same
> MSDOS disk. But who still wants to use MSDOS format nowadays ?

Is it impossible, then, to change the boot flag in a protective MBR?

> >     "Disk formats (MBR vs. GPT)
> >
> >       Here’s another very important consideration:
> >
> >       If you want to do a ‘BIOS compatibility’ type installation, you
> >     probably want to install to an MBR formatted disk. If you want to
> >     do a UEFI native installation, you probably want to install to a
> >     GPT formatted disk."
> 
> I do not agree so much with this one when it comes to install
> GNU/Linux. But it is an absolute requirement when installing
> Windows.

Yes, though I assume few people install Windows. It's more likely to
be pre-installed.

> >     "A specific example
> >
> >     To boil down the above: if you bought a Windows 8 or later system,
> >     you almost certainly have a UEFI native install of Windows to a
> >     GPT-formatted disk. This means that if you want to install another
> >     OS alongside that Windows install, you almost certainly want to do
> >     a UEFI-native installation of your other OS. If you don’t like all
> >     this UEFI nonsense and want to go back to the good old world
> >     you’re familiar with, you will, I’m afraid, have to blow away the
> >     UEFI-native Windows installation, and it would be a good idea to
> >     reformat the disk to MBR."
> 
> I agree with the author. If you want to keep the existing EFI
> Windows installation and have a convenient dual boot with GRUB,
> you'll have to set up your favourite distribution to boot in EFI
> mode. If you want to go back to legacy boot, including for Windows,
> you'll have to repartition the disk to MSDOS format and reinstall
> Windows.

"convenient dual boot with GRUB" moves the goalposts.

> >I can't reconcile that with the system here, a Windows 8→10 UEFI laptop
> >and GPT disk running linux in BIOS compatibility mode (here called
> >Legacy mode by Lenovo) booting from an MBR on an ATA disk:
> 
> That is not very convenient, is it ? You cannot boot Windows boot
> manager from GRUB nor you can boot GRUB from Windows boot manager
> and must select the boot mode in the UEFI firmware setup whenever
> you want to switch the operating system.

It's very convenient for me. It means I haven't had to interfere with
the way windows chooses to boot, or its configuration of the disk, at all.

> >Switching over involves going through the "BIOS Setup", reached
> >by a separate button (almost recessed).
> 
> As expected.

Not by the author, who would have me reformat the disk as MBR and then
install windows…from where exactly?

Cheers,
David.

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

#195739 — Re: UEFI/"BIOS" booting, was Re: USB Install Fails, Complains about CD-ROM

Le 14/05/2018 à 02:02, David Wright a écrit :
> On Sun 13 May 2018 at 19:08:48 (+0200), Pascal Hambourg wrote:
>>
>> Most of my early experience with UEFI boot comes from a rather old
>> Intel motherboard. Beside crippled UEFI support (no UEFI boot from
>> USB or SATA in AHCI mode), it had a couple of annoying requirements :
>> - boot in legacy mode only if the MBR contains a partition entry
>> with the boot flag set, regardless of whether the disk has a MSDOS
>> or GPT partition table. This behaviour is beyond any common BIOS
>> standard, but I have observed it on many other systems, mostly Dell
>> and HP ;
> 
> In the case of GPT, I assume the partition entry with the boot flag set
> is the protective MBR.

Yes, as the protective GPT partition entry is the only non-empty entry.

>> - boot in EFI mode from GPT only if the protective partition entry
>> in the MBR has the boot flag unset. I admit this requirement is part
>> of the GPT specification, but really do not see the point in
>> enforcing such a minor detail.
>>
>> Anyway, these two requirements put together make it impossible to
>> boot in both legacy and EFI mode from the same GPT disk with this
>> motherboard. However they allow to boot in both modes from the same
>> MSDOS disk. But who still wants to use MSDOS format nowadays ?
> 
> Is it impossible, then, to change the boot flag in a protective MBR?

Of cours not, but it is even less convenient than switching the boot 
mode in the firmware setup : boot the system, switch the boot flag, 
reboot the system...

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

#195755 — Re: UEFI/"BIOS" booting, was Re: USB Install Fails, Complains about CD-ROM

On Mon 14 May 2018 at 23:29:43 (+0200), Pascal Hambourg wrote:
> Le 14/05/2018 à 02:02, David Wright a écrit :
> >On Sun 13 May 2018 at 19:08:48 (+0200), Pascal Hambourg wrote:
> >>
> >>Most of my early experience with UEFI boot comes from a rather old
> >>Intel motherboard. Beside crippled UEFI support (no UEFI boot from
> >>USB or SATA in AHCI mode), it had a couple of annoying requirements :
> >>- boot in legacy mode only if the MBR contains a partition entry
> >>with the boot flag set, regardless of whether the disk has a MSDOS
> >>or GPT partition table. This behaviour is beyond any common BIOS
> >>standard, but I have observed it on many other systems, mostly Dell
> >>and HP ;
> >
> >In the case of GPT, I assume the partition entry with the boot flag set
> >is the protective MBR.
> 
> Yes, as the protective GPT partition entry is the only non-empty entry.
> 
> >>- boot in EFI mode from GPT only if the protective partition entry
> >>in the MBR has the boot flag unset. I admit this requirement is part
> >>of the GPT specification, but really do not see the point in
> >>enforcing such a minor detail.
> >>
> >>Anyway, these two requirements put together make it impossible to
> >>boot in both legacy and EFI mode from the same GPT disk with this
> >>motherboard. However they allow to boot in both modes from the same
> >>MSDOS disk. But who still wants to use MSDOS format nowadays ?
> >
> >Is it impossible, then, to change the boot flag in a protective MBR?
> 
> Of cours not, but it is even less convenient than switching the boot
> mode in the firmware setup : boot the system, switch the boot flag,
> reboot the system...

Sorry, I thought impossible meant not possible. I agree that booting
up a system (that happens to be set to the wrong state) just to change
the boot flag and then reboot is a lot less convenient than the
process I use (which always lets you boot into the correct system
first time, and only requires action when you want to change over).

But the fact that you've experienced a crippled mobo does not IMHO
mean that some of the scenarios you could use on less crippled systems
shouldn't be discussed—nay, be treated as near impossible—in a web
page that's meant to be throwing light on the matter. As written, the
author just pours special magic sauce around, whatever that is.

Cheers,
David.

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

#195709 — Re: UEFI/"BIOS" booting, was Re: USB Install Fails, Complains about CD-ROM

Pascal Hambourg wrote:
...
> I agree with the author. If you want to keep the existing EFI Windows 
> installation and have a convenient dual boot with GRUB, you'll have to 
> set up your favourite distribution to boot in EFI mode. If you want to 
> go back to legacy boot, including for Windows, you'll have to 
> repartition the disk to MSDOS format and reinstall Windows.

  all i know is that if your bios doesn't boot in
UEFI mode and you don't know anything about what this
means you can end up installing Debian without UEFI
support and then it can be rather fun to get it back.

  i managed to have grub do an install to a stable
partition without UEFI and i messed up the testing
setup i had.  it took me some while to figure out
what went wrong and how to fix it.  if you don't
really understand grub rescue commands and there
isn't a working system you can use to connect and
find help for the commands you need to enter it's
very frustrating.

  the Debian UEFI pages helped a great deal but 
there were other things i had to figure out coming in
cold to UEFI.

  how to create a /boot/efi partition, what goes in 
it, mounting it, clearing and putting in new efibootmgr 
entries, etc.

  refind was useful and at least it does what i expect
it to do.  grub, i dislike how it assumed things i
didn't want to do.  alas, i didn't know how different
UEFI was from bios mode.

  i still haven't redone my efibootmgr entries but
refind doesn't care, i can create custom entries in
that config file and they work that is all i really
need at this point.


  songbird

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

#195716 — Re: UEFI/"BIOS" booting, was Re: USB Install Fails, Complains about CD-ROM

On 2018-05-14 01:21, songbird wrote:
> Pascal Hambourg wrote:
> ...
>> I agree with the author. If you want to keep the existing EFI Windows 
>> installation and have a convenient dual boot with GRUB, you'll have to 
>> set up your favourite distribution to boot in EFI mode. If you want to 
>> go back to legacy boot, including for Windows, you'll have to 
>> repartition the disk to MSDOS format and reinstall Windows.
>   all i know is that if your bios doesn't boot in
> UEFI mode and you don't know anything about what this
> means you can end up installing Debian without UEFI
> support and then it can be rather fun to get it back.
>
>   i managed to have grub do an install to a stable
> partition without UEFI and i messed up the testing
> setup i had.  it took me some while to figure out
> what went wrong and how to fix it.  if you don't
> really understand grub rescue commands and there
> isn't a working system you can use to connect and
> find help for the commands you need to enter it's
> very frustrating.
>
>   the Debian UEFI pages helped a great deal but 
> there were other things i had to figure out coming in
> cold to UEFI.
>
>   how to create a /boot/efi partition, what goes in 
> it, mounting it, clearing and putting in new efibootmgr 
> entries, etc.
>
>   refind was useful and at least it does what i expect
> it to do.  grub, i dislike how it assumed things i
> didn't want to do.  alas, i didn't know how different
> UEFI was from bios mode.
>
>   i still haven't redone my efibootmgr entries but
> refind doesn't care, i can create custom entries in
> that config file and they work that is all i really
> need at this point.
>
>
>   songbird
>
Hmm, do you have any useful references?

I got a new Dell computer, shrunk the existing partitions down and
successfully installed grub2 and got a windows10/Linux multi boot using
grub. Then later I tried to upgrade my Linux and soon found that I was
getting error messages about grub not being able to find necessary
features on the boot device.

I tried to rebuild it with a clean install of Windows 10, reasoning that
if I could get it back to the original configuration, I could repeat the
original exercise. But alas, no, it remains stubbornly unable to install
grub2 alongside the windows bootloader. I got it to a state where I
could use the BIOS POST boot screen to choose a boot option, but this
wasn't the original successful arrangement where grub offered me the
Linux/windows loader choice.

I gave up, wiped windows and went through with a clean Linux install. I
don't really want windows that much, but it irks me that I haven't been
able to fathom out how to return to the original state in which it was
shipped. Your words hint at many things I became vaguely aware of but
totally failed to grasp. The other posters to this thread have at least
reassured me that it isn't easy or trivial to get right.

-- 
Chris

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

#195723 — Re: UEFI/"BIOS" booting, was Re: USB Install Fails, Complains about CD-ROM

On Mon 14 May 2018 at 13:28:56 (+0100), Chris Ramsden wrote:
> On 2018-05-14 01:21, songbird wrote:
> > Pascal Hambourg wrote:
> > ...
> >> I agree with the author. If you want to keep the existing EFI Windows 
> >> installation and have a convenient dual boot with GRUB, you'll have to 
> >> set up your favourite distribution to boot in EFI mode. If you want to 
> >> go back to legacy boot, including for Windows, you'll have to 
> >> repartition the disk to MSDOS format and reinstall Windows.
> >   all i know is that if your bios doesn't boot in
> > UEFI mode and you don't know anything about what this
> > means you can end up installing Debian without UEFI
> > support and then it can be rather fun to get it back.
> >
> >   i managed to have grub do an install to a stable
> > partition without UEFI and i messed up the testing
> > setup i had.  it took me some while to figure out
> > what went wrong and how to fix it.  if you don't
> > really understand grub rescue commands and there
> > isn't a working system you can use to connect and
> > find help for the commands you need to enter it's
> > very frustrating.
> >
> >   the Debian UEFI pages helped a great deal but 
> > there were other things i had to figure out coming in
> > cold to UEFI.
> >
> >   how to create a /boot/efi partition, what goes in 
> > it, mounting it, clearing and putting in new efibootmgr 
> > entries, etc.
> >
> >   refind was useful and at least it does what i expect
> > it to do.  grub, i dislike how it assumed things i
> > didn't want to do.  alas, i didn't know how different
> > UEFI was from bios mode.
> >
> >   i still haven't redone my efibootmgr entries but
> > refind doesn't care, i can create custom entries in
> > that config file and they work that is all i really
> > need at this point.
> >
> >
> >   songbird
> >
> Hmm, do you have any useful references?
> 
> I got a new Dell computer, shrunk the existing partitions down and
> successfully installed grub2 and got a windows10/Linux multi boot using
> grub. Then later I tried to upgrade my Linux and soon found that I was
> getting error messages about grub not being able to find necessary
> features on the boot device.
> 
> I tried to rebuild it with a clean install of Windows 10, reasoning that
> if I could get it back to the original configuration, I could repeat the
> original exercise. But alas, no, it remains stubbornly unable to install
> grub2 alongside the windows bootloader. I got it to a state where I
> could use the BIOS POST boot screen to choose a boot option, but this
> wasn't the original successful arrangement where grub offered me the
> Linux/windows loader choice.

Would I be correct in thinking that the BIOS POST boot screen is
what you get when you hit F12 sufficiently quickly after switch-on?
So are you choosing between UEFI and Legacy (compatibility) mode.
(I would like to know how Dell handles what I've been reporting on
with this Lenovo.)

> I gave up, wiped windows and went through with a clean Linux install. I
> don't really want windows that much, but it irks me that I haven't been
> able to fathom out how to return to the original state in which it was
> shipped. Your words hint at many things I became vaguely aware of but
> totally failed to grasp. The other posters to this thread have at least
> reassured me that it isn't easy or trivial to get right.

This is the scenario I was trying to avoid. As far as windows was
concerned, my mantra was Failure Is Not An Option.

Cheers,
David.

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

#195728 — Re: UEFI/"BIOS" booting, was Re: USB Install Fails, Complains about CD-ROM

On 2018-05-14 14:55, David Wright wrote:
> Would I be correct in thinking that the BIOS POST boot screen is
> what you get when you hit F12 sufficiently quickly after switch-on?
> So are you choosing between UEFI and Legacy (compatibility) mode.
> (I would like to know how Dell handles what I've been reporting on
> with this Lenovo.)
Yes. F12. Then you get to choose between the various bootable devices
and partitions. But this is BIOS or firmware (not Grub) doing it for you.
>> I gave up, wiped windows and went through with a clean Linux install. I
>> don't really want windows that much, but it irks me that I haven't been
>> able to fathom out how to return to the original state in which it was
>> shipped. Your words hint at many things I became vaguely aware of but
>> totally failed to grasp. The other posters to this thread have at least
>> reassured me that it isn't easy or trivial to get right.
> This is the scenario I was trying to avoid. As far as windows was
> concerned, my mantra was Failure Is Not An Option.
>
> Cheers,
> David.
-- 
Chris

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

#195751 — Re: UEFI/"BIOS" booting, was Re: USB Install Fails, Complains about CD-ROM

Chris Ramsden wrote:
> On 2018-05-14 01:21, songbird wrote:
>> Pascal Hambourg wrote:
>> ...
>>> I agree with the author. If you want to keep the existing EFI Windows 
>>> installation and have a convenient dual boot with GRUB, you'll have to 
>>> set up your favourite distribution to boot in EFI mode. If you want to 
>>> go back to legacy boot, including for Windows, you'll have to 
>>> repartition the disk to MSDOS format and reinstall Windows.
>>   all i know is that if your bios doesn't boot in
>> UEFI mode and you don't know anything about what this
>> means you can end up installing Debian without UEFI
>> support and then it can be rather fun to get it back.
>>
>>   i managed to have grub do an install to a stable
>> partition without UEFI and i messed up the testing
>> setup i had.  it took me some while to figure out
>> what went wrong and how to fix it.  if you don't
>> really understand grub rescue commands and there
>> isn't a working system you can use to connect and
>> find help for the commands you need to enter it's
>> very frustrating.
>>
>>   the Debian UEFI pages helped a great deal but 
>> there were other things i had to figure out coming in
>> cold to UEFI.
>>
>>   how to create a /boot/efi partition, what goes in 
>> it, mounting it, clearing and putting in new efibootmgr 
>> entries, etc.
>>
>>   refind was useful and at least it does what i expect
>> it to do.  grub, i dislike how it assumed things i
>> didn't want to do.  alas, i didn't know how different
>> UEFI was from bios mode.
>>
>>   i still haven't redone my efibootmgr entries but
>> refind doesn't care, i can create custom entries in
>> that config file and they work that is all i really
>> need at this point.
>>
>>
>>   songbird
>>
> Hmm, do you have any useful references?

  https://wiki.debian.org/UEFI
  https://wiki.debian.org/GrubEFIReinstall

  and

  http://www.rodsbooks.com/refind/


> I got a new Dell computer, shrunk the existing partitions down and
> successfully installed grub2 and got a windows10/Linux multi boot using
> grub. Then later I tried to upgrade my Linux and soon found that I was
> getting error messages about grub not being able to find necessary
> features on the boot device.

  yep.  do not install stable after testing is all i
can recommend at this point (based upon my experience)
and of course keep a working/verified netinst image 
handy.


> I tried to rebuild it with a clean install of Windows 10, reasoning that
> if I could get it back to the original configuration, I could repeat the
> original exercise. But alas, no, it remains stubbornly unable to install
> grub2 alongside the windows bootloader. I got it to a state where I
> could use the BIOS POST boot screen to choose a boot option, but this
> wasn't the original successful arrangement where grub offered me the
> Linux/windows loader choice.
>
> I gave up, wiped windows and went through with a clean Linux install. I
> don't really want windows that much, but it irks me that I haven't been
> able to fathom out how to return to the original state in which it was
> shipped. Your words hint at many things I became vaguely aware of but
> totally failed to grasp. The other posters to this thread have at least
> reassured me that it isn't easy or trivial to get right.

  i was rather surprised by it all but i'd been living
in the dark ages for years anyways.


  songbird

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

#195718 — Re: UEFI/"BIOS" booting, was Re: USB Install Fails, Complains about CD-ROM

> That said, there are other statements that are odd:

Not sure what you find odd about them:

>     "I really can’t recommend strongly enough that you do not attempt
>     to mix UEFI-native and BIOS-compatible booting of
>     permanently-installed operating systems on the same computer, and
>     especially not on the same disk. It is a terrible terrible idea
>     and will cause you heartache and pain. If you decide to do it,
>     don’t come crying to me." (under "UEFI booting: background").

Here he's just saying that there's a good chance you'll encounter
difficulties if you try that, and indeed in my experience the behavior
of such a config will depend on undocumented details.

>     "Disk formats (MBR vs. GPT)
>
>       Here’s another very important consideration:
>
>       If you want to do a ‘BIOS compatibility’ type installation, you
>     probably want to install to an MBR formatted disk. If you want to
>     do a UEFI native installation, you probably want to install to a
>     GPT formatted disk."

Same here (basically for the same reason: the behavior of the firmware
and OS when faced with a disk that has both a GPT and an MBR partitions
is largely unspecified and will vary depending on your system).

> I can't reconcile that with the system here, a Windows 8→10 UEFI laptop
> and GPT disk running linux in BIOS compatibility mode (here called
> Legacy mode by Lenovo) booting from an MBR on an ATA disk:

It's easy to reconcile: he doesn't say your setup is impossible or can't
work, he just recommends not to do that because you may encounter
unexpected difficulties.  E.g. in theory an upgrade to your firmware or
to one of your OSes could break it, tho in practice you're probably OK
at least until you move that setup to another machine with
a different firmware.


        Stefan

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

#195726 — Re: UEFI/"BIOS" booting, was Re: USB Install Fails, Complains about CD-ROM

On Mon 14 May 2018 at 09:14:23 (-0400), Stefan Monnier wrote:
> > That said, there are other statements that are odd:
> 
> Not sure what you find odd about them:
> 
> >     "I really can’t recommend strongly enough that you do not attempt
> >     to mix UEFI-native and BIOS-compatible booting of
> >     permanently-installed operating systems on the same computer, and
> >     especially not on the same disk. It is a terrible terrible idea
> >     and will cause you heartache and pain. If you decide to do it,
> >     don’t come crying to me." (under "UEFI booting: background").
> 
> Here he's just saying that there's a good chance you'll encounter
> difficulties if you try that, and indeed in my experience the behavior
> of such a config will depend on undocumented details.

Yes, documentation of firmware is almost unknown in my experience
(since probably 30 years ago). That's why I took the least invasive
method that I could. Using a UEFI/UEFI approach means that you have
to explore the manufacturer's undocumented implementation of UEFI.
Plenty of horror stories there, including Pascal's.

> >     "Disk formats (MBR vs. GPT)
> >
> >       Here’s another very important consideration:
> >
> >       If you want to do a ‘BIOS compatibility’ type installation, you
> >     probably want to install to an MBR formatted disk. If you want to
> >     do a UEFI native installation, you probably want to install to a
> >     GPT formatted disk."
> 
> Same here (basically for the same reason: the behavior of the firmware
> and OS when faced with a disk that has both a GPT and an MBR partitions
> is largely unspecified and will vary depending on your system).

Eh? I've yet to see a GPT disk that didn't have a protective MBR.
I thought that's the reason why GPT starts at block 1 and not
block 0: an MBR was designed into GPT from the start (no pun intended).

> > I can't reconcile that with the system here, a Windows 8→10 UEFI laptop
> > and GPT disk running linux in BIOS compatibility mode (here called
> > Legacy mode by Lenovo) booting from an MBR on an ATA disk:
> 
> It's easy to reconcile: he doesn't say your setup is impossible or can't
> work, he just recommends not to do that because you may encounter
> unexpected difficulties.  E.g. in theory an upgrade to your firmware or
> to one of your OSes could break it, tho in practice you're probably OK
> at least until you move that setup to another machine with
> a different firmware.

Not sure what you mean here. It's a laptop: nowt's going nowhere.

But in a page as long as this one is, I think the author is rather
dismissive of using Legacy mode at all. Perhaps the clue is here:

    "Don’t do UEFI-native installs to MBR-formatted disks, or BIOS
    compatibility installs to GPT-formatted disks (an exception to the
    latter is if your disk is, IIRC, 2.2+TB in size, because the MBR
    format can’t handle disks that big – if you want to do a BIOS
    compatibility install to a disk that big, you’re kinda stuck with
    the BIOS+GPT combination, which works but is a bit wonky and
    involves the infamous ‘BIOS Boot partition’ you may recall from
    Fedora 17).

I haven't been able to find anything infamous about the BIOS Boot
partition but it sounds as if the author had a bad experience at
sometime in the past which has affected their ability to view the
topic objectively.

Cheers,
David.

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

#195730 — Re: UEFI/"BIOS" booting

Hi,

Stefan Monnier wrote:
> > the behavior of the firmware
> > and OS when faced with a disk that has both a GPT and an MBR partitions
> > is largely unspecified and will vary depending on your system).

David Wright wrote:
> I've yet to see a GPT disk that didn't have a protective MBR.
> I thought that's the reason why GPT starts at block 1 and not
> block 0: an MBR was designed into GPT from the start (no pun intended).

Indeed. The byte format of GPT is specified in UEFI. The Protective MBR is
the magic number of GPT. This implies that one cannot have a valid GPT and
MBR partitions with payload on the same disk.

But the code area of the Protective MBR can well be used to boot via BIOS.
EFI explicitely specifies that these bytes shall be ignored by EFI.
And as said previously, BIOS does not expect any partitions. Such expectation
could be in the MBR code, though. Most probably such code won't work with
GPT because of no bootable/active MBR partition.

============================================================================
Quotes from UEFI 2.4:

  5 GUID Partition Table (GPT) Disk Layout
  [...]

  5.2 LBA 0 Format
  LBA 0 (i.e. the first logical block) of the hard disk contains either
  • a legacy Master Boot Record (MBR) (see Section 5.2.1)
  • or a protective MBR (see Section 5.2.2 [actually 5.2.3]).

  5.2.1 Legacy Master Boot Record (MBR)
  A legacy MBR may be located at LBA 0 (i.e. the first logical block) of
  the disk if it is not using the GPT disk layout (i.e., if it is using
  the MBR disk layout).
  [...]

  5.2.2 OS Types
  Unique types [of MBR partitions] defined by this specification (other
  values are not defined by this specification):
  • 0xEF (i.e., UEFI System Partition) defines a UEFI system partition.
  • 0xEE (i.e., GPT Protective) is used by a protective MBR (see 5.2.2)
    to define a fake partition covering the entire disk.

  5.2.3 Protective MBR
  A Protective MBR may be located at LBA 0 (i.e. the first logical block)
  of the disk if it is using the GPT disk layout. The Protective MBR
  precedes the GUID Partition Table Header to maintain compatibility with
  existing tools that do not understand GPT partition structures.

  Table 15. Protective MBR
  Mnemonic             | Byte   | Byte   | Content
                       | Offset | Length |
  ---------------------------------------------------------------
  Boot Code            | 0      | 440    | Unused by UEFI systems.
  Unique MBR Signature | 440    | 4      | Unused. Set to zero.
  Unknown              | 444    | 2      | Unused. Set to zero.
  Partition Record     | 446    | 16*4   | [partition table]
  Signature            | 510    | 2      | Set to 0xAA55 [...]

The MBR partition table is described in table 15 as
  Array of four MBR partition records. Contains:
  • one partition record as defined Table 16; and
  • three partition records each set to zero.

Table 16 then states

  Protective MBR Partition Record protecting the entire disk
  [...]
  Mnemonic     |Byte  |Byte  | Description
               |Offset|Length|
  ----------------------------------------------------------------
  BootIndicator| 0    | 1    | Set to 0x00 to indicate a non-bootable
               |      |      | partition. [...]
  StartingCHS  | 1    | 3    | Set to 0x000200 [...]
  OSType       | 4    | 1    | Set to 0xEE (i.e., GPT Protective)
  EndingCHS    | 5    | 3    | Set to the CHS address of the last logical
               |      |      | block on the disk. Set to 0xFFFFFF if it is
               |      |      | not possible to represent the value in this
               |      |      | field.
  StartingLBA  | 8    | 4    | Set to 0x00000001 (i.e., the LBA of the GPT
               |      |      | Partition Header).
  SizeInLBA    | 12   | 4    | Set to the size of the disk minus one. Set to
               |      |      | 0xFFFFFFFF if the size of the disk is too
               |      |      | large to be represented in this field.

============================================================================


Have a nice day :)

Thomas

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

#195740 — Re: UEFI/"BIOS" booting

Le 14/05/2018 à 17:50, Thomas Schmitt a écrit :
> 
> And as said previously, BIOS does not expect any partitions.

In theory. All it should expect is the MBR signature 0xAA55. But as said 
previously, experience taught me that many BIOS implementations wrongly 
expect an MBR partition entry with the boot flag set in order to boot 
from the disk.

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

#195759 — Re: UEFI/"BIOS" booting

Hi,

i wrote:
> > And as said previously, BIOS does not expect any partitions.

Pascal Hambourg wrote:
> experience taught me that many BIOS implementations wrongly
> expect an MBR partition entry with the boot flag set in order to boot from
> the disk.

You are right (and those firmwares are wrong).

I had to introduce a special option in xorriso in order to cater for this:
  https://savannah.gnu.org/bugs/?46716
  http://lists.gnu.org/archive/html/bug-xorriso/2015-12/threads.html
with the final conclusion described in
  https://lists.gnu.org/archive/html/bug-grub/2016-03/msg00087.html

Summary:
- Boot flag on MBR partition of type 0xEE is bad on several EFI
  implementations.
- No MBR partition with boot flag is bad on some very few BIOS
  implementations.
- Compromise is to set the boot flag on a dummy partition of type 0x00.
  This is barely UEFI-compliant because the specs say that a partition of
  type 0x00 shall be regarded as non-existent.

Debian isohybrids for BIOS do not have this problem because MBR partition 1
has the boot flag set, anyway. But grub-mkrescue ISOs might be in need of
xorrisofs option
  --mbr-force-bootable
if the owner suffers from one of those rare BIOSes.
(It was decided that from the view of GRUB this is a workaround for a
 specs violation by the firmware. iSo --mbr-force-bootable is not applied
 by default.)


Have a nice day :)

Thomas

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

#195778 — Re: UEFI/"BIOS" booting

Le 15/05/2018 à 08:51, Thomas Schmitt a écrit :
> 
> Summary:
> - Boot flag on MBR partition of type 0xEE is bad on several EFI
>    implementations.
> - No MBR partition with boot flag is bad on some very few BIOS
>    implementations.

Not so few in my experience.

> - Compromise is to set the boot flag on a dummy partition of type 0x00.
>    This is barely UEFI-compliant because the specs say that a partition of
>    type 0x00 shall be regarded as non-existent.

I never thought about this. It may be a workaround with my old UEFI 
motherboard. Thanks for the tip, I will try it and report.

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

#195821 — Re: UEFI/"BIOS" booting

Le 16/05/2018 à 00:10, Pascal Hambourg a écrit :
> Le 15/05/2018 à 08:51, Thomas Schmitt a écrit :
>>
>> Summary:
>> - Boot flag on MBR partition of type 0xEE is bad on several EFI
>>    implementations.
>> - No MBR partition with boot flag is bad on some very few BIOS
>>    implementations.
> 
> Not so few in my experience.
> 
>> - Compromise is to set the boot flag on a dummy partition of type 0x00.
>>    This is barely UEFI-compliant because the specs say that a 
>> partition of
>>    type 0x00 shall be regarded as non-existent.
> 
> I never thought about this. It may be a workaround with my old UEFI 
> motherboard. Thanks for the tip, I will try it and report.

The trick indeed worked with my old motherboard ! Good to know, thanks.

However there are some caveats :
- I had to use the old fdisk version from Wheezy because newer versions 
and other partition editors would not allow to set the boot flag on an 
empty partition entry.
- parted silently erased the flag when I used it to edit the GPT table. 
I expected it, because parted had already reset a hybrid MBR I had set 
up with gdisk to a standard protective MBR.

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

#195835 — Re: UEFI/"BIOS" booting

Hi,

i wrote:
> > - Compromise is to set the boot flag on a dummy partition of type 0x00.
> >    This is barely UEFI-compliant because the specs say that a partition of
> >    type 0x00 shall be regarded as non-existent.

Pascal Hambourg wrote:
> - I had to use the old fdisk version from Wheezy because newer versions and
> other partition editors would not allow to set the boot flag on an empty
> partition entry.

You never know what kind of user-friendly abstraction a partition editor will
apply. So portable and future-safe is only the manipulation on byte level.

The layout of the MBR partition table can be learned from
  https://en.wikipedia.org/wiki/Master_boot_record#Sector_layout
  "Structure of a classical generic MBR" 
  https://en.wikipedia.org/wiki/Master_boot_record#Partition_table_entries

Partition entries are 16 bytes of size and number 1 begins at offset 446.
The boot/active flag sits in the first byte of the partition entry.
The value of this byte is either 0 or 128 (= 0x80 in hex). We want 128.
Further we need to write values for partition start and size.

  # Choose target disk or image file
  disk=/dev/sdX

  # Make a backup of your MBR by
  backup_path="$HOME"/mbr_backup_of_"$(basename "$disk")"
  dd if="$disk" bs=512 count=1 conv=notrunc of="$backup_path"

  # Restore the backup to $disk would be done like this:
  #   dd if="$backup_path" bs=512 count=1 conv=notrunc of="$disk"
  # If $disk is the system disk: Have a rescue system ready which can
  # access the backup file and the system disk.

  # Choose partition and compute start of its entry
  partno=2
  offset=$(expr 430 + "$partno" '*' 16)

  # First set the partition entry to all zeros. So we can just hop over
  # those bytes which shall stay 0. This spares us the plight to handle
  # 0-bytes by shell commands.
  dd if=/dev/zero bs=1 count=16 conv=notrunc seek="$offset" of="$disk"

  # The boot/active flag
  # (The gesture $'\xHH' is described in man bash section QUOTING.)
  echo -n $'\x80' | dd bs=1 count=1 conv=notrunc seek="$offset" of="$disk"

  # Start C/H/S = 0/0/1
  offset=$(expr "$offset" + 2)
  echo -n $'\x01' | dd bs=1 count=1 conv=notrunc seek="$offset" of="$disk"

  # End C/H/S = 0/0/1
  offset=$(expr "$offset" + 4)
  echo -n $'\x01' | dd bs=1 count=1 conv=notrunc seek="$offset" of="$disk"

  # Sector count = 1 (start LBA is 0)
  offset=$(expr "$offset" + 6)
  echo -n $'\x01' | dd bs=1 count=1 conv=notrunc seek="$offset" of="$disk"

The task would also be a good execercise for Programmer's First C Program.


Have a nice day :)

Thomas

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

#195731 — Re: UEFI/"BIOS" booting, was Re: USB Install Fails, Complains about CD-ROM

> Yes, documentation of firmware is almost unknown in my experience
> (since probably 30 years ago). That's why I took the least invasive

It's documented to the extent that it says "implements UEFI" and that
UEFI is documented.

>> Same here (basically for the same reason: the behavior of the firmware
>> and OS when faced with a disk that has both a GPT and an MBR partitions
>> is largely unspecified and will vary depending on your system).
> Eh? I've yet to see a GPT disk that didn't have a protective MBR.

Exactly: what happens when a GPT disk has a real MBR (rather than a
protective MBR) is "you're on your own".

>> It's easy to reconcile: he doesn't say your setup is impossible or can't
>> work, he just recommends not to do that because you may encounter
>> unexpected difficulties.  E.g. in theory an upgrade to your firmware or
>> to one of your OSes could break it, tho in practice you're probably OK
>> at least until you move that setup to another machine with
>> a different firmware.
> Not sure what you mean here. It's a laptop: nowt's going nowhere.

Take the disk out, put it in another machine (laptop or desktop, it
doesn't matter).


        Stefan

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

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

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

csiph-web