A spinoff of this topic... http://www.linuxquestions.org/questi...322/page6.html

A good question about actually building the installation disk itself was asked, how does one actually build the installation disk operating system, and exactly which packages other than dhcpcd-3.x, dropbear, and busybox as well as the kernel are used, and how is it actually built? What libc is used if any? How does mdev from Busybox setup devices? And any other questions that could be asked about this part of Slackware really are seldom discussed.

So, how does one actually configure, setup for, build, and compile the Slackware installation operating system? And even more-so, could this be added onto for certain customizations?

Well, just unpacking /syslinux/initrd.gz will give answers to most of your questions.

Roughly, the binaries used are a mix of links to BusyBox (to save space) and binaries also shipped in Slackware. I doubt that Pat makes much specific compilation for the installer if any, beyond dropbear and BusyBox and dhcpcd. That's mostly gathering files shipped in Slackware and putting them into place, I think, and providing ad-hoc specific shell scripts, most stored in /usr/lib/setup.

The broad idea is to cherry pick from the Slackware packages just what's needed at time of installation, thus avoiding useless overweight (payload, in other words), not to require too much RAM.

For instance not all kernel modules are shipped, e.g. there are no sound modules.

That's also what I do when building (actually, just customizing) the Slint installers, taking as a basis Slackware's ones. For instance I ship only binaries and the shared objects needed as dependencies of gettext, fbterm and brltty, and don't ship any documentation for these programs. To get an idea, see the script appended, that takes as a basis a Slackware installer to customize a Slint one.

The regular udev is used, not the mdev from busybox. The libc version is the same as in Slackware. EDIT, well, none is needed, the user is not expected to compile programs there But if you want to do that, better take the same as in Slackware. EDIT 2. I now see that I misunderstood your question. Actually just a look in /source/installer in a Slackware distribution media shows what's done, I think.

So, if you want to add something to the installer either copy the additional files into place in the initrd tree, or if you are lazy and have a lot of RAM, just do this:Now, just out of curiosity: what customizations do you have in mind?

Attached Files

slint-14.1-brltty.sh.txt (17.2 KB, 15 views)

More or less, I just want to experiment with seeing what can be used differently as a sort of baseline installation disk to use with possibly a custom OS. I had wondered also how similar and different a bootable media disk was compared to a small embedded OS like CLFS-Embedded Here: http://clfs.org/view/clfs-embedded/x86/ is compared to the Slackware installation disk operating system, and how one could formulate even their own installation media from the ground up, using a sound example that doesn't have too much on the installation disk, or too little to be useful.

Well, it happens that I had a look into lfslivecd-x86-6.3-r2130.iso because it is usable through brltty. I would suggest though that you have a look yourself to some (probably more recent) live CDs ISOs to compare with the Slackware ISOs.

PS at the root of lfslivecd-x86-6.3-r2130.iso there is a big file root.ext2. If you mount it you'll see that it contains a full featured distribution. This is far from being the case with Slackware installers, so if you want to experiment cross compiling from there, you'll have to add a full toolchain, a compiler, a libc, etc. In short, most packages shipped in the L and D series of the Slackware distribution media.

I've actually looked at a Live disk before, but that's not exactly what I want. More or less my aim is similar to the Slackware install disk. Keep it minimal, but offer at least minimally a text browser, ssh client and server, networking for lan or wlan, partitioning tools, file system tools, and a common environment. I liked the way clfs-embedded uses musl-libc as well. Afterwards, add in the tarball of the base system that can be copied and extracted. Everything else will be left to using pkgtool and a host of in-house designed build scripts based on SlackBuilds to construct the remainder of the system.

Up till about how you create the actual bootable image and kernel is what I know offhand. After that getting the disk media made bootable through a bootloader is the next goal.

Nothing difficult. Just have a look from line 433 in the script attached to post #2 In that case I just follow Pat's advice in /syslinux/README.TXT and the ISO image can be put on an optical disk as on an USB strick.. You'll find another example in the script attached to this post, that make an USB image bootable on BIOS and UEFI firmware. See from line # 397.

Attached Files

slint64-14.1_syslinux-6.03-1.sh.txt (16.7 KB, 11 views)

[Duplicate from post #6]

As I explained in that thread - have a look at the original build script for ARMedslack.
That script was a result of me spending one day in the UK Red Hat office, having taken a colleague there on the weekend, who wanted to spend 1 hr catching up on some work.. which turned into a day (If I'd have known he was a work-o-holic I'd not have gone!). Since ARMedslack was complete except for the installer, and having realised that this guy's idea of 'hour' was not 60 mins, I started reverse engineering the x86 installer image, figuring out which binaries belonged to what sources, and making changes where necessary - such as building bash since ARM needed it.
At the end of the day, the installer was ported to ARM and I just needed to make some ARM specific patches to the installer OS scripts.

The script that builds the installer image mostly installpkg's the package set into a temp dir, and cherry picks the necessary binaries and libraries from there, placing them into the installer file system. Many binaries and libs are moved into /sbin and /lib for legacy reasons since this was their original location back in 2006 (or whenever I created the original script). I don't know why the libs and bins were not in /usr - maybe the locations in the t?z packages shifted over time; I just tried to make the ARM installer model the x86 as closely as possible since it had a better chance of working :-)
The original installer build script included a few patches to the installer OS itself to add some ARM specific patches, but these were merged upstream a while ago.
The script unpacked the x86 installer image (which was a loop back fs at the time - it's now an initrd), removed all of the x86 binaries then copied across the list of libraries and binaries, applied any patches to the installer OS scripts and made a new loopback fs with enough padding for temporary files.

The script worked fine for its purpose but didn't include any support for Kernel modules since the original and only ARM kernel was monolithic since the only target -- the StrongARM RiscPC -- only had about 5 pieces of expansion hardware, and back then modular kernels weren't very common (in fact many drivers didn't even work properly when built as modules!).

Slackware x86's installer was managed entirely by hand, and was rarely updated since Pat said that changing things like glibc in the installer had been problematic in the past, so he only changed what was absolutely necessary (usually only updating the kernel modules). My attitude is quite different - I prefer to automate everything and document it : we're going to need to update stuff at some point, so we might as well have a script that does it all and just amend the script as we go along.
I update the ARM kernels more frequently than x86 so I ran into a number of issues that necessitated an update, and fixed them before x86 got there.

When alienBOB had mostly completed (as I recall) development of Slackware 64, an installer was needed, so he took the ARM build script and extensively modified it to include Kernel module support; made it work properly to build the installer OS (including USB file system images) for multiple targets - including an x86, x86_64 and s390 (although I don't think Mark has ever used it since s390 was at rest by then). In addition to using the x86 installer image as the source, it also allowed building from Pat's master installer archive for obvious reasons.
I recall at first that Pat wasn't entirely convinced about the installer build script since it's quite a piece of engineering to comprehend (alienBOB's engineering, not mine - my original script is straight forward ;-) ) and using it to build the 32bit installer meant it'd be a complete refresh of the component parts; but I recall that he acquiesced after a short while since the resulting installer worked fine.

There are a few things that are compiled in the installer such as bash (I don't recall exactly why since it was 8 years ago, but it had something to do with making a lighter weight one, or making it not link against some libraries that were not included in the installer), dhcpcd, busybox.


The easiest way to customise it is this:

as root (needed to maintain the device perms and ownerships on /dev)

5 members found this post helpful.