I'm quite used to installing NetBSD by breaking into a shell from the installer and taking it from there. It allows me to use GPT for partitioning the disk among other advantages.

I presume there's a way of doing the same with Slackware but it's not staring me in the face at the moment. Directing me to a guide would be useful.

The rationale behind this is that it is awkward to install Slackware in a Xen domU (guest, in layman's terms) using the installer. Simply unpacking the sets and fixing fstab and whatever else would make life a lot easier.

I don't understand what you are trying to do. Do you not want to boot off the ISO at all?

I'm a little muddled myself. It's been a while since I needed to do this. As far as I remember, I was not presented with a console while setting up a paravirtualised Linux domU in Xen (a virtual guest that runs at near native speed). I got around it at the time by installing Slackware as normal to an fdisk partition on the real disk, booting back into Xen and setting up this Slackware as a virtual machine from there. (Very convenient, as it allowed me to run the same Slackware as either a virtual or real machine.)

This option is no longer available to me, since I need GPT partitioning and there are too many roadblocks preventing me from going down the same route I went down years ago. So I thought it would be useful to install Slackware perhaps from the host, by unpacking the sets, entering the chroot and doing all the configuration from there. A little bit like how you can break out of the Slackware installer to do LVM, RAID, LUKS, etc., except that you don't boot the installer at all.

Yes, very muddled indeed.

I suppose you are essentially looking for a way to "install" Slackware packages to a directory? Since Slackware packages are just fancy tarballs, you could conceivable uncompress your pkgtools, tar, core-utils, and probably a few others to a directory, then you could chroot into it and then use pkgtools to install the rest there (reinstalling the packages you unpacked so they show up properly with pkgtools.

The problem I foresee is just trying to find out what packages are required to get pkgtools to work (at least Installpkg/upgradepkg, since you wouldn't really need the dialog provided by pkgtools).

Once everything is installed to the chroot, you could then run your normal post-install scripts like netconfig, timeconfig, etc, followed by editing your lilo.conf to ensure everything is listed properly, and then finally installing it to the MBR.

I almost wonder if it would be easier to install a system elsewhere (maybe a VM), then copy everything over to the new chroot (maybe creating a giant tarball and then extracting it on the new computer).

1 members found this post helpful.

This is what I do with NetBSD. The question is, why extract just the pkgtools? Why not extract the whole lot, since the rest of the Slackware packages are also tarballs?

That's another way of doing it, and I'm weighing up the options. Things get a little complicated installing into a paravirtualized guest in Xen. HVM guests fine, because you get an SDL console, but PV guests not so straightforward. The console is tricky to get working for starters.

I suppose you could, but then pkgtools would not be aware of any of the installed packages, plus there's all the doinst.sh files that are run to set up symlinks, handle .new files, etc.

I suppose if you reinstalled all packages after you extracted them so pkgtool is aware and doinst.sh can be run, but that just seems like double the work, so it'd probably be easier to find just the packages needed for pkgtool.

Do you want to install Slackware on an empty partition from a .iso on your running system? That's what I want to do.
Here's how I propose to go about it (I haven't done this before)

First attempt (succeeded already)
1. Extract the initrd image to the file system (e.g. in /tmp)
2. chroot into that image
3. mount /proc
4. run setup

This isn't a full solution, because I don't yet have any media to install from. I'll try that next and post again afterward.

Here are the commands to get this far. slackware-14.2-install-dvd.iso is mounted at /home/dunc/slkdvd

cd /tmp
rm -rf initrd
mkdir initrd
cd initrd
cat /home/dunc/slkdvd/isolinux/initrd.img|gzip -d|cpio -i
chroot . bin/bash
mount /proc
usr/lib/setup/setup

This brings up the light blue menu on the dark blue background. An error message flashes up on the way - will investigate that next

From http://wiki.xenproject.org/wiki/CD_Rom_Support_in_Xen
From http://wiki.xenproject.org/wiki/Xen_...eginners_Guide
which links to http://wiki.alpinelinux.org/wiki/Cre..._Linux_PV_DomU
Might give you some ideas.

1 members found this post helpful.

Ran chroot under script. Didn't see any error.

*** New step: hard-link the iso image into the initrd created in my previous post:

cd /tmp/initrd
ln /usr/iso/slackware-14.2-iso/slackware-14.2-install-dvd.iso

*** UNMOUNT the partition to be installed into

umount /dev/sda3

chroot . bin/bash
mount /proc
mkdir iso # Don't use cdrom
mount -oro,loop slackware-14.2-install-dvd.iso iso

usr/lib/setup/setup

---------------------------
Now back in the menu.

I selected swap partitions. Only able to do that because the main system doesn't have any.
Otherwise you'd have to do this once booted into the system you're about to install.

Select /dev/sda3 and quick format, ext3.
Decline offers to use more Linux partitions or add others.

Now at the SOURCE MEDIA SELECTION prompt, select "Install from a pre-mounted directory" and specify "/iso/slackware"

accept defaults in PACKAGE SERIES SELECTION dialogue

Select full installation, and it starts

You can check progress by doing a chroot from another xterm. The mounts therein are not visible to the main system (but added swap disks are).

Back on the main screen, once the install finishes, I skip network config (can copy from main system) and lilo.
Unmount everything before exiting chroot (otherwise /sda3 will nor be cleanly umounted at reboot time).
Since I installed vmlinuz on the main system already, I can boot appending "root=/dev/sda3": it will use /sda3/lib/modules/4.4.14-smp but they are the same as in /lib/modules.

Tried a reboot with root=/dev/sda3 and everything in the newly installed system is OK.

1 members found this post helpful.