[syslinux] Stumped by extlinux After OS Upgrade

John.Florian at dart.biz John.Florian at dart.biz
Mon Nov 1 11:16:43 PDT 2010


> From: Gene Cumm <gene.cumm at gmail.com>
 
> My comments are inline but I'd suggest you follow my advice at the end
> of my email as a first thing to try.

First off, thanks for the reply!

I agree, so that's where I'm heading first and have already ran into 
difficulty -- detailed at the end.  I will also respond inline to you 
various questions just to be thorough.


> > I've developed a specialized spin of Fedora that runs off 
CompactFlash.
> > The spin is actually produced by the livecd-tools package and is then
> > transferred to the CF card -- which has been formatted with ext3 -- 
using
> > livecd-tools' livecd-iso-to-disk.  I have hundreds of embedded systems
> > running this spin.  Every now and then we need to upgrade these 
systems
> > and needless to say swapping CF cards is labor expensive.  Thus I
> > developed an in-place upgrade which essentially downloads a new 
squashfs
> > image and syslinux directory, both of which are obtained from a newer
> > spin.  These downloads do not overwrite those of the running system; 
they
> > get a name suffix of ".new".  Then a special initrd is booted into 
which
> > looks for the new stuff and puts them in place after renaming the
> > originals with an ".old" suffix.  Another reboot occurs and the new 
spin
> > is then running.  Currently I'm trying to effect an upgrade that will 
take
> > these systems from a Fedora 10 base to Fedora 13.
> >
> > Now the fun part and my problem.  Before shipping CF cards out with 
F10 on
> > them, I went through rigorous functional testing and one step was to
> > verify that future upgrades would be successful as best that I could.
> > Since F10 was the latest Fedora at the time it was only a pseudo-test 
that
> > tried to upgrade the F10 spin to an alternate, distinguishable F10 
spin. I
> > made that work, but found it necessary to run "extlinux --update
> > /sysroot/syslinux" after swapping in the replacement squashfs image 
and
> > syslinux directory.  I don't recall exactly why it was necessary, but
> > suffice it to say it solved the problem and I could reboot the system 
and
> > be running the alternate F10 image.
> 
> Which version(s) of EXTLINUX?


Fedora 13 is using syslinux-3.84 whereas Fedora 10 has syslinux-3.61.


>  If you're attempting to use an old
> version of EXTLINUX to patch the extlinux.sys of a new version, it
> probably won't work the way you want.


I was afraid I'd hear that.


> I think "extlinux --update"
> also refreshes the VBR (Volume boot record), which contains a pointer
> to the extlinux.sys file.
> 
> I normally take the approach that if the core
> binary(extlinux.sys/ldlinux.sys) is moved (including the directory it
> sits in), renamed, or modified, it should be redone with --update for
> maximum reliability.  I can't say for certain if it's needed.


I wish it were not necessary, but given the behavior I suspect it must. 
extlinux doesn't understand file systems like, say grub, does it?  Please 
correct me if I'm wrong, but it's my guess that extlinux behaves more like 
lilo than grub.


>  After
> your initrd shuffles the directories around, it might be wise to
> re-run your extlinux update (from the F13 installer, of course).
> 
> > Now I'm doing it for real but instead of that alternate F10 spin, the
> > upgrade would bring F13 into place.  Everything works smoothly -- the
> > extlinux update runs without error and has the expected message 
indicating
> > "/sysroot/syslinux is device /dev/sda1" -- right up until that final
> > reboot which should take us into F13.  What happens?  Well, I get a
> > "boot:" prompt for a second or two and then it disappears and then 
repeats
> > endlessly.
> 
> Strange to say the least.  Is this "second or two" possibly your
> TIMEOUT in your configuration?


Well, the timeout in the old (F10) extlinux.conf is 10 and the new (F13) 
is 30.  So if those are in 1/10s, I'd guess no.  I really wish all boot 
loaders would include their name and version in their prompt.  When trying 
to unravel chain-loading "boot:" doesn't tell one much.  I don't think 
there is any chain-loading going on here, but the Fedora Live images are 
originally intended for a bootable CD that then gets transferred to the CF 
card.  I know extlinux is here for sure; isolinux too?  I don't think so, 
but a detailed prompt would help alleviate such concerns.


>  Also, what does your configuration
> look like?  Do your kernel, initrd, and squashfs sit in another
> directory?


