Testing: Improved Remaster Script

[jam]

Dougal,

I'm back now. Sorry for the delay in responding. By the way, I should be available for the next 6-8 hours from the time of this post. Puppy <finally> did boot to the desktop, but none of my saved settings were reflected. Some of the GTK objects appeared, but icons and background did not. I could not get to the JWM/IceWM menus, and although the mouse/keyboard functioned, clicking an object on the desktop produced no action.

For this test run I used Murga's Very Mean Puppy 2.02 SE. My next run will consist of downloading and using the the puppy-2.02-seamonkey.iso from ibiblio.org to see if that makes any difference.

[jam]

Dougal,

Went through the same process with Puppy 2.02 Seamonkey and the result was the same. The ISO created was 300 Mb in size, the bootup process went fine, but the desktop displayed did not resemble anywhere near the settings saved in my PUP_SAVE.3FS file. Just to clarify, my PUP_SAVE.3FS file resides in a directory located on hard drive device /dev/hda2, and the remaster files used for the ISO build were properly placed on that device as well. There were no obvious critical errors that came up during the remaster process, and the output scrolled by so quickly during some phases of rhe remaster process that it would have been almost impossible to detect the errors anyway.

[Dougal]

I didn't know exactly what to do at the step where I can edit the tmp/etc.
Also I didn't know what parameters to change in the boot script. Is it just about kernel parameters or is it also about keyboard layout,...?

It's best to just not touch those two if you don't know what to do with them.
The /tmp/etc one is to let you copy extra files into /etc on the remaster, in case you added something that isn't copied by default.
The isolinux.cfg editing gives you the option of adding things that you usually need to add when booting, like acpi=on/off/force, or things like the keyboard, but it's really not a good idea to touch it unless you know what you're doing.

One last question:
Why does the step, where the script reads the CD take so much longer than in the last version?

This step takes so long since in your case (HD install), you don't have a pup_2xx.sfs file mounted on /initrd/pup_ro2, so after copying the 5 little files it always did, the script found pup_2xx.sfs on the cd, mounted it and used it to copy the files it needs for creating the new iso. (the old remaster script couldn't work with your HD install since it couldn't find anything on /initrd/pup_ro2...)

[Dougal]

Puppy <finally> did boot to the desktop, but none of my saved settings were reflected. Some of the GTK objects appeared, but icons and background did not. I could not get to the JWM/IceWM menus, and although the mouse/keyboard functioned, clicking an object on the desktop produced no action.

That's really strange. It's probably related to which files are copied into the new /root directory. Can you give examples of settings that were not copied?

Another thing: if you added new icons/backgrounds and the files are actually in /root, then you should have added them manually when you were given the option of adding things to /tmp/root. The script takes a "pristine" /root directory and only copies certain config files, so various files you added to /root aren't added!

See my next post for another idea.

[Dougal]

Ok folks, I have an idea:

Barry's script (and hence mine) takes some "pristine" directories (/root, /var, /etc...) to use in the new cd and adds to them some config files.

AlienX's script simply took your directories and -- if you chose "no hardware customisations" -- removed a few files.

Should I add an option of copying the full /root (and maybe also /etc) directory instead of the "pristine" one?

It's probably easier to then go to /tmp/root and delete all the emails and whatever that you don't want... then you can be sure all your customisations will remain intact.

[BarryK]

Dougal,
be careful though, the stuff in /root can get quite large.
That will also include cache and tmp subdirectories.
There is a way of copying /root while at the same time screening out unwanted
subdirectories ...a different method from 'cp', but I can't think of it right now.
...there is something about this in one of my old notebooks somewhere.

[jam]

Dougal,

While I can't give you an exact breakdown of what settings were copied and which ones were not saved since the machine locked up on me, I can tell you that visually the background and icons were missing. I'm not at my Puppy machine at the moment so I can't itemize what was stored in the /root folder, but I can tell you that I did not manually copy off anything from /root.

Really like your new idea of adding an option to copy off /root and /etc since there are important custom settings that need to be preserved(less the cache and tmp objects Barry mentioned which I can care less about).

