Slax author's Blog (RSS)

Porteus switched to 32bit busybox linked statically against uclibc (also for 64bit systems) some time ago and i havent seen any issue caused by that yet.

Make sure your busybox was compiled against 0.9.33 version othervise you'll come across 255 loop devices limit (which means that slax 7 won be able to use more than 255 modules).
I have reported this bug to uclibc devs and they fixed that in 0.9.33.x

Additionally - i have linked statically everything what i could to uclibc and benefited with ridicolously small size for /sbin/init (65KB instead of 550KB), lilo and extlinux (porteus does not use linux version of syslinux as extlinux supports ext*, btrfs and also FAT, ofc you will need syslinux.exe for installation from Windows).

i needed 32bit version of lilo and extlinux compiled statically as sometimes users were trying to install 64bit version of Porteus under 32bit OS (and 64bit binaries simply couldn't work) or 32bit Porteus under 64bit OS (and 32bit binaries couldn't work without multilib environment).

long story short: 32bit installation utilities linked statically against uclibc resolved all of the issues mentioned abowe without increasing of the ISO size.

i would also go with 32bit initrd only (except for network drivers needed for PXE boot) as you wont get any benefit from 64bits in initrd anyway.
Less maintenance is always good and this could solve the issue when users mix up initrd between 32/64 bit versions of slax.

Cheers

That is good to know, thank you very much! I'm relatively new to this uclibc static linking, is there any simple howto where I could learn what is needed to recompile binaries with uclibc statically?

unfortunately there isn't - or at least i couldn't find it on google.

Once i return home i may provide a procedure for static linking of extlinux as i have it documented somewhere.

I found this howto, related to the subject of uclibc and static linking of busybox:
http://blog.rootserverexperiment.de/2011/07/02/cross-compiling-uclibc-and-busybox/

@jm
why bother with manual compilation of whole uclibc environment while there is a buildroot?
http://buildroot.uclibc.org/

static linking of busybox is not a problem as this utility provides a static binary option in the configuration menu.

the problem may appear if you want to link other utilities like: init, lilo, extlinux, cryptsetup, etc...
i have succed with them in the past but have documented only extlinux (silly me).

Cheers

Thanks for pointing out buildroot, fanthom.
Maybe it will help Tomas, to build better initramfs.

another thing:

initramfs has very small advantages over initrd.
in fact i can see only two:

a) initramfs is destroyed after switch_root so you can save all memory used for it

b) initramfs is easier for packing/unpacking and does not require specyfying it's size in advance in bootloader config

the points above ore valid, but:
- in case of going with uclibc based initrd it's size can be reduced to 3-4 MB (unpacked) so it doesn't affect the free RAM size that much.

- size of the initrd can be hardcoded in the kernel config so "ramdisk_size=6666" cheatcode is not necessary (it still could be used to overwrite default setting in case of changing initrd size by the users)

What are the cons of using initramfs from slax point of view? let's point them out:

a)you are loosing an access to the /mnt/live/memory/images directory which makes acitavion/deactivation of the modules harder and messier (they must be mounted somewhere anyway before injecting to the aufs)

b) you are loosing possibility messing up with various configs/settings then bringing back defaults from /mnt/live/memory/images/001-core.xzm (which serves as a kind of backup in this case)

c) you are loosing a direct access to aufs writable branch in /mnt/live/memory/changes.
this access is useful for me as Porteus is shipped with 'changes-time' script which does a snapshots of all files modified in the live system in definied period of time.

d) finally - (as far as my tests gone) clean shutdown was not possible with initramfs. you can always use "lazy" umount flag but filesystem still remains dirty which doesn't look professional.

that's the reasons Porteus sticked with initrd and this probably wont change anytime soon.

Cheers

I'm actually thinking of the initramfs as a dynamic-sized initrd anyway, I don't plan to free it from memory. I'm not sure yet if it is possible this way, the goal is to try it during today :)

I read somewhere that you don't chroot / pivot-root from initramfs, one should use switch_root instead (which I do not want to use). I should be more clever tomorrow.

I built a testing version of Porteus based on SlackwareARM for my android tablet. My bootloader is locked so I couldn't specify an initrd to load at startup. My only option was to use an initramfs embedded in the kernel. With a little help from fanthom (he found a script on the slax forum that addressed this), I was able to make the initramfs act like an initrd (leaving files in /mnt/live/memory available via pivot_root), but don't see a technical advantage to this method. I only used it because I had no alternative. The basic jist is that you pack all of the files into your initramfs with an 'init' script that formats /dev/ram0, copies most of the files from initramfs (current root) into a new root folder, switch_root into that folder, and then run linuxrc from the new root, as if you were running it from initrd. So, it takes a little more time, and you still have all of the files from your initramfs sitting in /dev/ram0.

Perhaps there's a better way to handle this, but I wasn't able to come up with it :)

Cheers!

Ahau

Yes there is actually a better way and is already implemented in Slax 7 - instead of formating /dev/ram0, you simply mount 'ramfs' and do the same like before (copy all files to it and switch_root to it).

The advantage of doing this is that ramfs does consume only the RAM memory needed for the initramfs files, while /dev/ram0 consumes entire filesystem size (eg. 16MB). And the advantage of the approach in general is to be able to pivot_root, which is explained in some of the other blog posts.

The blog post as I mentioned in my previous comment is here: http://www.tomas-m.com/blog/18438-initramfs-pivot-root-solution.html

Sorry, I found your post on a google search and commented on it before reading your more recent posts! I see you've worked out a solution, and I'm interested to see it in action :)

The way in which I envision your solution working, it seems like it will cause some duplicity -- both files in your base installation (busybox and other utilities will have to be in initramfs as well as the module/bundle containing the initrd portion of the startup) and increased startup speed, since initramfs's init will have to load utilities and search for an .sgn file to find the initrd module/bundle. There are always trade-offs, I guess.

Anyway, I hope it's going well! Cheers!

Actually what is in initramfs is only busybox. Furthermore it is not in any bundle, just in initramfs.

I currently included some tools and libs in initramfs too (strace, for example) for testing purposes but those won't be there for the final release. Only busybox and ntfs-3g static binaries, and probably posixovl static binaries (if Jan Engelhardt could find a way how to add libfuse-lite to it).