Woof: built Wary 5.5RC

I have uploaded the latest Woof, as used to build Wary Puppy 5.4.90 (5.5RC).

Last commit:
http://bkhome.org/fossil/woof2.cgi/info/78d226cc6a

---

Comments

Couple of woof related things
Username: 01micko
Hi Barry, Firstly, in initial testing, busybox strings seems ok, sorry for the earlier concern but I didn't see any reference to BB strings in documentation, may have missed it. Second, I know you won't like this but I stuck with kmod. Of course depmod is slower than BB depmod but 10 seconds on my slowest machin (eee.pc-701-SD, 866MHz celeron, 512 shared RAM) is acceptable though not stellar performance. My reason is that those wanting to upgrade from 5.4 will have all sorts of problems if I reverted to module-init-tools. I thought long and hard about this. There is also the IO bug that I have mentioned several times. I'll do a more comprehensive report later today. [b]It's important[/b]. I know this has been requested many times, but can we have isohybrid the default in woof please? It's a simple matter of dd'ing an iso to flash and would be a great complement to f2fs. Also the unetbootin guys will be happy, not that I ever used that but many do. Thanks, and my slacko beta is released and looking real good, it's RC standard actually. Want a race to final? (Joke) Regards

Comprehensive report
Username: 01micko
"[u]IO Bug (aka the "BUG")[/u] This is a report on the IO bug experienced in Slacko-5.4 by various users. It is only apparent under certain conditions. Those conditions include installation of the save file to a windows partition (NTFS or VFAT, including USB installs) and have been reported to occur in ext2 savefiles to ext2 partitions. I'm not sure about ext2 because I can not reproduce it. This is a very mysterious bug as I have found nothing trawling kernel documentation, AUFS documentation and various mailing lists and fora. I have experienced the bug first hand on an USB install to VFAT on a reasonably fast laptop that runs true slackwar64-current with KDE-4.10 just fine from the HDD. The slowdown occurs during the snap-merge. IO becomes intolerably slow for about 10 to 30 seconds depending on how much data is to be saved. If very little data it is almost unnoticeable, but if you grabbed an iso to the save file it is excruciatingly slow. This affects ALL puppy versions with kernels 3.2 to 3.7. SFR has demonstrated it in Precise-5.4.90 (k3.2.29), Upup-precise-3.7.2 and Slacko-5.4 (kernels 3.2.33, 3.4.17, 3.4.28). I built an experimental Slacko with k3.0.60 and the bug does not occur. I have [url=https://docs.google.com/spreadsheet/ccc?key=0Atag-cdyFbQmdG9ZVkR5VXp1SUxCMzV2T0tQMVJrNmc&usp=sharing]constructed a table[/url] at google-docs to illustrate the conditions under which the bug occurs. Here are references to the bug and the fix by [b]SFR[/b] (forum member). [url=http://murga-linux.com/puppy/viewtopic.php?p=673122#673122]Initial report and some links to others[/url] by SFR. This post shows a scientific method to reproduce the bug. Please refer to my table if you want to test. [url=http://murga-linux.com/puppy/viewtopic.php?p=681383#681383]Proposed work-around[/url] by SFR The work-around currently employed in Slacko: (The last lines of /etc/rc.d/rc.sysinit) [code]#SFR hack for IO bug http://murga-linux.com/puppy/viewtopic.php?p=681383#681383 if [ ! "$PUPMODE" = 5 ];then if vercmp $KERNVER ge 3.2 ;then if vercmp $KERNVER lt 3.8 ;then case "$DEV1FS" in ntfs|vfat|ext2) mount -o remount,sync /dev/loop1 # changed 130210, SFR ;; esac fi fi fi #that's it. next stop is /etc/profile... ###END### [/code] Note the conditional application of the code. With this fix applied the system runs just fine from USB install even during snap-merge. Thanks for reading. 01micko

Tags: woof