Well that was an interesting afternoon.

I got Bob's CD burned on the second attempt. Don't know why the first one failed; maybe because I was root and wodim doesn't like that. Or perhaps it was just a bad disc. The second time around I used a new disc and worked as myself (I'm a member of the cdrom group on Debian).

I booted it up and spent a long time playing around with it. It's a nice friendly little installer, but it took me a bit of exploration to work out where the software actually comes from. Turns out I need a local repository. I will create one on my data drive where there's plenty of room; the manual on the CD is very informative on the directory structure you need. The nice thing is that I can download the actual packages needed for a skeleton Slackware (a and some of n plus links, which I assume is in ap) at a pace that suits my Internet package, then run setup again when I'm ready. The result should be quite similar to a freshly built LFS.

I'll build it on my spare partition (sda8) and get it up to full working order over a couple of months, then say goodbye to Crux and copy Slack over to sda1.

Interim thanks to everyone who has helped me so far.

8 members found this post helpful.

Please post how things work out, and any adventures in Slackware you might have.

1 members found this post helpful.

I have Slack! It's a bit spartan at the moment, but I have got it to boot using the generic kernel. First time I ever made an initrd and it took me two tries. The first unsuccessful time, I went by the README file in /boot. But DDG showed me a thread in this forum that referenced a script by Pat for generating correct mkinitrd arguments and when I used that as a guide I got an initrd that actually worked. Maybe it's a bit cheeky making suggestions when you are so new to the distro, but I think that /boot/README.initrd should point the reader to this excellent script (which is located in /usr/share/mkinitrd).

I managed to get the network up by copying a script from Crux (which also uses bsdinit) and running it by hand. The rcM runlevel script expects a pair of scripts called inet1 and inet2 (one to bring up the interface and the other to launch dhcpcd), but I don't yet have those for some reason; I'll have to find out where they live.

This is going to be fun.

PS: found the scripts! They're in a separate package called network-scripts.

3 members found this post helpful.

It's not a Slackware experience if something doesn't go wrong when you're learning.

The screenshot thread is that way >>> [hint]

Don't be daft! I won't have a desktop for ages yet.

If you have slackpkg set up, you can use slackpkg file-search $FILENAME or you can use the online Slackware Packages page and you can change the "Mode" dropdown to "content" and then search for filenames. Keep in mind, the search won't show you beyond the number set in the results drop down, so if you have it at the default of 10 and you don't see the file you were expecting, it may just have more than 10 results, so I'd recommend changing it to 100 or 1000.

1 members found this post helpful.

Congratulations hazel! I'd like to point out that you can eliminate initrd altogether unless you encrypt your filesystems. For most people (and please do forgive this silly pun) filesystem support is the crux of the biscuit.

2 members found this post helpful.

Well, whenever you get round to it then!

And unless you have multiple internal drives.

Only if those drives are prone to changes... and even then, AFAIK, you should be able to use PARTUUID without requiring an initrd.

1 members found this post helpful.

This box has 4 internal drives and several external drives and I never create nor use an initrd. FWIW I use lilo and only some of the 4 drives are hard assigned with LABEL in /etc/fstab as well as two locations in /mnt for USB thumbdrives that error out to no effect until one is plugged in. I just want a defined location where the routinely important ones go. No problems to report at all.

Edit: Oh wait that isn't perfectly correct. One of the many externals is a small, powered eSATA enclosure housing a 2TB hard drive and a Plextor DVD burner and recently I destroyed the partition table on the hard drive because of a perfect storm combination of stupid errors, one by Legacy Bios partition requirements, a silly lilo error, and a huge foolish mistake on my part trying "fix-table" in lilo. Anyway ever since then if I boot with the external enclosure powered down and power it up in KDE, the system hard freezes. So I have to drop back to runlevel 3 when I power that enclosure up but Im reasonably certain that has nothing to do with a lack of an initrd.

it worked fine before my stupid action so once I have a solid day to try to recover data from the wipe and can then recreate the partitioning, that minor inconvenience should again disappear.

2 members found this post helpful.

What's wrong with the initrd?

I heard that some drivers steps on each other shoes, and using an initrd is definitively better than loading and activating every obscure driver possible.

Umm, what?

Unless you're using kernel-huge, you *need* an initrd in order to boot as the generic kernel has all file systems as modules. Simple as that.

Running huge kernel is not recommended, generic kernel is the only one officially supported.

Also, instead of running the helper scripts and whatnot, this is usually all you need, directly:

Replace the kernel version and file system as appropriate.

2 members found this post helpful.

There's nothing wrong with using an initrd.

2 members found this post helpful.

I only know one way to avoid an initrd and that's to build your own kernel. Which I do in Crux and LFS obviously because they require you to. A time is coming when I will have to build all my kernels to patch away that stupid acpi bug that my computer has, but Slackware doesn't use the most recent kernels that cause that problem.

@enorbet: I wonder if you are having the same problem with lilo that I had yesterday. It's 24.2, the same version that Crux uses (and that I have ported to LFS) and I've never had any problems with it in either of those systems. But in Slackware I get a weird error: "First sector of /dev/sda1 doesn't have a valid host signature". I googled and saw that running lilo with "fix" was dangerous so I'm leaving it at present. I'll start a new thread on it later.

@birdboy: that was the command I used the first time around. I got it out of that README file. And it didn't give me a workable initrd. The version created by Pat's generator script did.

Interesting.
Over the years I've found a initrd is not necessary, the huge kernel works just fine, always has, but, OTOH, I don't do anything esoteric with the hardware.
It was only when I started using the DUSK kernels, because the 4.14.xx kernel doesn't properly support the newer CPUs, that I started using an initrd.
When I have used an initrd, as I am now, the command suggested by birdboy to create the initrd has always worked.
As mentioned in another thread recently, the more recent hardware is so fast I can no longer "see or feel" a difference between the generic and huge kernels.

Edit in: Just replaced the 4.19.9 generic kernel with the huge version of the same, edited the lilo.conf file and rebooted, of course, and, unless one is using a utility of some sort, there is no way to "see or feel" the difference between the generic and huge kernels.