Simple-Remaster

[stemsee]

This is an update with additions to /root/my-applications/.exclude (/etc/init.d/BOOTCONFIG, /etc/rc.d/wcpufreqfile, /root/.megaconf) (which may have been missing in previous package!!!) and a couple of minor additions to the code for opening boot from dir, now also opens /initrd/mnt/dev_ro2 (could alo be /mnt/home /mnt/Home or nothing if system copied to ram) (doesn't check if mounted) this is to assist in locating and copying vmlinux and initrd and zdrv adrv ydrv kernel-modules.sfs files for iso creation.

[stemsee]

So you compiled in NVIDIA modules, then remastered with modules in. Then you decide to boot with a 64bit kernel and zdrv-modules.sfs, while running you install a video editor, upgrade libreoffice and improve some scripts, o you decide to remaster again. However you do not want to include the 64bit zdrv-modules.sfs but you do want to keep the modules already in the main sfs from previous remaster. How do you do that? Simple-Remaster excludes /lib/firmware, /lib/modules, /etc/modules/*, /boot/System.map from the rsync command, and after rsync if modules were kept 'in' then rsync copys thos files/dirs from /initrd/pup_z/*, so any remastered in modules will not be included. Modules out simply does not include the second rsync. So the only way to remaster and keep already in modules in is to use the original kernel without zdrv and selecting modules in. Now there is a third option, at the option to leave modules in or out, just pressing enter will will not include zdrv and will not copy from the / but will copy from /initrd/pup_ro2 /lib/modules, lib/firmware, boot/system.map, and etc/modules. So now you can be running with other kernel and not include those elements (a situation I found myself in!). There are other considerations which I will deal with later.

[stemsee]

Here is an update with more added to cleaning/exclude lists cups/cache and xsane and popcorn-time.

[stemsee]

Simple-Remaster-8

Fixed going to iso. If mods in then zdrv* ydrz* and kernel-modules.sfs not in root of iso, but adrv will be.

Tested

[slavvo67]

Hi Stemsee:

Any remaster product for Fatdog64? The built-in remaster iso doesn't work for me on that one.

Best,

Charlie

[stemsee]

Simple-Remaster has Fatdog Compatibility built in. So does my sfs-remaster suite.

[Ted Dog]

lol yet another simple remaster effort, you should ask for a sub section like we got for multisession just for remaster.
So what is different from the last half dozen remaster tools you have provided?
Like the FatDog support.

[slavvo67]

The more remastering, the better!

Thanks Stemsee. I'll give her a try.

[Bindee]

The more remastering, the better!

Thanks Stemsee. I'll give her a try.

How do you know it's a her?

[stemsee]

@TedDog
Well i have learnt a lot from my mistakes.
This is a less ambitious yet equally effective tool.
SFS-Direct-Remaster simply builds an sfs (Still a great tool).
This has fatdog, Quirky, Lighthouse, and regular pups, but not DebianDog.
I will upload latest which (hopefully) fixes a bug for remastering quirky.
It's quick and versatile and goes to iso. All but one question is asked at beginning and let's user leave modules in or out or as is.
This is a one script tool no supporting files needed for remaster, boot files included for iso.

Smooth sailing with this one, so probably a she!

[stemsee]

I will have to build in a partition format checker as I notice that cups doesn't survive the remaster, at least on ntfs partition. I will need to check fat32 to see if the same corruption occurs in usr/lib/cups/. I will let it check and warn but not prevent using the partition for the intermediate remaster directory, this wont occur when remastering in ram!

[stemsee]

Without investigating I wonder if the corruption occurs only with files or folders whose size is less than 1kb close to 0bytes. If this turns out to be correct then a workaround would be to suffix such files and store them in ram until the squash. Just a thought.

[stemsee]

So last to the party again!!!

fat32/ntfs cannot handle linux symlinks! Thanks for caring and sharing!

!laughable Cactus needles!

So if one wants to remaster on ntfs or fat32 then it must be inside file with internal ext2/3/4 formatted filesystem.

[stemsee]

A few improvemets particularly with regard to chrome extensions retained and history/profile removal.

to do detect fat/ntfs partition, work in ram or ext partitions only.

[LazY Puppy]

So last to the party again!!!

fat32/ntfs cannot handle linux symlinks! Thanks for caring and sharing!

This is NOT the only thing that could cause trouble of some sort.

Anything what has to do with extracting files (like archives, .pet, .sfs etc) containing Linux file system structure should be done GENERALLY on a ext partition !!!

E.g. create a text file (without the .txt extension) on a ext partition and move or make a copy of it to vfat or ntfs partition - it will have changed some of its permissions then, since it will appear as a script file (those ones having green text).

You can see this effect also on binaries like the grub4dos boot loader, grldr.

More examples on this are the isolinux.bin file and/or the .msg files from within a ISO.

All of those appearing with green text as soon as they are stored on vfat/ntfs.

It's good to have ability to write to vfat/ntfs in Linux, but don't do this when editing files from a Linux file system structure !!!

[stemsee]

Thanks! So I will basically have to remaster in a savefile/swapfile on a fat or ntfs system but the mksquashfs itself can be on the fat/ntfs!

So here is simple remaster which checks for fat/ntfs and also follows symlinks in case of home Home,

I will add the remaster on fat/nfs in temporary swapfile/savefile later!