SlackwareThis Forum is for the discussion of Slackware Linux.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
I attached a file that talks about automated installation of Slackware by modifying the initrd.img on the installation medium. See section 6.5 of the attached PDF.
Is this still a viable way to execute an automated installation of Slackware?
If so, maybe it should be documented as is on docs.slackware.com. I knew it was possible to use tag files to automate the installation, but did not know that the rest of the installer could just be skipped by using a shell script. I've found next to zero documentation on the subject of unattended or automated installation of Slackware.
Is this still a viable way to execute an automated installation of Slackware?
Yes, with a few modifications as Danil de Kok wrote that book for Slackware 12.0. For instance now the initrd is a CPIO compressed archive, there are more configuration scripts in /var/log/setup, we need to cope with UEFI, etc.
Quote:
I've found next to zero documentation on the subject of unattended or automated installation of Slackware.
I am ready to contribute something to SlackDocs as I am acquainted with the Slackware installers but the question is: what?
To answer that question we need to choose target audience(s), uses case(s) and context(s) as that determines the needs that our "product" (the document + scripts) should fulfill, to define its scope.
Let's take a few examples:
We want to install Slackware for friends or relatives either to revive an old box or in a new one, with or without wiping out the previously installed OS.
We have several boxes on which we need to install Slackware at the same time.
We are an OEM that sells computers with Slackware pre-installed.
About the context: Obviously the work to do will vary if we want to put the boot menu on a hard disk's partition or MBR (in case of BIOS or UEFI) or in the firmware (in case of UEFI), if we want to use a whole disk to install or if we need to preserve an existing OS, etc.
So, what scope do you have in mind?
Last edited by Didier Spaier; 07-11-2015 at 06:59 AM.
I think the best way to start would be to address unattended installations for enterprise workstation deployment. While I realize (did not know this at the time I switched to Slackware) that Slackware is not intended for large deployments, it could easily be used for small businesses in the home or at a small office. A medium sized business could even venture into the world of Slackware with this scope.
I've seen mentioned on LQ that there is no such thing as unattended installation for Slackware. While I did not believe Slackware did not have the ability to be installed unattended, I can only imagine the lack of documentation prevents most system administrators from even trying to deploy a Slackware workstation force.
This scope would require, I think, but please make suggestions if it is flawed:
The installer use a local media or a PXE boot to install
Should allow for installation on multiple machines or just one machine
It would use the whole hard disk
*Automatically partitioning approximately 10% of disk for a full installation to root
The rest of the disk for home using the remaining % of the disk
Should be easy to use a custom set of tag files from PXE server or via local media
*Maybe my partition sizes could be adjusted to something more sane. On a 1TB disk, 10% is over kill. I still use 500GB disks though.
I think if I saw a full example of a modern day Slackware unattended installation, I could probably modify it to work with other scopes.
Some thoughts:
1. That's already what the Slackware installer allows (setup vs pxesetup, thanks to Alien BoB).
2. Installation on multiple machines: if at the same time, either use several physical media or through PXE.
3+4+5: The Salix installer can do that (if you choose AUTOINSTALL), see attached script. It makes a root partition (xfs) and a swap one using either sfdisk or sgdisk, no /home. IMHO /home is useless, anyhow it would be possible to modify that script so that it takes instructions from an additional config file e.g. to choose a different layout or filesystem.
Similarly, I see that Daniël de Kok proposes an automated installation script (under 6.5 Automated installation script) that includes the settings to be used by the scripts in /var/log/setup. It could be useful that this script instead read these settings in a configuration file so that the user can do all customizations just setting the variables in the config file, instead of modifying the automated installation script.
Last edited by Didier Spaier; 07-11-2015 at 05:06 PM.
A few thoughts. I for one don't see a lot of value in preparing automated unattended install media, building tag files, figuring out how to integrate with the existing step process, unless you need people to perform installs on equipment in the field.
Slackware pretty much after 13.0 on with the changes to X.Org etc works out of box with virtually no additional configuration steps or requires a substantial number of actions the installation scripts don't even try to help you with.
In the end using custom tag files etc and scripting the installer is going to leave you with a drive partitioned and formatted, a file system copied onto it, and a boot loader installed. Why bother?
One of the wonderful things about Slackware is its easily copied. Just install it, configure it on one 'gold system' or even a VM. Setup everything they way you like. Use the generic kernel, delete some of the 70-persisten-* udev rules and ssh-key. Now just tar up the entire thing. Create a few simple scripts to partition disks and create filesystems on the targets, extract the tar from some network server (net pipes faucet) and write it down to the disk. Last step your script chroots into the installation and installs the boot loader, reboots done. If the hardware is all mostly the same those scripts don't even need to be very smart.
@chemfire I'm doing almost exactly what you say. I used QEMU to install, customize and configure base installation of Slackware. Then I tar'red everything up. Then I have a script that partitions (SATA attached, hotplug) the target disk and extracts the packed rootfs. Then it installs the kernel using lilo. That's it.
I'm using tagfiles all the time for my Slackware-based MLED installations. While Slackware is not really meant to be fully automatized as RHEL, CentOS or SLED, you can design your installations to be as centralized as possible. When I have two dozen desktop clients to install, I usually clone them using G4L (Ghost For Linux). Hostnames, users and files are all managed by the server.
...
I attached a file that talks about automated installation of Slackware by modifying the initrd.img on the installation medium. See section 6.5 of the attached PDF.
Is this still a viable way to execute an automated installation of Slackware?
...
Depending on how much customization is to be done, the following may also be useful. Substitute my location for yours:
Does this method also include all of the installed packages?
I ask because I am currently testing Slackware in a VM and it will probably take a while to get everything "just right".
Once I've achieved that I would like to be able to port that over to a physical machine without having to replicate all of my work.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.