sfs_load-2.4 on-the-fly
quick hack against sfs_load-0.3
Ah...you are right.rodin.s wrote:When I choose sfs-file from the pulldown it doesn't work, but works OK with drug and drop into the field
Quick hacks at /usr/sbin/sfs_load:
Enable the line 371 and the line 372 to be commented out:
Code: Select all
BASELIST=$( echo "$BASEFIXEDSFSLIST" | sort | uniq)
#echo "$BASEFIXEDSFSLIST" | sort | uniq
Code: Select all
loadable_sfs_list
#BASELIST=$(loadable_sfs_list)
Downloads for Puppy Linux [url]http://shino.pos.to/linux/downloads.html[/url]
I like this one shino (with the small fix you posted)
Working well in spup-055 and latest puppeee 4.4beta8. (sd card installs on the one disk using grub4dos to boot, so PUPMODE=13 for both).(also ok in spup on main box, PUPMODE=12).
One thing, age old puppy bug, the desktop icons mess up after a reboot (only if you customise your pinboard). I think it's something to do with the layering order, where the main sfs takes priority. I hate that bug!
Nice work and I will include in next spup for broader testing.
Cheers
EDIT: shino, the rox pinboard is not your problem. The main sfs contains a hard coded pinboard. The main sfs will always take priority and that's fine. The real fix is to create the pinboard in the init scripts, I might work on that one (sorry a bit off topic)
Working well in spup-055 and latest puppeee 4.4beta8. (sd card installs on the one disk using grub4dos to boot, so PUPMODE=13 for both).(also ok in spup on main box, PUPMODE=12).
One thing, age old puppy bug, the desktop icons mess up after a reboot (only if you customise your pinboard). I think it's something to do with the layering order, where the main sfs takes priority. I hate that bug!
Nice work and I will include in next spup for broader testing.
Cheers
EDIT: shino, the rox pinboard is not your problem. The main sfs contains a hard coded pinboard. The main sfs will always take priority and that's fine. The real fix is to create the pinboard in the init scripts, I might work on that one (sorry a bit off topic)
Puppy Linux Blog - contact me for access
Extra sfs order
Thanks for testing, jpeps, stu90 and mick.
At the reboot, the initrd ignores the directed order of the extra sfs, and re-arrange maybe by the filename.
So, sometimes the order is modified and the rc.update runs, and sometimes does not.
Yes, i think it a bug of the woof on the order of the extra sfs's.
The initrd of Puppy-431JP(Japanese edition) and of LupQ-511 keeps the directed order of the extra sfs, and the main sfs at the last.
It may cause troubles with improperly prepaired sfs's, and makes serious issue with some devx.sfs.
So i conclude that the main sfs is better to be at the top as the tradition, but the extra sfs's should be in the order of 'EXTRASFSLIST' written in the '/etc/rc.d/BOOTCONFIG'.
EDIT: Sorry, the discussion i made here is on somewhat different topic.
As for the pinboard, the issue is the sfs_loader does not run the rc.update, but the rc.update runs at the next reboot...
EDIT2: sfs_load-0.9 and later handles the puppypin.
The sfs_load appends the extra sfs at the last layer, and doesn't run the rc.update(should run because of the pinboard issue?).01micko wrote:One thing, age old puppy bug, the desktop icons mess up after a reboot (only if you customise your pinboard). I think it's something to do with the layering order, where the main sfs takes priority. I hate that bug!
At the reboot, the initrd ignores the directed order of the extra sfs, and re-arrange maybe by the filename.
So, sometimes the order is modified and the rc.update runs, and sometimes does not.
Yes, i think it a bug of the woof on the order of the extra sfs's.
The initrd of Puppy-431JP(Japanese edition) and of LupQ-511 keeps the directed order of the extra sfs, and the main sfs at the last.
It may cause troubles with improperly prepaired sfs's, and makes serious issue with some devx.sfs.
So i conclude that the main sfs is better to be at the top as the tradition, but the extra sfs's should be in the order of 'EXTRASFSLIST' written in the '/etc/rc.d/BOOTCONFIG'.
EDIT: Sorry, the discussion i made here is on somewhat different topic.
As for the pinboard, the issue is the sfs_loader does not run the rc.update, but the rc.update runs at the next reboot...
EDIT2: sfs_load-0.9 and later handles the puppypin.
Last edited by shinobar on Thu 24 Feb 2011, 00:59, edited 1 time in total.
Downloads for Puppy Linux [url]http://shino.pos.to/linux/downloads.html[/url]
APOLOGIES FOR OT RESPONSE01micko wrote:
EDIT: shino, the rox pinboard is not your problem. The main sfs contains a hard coded pinboard. The main sfs will always take priority and that's fine. The real fix is to create the pinboard in the init scripts, I might work on that one (sorry a bit off topic)
I'm surprised that this hasn't already been done, given the ongoing complaints. Or if it isn't so simple, an "autorestore last setup" could be put in the menu for nubees to click on....end of complaints. (the globicons symlink isn't always so obvious).
Jammed this together for starters:
http://murga-linux.com/puppy/viewtopic. ... 976#491976
I guess "tentative" means "dependent on" whether the layered filesytem gets updated, and if the SFS is located in /mnt/home when it is. Shouldn't be any more temporary than a traditional mount. For temporary on-the-fly....drag from a location other than /mnt/home.jemimah wrote:I think it makes more sense to use the word "temporary" instead of "tentative" to describe changes that may not be saved.
This is why I like calculators that round correctly:
179: echo "$(dc $MB 1024 \/ p|sed -e 's/\(^.*\..\).*/\1/')GB"
echo "$(mc $MB/1024 -s1)GB"
http://murga-linux.com/puppy/viewtopic.php?t=62969
179: echo "$(dc $MB 1024 \/ p|sed -e 's/\(^.*\..\).*/\1/')GB"
echo "$(mc $MB/1024 -s1)GB"
http://murga-linux.com/puppy/viewtopic.php?t=62969
Some comments and feedback:
1. Would be useful to add option for "non-persistent change" (doesn't persist across reboots - i.e. don't touch SFSLIST) - especially useful for people (=me ) who runs at full capacity (6 SFS) and want to change / swap SFS for one session only. E.g. unload openoffice to be able to load something else.
2. As in my earlier comment, if you don't mind adding "non-persistent" loading of SFS beyond the original 6 SFS limit.
3. Does on the fly sfs loading / unloading works with pfix=nocopy option? (ie /pup_rw points to the disk rather than tmpfs)?
4. This is specific occurence, happenng in Fatdog I'm running at full capacity - 6 SFS. I can unload openoffice, but when I tried to load it again I always get an error --- it says the SFS doesn't exist. It's available on the left-hand selection, though, it's only after I selected and click ok - I'm asked whether I want to load it (and says size unknown), after I click it, I get an error saying this sfs is not found. This is what the console output looks like:All my SFS are stored in /mnt/home.
1. Would be useful to add option for "non-persistent change" (doesn't persist across reboots - i.e. don't touch SFSLIST) - especially useful for people (=me ) who runs at full capacity (6 SFS) and want to change / swap SFS for one session only. E.g. unload openoffice to be able to load something else.
2. As in my earlier comment, if you don't mind adding "non-persistent" loading of SFS beyond the original 6 SFS limit.
3. Does on the fly sfs loading / unloading works with pfix=nocopy option? (ie /pup_rw points to the disk rather than tmpfs)?
4. This is specific occurence, happenng in Fatdog I'm running at full capacity - 6 SFS. I can unload openoffice, but when I tried to load it again I always get an error --- it says the SFS doesn't exist. It's available on the left-hand selection, though, it's only after I selected and click ok - I'm asked whether I want to load it (and says size unknown), after I click it, I get an error saying this sfs is not found. This is what the console output looks like:
Code: Select all
SFS-Load: FILE1="go-oo_32_amd64-3.sfs"
LOADCHK="true"
LOADTXT=""
UNLOADCHK="false"
UNLOADSFS="audio-all-in-one-amd64-8.sfs"
UNLOADSFS_ALL="'audio-all-in-one-amd64-8.sfs' 'fd64-32bit-libs-4.sfs' 'fd64-devx_510.sfs' 'jre160_amd64-3.sfs' 'wine-1.3.8-i486.sfs'"
UNLOADTXT=""
EXIT="OK"
/usr/sbin/sfs_load: line 442: 20401 Terminated gtkdialog3 -p DIALOG -c > /dev/null
SFS-Load: go-oo_32_amd64-3.sfs
du: cannot access `go-oo_32_amd64-3.sfs': No such file or directory
SFS-Load: FILEISAT=unionfs
SFS-Load: Do you want to load 'go-oo_32_amd64-3.sfs(filesize: unknown)'?
SFS-Load: 'go-oo_32_amd64-3.sfs' not found.
Fatdog64 forum links: [url=http://murga-linux.com/puppy/viewtopic.php?t=117546]Latest version[/url] | [url=https://cutt.ly/ke8sn5H]Contributed packages[/url] | [url=https://cutt.ly/se8scrb]ISO builder[/url]
jamesbond
I think the little bugfix toward the top of this page in shinobar's post fixes issue number 4.
Cheers
I think the little bugfix toward the top of this page in shinobar's post fixes issue number 4.
Cheers
4. This is specific occurence, happenng in Fatdog I'm running at full capacity - 6 SFS. I can unload openoffice, but when I tried to load it again I always get an error --- it says the SFS doesn't exist. It's available on the left-hand selection, though, it's only after I selected and click ok - I'm asked whether I want to load it (and says size unknown), after I click it, I get an error saying this sfs is not found.
Puppy Linux Blog - contact me for access
Thanks 01micko, I will try that. Somehow I got the wrong impression that this fix has been incorporated into version 3. Will let you know.
EDIT: it works now, thanks.
cheers!
EDIT: it works now, thanks.
cheers!
Fatdog64 forum links: [url=http://murga-linux.com/puppy/viewtopic.php?t=117546]Latest version[/url] | [url=https://cutt.ly/ke8sn5H]Contributed packages[/url] | [url=https://cutt.ly/se8scrb]ISO builder[/url]
Answering my own question - it does work.jamesbond wrote:3. Does on the fly sfs loading / unloading works with pfix=nocopy option? (ie /pup_rw points to the disk rather than tmpfs)?
Just FYI (and a puzzle) - this works with when busybox mount is used. When mount-FULL is used, it will bring down the system I wonder what's the difference?
Last edited by jamesbond on Fri 04 Feb 2011, 04:11, edited 2 times in total.
Fatdog64 forum links: [url=http://murga-linux.com/puppy/viewtopic.php?t=117546]Latest version[/url] | [url=https://cutt.ly/ke8sn5H]Contributed packages[/url] | [url=https://cutt.ly/se8scrb]ISO builder[/url]
Testing this - this is currently works partially:jamesbond wrote:2. As in my earlier comment, if you don't mind adding "non-persistent" loading of SFS beyond the original 6 SFS limit.
a) Adding SFS beyond the maximum 6 works. The script will create the necessary mountpoint in /initrd (e.g. /initrd/pup_ro10). But it uses the wrong loop device - instead of using loop10, it uses loop2 instead.
b) It still adds into SFSLIST (obviously because this is how it's designed for right now).
c) Removing it (within the same session as adding it) seems to work (success message), but actually fails - the SFS is still mounted. But because it's no longer in SFSLIST, sfs_load doesn't see it anymore.
Well, I know this is probably outside your original scope of design when you started, so if you don't want to hear this, just tell me to shut up and I'll do
cheers!
Fatdog64 forum links: [url=http://murga-linux.com/puppy/viewtopic.php?t=117546]Latest version[/url] | [url=https://cutt.ly/ke8sn5H]Contributed packages[/url] | [url=https://cutt.ly/se8scrb]ISO builder[/url]
Interesting - even calling mount.aufs directly still kills this busybox mount must have a power we all don't knowjamesbond wrote:Just FYI (and a puzzle) - this works with when busybox mount is used. When mount-FULL is used, it will bring down the system I wonder what's the difference?
EDIT: mount.aufs is just a wrapper which will call the full mount - and thus it kills. busybox mount make the mount syscall directly.
Last edited by jamesbond on Fri 04 Feb 2011, 10:04, edited 1 time in total.
Fatdog64 forum links: [url=http://murga-linux.com/puppy/viewtopic.php?t=117546]Latest version[/url] | [url=https://cutt.ly/ke8sn5H]Contributed packages[/url] | [url=https://cutt.ly/se8scrb]ISO builder[/url]
Why not just create a simple merge utility?jamesbond wrote:Testing this - this is currently works partially:jamesbond wrote:2. As in my earlier comment, if you don't mind adding "non-persistent" loading of SFS beyond the original 6 SFS limit.
EDIT:
http://murga-linux.com/puppy/viewtopic. ... 619#492619
Because this is what OTF SFS loader is for ?jpeps wrote:Why not just create a simple merge utility?jamesbond wrote:Testing this - this is currently works partially:jamesbond wrote:2. As in my earlier comment, if you don't mind adding "non-persistent" loading of SFS beyond the original 6 SFS limit.
EDIT:
http://murga-linux.com/puppy/viewtopic. ... 619#492619
Fatdog64 forum links: [url=http://murga-linux.com/puppy/viewtopic.php?t=117546]Latest version[/url] | [url=https://cutt.ly/ke8sn5H]Contributed packages[/url] | [url=https://cutt.ly/se8scrb]ISO builder[/url]
sfs_load-0.4
Thanks to all testers.
But please test again with the new version, sfs_load-0.4.
Mainly improved loading SFS from CD with RAM mode.
It offers COPYtoHDD/RAM/NOCOPY options for the live CD without pupsave.
You can see how it works with the multilingual Wary-500m07.
Doesn't check the number of extra SFS. I am not sure what happens when it exceeds 6...
But please test again with the new version, sfs_load-0.4.
Mainly improved loading SFS from CD with RAM mode.
It offers COPYtoHDD/RAM/NOCOPY options for the live CD without pupsave.
You can see how it works with the multilingual Wary-500m07.
Doesn't check the number of extra SFS. I am not sure what happens when it exceeds 6...
- Attachments
-
- sfs_load_whereto.png
- Load from CD without pupsave
- (6.77 KiB) Downloaded 1365 times
Last edited by shinobar on Fri 04 Feb 2011, 15:12, edited 1 time in total.
Downloads for Puppy Linux [url]http://shino.pos.to/linux/downloads.html[/url]