Syslinux - Jul 2014 - Syslinux 6.03pre18 cannot boot kernel from btrfs

Hi

I keep trying syslinux on my testing machine with BIOS and btrfs on
root partition. I use syslinux 6.03pre18, kernel 3.15.4.

A number of btrfs related bugs has been fixed in syslinux 6.03
recently, but I still see one more. Syslinux stops booting my kernel
from btrfs partition. The partition itself is fine - I can mount it
from other kernel booted from USB. The partition superblock is fine,
no errors in dmesg.

The problem happened to me several times recently. It appears after a
kernel update/initrd generation. To fix the problem I tried to
reinstall syslinux, kernel, regenerate initrd and after several
retries it helped. I do not know exact algorithm how to fix this
problem though.

I enabled syslinux debug and it says "Invalid boot magic". Thus the
problem either corrupted vmlinuz or, most likely, syslinux does not
read btrfs filesystem correctly.

I mounted my root partition and here is filefrag information about
/boot/* files [2]. Note to physical file offsets for vmlinuz and
initramfs, it is about 10^12 bytes and corresponds to 280G on
/dev/sda1. This number makes sense as my sda harddrive is 500G.

syslinux also reports numbers, see [1]. It says "EDD...." and I
believe the third field is disk offset, right? If so the number looks
suspiciously large, it is ~10^17. Could it be that syslinux has some
kind of integer overflow in calculating disk offsets? How syslinux (or
bios?) is able to load anything with such big offset?

Is there any additional information I can provide? What is the easiest
way to check that my vmlinuz file has correct "boot magic number"? I
would like to check that this file is not corrupted.

[1] http://bit.ly/1sJ61yb
[2] http://bit.ly/1m2eBCG

Hi

On Fri, Jul 11, 2014 at 6:35 PM, Anatol Pomozov
<anatol.pomozov at gmail.com> wrote:
> Hi
>
> I keep trying syslinux on my testing machine with BIOS and btrfs on
> root partition. I use syslinux 6.03pre18, kernel 3.15.4.
>
> A number of btrfs related bugs has been fixed in syslinux 6.03
> recently, but I still see one more. Syslinux stops booting my kernel
> from btrfs partition. The partition itself is fine - I can mount it
> from other kernel booted from USB. The partition superblock is fine,
> no errors in dmesg.
>
> The problem happened to me several times recently. It appears after a
> kernel update/initrd generation. To fix the problem I tried to
> reinstall syslinux, kernel, regenerate initrd and after several
> retries it helped. I do not know exact algorithm how to fix this
> problem though.
>
> I enabled syslinux debug and it says "Invalid boot magic". Thus
the
> problem either corrupted vmlinuz or, most likely, syslinux does not
> read btrfs filesystem correctly.
>
> I mounted my root partition and here is filefrag information about
> /boot/* files [2]. Note to physical file offsets for vmlinuz and
> initramfs, it is about 10^12 bytes and corresponds to 280G on
> /dev/sda1. This number makes sense as my sda harddrive is 500G.
>
> syslinux also reports numbers, see [1]. It says "EDD...." and I
> believe the third field is disk offset, right? If so the number looks
> suspiciously large, it is ~10^17. Could it be that syslinux has some
> kind of integer overflow in calculating disk offsets? How syslinux (or
> bios?) is able to load anything with such big offset?
>
> Is there any additional information I can provide? What is the easiest
> way to check that my vmlinuz file has correct "boot magic
number"? I
> would like to check that this file is not corrupted.
>
> [1] http://bit.ly/1sJ61yb
> [2] http://bit.ly/1m2eBCG

I was able to restore my machine by moving /boot folder to a separate
ext4 partition at the beginning of the disk.

I have quite old PC BIOS machine with 500GB disk. I've had one large
partition where root and boot lived. When I initially installed the
system it booted fine, but after kernel reinstall it got broken as
described above. If I understand correctly syslinux uses BIOS
functionality to get access to the disk and BIOS cannot access it
above some limit (what is the limit btw, is it 1024 cylinder i.e.
8GB?). And I guess reinstall process put my initrd/kernel above this
limit and syslinux was not able to load it. Does it sound right?

Does it mean that one always need to put /boot to a separate partition
at the beginning of the disk?

Also I believe grub does not have this '/boot' location restriction.
Does it mean that their stage1.5 blob contains sata drivers so
stage1.5 uses sata directly instead of BIOS EDD?

> Hi
> 
> On Fri, Jul 11, 2014 at 6:35 PM, Anatol Pomozov
> <anatol.pomozov at gmail.com> wrote:
> > Hi
> >
> > I keep trying syslinux on my testing machine with BIOS and btrfs on
> > root partition. I use syslinux 6.03pre18, kernel 3.15.4.
> >
> > A number of btrfs related bugs has been fixed in syslinux 6.03
> > recently, but I still see one more. Syslinux stops booting my kernel
> > from btrfs partition. The partition itself is fine - I can mount it
> > from other kernel booted from USB. The partition superblock is fine,
> > no errors in dmesg.
> >
> > The problem happened to me several times recently. It appears after a
> > kernel update/initrd generation. To fix the problem I tried to
> > reinstall syslinux, kernel, regenerate initrd and after several
> > retries it helped. I do not know exact algorithm how to fix this
> > problem though.
> >
> > I enabled syslinux debug and it says "Invalid boot magic".
Thus the
> > problem either corrupted vmlinuz or, most likely, syslinux does not
> > read btrfs filesystem correctly.
> >
> > I mounted my root partition and here is filefrag information about
> > /boot/* files [2]. Note to physical file offsets for vmlinuz and
> > initramfs, it is about 10^12 bytes and corresponds to 280G on
> > /dev/sda1. This number makes sense as my sda harddrive is 500G.
> >
> > syslinux also reports numbers, see [1]. It says "EDD...."
and I
> > believe the third field is disk offset, right? If so the number looks
> > suspiciously large, it is ~10^17. Could it be that syslinux has some
> > kind of integer overflow in calculating disk offsets? How syslinux (or
> > bios?) is able to load anything with such big offset?
> >
> > Is there any additional information I can provide? What is the easiest
> > way to check that my vmlinuz file has correct "boot magic
number"? I
> > would like to check that this file is not corrupted.
> >
> > [1] http://bit.ly/1sJ61yb
> > [2] http://bit.ly/1m2eBCG
> 
> 
> I was able to restore my machine by moving /boot folder to a separate
> ext4 partition at the beginning of the disk.
> 
> I have quite old PC BIOS machine with 500GB disk. I've had one large
> partition where root and boot lived. When I initially installed the
> system it booted fine, but after kernel reinstall it got broken as
> described above. If I understand correctly syslinux uses BIOS
> functionality to get access to the disk and BIOS cannot access it
> above some limit (what is the limit btw, is it 1024 cylinder i.e.
> 8GB?). And I guess reinstall process put my initrd/kernel above this
> limit and syslinux was not able to load it. Does it sound right?
> 
> Does it mean that one always need to put /boot to a separate partition
> at the beginning of the disk?
> 
> Also I believe grub does not have this '/boot' location
restriction.
> Does it mean that their stage1.5 blob contains sata drivers so
> stage1.5 uses sata directly instead of BIOS EDD?
> 
 
I doubt your "old" BIOS doesn't support LBA48 (if I understand 
correctly, it supports SATA already).
I am going to guess that you also performed your tests with an 
updated mbr.bin.
I am also going to guess that, during your tests, you (re)installed 
Syslinux manually (not with scripts).
We should also discard the possibility of some other issue. For 
instance, if _some specific_ kernels are failing with other 
bootloaders after an update, then there is a chance that some update 
could be messing with Syslinux too, right?

You seem to be suggesting that Syslinux is not really installed in 
EDD mode, or that the EDD mode is somehow failing (or buggy) when 
Syslinux is installed in Btrfs.

Regards,
Ady.

On 07/11/2014 06:35 PM, Anatol Pomozov wrote:
> 
> syslinux also reports numbers, see [1]. It says "EDD...." and I
> believe the third field is disk offset, right? If so the number looks
> suspiciously large, it is ~10^17. Could it be that syslinux has some
> kind of integer overflow in calculating disk offsets? How syslinux (or
> bios?) is able to load anything with such big offset?
> 
Most likely it is already lost at that time: it read some garbage from
the disk and is interpreting it as a disk address.  An interesting
thing, though, is that it is exactly one bit from a small number: in
hexadecimal 36028797018973762 is 0x80000000002642, so I'm wondering if
there is a bit we should mask which we don't.

	-hpa