Here's another idea to consider - although you are technically more qualified to implement this than I:

1. Check the contents of the original pristine/base Puppy CD and compare
them to the current installation (excluding the contents of tmp and
cache and special device files, etc.). This will give you an inventory
of what was added/change in the custom installation. You can also
take the opposite approach, looking at the custom installation and
comparing them against the base/pristine CD.

2. If the user does not want to preserve their custom settings for
keyboard/mouse/locale/display, then overwrite ONLY those files
with the pristine files from the original CD, otherwise save other
custom settings to the remaster.

In basic terms, the goal is to take a literal snapshot of your current operating environment, regardless of whether you're running a multisession or HD install, and recreate that in the remaster so you can distribute your exact desktop to others without all the normal complexities of remastering. I've been through some painful and time-consuming Knoppix remasters on one end of the spectrum and very simplistic remasters using Slax so I know this can be done with Puppy - and you're getting very close. Believe me, I know it's not easy and takes some work, and I very much appreciate your effort!

[Dougal]

Dougal,
be careful though, the stuff in /root can get quite large.
That will also include cache and tmp subdirectories.
There is a way of copying /root while at the same time screening out unwanted
subdirectories ...a different method from 'cp', but I can't think of it right now.
...there is something about this in one of my old notebooks somewhere.

Yeah, it could be a bit of a problem. Also things like my-roxapps.
It just occured to me that Spot should also be handled! Maybe the "spot" directory has program settings in it, if it has been used?

It's a little frustrating... AlienX's script was very simplistic, but it worked! The iso could get a little fat, the dotpups wouldn't be registered... but you did get a running cd in the end, which is probably what the users want.

So as long as the users don't give us a lot of feedback on which other files are needed... maybe it's best to give them the option of doing it that way.

[Dougal]

1. Check the contents of the original pristine/base Puppy CD and compare
them to the current installation (excluding the contents of tmp and
cache and special device files, etc.). This will give you an inventory
of what was added/change in the custom installation. You can also
take the opposite approach, looking at the custom installation and
comparing them against the base/pristine CD.

2. If the user does not want to preserve their custom settings for
keyboard/mouse/locale/display, then overwrite ONLY those files
with the pristine files from the original CD, otherwise save other
custom settings to the remaster.

1 could get complicated. You could just keep getting deeper and deeper into what should and should not get copied. And the files that are in the "pristine" directory do need to be copied in many cases (.jwmrc...). I'd actually like to look at the remaster scripts for other distros and see what they do...

2 is trivial. it's just a matter of deleting 10-15 files.

In basic terms, the goal is to take a literal snapshot of your current operating environment, regardless of whether you're running a multisession or HD install, and recreate that in the remaster so you can distribute your exact desktop to others without all the normal complexities of remastering.

The snapshot thing is how it started, with AlienX's script. But it starts getting complicated when you try and keep the iso slim (leaving out extra baggage), register dotpups as built-in packages... Barry's script was an attempt at doing that. Not an easy task.

[jam]

Dougal,

You'll have to decide the best approach to take here. Perhaps in your remaster script you can give the option to use one or the other - Dougal/AlienX schemes. I'm not sure how important the package registration step would be or whether it needs to occur, since at least from my perspective you're creating a base ISO from your current desktop settings. Any new packages can be added to the base.

[Billcnz]

Dougal - just some feed back, the remaster I did today with your latest script went through without a glitch and the new cd didn't have the problem with the xserver that I mentioned earlier in this thread. I don't know if that was something you fixed or something I did differently. The only thing I can think that I did different was I overwrit /tmp/etc/profile with the one from /etc/profile.

I was running from livecd with a pup_save file when I ran the remaster.

Cheers
Bill

[Dougal]

Dougal,

You'll have to decide the best approach to take here. Perhaps in your remaster script you can give the option to use one or the other - Dougal/AlienX schemes. I'm not sure how important the package registration step would be or whether it needs to occur, since at least from my perspective you're creating a base ISO from your current desktop settings. Any new packages can be added to the base.

