[ resend - fixed list address ]

In the course of diagnosing a strange problem that seems to happen
only on some anaconda-driven upgrades, I found that -- unlike the
normal boot process -- there is nothing in anaconda that clears
/var/lock/subsys.

(Note - this applies to the Fedora 9 based OLPC XS. Perhaps this is
known and fixed?)

This completely fools the `service <svc> condrestart` lines in %post,
and can lead to various hard to debug problems. In my case, I am
seeing corrupt databases with ejabberd *(which has an admittedly
brittle db scheme).

To test this, touch /var/lock/subsys/foo; sync ; power off the machine
and run an anaconda upgrade. You'll see that while packages are being
installed, the file remains there. If that had been
'/var/lock/subsys/ejabberd' you'd have a corrupt DB. Don't feel left
out though, if you want one, I can give you mine :-)

This may sound weird -- don't you expect a clean shutdown before an
upgrade? -- but in OLPC School Servers in the field get quite a bit of
rough handling. The ones I work with sure get most of their poweroffs
via the "powercable yanking" scheme, so I get to see these problems
here before they happen in the field.

IOWs reliability in the face of strange conditions _is_ desirable, and
important.

*- Is this known, or fixed?
*- Is there a reasonable workaround? kickstart is not used for
upgrades, even if it was, %pre happens to early, %post happens too
late.

Would the right place to clear (or complain about!) /var/lock/subsys
would be upgrade.py: upgradeMountFilesystems()?

cheers,




m
--
*martin.langhoff@gmail.com
*martin@laptop.org -- School Server Architect
*- ask interesting questions
*- don't get distracted with shiny stuff *- working code first
*- http://wiki.laptop.org/go/User:Martinlanghoff

_______________________________________________
Anaconda-devel-list mailing list
Anaconda-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/anaconda-devel-list

On Thu, Mar 19, 2009 at 4:04 AM, Jeremy Katz <katzj@redhat.com> wrote:
>> Would the right place to clear (or complain about!) /var/lock/subsys
>> would be upgrade.py: upgradeMountFilesystems()?
>
> We definitely tend to expect that you've shut down cleanly and there are
> a few other things that could trip up if you haven't. *But that's where

In earlier times, when ext2 ruled the roost, an unclean shutdown would
have prevented an anaconda upgrade, just because the fs was dirty and
anaconda checks for that.

In these days of ext3 with automatic and fast journal recovery that
(if trivial) happens transparently on mount... well, other "unclean
shutdown" conditions turn up. Like this one, I gues...

> we'd want it. *And if you want to throw together a patch, I'm all for
> applying it. *Just a heads-up that there may be other dragons lurking

Will try to craft one to check and complain about dirty
/var/lock/subsys -- taking it as a hint that other dragons may be
about...

cheers,


m
--
martin.langhoff@gmail.com
martin@laptop.org -- School Server Architect
- ask interesting questions
- don't get distracted with shiny stuff - working code first
- http://wiki.laptop.org/go/User:Martinlanghoff

_______________________________________________
Anaconda-devel-list mailing list
Anaconda-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/anaconda-devel-list