Re: simple message under BIOS/CSM/LEGACY

[Michael D. Setzer II]

On 6 Jul 2023 at 15:17, lacsaP Patatetom wrote:

From:   lacsaP Patatetom <patatetom@gmail.com>
Date sent:      Thu, 6 Jul 2023 15:17:14 +0200
Subject:        Re: simple message under BIOS/CSM/LEGACY
To:     help-grub@gnu.org

> Le lun. 21 nov. 2022 à 10:22, Pascal <patatetom@gmail.com> a écrit :
>
> > hi,
> >
> > I'm coming back on this subject (eg. display a short message inviting the
> > user to switch the PC to EFI/UEFI) after some field feedback.
> >
> > here is the simple code now used :
> >
> > ; nasm nobioscsm.asm -f bin -o nobioscsm
> > bits 16
> > org 0x7C00
> > start:
> >     sti
> >     cld
> >     mov si, msg
> >     mov ah, 0x0E
> >     .loop lodsb
> >     or al, al
> >     jz halt
> >     int 0x10
> >     jmp .loop
> > halt:
> >     hlt
> >     jmp halt
> > msg:
> >     db 0x0D, 0x0A, 'Boot with BIOS/CSM/LEGACY no longer supported : reboot
> > with EFI/UEFI', 0
> >
> > and here is what appears on the screen (Lenovo Thinkcenter M720) instead
> > of the expected message :
> >
> > [image: clover.jpg]
> >
> >
> > the problem occurs mainly with the Lenovo brand (Thinkcentre M70
> > <https://www.google.com/search?q=Lenovo+Thinkcenter+M70>, Thinkcentre M720
> > <https://www.google.com/search?q=Lenovo+Thinkcenter+M720>), but not only
> > according to my information.
> >
> > changing the partitioning to BIOS/Intel/MBR (instead of GPT) does not
> > change the problem : this last point makes me strongly believe that the
> > problem comes from the code...
> >
> > regards, lacsaP.
> >
> > Le mer. 3 août 2022 à 23:50, Pascal <patatetom@gmail.com> a écrit :
> >
> >> thanks for the track of the second active partition (as Ubuntu does
> >> according to exchanges on the syslinux mailing list).
> >> I'll try it, but I'm wondering if I'm not going to abandon GPT
> >> partitioning in favor of DOS partitioning which remains fully operational
> >> under UEFI...
> >>
> >> Le mer. 3 août 2022 à 20:25, Pascal Hambourg <pascal@plouf.fr.eu.org> a
> >> écrit :
> >>
> >>> Le 03/08/2022 à 16:11, Pascal a écrit :
> >>> > *this is python biting its tail ;-)*
> >>> >
> >>> > here is what I plan to test :
> >>> > leave the protective partition in place (1), mark it as active (2) and
> >>> > change its first sector to zero (3).
> >>> >
> >>> > 1) its absence seems to be a problem (at least with qemu/ovmf),
> >>>
> >>> The GPT scheme is usually not recognized without a protective partition.
> >>>
> >>> > 2) gdisk does not activate it by default,
> >>>
> >>> As expected. Setting the boot flag on the protective partition is
> >>> against the EFI specification.
> >>>
> >>> Also, some UEFI firmware refuse to boot in EFI mode if the protective
> >>> partition has the boot flag set. Setting the boot flag on another (even
> >>> empty) partition entry has given good results with both legacy and EFI
> >>> boot.
> >>>
> >>> > the only point that seems contentious to me is whether a partition can
> >>> have
> >>> > its first sector set to zero ?
> >>>
> >>> In the MBR/DOS partition scheme, it should not because the first sector
> >>> is reserved for the MBR (but in Sun/BSD disklabel, partition 'c' starts
> >>> at sector 0 and covers the whole drive). But Debian installation images
> >>> for x86 are set up this way :
> >>>
> >>> Device Boot Start     End Sectors  Size Id Type
> >>> sdb1   *        0 1320959 1320960  645M  0 Empty
> >>> sdb2         4288   13343    9056  4,4M ef EFI (FAT-12/16/32)
> >>>
> >>>
> >>> > does the BIOS check this kind of thing ?
> >>>
> >>> Not in my experience, but I haven't used the Debian installer with all
> >>> existing firmware.
> >>>
> >>>
> hi,
>
> a little feedback on this subject we broached last year.
>
> I think I've identified the problem, which is linked to the workstation's
> UEFI, which "jams" when the GPT is "malformed".
> so, the problem has nothing to do with the little piece of code designed to
> display the warning...
>
> the USB media is initially "burned" with a small disk image in GPT format :
> the GPT defined in this small disk image is no longer valid for this USB
> media once the disk image has been dropped onto it (for example, the backup
> copy expected at the end of the USB media is not there or is not the right
> one).
>
> disk image
> [[GPT#1][P1 NTFS][P2 ESP][GPT#2]]
> USB media
> [[GPT#1][P1 NTFS][P2 ESP][GPT#2]             ]
> - or -
> [[GPT#1][P1 NTFS][P2 ESP][GPT#2]      [OLD#2]]
>
> the same USB media "initialized" (this initialization, performed in
> initramfs at first boot, consists in repartitioning the USB media to occupy
> all its space) on a second workstation that does not pose this problem,
> then no longer poses a problem on the first workstation.
>
> USB media initialized
> [[GPT#1][P1 NTFS:::::::::::::][P2 ESP][GPT#2]]
>
> the repartitioning operation "corrects" the GPT and the recalcitrant
> workstation is no longer recalcitrant following this correction.
>
> I hope I've made my explanations clear.
>
> regards, lacsaP.
>
> (ps : I still don't have any recalcitrant workstation available)
>

Don't know if this would apply to this.
I create a 64M image file that has GPT disk and contains both a
regular grub4dos boot and a grub4dos-efi boot to load files.
Copy the image to a flash using dd and the GPT has the problem
mentioned.
Use this to correct it.
echo -e "Fix" | parted -l ---pretend-input-tty

Believe that looking at flash with gparted also prompts to fix it,
but the parted -l is much faster.

Perhaps has nothing to do, but thought worth mentioning.



+------------------------------------------------------------+
 Michael D. Setzer II - Computer Science Instructor (Retired)
 mailto:mikes@guam.net
 mailto:msetzerii@gmail.com
 Guam - Where America's Day Begins
 G4L Disk Imaging Project maintainer
 http://sourceforge.net/projects/g4l/
+------------------------------------------------------------+