Le ven. 7 juil. 2023 à 09:50, lacsaP Patatetom <[email protected]> a écrit :
> Le jeu. 6 juil. 2023 à 16:20, Michael D. Setzer II <[email protected]> a > écrit : > >> 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/ >> +------------------------------------------------------------+ >> >> >> >> > 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.
