On 6 Jul 2023 at 15:17, lacsaP Patatetom wrote: From: lacsaP Patatetom <[email protected]> Date sent: Thu, 6 Jul 2023 15:17:14 +0200 Subject: Re: simple message under BIOS/CSM/LEGACY To: [email protected]
> Le lun. 21 nov. 2022 à 10:22, Pascal <[email protected]> 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 <[email protected]> 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 <[email protected]> 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:[email protected] mailto:[email protected] Guam - Where America's Day Begins G4L Disk Imaging Project maintainer http://sourceforge.net/projects/g4l/ +------------------------------------------------------------+
