[ 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@xxxxxxxxx martin@xxxxxxxxxx -- 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@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/anaconda-devel-list
