[syslinux] Stumped by extlinux After OS Upgrade

[Gene Cumm]

On Thu, Oct 14, 2010 at 10:31,  <John.Florian at dart.biz> wrote:
> Hello fellow syslinux/extlinux users!  Please forgive the long post, but I
> believe my problem warrants the background info to understand the issue.

My comments are inline but I'd suggest you follow my advice at the end
of my email as a first thing to try.

> 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?  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 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.  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?  Also, what does your configuration
look like?  Do your kernel, initrd, and squashfs sit in another
directory?

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.

> 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.

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.

> Any ideas would be greatly appreciated!
>
> --
> John Florian

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.

-- 
-Gene