Hi all,
I was using grub2 for booting Archlinux x86_64 in my GPT
Internal HDD (/dev/sda) then I switched to syslinux/extlinux. It was
working fine but suddenly it staring showing "Boot Error" message on
screen. I googled for a solution and tried all syslinux versions from
4.04-pre4 down to 4.03-stable but non of them worked. I don't know
what suddenly changed caused this error. This is the gdisk output of
/dev/sda
[keshav_pr at keshav-laptop ~]$ sgdisk -p /dev/sda
Disk /dev/sda: 625142448 sectors, 298.1 GiB
Logical sector size: 512 bytes
Disk identifier (GUID): XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
Partition table holds up to 128 entries
First usable sector is 34, last usable sector is 625142414
Partitions will be aligned on 1-sector boundaries
Total free space is 18 sectors (9.0 KiB)
Number Start (sector) End (sector) Size Code Name
1 40 401623 196.1 MiB EF00
EFI_SYSTEM_PART -> fat32 - /boot/efi - efi system
partition
2 401624 483543 40.0 MiB EF02
BIOS_BOOT_GRUB2 -> bios_grub for grub2
3 483544 2488472 979.0 MiB FFFF Tianocore_EDK_DUET_UEFI
4 17260760 17832149 279.0 MiB FFFF EDK_UEFI64
5 17832150 112197959 45.0 GiB 0700
MS_WINDOWS_7_x64_RTM -> Windows 7 x64 Pro - ntfs - boot using uefi
so syslinux is not involved in any chainloading
6 112197960 206563769 45.0 GiB 0700 DATA_3
7 206563770 258179514 24.6 GiB FFFF LINUX_x64
-> ext4 - Archlinux x86_64 /
8 258179515 258998714 400.0 MiB FFFF
Linux_Boot_GRUB2_BIOS -> Marked GPT attribute Legacy BIOS
Bootable - ext4 - Archlinux x86_64 /boot
9 258998720 290455199 15.0 GiB FFFF Unknown
10 290455200 457370549 79.6 GiB 0700 DATA_1
11 457370550 625137344 80.0 GiB 0700 DATA_2
12 625137352 625142414 2.5 MiB FFFF Unknown
13 2488473 17260759 7.0 GiB 8200 Linux swap
I tried installing using all these combinations but none of them work
sudo extlinux --{install/upgrade} /boot/{syslinux/extlinux}
I switched back to grub2 for now but I want to know what is the exact
problem that has cropped up suddenly and how to solve it. Just FYI,
grub2 does not use the boot sector in /boot partition, it stores fs
modules in core.img in the bios_grub partition.
I tried "chainloader (hd0,8)+1" in grub2 terminal but the same
"Boot
Error" message came. So this might rule out gptmbr.bin problem. Thanks
in advance for any help.
Regards.
Keshav
Good day Keshav, If you install gptmbr.bin on the MBR and re-install Syslinux to whichever GPT partition is marked as bootable and if you reboot and make sure the CAPS LOCK LED is on before the BIOS tries to boot the HDD (or if you hold shift down for the whole boot), do you get the Syslinux "boot:" prompt? Somewhat similarly, if you modify your Syslinux config-file, are you changes reflected in the booting behaviour? What I'm wondering is if you are getting as far as loading Syslinux or not. If you are chaining to a partition and that partition's boot sector is the producer of the "Boot error" message, then perhaps that partition needs some boot code installed to it (such as Syslinux). You might be able to determine which partition is being invoked: dd if=/dev/sda8 of=bootsect.bin count=1 strings bootsect.bin | grep "Boot error" (Repeat for each other suspect partition.) I'd suggest using the debug-build of chain.c32 to dump what it thinks the partition table is, but I'm not sure you are actually loading Syslinux. Also, this might seem a silly question, but: Do you have a USB storage device plugged into the computer somewhere, perhaps BIOS might be booting it, or confusing matters? If you can track down the partition that "says" "Boot error", that might be a start towards understanding. - Shao Miller
On Wed, Jan 19, 2011 at 13:21, H. Peter Anvin <hpa at zytor.com> wrote:> On 01/18/2011 11:45 PM, KESHAV P.R. wrote: >> >> /usr/lib/syslinux/gptmbr.bin >> >> syslinux-4.03 in Archlinux x86_64 (installed from distro's package - >> not compiled my be) >> >> gdisk output >> >> GPT fdisk (gdisk) version 0.6.14 >> >> Partition table scan: >> ? MBR: protective >> ? BSD: not present >> ? APM: not present >> ? GPT: present >> >> Found valid GPT with protective MBR; using GPT. >> Disk /dev/sda: 625142448 sectors, 298.1 GiB >> Logical sector size: 512 bytes >> Disk identifier (GUID): XXXXXXXXXXXXXXXXXXXXXXXX >> Partition table holds up to 128 entries >> First usable sector is 34, last usable sector is 625142414 >> Partitions will be aligned on 2-sector boundaries >> Total free space is 33792359 sectors (16.1 GiB) >> >> Number ?Start (sector) ? ?End (sector) ?Size ? ? ? Code ?Name >> ? ?1 ? ? ? ? ? ?2048 ? ? ? ? ?821247 ? 400.0 MiB ? EF00 >> EFI_SYSTEM_PART ? ? ? ? ? ? ? ? -> EFISYS partitions for efi >> bootloaders - FAT32 >> ? ?2 ? ? ? ? ?821248 ? ? ? ? ?823295 ? 1024.0 KiB ?EF02 >> BIOS_BOOT_GRUB2 ? ? ? ? ? ? ? -> Grub2 is still installed - just needs >> boot.img mbr to be installed, currently unused >> ? ?3 ? ? ? ? ?823296 ? ? ? ? 1642495 ? 400.0 MiB ? FFFF >> ARCHLINUX_x86_64_BOOT ? ? ?-> /boot in ext4 - Legacy Boot GPT attibute >> set - syslinux 4.03 booting properly - ldlinux.sys immutable attribute >> set >> ? ?4 ? ? ? ? 1642496 ? ? ? ?16322559 ? 7.0 GiB ? ? 8200 ?ARCHLINUX_x86_64_SWAP >> ? ?5 ? ? ? ?17832150 ? ? ? 112197959 ? 45.0 GiB ? ?0700 ?MS_WINDOWS_7_x86_64_PRO >> ? ?6 ? ? ? 112197960 ? ? ? 206563769 ? 45.0 GiB ? ?0700 ?DATA_3 >> ? ?7 ? ? ? 206563770 ? ? ? 258179514 ? 24.6 GiB ? ?FFFF >> ARCHLINUX_x86_64_ROOT >> ? ?8 ? ? ? 290455200 ? ? ? 457370549 ? 79.6 GiB ? ?0700 ?DATA_1 >> ? ?9 ? ? ? 457370550 ? ? ? 625137344 ? 80.0 GiB ? ?0700 ?DATA_2 >> >> >> Any other info required? >> > > I presume you're booting straight from the MBR, not chainloading via > Grub2, correct? ? Thank you *so much* for the info... I will look into > it as soon as I can. > > ? ? ? ?-hpa >I have grub2 simply as standby, in case syslinux does not work (once 4.04 is released), I will overwrite gptmbr.bin in the mbr 440 byte region with grub2's boot.img to boot into grub2. Right now syslinux 4.03 is booting fine without any problems (setup in /boot/syslinux or (/dev/sda3)/syslinux ). 4.04's extlinux installer created the problems for me. No chainloading from grub2. Thanks. Any info on syslinux efi bootloader (mainly for 64-bit efi firmware like the ones in Sandy Bridge Asus and MSI mobos or in virtualbox etc.). - Keshav
Michal Soltys
2011-Feb-21 08:34 UTC
[syslinux] [PATCH] core/diskboot.inc: fix handover info sanity checks
W dniu 21.02.2011 02:07, H. Peter Anvin pisze:> On 02/20/2011 04:17 PM, Michal Soltys wrote: >> Signed-off-by: Michal Soltys<soltys at ziu.info> >> --- >> core/diskboot.inc | 6 +++--- >> 1 files changed, 3 insertions(+), 3 deletions(-) >> >> diff --git a/core/diskboot.inc b/core/diskboot.inc >> index 7c02066..3d48dfd 100644 >> --- a/core/diskboot.inc >> +++ b/core/diskboot.inc >> @@ -182,12 +182,12 @@ floppy: >> harddisk: >> mov dx,[di-76-10] ; Original DS >> mov si,[di-76-12] ; Original SI >> - shr si,4 >> - jz .no_partition ; SI == 0 -> assume no partition >> + shl dx,4 >> add dx,si >> + jz .no_partition ; DS:SI == 0 -> assume no partition >> cmp dx,1024 ; DS:SI< 1K (inside the IVT)? >> jb .no_partition >> - cmp dx,PartInfo>> 4 ; DS:SI in overwritten memory? >> + cmp dx,PartInfo ; DS:SI in overwritten memory? >> jae .no_partition >> test byte [di-76],7Fh ; Sanity check: "active flag" should >> jnz .no_partition ; be 00 or 80 > > No, this might overflow dx. > > -hpa >Indeed, but SI doesn't have to be divisable by 16. E.g. typical handover address (if that's what DS:SI is here) such as 0:7beh . DX while it can overflow - considering addresses where handover is placed, should be safe. With check against overflow, how about: test dh, 0xf0h jnz .no_partition ; overflow shl dx, 4 add dx, si jc .no_partition ; overflow, DS:SI must be less than 64KiB cmp dx,1024 ; DS:SI< 1K (inside the IVT)? jb .no_partition cmp dx, PartInfo-75 jae .no_partition ; copied area (76 bytes) overlaps with PartInfo ... This would guarantee: DS:SI < 65536 DS:SI >= 1024 DS:SI + 75 < PartInfo 3rd implies 1st, but we have to check against overflow.