Is the kernel src modified when unloaded?
Is the kernel src modified when unloaded?
I have posted a little How-to concerning the devx and kernel src sfs's at: http://www.murga-linux.com/puppy/viewtopic.php?t=82542. It relates to Puppy 5.2.8 in a full HD installation. In the text I mentioned that when the kernel src sfs is unloaded and later reloaded, any work done to prepare the source tree for compiling will need to be done again. My assumption was that the kernel src sfs file remains in its original state and a reload would yield exactly the same data in memory as any previous load. In the How-to I am using Shinobar's excellent SFS Load-on-the-fly utility. Is the assumption correct or is the kernel src sfs rewritten with data from the unloading operation?
[i]Puppy 5.2.8.7, Full Install[/i]
Hi Hotdog,
I don't run a full installation, and until I read your post I did not even realize that SFS-Load-on-the-fly could unload an .sfs from a full installation. (That's cool that it can do that.) So I'm certainly no expert in this department. But seeing as you've had no response to your post in three days, I'll give it a shot. But be forewarned that I'm just making my best guess.
In order to uninstall the .sfs file it would seem like SFS-Load-on-the-fly must keep a list somewhere of the files it previously installed. Looking at sfs_load-1.9.6 on-the-fly, I see that shinobar says this about it:
So my guess is that if "any work done to prepare the source tree for compiling" creates some new files or directories, those will not be uninstalled. You could verify that by looking to see if any such files or directories remain on your filesystem after the .sfs is uninstalled.
Does this mean all "work done to prepare the source tree for compiling" will be saved? Probably not, since existing files may also have been edited, and those will be removed when the .sfs is unloaded.
Sorry that I'm only able to provide a guess here, but perhaps this will shed some light.
I don't run a full installation, and until I read your post I did not even realize that SFS-Load-on-the-fly could unload an .sfs from a full installation. (That's cool that it can do that.) So I'm certainly no expert in this department. But seeing as you've had no response to your post in three days, I'll give it a shot. But be forewarned that I'm just making my best guess.
In order to uninstall the .sfs file it would seem like SFS-Load-on-the-fly must keep a list somewhere of the files it previously installed. Looking at sfs_load-1.9.6 on-the-fly, I see that shinobar says this about it:
So, yes, there is a list since the PPM is actually doing the uninstallation, and the PPM uses a list. (The list would be in the /root/.packages/ directory and would have a ".files" filename extension.)shinobar wrote:The pseudo-PET is listed on the Puppy Package Manager and can uninstall both from the sfs_load and from the PPM.
(Actually, the sfs_load calls the PPM as for uninstallation.)
So my guess is that if "any work done to prepare the source tree for compiling" creates some new files or directories, those will not be uninstalled. You could verify that by looking to see if any such files or directories remain on your filesystem after the .sfs is uninstalled.
Does this mean all "work done to prepare the source tree for compiling" will be saved? Probably not, since existing files may also have been edited, and those will be removed when the .sfs is unloaded.
Sorry that I'm only able to provide a guess here, but perhaps this will shed some light.
Npierce,
Thanks for the reply. You are correct, any files created or modified outside the kernel src SFS do remain. I have tested whether the original SFS gets rewritten by 1-Loading the SFS, 2-Renaming the SFS then 3-Doing the unload. The SFS is not rewritten. However, after doing that little test there are files left in the source tree that do not usually remain after an unload. So, my understanding still is unclear.
Until some one can explain otherwise, I am going to maintain the position in the How-to that says if the kernel src SFS is unloaded and subsequently reloaded then the source tree prep work should be redone. I spent many days getting the devx and kernel src working properly and I just want to help others avoid that turmoil and possibly giving up altogether.
Thanks for the reply. You are correct, any files created or modified outside the kernel src SFS do remain. I have tested whether the original SFS gets rewritten by 1-Loading the SFS, 2-Renaming the SFS then 3-Doing the unload. The SFS is not rewritten. However, after doing that little test there are files left in the source tree that do not usually remain after an unload. So, my understanding still is unclear.
Until some one can explain otherwise, I am going to maintain the position in the How-to that says if the kernel src SFS is unloaded and subsequently reloaded then the source tree prep work should be redone. I spent many days getting the devx and kernel src working properly and I just want to help others avoid that turmoil and possibly giving up altogether.
[i]Puppy 5.2.8.7, Full Install[/i]
Hotdog,
You're welcome.
Good test -- it looks like you have made it clear that the .sfs doesn't get rewritten. I can't explain the mystery of the additional files that remained.
You're welcome.
Good test -- it looks like you have made it clear that the .sfs doesn't get rewritten. I can't explain the mystery of the additional files that remained.
Yes, I would agree that that is best. Although some work may be saved in the newly created files, it would be hard to predict what exactly is and is not saved -- best to redo from the beginning.Hotdog wrote:Until some one can explain otherwise, I am going to maintain the position in the How-to that says if the kernel src SFS is unloaded and subsequently reloaded then the source tree prep work should be redone.
Hello 8-bit,
Adding a kernel module via insmod persists only for the currently booted session. In Puppy 5.2.8 added modules can be included in subsequent boot-ups by doing Menu -> System -> BootManager configure bootup and choosing the additional modules to be included. This same method can be used to prevent modules from loading. Another way to have it added on bootup is to put the insmod command in /etc/rc.d/rc.local. Also, the kernel could be compiled with the added module.
Adding a kernel module via insmod persists only for the currently booted session. In Puppy 5.2.8 added modules can be included in subsequent boot-ups by doing Menu -> System -> BootManager configure bootup and choosing the additional modules to be included. This same method can be used to prevent modules from loading. Another way to have it added on bootup is to put the insmod command in /etc/rc.d/rc.local. Also, the kernel could be compiled with the added module.
[i]Puppy 5.2.8.7, Full Install[/i]