I might add an option of choosing between the two.

I'm still not sure though. There are all kinds of config files to remove and I'll have to find out which they are. Example: the Graveman config file (so it'll search for drives when started by users.).

[Dougal]

Dougal - just some feed back, the remaster I did today with your latest script went through without a glitch and the new cd didn't have the problem with the xserver that I mentioned earlier in this thread. I don't know if that was something you fixed or something I did differently. The only thing I can think that I did different was I overwrit /tmp/etc/profile with the one from /etc/profile.

I was running from livecd with a pup_save file when I ran the remaster.

Cheers
Bill

Good. I'll see, I might just release this one the way it is (a little prettied up, maybe) and then start dealing with the more drastic changes.

[Q]

Nice work Mr.guru
it worked perfectly on 2.10 but when i tried it on John Murga's MeanPup2.02 I got the following error:

Code: Select all

creating unionfs...
/sbin/init : 1041 :cannot open dev/console : no such file.
kernel panic - not syncing :attempted to kill init!.....

can you please if you have the time try to make the script work on that version....your help would be very appreciated if you can do me this big favor.
Thanks again for the clever script Mr.guru

[Dougal]

Code: Select all

creating unionfs...
/sbin/init : 1041 :cannot open dev/console : no such file.
kernel panic - not syncing :attempted to kill init!.....

can you please if you have the time try to make the script work on that version...

I have no idea what this error means... I'll try and boot MeanPup and give it a try.
you might want to ask Murga, maybe he knows what could cause it?

[giiba]

this might be a dumb question, but how do I extract the ".sh.gz" file? Xarchive just tells me it doesn't know how to extract it...

[Billcnz]

this might be a dumb question, but how do I extract the ".sh.gz" file? Xarchive just tells me it doesn't know how to extract it...

use "gunzip"

sh-3.00# gunzip remasterpup2c.sh.gz

Tip: if you browse to the directory in Rox you can right click a blank part of the Rox window and click "Xterm Here"
Also when typing in the console you can use the Tab key to auto-complete file names in the current directory so you dont have to type the whole thing.

Bill

[BarryK]

I've emailed the author of Xarchive about the lack of support for a single gzipped file, filename.gz, but no joy so far.
So, may have to modify the drag-and-drop PupZip desktop icon so that especially recognises these kind of files and just runs 'gunzip'.
I've made a note in my notebook, but if anyone else wants to tackle it, go for it, as I don't know when I'll be able to look at it.

PupZip is a thing I created that is a drag-and-drop frontend to any archiver program, such as Xarchive or GuiTAR. It is to be found at /usr/local/apps/PupZip.

[Dougal]

I've emailed the author of Xarchive about the lack of support for a single gzipped file, filename.gz, but no joy so far.

I alsways assumed it's because a gzipped file isn't really an "archive"... there's no archive to look into, just the one file. (and when you unzip it, it doesn't make --extract-- another copy and leave the original intact, it actually changes the original)

You could change the default program Rox uses to be gunzip, so it'll just unzip when you click on it.

[SamSung]

Hi Dougal,

I have been following this thread in parrellel with my own attempts to remaster Puppy using the defaualt script, and really would like to add my opinion in what I think is useful in a remaster script.

Firstly I think that we can assume that those that are using the script wish to make a base system on which to then add apps etc, if that is the case then most people proabably do what I have been doing start with a barebones version cd that bots into RAM and has not been used for anything other than the task of creating the remastered version about to be created, therefore it is already pristine. Any changes made such as the cosmetic changes, icons, menu structure, backgrounds, apps are the things that are needed in the remaster and thus the users want or expect that these changes will be remastered without having to then move all the files into root at the appropriate moment. As the remaster is for a livecd we can also assume that the specific pc setings in /etc need not be saved so that the livecd is indeed that and will boot on any PC.

Well that is my opinion for what it is worth I hope that it helps to clrify the user requirements for you, and I look forward to the next version of the script.

Sam