SFS loading bugfixes

MU reported two bugs, that I have fixed. That's good news, but it is also rather disturbing...

Checkbox
The first bug MU reported was when he unchecked the checkbox in the BootManager window for selecting what SFS files to load. The checkbox, if checked, overrides any user selection and only loads SFS files that are named *_nnn.sfs (where 'nnn' is the current Puppy version number). The bug is that if unchecked then at least one file has to be selected into the right pane, otherwise the 'init' script reverts to loading any *_nnn.sfs files.

I have done what I have been thinking of doing for sometime, remove that checkbox altogether. Users find it confusing the first time they encounter it. Now that it has gone, no SFS files will load at bootup unless that are explicitly selected (moved into the right pane) in the BootManager.

Removal of whiteout files
This one is disturbing because it's an old bug that goes right back to Puppy 2.x. MU reported that he created directory /usr/src, then at a future boot he loaded the 2.6.29.6 kernel SFS file -- but its /usr/src stuff was not there.

This problem is due to a very annoying "feature" of Unionfs. When you create a directory, in this case /usr/src, Unionfs creates file '.wh.__dir_opaque' inside it, which has the effect of hiding any future SFS file underneath that has stuff in /us/src.
The thing is, Unionfs is following an official standard laid down for layered filesystems -- it's too long ago and I don't recall what or where that standard is. Aufs ignores it and does not create '.wh.__dir_opaque' so doesn't have the problem.

Amyway, I figured out a solution right back in the pup 2.x days. The 'init' script detects any change in the Unionfs layers, and if changed then deletes any '.wh.__dir_opaque' file that might be blocking a lower layer.
However, after MU reported the problem, I checked the code in the 'init' script and it doesn't work, never has.

I have now fixed it. I did a test build and went through the same steps that MU did, and the fix works. What disturbs me is that all of our previous testing of Unionfs was compromised by that broken code. Now that it's fixed, it eliminates one of the major complaints about Unionfs.

I can't upload a patch for 4.3beta1 testers, as the fix is in initrd.gz, but it will of course be in 4.3beta2.

---

Comments

Firefox
Username: 01micko
Hi Barry, Many forum members have reported (as you may have seen) problems trying to run the latest firefox, but only with the newer kernels. This is not restricted to Puppy as reported by gposil. He has had problems with Firefox-3.5.2 in k 2.6.29.6 in Ubuntu and Fedora, and Seamonkey-2. I compiled firefox from the mozilla-1.9.1 source in ppa-423 and it fails, but that compile works fine in Puppy 4.2.1, Seamonkey-2-beta also fails. I lodged a bug report with bugzilla, https://bugzilla.mozilla.org/show_bug.cgi?id=510764 Hopefully they will fix it. Cheers

whiteouts
Username: foo
"Yes, this might explain some anomalies (for me, one symptom has to do with moved and/or 'deleted' .desktop files returning and showing up in the submenus again :| ) ..devilish details in the layers/modes.

layer fix - great
Username: MU
"that is fantastic news, Barry. I currently use Newyearspup as my main operationg system for 4 reasons: - aufs (now hopefully no longer required) - newer glib/gtk (not that critical, can be updated via pets) - unicode support - if we fix the LC_ALL issue, also no longer an advantage - includes some daemons required by several programs, dbus, udev, hal. These also can be added as pets if required, and it maybe is better, if udev is not included by default, as it slows down startup. So Puppy 4.3 now includes the most important parts, so we have them in an official branch. I think, this will be the point, to stop further development of NYP, and instead convert/update some custom sfs (windowmanagers, Java, Mono etc.) from it for Puppy in the next weeks. Nice development :-) Thanks for investigating those issues! Mark

Tags: woof