Remove extra sfs from BootManager
Remove extra sfs from BootManager
What shinobar is doing to sfs_load for Slacko6 got me thinking about extra sfs's. From a users perspective, extra sfs's should have nothing to do with booting.
There should be a single utility for loading and unloading extra sfs's, perhaps called something like "Extra sfs loader".
This should be the only way of loading an extra sfs.
Loading an extra sfs should mean, load in now.
Any loaded sfs should remain loaded, until it is unloaded by "Extra sfs loader". This means that the load persists through subsequent boots.
This facility should be available in pupmode=5.
Note: The new sfs_load that shinobar is working on, will have all the capability required for "Extra sfs loader".
gyro
There should be a single utility for loading and unloading extra sfs's, perhaps called something like "Extra sfs loader".
This should be the only way of loading an extra sfs.
Loading an extra sfs should mean, load in now.
Any loaded sfs should remain loaded, until it is unloaded by "Extra sfs loader". This means that the load persists through subsequent boots.
This facility should be available in pupmode=5.
Note: The new sfs_load that shinobar is working on, will have all the capability required for "Extra sfs loader".
gyro
I never really understood why the simple act of naming the file to match the release ( eg. filename_412.sfs ) and placing it with the main sfs was rejected as a method of controlling what sfs get loaded at boot... a noob like me managed it when I first used linux and it works without needing a save... so i kept it that way....... handy for compiling pfix=ram (though a split second 3kb sfs load and not saving at shutdown works well too) or simply creating a custom system in a few seconds.
But simple is not the puppy way it seems...
mike
But simple is not the puppy way it seems...
mike
@mikeb -- let me get this straight --
(1) download an additional SFS to the same folder/partition as the main SFS.
(2) give it the same ending number, so for Slacko 57 non-PAE it would be example_57.sfs.
(3) reboot, and the SFS is recognized and loaded, without any mucking around with SFS-Load or BootManager.
Is that correct?
(1) download an additional SFS to the same folder/partition as the main SFS.
(2) give it the same ending number, so for Slacko 57 non-PAE it would be example_57.sfs.
(3) reboot, and the SFS is recognized and loaded, without any mucking around with SFS-Load or BootManager.
Is that correct?
mikeb wrote:I never really understood why the simple act of naming the file to match the release ( eg. filename_412.sfs ) and placing it with the main sfs was rejected as a method of controlling what sfs get loaded at boot... a noob like me managed it when I first used linux and it works without needing a save... so i kept it that way....... handy for compiling pfix=ram (though a split second 3kb sfs load and not saving at shutdown works well too) or simply creating a custom system in a few seconds.
But simple is not the puppy way it seems...
mike
Wouldn't this mean to rename all the files again and again (or to move them out of the way) to be able to boot with them loaded at boot up or to boot without them loaded at boot up - e.g. ability to do a remaster without all those sfs files included?starhawk wrote:@mikeb -- let me get this straight --
(1) download an additional SFS to the same folder/partition as the main SFS.
(2) give it the same ending number, so for Slacko 57 non-PAE it would be example_57.sfs.
(3) reboot, and the SFS is recognized and loaded, without any mucking around with SFS-Load or BootManager.
Is that correct?
[b][url=http://lazy-puppy.weebly.com]LazY Puppy[/url][/b]
[b][url=http://rshs-dna.weebly.com]RSH's DNA[/url][/b]
[url=http://murga-linux.com/puppy/viewtopic.php?t=91422][b]SARA B.[/b][/url]
[b][url=http://rshs-dna.weebly.com]RSH's DNA[/url][/b]
[url=http://murga-linux.com/puppy/viewtopic.php?t=91422][b]SARA B.[/b][/url]
well starhawk this no longer applies hence my point/rant.
Well moving a file or two compared to fiddling around with a gui that has to rely on a save option being present...but bear in mind below...
Sfs use... have a set that load at boot for commonly used apps...eg thunderbird, GIMP and so on.
Load on the fly those that are used occasionally kept in a separate folder.
Who the hell is moving anything?
mike
Well moving a file or two compared to fiddling around with a gui that has to rely on a save option being present...but bear in mind below...
Sfs use... have a set that load at boot for commonly used apps...eg thunderbird, GIMP and so on.
Load on the fly those that are used occasionally kept in a separate folder.
Who the hell is moving anything?
mike
new features... like those really annoying things added to browsers while loosing useful stuff.Why the heck did they ever even take that out?
Perhaps its related to the search for everything everywhere approach or use of subfolders, or distrospecs...
Searches used to use ls which is easy peasy to do a pattern match though find should handle that too.
Ok have a gui for users to twiddle with what loads or not (SLAX does that using grub boot parameters) . It also meant sfs ONLY loaded for the intended pup version. I did add a _uni.sfs search for things like open office that worked on many variants.
mike
I don't know!mikeb wrote:Who the hell is moving anything?
I'm just asking, how do you remaster when all those SFS will load automatically at boot up?
Or how do you avoid the loading at boot up, when you just want to do a remaster?
[b][url=http://lazy-puppy.weebly.com]LazY Puppy[/url][/b]
[b][url=http://rshs-dna.weebly.com]RSH's DNA[/url][/b]
[url=http://murga-linux.com/puppy/viewtopic.php?t=91422][b]SARA B.[/b][/url]
[b][url=http://rshs-dna.weebly.com]RSH's DNA[/url][/b]
[url=http://murga-linux.com/puppy/viewtopic.php?t=91422][b]SARA B.[/b][/url]
okies remastering.... well for that unique function I find a quick drag and drop to a folder does the trick.. Actually for most sfs they can be unloaded on the fly too (only the devx seems to resist that as it duplicates core files but thats not something thats normally loaded anyway.) ..that's assuming an sfs loader script that does not upset the system.
All things being different, not loading any extra sfs could be added as a boot parameter but there are enough of them now. Otherwise...have a gui for it.
In my particular case the machine that I do remasters on I keep the main sfs only and load others if needed... all the rest have fuller setups.
mike
All things being different, not loading any extra sfs could be added as a boot parameter but there are enough of them now. Otherwise...have a gui for it.
In my particular case the machine that I do remasters on I keep the main sfs only and load others if needed... all the rest have fuller setups.
mike
You don't need to remove one thing to fit something else in. This is Puppy, everything's small here (well, relatively speaking...), so that's an excuse in my book, rather than a proper reason.mikeb wrote:new features... like those really annoying things added to browsers while loosing useful stuff.
That's what I meant by "to move them out of the way".a quick drag and drop to a folder does the trick
So far I haven't got problems unloading the devx - though I'm not using it very often.(only the devx seems to resist
[b][url=http://lazy-puppy.weebly.com]LazY Puppy[/url][/b]
[b][url=http://rshs-dna.weebly.com]RSH's DNA[/url][/b]
[url=http://murga-linux.com/puppy/viewtopic.php?t=91422][b]SARA B.[/b][/url]
[b][url=http://rshs-dna.weebly.com]RSH's DNA[/url][/b]
[url=http://murga-linux.com/puppy/viewtopic.php?t=91422][b]SARA B.[/b][/url]
hmm the only advantage of loading sfs under the main one..... the duplicate files will be ignored so core files in the devx will not be in use preventing removal...if you understand my meaning.So far I haven't got problems unloading the devx - though I'm not using it very often.
Of course if replacing a file is intended behaviour that's another matter.
Then its time to invent adrv, bdrv zdrv yodrv, bumdrv, slapdrv and so on....
Not my excuse starhawk.... just pointing out changes that might be a relevant. I notice puppy's shutdown methods becoming just as convoluted.
mike
no I know.... I am a happy bunny and didn't think you were having a go....just adding to my point of there not being an apparent technical reason as such for the change....and my general view of puppy making simple things complicated.Oh good heavens -- I wasn't mad at you!
I think we are on the same page on this one.....
mike
For me , sfs_load does too much to make things " easy " for the user .
I roughly know what I am doing and want load and unload on the fly
and not auto-load it next boot by writing into
/etc/rc.d/BOOTCONFIG .
I have several versions of sfs_load and some try to fixmenus
by
/etc/init.d/?sfs_load? stop
at shutown and such glitches .
And I know why my .sfs files are at their location
and don't want to be asked to copy or move them so
" Puppy " can find them next boot .
I am also not so happy about mounting everything to look for files that was introduced somewhere
Otherwise sfs_load it is quite usable and I am using it every time, I boot pfix=ram to load the devx .
I would strip sfs_load for my needs from any code that writes to BOOTCONFIG or /etc/init.d/* .
rc.shutdown should unmount all unneeded loop devices now correctly without /etc/init.d/sfs_load stop and such .
But of course the unmounting by rc.shutdown was buggy until around slacko-5.x .
I roughly know what I am doing and want load and unload on the fly
and not auto-load it next boot by writing into
/etc/rc.d/BOOTCONFIG .
I have several versions of sfs_load and some try to fixmenus
by
/etc/init.d/?sfs_load? stop
at shutown and such glitches .
And I know why my .sfs files are at their location
and don't want to be asked to copy or move them so
" Puppy " can find them next boot .
I am also not so happy about mounting everything to look for files that was introduced somewhere
by Barry in the /init file , which is the cause that I still stick with Puppy-4 .#100911 completely overhauled the code to find puppy files. note, dropped support for /proc/ide.
and
#110425 major change, /sbin/wait4usb parallel process while searching ata drives, to speed booting.
Otherwise sfs_load it is quite usable and I am using it every time, I boot pfix=ram to load the devx .
I would strip sfs_load for my needs from any code that writes to BOOTCONFIG or /etc/init.d/* .
rc.shutdown should unmount all unneeded loop devices now correctly without /etc/init.d/sfs_load stop and such .
But of course the unmounting by rc.shutdown was buggy until around slacko-5.x .
#120103 karl godt: error unmounting stray partitions. 120103 karl godt: more tweaks.
#120129 karl godt: need to rearrange order, refer http://murga-linux.com/puppy/viewtopic. ... &start=405.