Re: simple message under BIOS/CSM/LEGACY

[lacsaP Patatetom]

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)