> I am aware of that. It doesn't change the fact that the system does
not
> boot a Fedora 21 partition with syslinux 6.03 and does boot it successfully
> when using the bootloader from 4.05.
>
The mismatch version of c32 modules is relevant in some cases because the error
message is not so clear / evident (especially considering that c32 modules do
not
contain any version info). Before launching the kernel, your config is already
trying to load menu.c32. In theory, you are correct in that it doesn't seem
to be
important in this particular case. I would tend to think that, in practice, we
should simplify as much as possible the environment so to narrow down the
(source
of the) problem, and "going by the book" (e.g. not mixing versions of
Syslinux-related files) is always recommended when troubleshooting.
If we could just catch the problem so easily we wouldn't need
troubleshooting :). I
would suggest commenting out the UI and the TIMEOUT directives. Since you have
no
DEFAULT directive, there might be some kind of warning message when getting to
the
Syslinux boot prompt (after commenting out the UI directive and rebooting), but
that's not really important in this case.
Then you could launch the respective label from the CLI. Additional
simplifications
for troubleshooting could be:
_ Using only lower-case for labels ("linux1" instead of
"Linux1").
_ Using simpler file names for labels, kernel files and initrd files (instead of
using multiple dots, hyphen symbols, long names,...). I tend to use basic
"8.3" for
troubleshooting (certainly no spaces, no "-", no
"1.2.3.c-test_moretext", only
English basic characters...).
_ Using the "LINUX" keyword instead of the generic "KERNEL"
keyword ("LINUX
mykernel" instead of "KERNEL mykernel").
_ Using short paths with short directory names (up to 11 basic english
characters,
no dots, no symbols, no spaces) (you are already using the root "/" of
the
partition for kernel and initrd files, and "/boot/extlinux/" for
Syslinux-related
files, including the c32 modules in the latter, so you should be OK in this
regard).
_ Avoiding (sym)links for troubleshooting.
_ Simplifying as much as possible the extlinux.conf (e.g. 2 simple entries, no
timers, no c32 modules being called from it, no "left-over"
directives, no global
directives, always using labels, CLI only...).
There are some additional possibilities, depending on the type of problem. For
instance, sometimes the problem is between the kernel and the hardware, or the
configuration settings when the kernel was built (e.g. relocatable, or not), so
testing the same hardware with different kernels could be useful in some cases.
As already mentioned, updating the firmware (BIOS) is part of troubleshooting.
There are more possible steps; let's hope we don't need them.
> > > If I then reboot the system, it is able to boot into either
Fedora 19 or
> > > Fedora 21 without any problems. It is true that I do get some
minor
> > > complaints:
> > >
> > > SYSLINUX 4.05 2011-12-09 Copyright (C) 1994-2011 H. Peter
Anvin et al
> > > menu.c32: not a COM32R image
> > > boot:
> >
> > The reason being a mismatch version between the c32 modules and the
version of the
> > bootloader.
>
> Yes, of course, but that's not a significant problem. The system still
boots.
See prior comments above.
>
> > > I don't think it's a mismatch issue. I have followed the
same scripted
> > > procedure many times without any problems.
> >
> > But until now you were updating versions of Syslinux up to 4.xx. The
mismatch
> > version problems were less evident then (more "tolerance"
was "accepted"), but
> > since Syslinux v.5+, the mismatch version problem is much more
relevant and even a
> > minor mismatch version (e.g. other package claiming to use the same
version) might
> > cause problems.
>
> I guess I wasn't clear. I have followed the same procedure for 22
different
> Fedora 19 to Fedora 21 upgrades. In each case, I went from 4.05 to 6.03.
> Only this one machine is misbehaving. It is presumably, therefore, related
> to a hardware issue.
You were clear; I just thought you were referring to prior updates in that
paragraph, from even older versions of Fedora, when the Syslinux version was
even
older than v4.05.
>
> > Anyway, the serial console is one immediate point for review (please
post your
> > entire extlinux.conf).
>
> I posted it above. Why is the serial console an "immediate point for
review"?
> Almost all of my systems use serial consoles, although most are using
> IPMI over serial redirection. This one uses a physical serial connection,
> since the baseboard does not have IPMI 2.0 support.
Well, you were an important part of our previous discussion about the SERIAL
console, which triggered the recent patch for octal and hex values. That was not
the first time the serial console was showing some problem. My hunch (calling it
that way because I cannot prove it in a consistent replicable way since I lack
the
knowledge and skills to do it) is that we will eventually find more issues with
the
serial console / output / directive (and anything related to them).
>
> > The BIOS version might matter because Syslinux v.6.xx could be
triggering a problem
> > in buggy BIOS versions, whereas v.4.xx was not triggering the same
problem. We have
> > seen this before; after the BIOS update the same version of Syslinux
might succeed.
>
> That's a fair point. I will try to upgrade the BIOS next week.
>
> > > The completely vanilla 6.03 setup fails to boot. The problem is
that there
> > > is no error message, so it's very hard to troubleshoot.
> >
> > You mean "vanilla" as the Syslinux-related packages from
Fedora 21, not upstream
> > Syslinux pre-built binaries downloaded from kernel.org, which _might_
(or might
> > not) give a different result. Again, please do not forget to update
the c32 files
> > too from the same origin of the bootloader you are actually installing
in the VBR.
> > Mixing files from one package with others from another one (even if
they are both
> > the same "version") is unwanted for troubleshooting.
>
> Correct. I am using the Fedora package. If a BIOS upgrade doesn't fix
the
> problem, I will try the official syslinux binaries. I will also try grub2.
>
Any chance you could test other kernels too? This would be another
troubleshooting
possibility.
> > There might be some commit after v.6.03 that might help too, but
let's start with
> > the easier steps.
>
> Thanks for your suggestions.
>
> -Andy
Thank you for the feedback.
Regards,
Ady.
> _______________________________________________
> Syslinux mailing list
> Submissions to Syslinux at zytor.com
> Unsubscribe or set options at:
> http://www.zytor.com/mailman/listinfo/syslinux
>