Slackware hardware detection and provisioning
 

Hi there slackers. I've just dicovered slackware and very quickly fallen for it. I like the simplicity and control that it brings.

I have many questions about slackware but I'll start with just one for now.

Is there any difference between installing slackware from DVD and imaging it via Clonezilla. Specifically with regard to harware detection and provisioning. I know that in general Linux distros will detect and setup hardware at boot time, so an installation can be moved to other hardware without any issue. Provided that a huge kernel is used as opposed to a streamlined kernel + initramfs.

I ask this because slackware seems to do a very good job of setting up the hardware. And also, it doesn't have a Live environment, seems geered towards a traditional UNIX installation.

I am considering remastering a corporate roll-out based on slackware, and i was wondering if using a clonezilla image and PXE boot to distribute it would work as well as a fresh install via the offical slackware DVD.

Does the slackware installer (bootable ISO) do any extra preparation for the speficic machines hardware during installation, that is not done on boot of differing hardware?

P.S. I've ordered a few DVD's, t-shirts and caps for me and my work colleagues. I've never felt so comfortable so quickly with any other Linux distro. I was going to base our roll-out on debian stable but the new Haswell hardware, in particular the HD graphics has stuffed that up. But slackware 14.1 works well on the new Dell hardware. And the fact that a new version comes out roughly once a year means that we can rebase on up-to-date kernel, xorg, drm, mesa etc more frequently. With slackware I feel I get the best of both worlds, a solid, well tested base, yet with the up-to-date upstream and flexibility at application level. Slackware, like FreeBSD, was born to compile. I am surprised at how well sbopkg and slack-builds works. Loving it so far! But early days yet.

There is one gotcha with deploying images of a Slackware install. http://blog.tpa.me.uk/2009/12/03/mig...-new-hardware/

Thanks allend. That article really applies to any Linux distro. And I am aware of the udev eth0 issue, I've fixed it many times. If that's all I have to worry about then "nae bother" as us scots say.

However, I meant to ask specifcally if slackware does anything differrntly here than other distros. I know Debian can be transported without any hardware detection differences. Well, except for udev net and xorg.conf. I was asking if the Slackware installer does any extra hardware configuring?

No, it does not. You should be able to transfer a Slackware installation to any other hardware without issues.

Eric

Thanks Alien Bob, that was the answer I was looking for. And I know you know your slackware. I saw your presentation at one of the Dutch universities on youtube. Very intersting history of Slackware and of Linux in general.

I'm quite busy next week, but I'm itching to start some serious playing around with Slackware. I'm sure I'll be asking lot's of questions here in the near future. I'll try to do research first ofcourse.

The only thing to watch out for is if the other hardware requires proprietary drivers (ie: broadcom-sta wireless drivers or nvidia graphics drivers).

Yes, proprietary drivers may require a rebuild or swap out, but you can always uninstall and rebuild them as needed.

Thanks guys. My intention was to use a vanilla Slackware install. Then apply my configurations and extra software. Proprietary driver can always be installed specific to one particular installation (hardware). It's better this way, because then the latest driver can be used. I noticed that the proprietary nvidia and ati/amd graphics drivers are not installed. But what about other proprietary drivers like broadcom etc? What is Slackwares policy on non-free? Is it a strict as Debian or is it just left to the user to decide. I haven't looked into codecs and DVD playback yet.

There's a slackbuild available for the broadcom wireless driver. You just need to know what card you have and what driver you need and also which drivers needs to be blacklisted.

Same for the nvidia drivers. I've used the proprietary drivers from nvidia's website with no problen.

http://slackbuilds.org/

You can also use sbopkg to install and update slackbuilds.
http://www.sbopkg.org/

As for codecs, Eric Hameleers has a lot of packages on his website. http://slackware.org.uk/people/alien...d_slackbuilds/

You can also check out MLED (by Niki Kovaks), which has a lot of codecs and even a package for the broadcom-sta wireless driver.
http://www.microlinux.fr/mled.php

If you want to refer to me, at least spell my name correctly.

Eric

Some people get upset when you omit an "e", others get upset when you add one.

(My True Last Name in meatspace often gets an additional "e" added to it. For a while, my nickname at work was "Ned" for "No E Dammit".)

I consider it a matter of careless disrespect if you are literally able to copy/paste someone's name and still manage to spell it incorrectly.

Eric

Sorry about that. I corrected my mistake.

Thanks Bertman123,

Once again guys, thank you very much. I know about slackbuilds and sbopkg. They are an awesome combination. Amazingly, I find sbopkg faster than most GUI package managers. And less error prone, on account of slackware's policy of KISS and control. I will look for the codecs etc when I get time. Good to know some non-free is available if needed.

Still waiting for my Slackware store delivery, I hope my VISA debit card payment went through. There's no order tracking, and I've had no email mentioning payment failure.

OK, just done some R&D into a Slackware based roll-out. Clonezilla is a good contender. It seems to sort out the udev id issue for you (by default, you can turn it off). What I recommend to anyone doing this is to keep the partitions to smallest sizes you're gonna install to. Clonezilla can resize partitions bigger but not smaller. I used gparted in a livecd to shrink the existing installation before imaging. But it wuold be better to install it this way initially.

Another way I'm thinking of doing it is a script that pull in my packages and settings and essentially sets everything up automagically. So the end result would be to install vanilla slack, then run a script which would wget to update itself and pull everything from a sort of repo and perhaps database. This way is more flexible and allows for centrally managed changes over time. However, it will probably be more work initially.

In my previous roll-out I used livecd generating tools to remaster an installabel ISO. It was cool but the remastering is slow (not a big deal) and the development cycle required lot's of re-installing.

Either way, what I've learnt is to put everything in packages. Not only is it easier to distribute and update, it's easier to track the customisations.