How to split and repack Fatdog64's humongous initrd?

[one]

Hi,

my question is in the subject,

I read the FAQ and found this:

You can use the command line tool fatdog-split-initrd.sh. Run the command in terminal to see the options.

Or, if you only want to get a smaller version (not the smallest), you can extract only the fd64.sfs by clicking on your installed initrd (this should open it up), moving fd64.sfs outside to a place accessible by the bootloader (perhaps the same location of vmlinuz and initrd itself), and then re-packing the initrd by clicking repack-initrd.sh.

I found the fatdog-split-initrd.sh but couldn't do the right syntax. Can someone please advice me how to do that?

So I used UExtract and moved the fd64.sfs outside - but I could not find the mentioned repack-initrd.sh to repack the initrd without the fd64.sfs?

[dr__Dan]

one,
don't use UExtract.
In ROX-filer, navigate to the folder containing initrd, and click (or double-click, depending on your settings) to open it. ROX is set up to open it in a new window, and in that window is a link to run the repack-initrd.sh on the contents of the window once you have done what you want. I've attached pictures.

Follow the help instructions carefully. It may take more than one try along the way to get a working, booting system, but it isn't hard.

Dan

[step]

I found the fatdog-split-initrd.sh but couldn't do the right syntax. Can someone please advice me how to do that?

Yes, I can. Before that, let me clarify that the purpose of fatdog-split-initrd.sh is to shave 400+ MB off the humongous initrd into the fd64.sfs. So you start with one initrd and end with another initrd + a new file fd64.sfs. You then reference both files in your bootloader menu. Practically, leave the reference to initrd unchanged but replace the file in the boot folder, add a suitable basesfs=.../fd64.sfs argument to the kernel line of the menu, add the fd64.sfs to the boot folder in the location specified with basesfs=... You can read in the Fatdog help document (the blue icon on the desktop) what goes into the ... placeholder.

So I used UExtract and moved the fd64.sfs outside - but I could not find the mentioned repack-initrd.sh to repack the initrd without the fd64.sfs?

Unless your intent is to change the Fatdog64 boot scripts, repacking the initrd should not be attempted. It's a different subject unrelated to the procedure for which fatdog-split-initrd.sh was created, which I described above.

So: BIG initrd = SMALL initrd + fd64.sfs via fatdog-split-initrd.sh

Now, let's get to your first question, how to use fatdog-split-initrd.sh.
1. You start from the fatdog64.iso file. Let's say that the full path of this file is /root/Downloads/fatdog64.iso.
2. Click the iso file, which will open a new filer window. Stop if no new window opens. Stop if the title bar of the new window isn't /mnt/+mnt+l+home+spot+Downloads+fatdog64+iso
3. Inside the new window you should see the BIG initrd. Don't click its icon, don't open it. You only need to provide its full path as input to fatdog-split-initrd.sh. Its full path is /mnt/+mnt+l+home+spot+Downloads+fatdog64+iso/initrd
4. Open a terminal window and type:

Code: Select all

cd /root
BASESFS_COMPRESSION='-comp xz' fatdog-split-initrd.sh /mnt/+mnt+l+home+spot+Downloads+fatdog64+iso/initrd "" "" fd64.sfs

This will eventually output the SMALL initrd and fd64.sfs in the current directory (/root, your home folder).

Clean up after the split:
1. Close the terminal window
2. Click the iso file. This will close the window that was opened in step 2 above
3. Open your home folder and make use of the new initrd and fd64.sfs files.

[one]

@dr__Dan and @step

Many thanks for your detailed help - nice!

@dr__Dan: I tried your suggestion and the result was an initrd with 74 MB + fd64.sfs with 341 MB. A frugal install booted via
grub4dos (parameter basesfs=... and savefile=...) boots ok.

@step Then I absorbed your wonderful explanation, used your code for fatdog-split-initrd.sh and after some errors:

("write failed because No space left on device")
("depmod: WARNING: could not open /tmp/module-piMYMMdl/lib/modules/4.19.92/modules.order: No such file or direcory")

I got the script to run and complete with this line:

Code: Select all

# cd /root
# BASESFS_COMPRESSION='-comp xz' fatdog-split-initrd.sh /mnt/+mnt+opt+fatdog64+iso/initrd "/tmp/split" "/mnt/sdb2/base" fd64.sfs

This resulted in an "small" initrd with 8982 K + fd64.sfs with 423 M - so the "small" initrd is nearly the same size as initrd-nano with 8898 K!

