'pupdesk.flg' redesigned

Some testers of latest pups were concerned about the temporary mounted partition at first boot.

I have redesigned how pupdesk.flg gets created, so as to remove that concern.

Firstly, it needs to be understood that 'pupdesk.flg' is an ephemeral thing, it only gets created once, for PUPMODE=5, and only exists until a working desktop is reached. It never gets created after that.

At bootup, the init script (in the initrd) scans partitions looking for Puppy files, that is, the main *puppy*.sfs, a save-file, and a zdrv*.sfs file. Even when booting off CD, the HD and USB drives are scanned.
Escept when booting off USB, only the USB drive is scanned.

I have edited 'init' to find a suitable writable partition during the scan, giving preference to a Linux f.s., and if PUPMODE=5 then create a zero-byte 'pupdesk.flg' on it.

After bootup, the desktop starts up, hopefully, and QuickSetup (/usr/sbin/quicksetup) is run -- if the user clicks the OK button, then, again only for PUPMODE=5, the partition with 'pupdesk.flg' is mounted, the file deleted, the partition immediately unmounted.

If the desktop fails and the user has to do a hard reboot/shut, by pressing reset/power button or even unplugging, at next bootup, the 'init' script will discover the pre-existing 'pupdesk.flg' and will force the pup to run the Xorg Wizard rather than attempt to go straight to desktop again.

Note, once a save-file is created, or running a full-HD installation, the older mechanism using file /root/.XLOADED is used, see script /usr/bin/xwin. This also enables going to the commandline after a forced reboot. Puppy has had this feature for a long time, it was originally proposed by forum member jay_rey.

Another note, there is another file 'fsckme.flg', which is created in the "home" partition (where the save-file is), and a forced shutdown, such as power-failure will force a filesystem check of the save-file and the "home" partition at next boot. Puppy has also has this feature for sometime.
This mechanism also works for full-HD installations.

I haven't tested the changes yet, will do a pup build tonight or early tomorrow.

Woof commit:
http://bkhome.org/fossil/woof2.cgi/info/e28eb986ce

---

Comments

other idea
Username: jamesbond
I think the point is not whether the flag is created by initrd or by quickset, but the fact that the fact is created *at all* during the first boot of a live CD. This isn't good. The first boot of a live CD should not touch anything on user's harddisk except when explicitly told so by the user (the fsck-me.flag is ok because the user has told puppy to modify his harddisk to install the savefile anyway). To illustrate, someone who uses Puppy to try to get his data from his only (possibly corrupted) NTFS partition leftover by Windows can end-up having worse corruption of his disk because of this. My suggestion is either: a) use a boot menu instead of boot prompt, where one of the menu entry is "safeboot" or something like that which will start puppy with the appropriate boot parameters, or b) if still using boot prompt, then have another label entry (say "safeboot") which will boot with the appropriate boot parameters, instead of asking the user to type "puppy pfix=blahblahblah". Yes it is not as convenient as "auto-fixing" but other than testers, how many times one boots in PUP_MODE=5? cheers

Re pupdesk.flg alternatives
Username: BarryK
"I was thinking that if the user enters the boot parameters: [i]puppy pfix=ram[/i] or [i]puppy pfix=nox[/i] Then 'pupdesk.flg' will not be created, ie that mechanism will be disabled. That would be a compromise. So, if someone needs to do repair/recovery off a HD and don't want to write anything to it, then those options will do it. Another possible alternative is not to create pupdesk.flg at all, instead, if the user holds down a key, say CTRL or ALT, then the xorgwizard will be forced to run. The thing is, how to read that in the initrd? Holding-the-key-down will be great when there is no boot menu, no opportunity to type in boot parameters. Then, we could advertise this feature, that CRTL key (for example) causes a boot in recovery mode. The key method though, has a disadvantage. pupdesk.flg passes the previous attempted Xorg driver back to the reboot. I really do want to be able to do that.

