Re: simple message under BIOS/CSM/LEGACY

[lacsaP Patatetom]

Le ven. 7 juil. 2023 à 09:50, lacsaP Patatetom <patatetom@gmail.com> a
écrit :

> Le jeu. 6 juil. 2023 à 16:20, Michael D. Setzer II <mikes@guam.net> a
> écrit :
>
>> 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/
>> +------------------------------------------------------------+
>>
>>
>>
>>
> thanks for the feedback.
>
> would you know of a similar command under Windows that could fix the GPT ?
> with a native Windows tool if possible (diskpart KO, cmdlet KO, what
> else...) ?
> or even with a small third-party console tool ?
>
> I use this script (https://github.com/patatetom/PowerShellBurner) to put
> my disk image on the USB media : I'd just have to add a few commands at the
> end to update the GPT...
>
> regards, lacsaP.
>

hi,

I found "gdisk for Windows" (https://sourceforge.net/projects/gptfdisk/)
which allows me to adjust/correct/rectify the GPT partition table.
this little line added to the powershell script does the job :
Write-Output "w`ny`ny" | & .\gdisk.exe \\.\physicaldrive$Selected 1>$null
2>$null

regards, lacsaP.