I have not yet tested this - time is running, I have to do other things - but I will do it in the next days.

[step]

("write failed because No space left on device")
("depmod: WARNING: could not open /tmp/module-piMYMMdl/lib/modules/4.19.92/modules.order: No such file or direcory")

I got the script to run and complete with this line:

Code: Select all

# cd /root
# BASESFS_COMPRESSION='-comp xz' fatdog-split-initrd.sh /mnt/+mnt+opt+fatdog64+iso/initrd "/tmp/split" "/mnt/sdb2/base" fd64.sfs

Well done! The error message told you that there wasn't enough free space on the /tmp filesystem. You solved this issue by moving large files to your hard disk, where space was available.

The size error happens because /tmp is a RAM filesystem. It means that physical RAM, not a physical disk, is used to save files and folders located under /tmp. The RAM filesystem size is capped at about half your physical RAM size. The other half is left for the OS. There can be multiple RAM filesystems in memory, not just /tmp. Their total size is capped at half the RAM size. So, in a PC with 8 GB RAM, about 4 GB is available for the RAM filesystem collective. That's just 0.4 % of a 1 TB hard disk. Why use RAM for /tmp, given TAM's stringent size cap vs. a disk's? Because RAM is faster than a disk. The OS and applications create many short-lived temporary files. Putting these temporary files in RAM results in a snappier experience.

Applications that create large intermediate files, such as video editors, usually provide a configuration option to set their "working" or "temporary" folder location. Then you'd want to point them to a hard disk rather than the default /tmp location.

[user1111]

I partitioned my HDD to include a linux swap partition, so now it looks like

Code: Select all

# fdisk -l
.
.
Device     Boot      Start        End   Sectors   Size Id Type
/dev/sda1  *          2048  953321471 953319424 454.6G 83 Linux
/dev/sda2        953321472 1007847423  54525952    26G 82 Linux swap / Solaris
/dev/sda4       1007847424 1953523711 945676288   451G 83 Linux

Disk /dev/mapper/cswap: 26 GiB, 27917287424 bytes, 54525952 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes

In /etc/rc.local at the end I added ...

Code: Select all

/sbin/cryptsetup open --type plain --key-file /dev/urandom /dev/sda2 cswap
mkswap /dev/mapper/cswap 
swapon /dev/mapper/cswap
# My swap partition is 26GB, so I resize / to match that
mount -o remount,size=26G /aufs/pup_multi
mount -o remount,size=26G /aufs/pup_save
mount -o remount,size=26G /dev/shm
mount -o remount,size=26G /tmp

So now /tmp (and others) has 26GB space available

Code: Select all

# df -h
Filesystem      Size  Used Avail Use% Mounted on
devtmpfs        1.7G  4.0K  1.7G   1% /dev
tmpfs           1.7G  6.0M  1.7G   1% /aufs/pup_init
/dev/loop0       66M   66M     0 100% /aufs/kernel-modules
/dev/loop1      514M  514M     0 100% /aufs/pup_ro
tmpfs            26G  532M   26G   2% /aufs/pup_multi
tmpfs            26G   52M   26G   1% /aufs/pup_save
aufs             26G   52M   26G   1% /
tmpfs            26G  9.8M   26G   1% /dev/shm
tmpfs            26G  304K   26G   1% /tmp
/dev/sda1       447G   49G  376G  12% /mnt/sda1

IIRC the first time that boots you have to do certain things (it prompts you)
can't recall exactly what, maybe just a simple Yes answer or something like that

I prefer that over conventional open swap as everything written/read from that swap is encrypted using a randomly generated key that's recreated at each reboot. So if my laptop were stolen the content of the swap partition is pretty much impossible to read.

Rarely gets used. except sometimes when I download a large file that automatically gets saved into the ~/Downloads folder that would otherwise exhaust available ram space. Copes well when it is used, but can slow up some, and you just have to be a little patient as things are swapped in/out of actual ram. Shutdowns can also be slowed after swap has been used, again just have to be patient and not press/hold the poweroff button thinking it had locked up. A few minutes instead of the more usual near instant shutdown type difference.

Might be best to run through those /sbin/cryptsetup open --type plain .... commands manually/interactively the first time after having created a swap partition if you do go down that route.

As said, rarely used, but can be a 'thank god' event when it is, such as otherwise a large download or video edit locking up the system due to ram being exhausted.