Hard reboot after X fail


Forum and blog member aarf was reporting on failure of X after upgrading Tahr 6.0 to 6.0.5.

I was testing the mechanisms for when X has failed, and discovered some problems.

First bootup
The first time that you boot a new installation, QuickSetup runs after the X desktop has started. if X is not working however, you won't see this application, so if you press the computer's Reset button (if it has one) or hold down the Power on/off button (usually for about 4 seconds), the computer will power-off, then you can restart it, and the Xorg Wizard will automatically run.

Except that the Xorg Wizard might not run. The problem is that QuickSetup (script /usr/sbin/quicksetup) writes to /var/local/quick-setup-test-success, but if this file has not flushed to the drive when the Power button causes a hard-shutdown, the file is lost.

All puppies have this problem, but I don't know if any of the variants/forks have addressed it. I did in Quirky, by placing a 'sync' immediately after writing that file in quicksetup. This caused a problem in Tahr 6.0.5, however, a very noticeable delay when booting off a USB2 stick before the QuickSetup window appears.

I don't want to flush just the one file, want to flush everything, so have now changed it to "sync &" to run as a separate process.

Subsequent hard-reboot
With subsequent bootups, there is a similar mechanism to handle hard-shutdowns. This is by file /root/.XLOADED, which is created in /usr/bin/xwin. If there is a hard reboot, xwin will see that X did not exit properly, and will popup a text-mode dialog asking if want to exit to commandline (and maybe run xorgwizard) or continue to startup X.

This may have the same problem with /root/.XLOADED not being flushed before the hard-power-down occurs. In this case, I put "fsync /root/.XLOADED" into xwin.

Tahr 6.0.6 will have these tweaks.


Comments:

f2fs   Posted on 17 Feb 2014, 21:38 by BarryK
It may be that I am experiencing these problems now, when they didn't seem to be an issue with earlier puppies, because of the f2fs Flash filesystem. It probably has very "lazy write", to keep everything in RAM as much as possible.