/mnt/live/syslinux
/mnt/live/syslinux/vmlinuz0
/mnt/live/syslinux/memtest
/mnt/live/syslinux/isolinux.bin
/mnt/live/syslinux/vesamenu.c32
/mnt/live/syslinux/extlinux.conf
/mnt/live/syslinux/splash.jpg
/mnt/live/syslinux/extlinux.sys
/mnt/live/syslinux/boot.cat
/mnt/live/syslinux/initrd0.img
/mnt/live/LiveOS
/mnt/live/LiveOS/osmin.img
/mnt/live/LiveOS/squashfs.img

Here /mnt/live is the root file system of the CF card.  The initrd0.img 
has a script to loop mount squashfs.img and find the regular kernel 
within.

 
> If you're running the F10 extlinux from your squashfs, it's probably
> not accomplishing much.
> 
> > I've tried a variety of things and have learned much, but not enough 
to
> > understand the problem and have become rather perplexed.  Inspecting 
the
> > CF card on my desktop system, I find what I'd expect.  I can make 
notes of
> > kernel parameters as found in extlinux.conf, return the card to the
> > device, power up and provide those same parameters at the "boot:" 
prompt
> > and the device will boot into F13 just fine.  Once there I can 
manually
> > run "extlinux --update /mnt/live/syslinux" and the system will reboot 
fine
> > thereafter w/o intervention.  (The path changes, but is effectively 
the
> > same directory, it's just mounted differently between the initrd and 
the
> > regular running system.)  I have also manually run the "extlinux 
--update"
> > from my desktop system (also F13) and found that also will "repair" 
the CF
> > card to good working order.
> 
> Which version loaded?  Which config did it load?  It might be the old
> version loading the old config still but I don't understand why it
> just reboots.


I'm not sure I understand the Qs.  Are you asking what extlinux version 
loads after I've manually made the repair?  I don't know how to ask the 
"boot:" prompt to tell me anything useful here.  For example, if I respond 
with "help" all I get back is "Could not find kernel image: help" and then 
the perpetual two second timeout before it reboots unless I try typing 
something else before the timeout expires.

 
> > My hunch is that either extlinux cannot find it's conf file or maybe 
the
> > path difference between initrd and regular somehow does matter. 
 Neither
> > seems likely though since my F10-F10 test upgrade worked.  That makes 
me
> > wonder about using "extlinux --update" from F10 on a syslinux 
directory
> > that was already populated by a F13 system and some compatibility 
issue.
> > I've noticed that my manually run "extlinux --update" makes 
extlinux.sys
> > grow a bit too as if the run from the initrd may have left something 
out,
> > but I really know nothing about that file (yet).  Lastly, there's been 
a
> > change in the "root=" kernel parameter between F10 and F13 that maybe 
is
> > at play here.  In F10, this read as "root=UUID=blablabla" but now 
reads as
> > "root=live:UUID=blablabla".  When I provide the kernel parameters 
manually
> > at the "boot:" prompt I must use the F13 form for a fully successful 
boot,
> > but even if I use the F10 format it get's much further than on its own 
--
> > it fails around the pivot_root point.  Maybe the "live" bit is 
confusing
> > the syslinux package in the initrd of F10?
> 
> If it didn't find a configuration file, it would have complained
> stating so.  The messages when there is no configuration file found
> have improved through the versions.


That alone is good to know.  Do you know if 3.61 would be that 
informative?


 
> Also, --update always installs a fresh copy of the core binary.  This
> "growth" is either replacing the F10 version with F13 like you wanted
> initially or effectively just patching it with the needed data.


That was my guess, but good to have confirmed.


> Shuffle the directories to their final destination then run extlinux
> from F13.  This probably can be done on the live system (assuming no
> library issues) or from your initrd as your live system shouldn't have
> any of those files open.


Well that seems like the sanest thing to try next, but it isn't going to 
be easy.  I've gotten myself a shell from within the initrd and had 
intended to loop mount the new squashfs image so that I could run extlinux 
from there, but the mount fails from the F10-based initrd with "SQUASHFS 
error: Major/Minor mismatch, trying to mount newer 4.0 filesystem".  I 
seem to recall that Fedora did update SquashFS in this time frame.  I 
guess this means I'm going to need to identify and extract the various 
syslinux bits from an F13 system and provide them to the initrd outside of 
the squashfs.img.

--
John Florian



More information about the Syslinux mailing list