Re writing to a wonky HD
Username: BarryK
"In the case of a wonky HD, it was stated on the forum that Puppy should not write to it at all, so that data can be recovered from it. That was used as an argument for not having the 'pupdesk.flg' mechanism. However, at first boot Puppy does look for a swap partition and will automatically load that. So the HD is getting written to. So, perhaps the init script should disable loading of a swap partition on first boot? But no, some people like to bootup in PUPMODE=5 and have a fully working system (with the extra memory space offered by a swap partition), and always shutdown without creating a save-file. Or, if a person is doing a recovery operation, booting with "pfix=ram" should boot without using a swap partition, not touch the HD at all.

No automatic swap for Fatdog too
Username: jamesbond
"In the case of Fatdog, we don't automatically use swap for the same reason. But Fatdog targets well-endowed machines, so this is excusable. Puppy on the other hand have different target, so it is a tough call. That being said, wonky HD is probably rarer than corrupted filesystem. I found a C program to detect keyboard shift states. Too big to be attached here (I tried!), I will drop you an email. cheers!

detect keypressed
Username: jamesbond
"I posted the source in the forum thread instead, here: http://murga-linux.com/puppy/viewtopic.php?p=703480#703480. cheers!

showkey
Username: BarryK
"jamesbond, Busybox has 'showkey', which works, no need to specify any device node. Problem is, it only terminates 10 secs after last keypress.

showkey
Username: scsijon
"I have emailed the toybox programmers thread and asked them if they would consider adding it into the set, but with a user-set time switch allowing for 0 instead of a fixed one of 10 seconds. It wouldn't get you an immediate fix, but it wouldn't be far away. For those who have not come across it by now, Toybox has a subset of busybox plus other full commands. However for those it has, the commands functions have been extended. http://landley.net/toybox/about.html is the info site.

Re showkey
Username: BarryK
"I took a closer look at 'showkey'. It doesn't seem to be what we want, only reports key presses and releases. So, if the shift-key for example is pressed after showkey has started, then it gets recorded, but not if shift was depressed prior to launching showkey. I found that showkey is also in the 'console-tools' and 'kbd' packages.

showkey
Username: jamesbond
"I know about showkey, but I thought it isn't useful for the reason you have said. But if you're willing to change the modus operandi (="tap shift key once to start safeboot", rather than "press shift key until safeboot starts"), then you can still use it: Start showkey in the background, capture the output, then echo a message "tap shift key once to start safeboot", then do any other init business. When it is time to decide between normal and safeboot, grep the showkey's output, if the user ever press the shift key, then starts safeboot. Oh and kill showkey if it is still running. The downside to this is that if the user accidentally press the shift key (he gets bored of waiting or whatever), then puppy will go into safeboot :) The app I posted is for detecting "keyboard state", instead of keypress. I should have titled my blog comment differently. If you use it, then the user must hold down the shift key long enough until init script is about to decide between normal boot and safeboot. With all this complexity, really you don't want to consider adding menus and/or another "safeboot" isolinux label? Personally, I don't like that "press F8 to boot in safemode, F5 to log boot sequence" stuff :cool: Menus and/or label is so much clearer. cheers!

Re mini multisession
Username: BarryK
"Ted Dog, Many people don't boot Puppy from a CD at all, me included most of the time. They just take the files out of the ISO file and manually install frugally.

fsckme.flg standing problem
Username: pdh
"I logged this in the "BUGS" thread on the murga forum (http://www.murga-linux.com/puppy/viewtopic.php?t=85960) but will reproduce here: [quote] I've recently upgraded two different machines from 5.4.2 to 5.5 Precise. These are frugal installs. In both cases the upgrade seems to have gone smoothly (although as usual desktop shortcuts disappear) with the exception that on every subsequent boot Puppy still displays " Updating ... layered file system ... next boot will be faster" (although the actual update is performed - correctly - only on the first boot with the new system - the subsequent ones appear to perform a check only, but do extend the boot time somewhat) I've noticed this in the past with previous version upgrades, but in those cases removing fsckme.flg from /mnt/home also removed the problem. With this version, fsckme.flg seems to be being recreated at every boot and triggering the "update" .[/quote] [quote]itseems that some changes made between boots are not retined (so if i add a desktop shortcut for instance this will not appear next time puppy is booted). however if i instll a pet or whatever, this is retained[/quote]

Tags: woof