Alien Pastures

My thoughts on Slackware, life and everything

Month: January 2010 (Page 2 of 3)

Remote installation of Slackware using ssh

January 24, 2010 / / 15 Comments

When you are installing Slackware, you have several options of using the network. Your packages can be on a NFS, HTTP, FTP or SaMBa server. But it still requires you do be physically present behind the keyboard of the computer you are installing Slackware on.

Or does it?

There is a way to make the installer launch an embedded SSH server automatically. Once that SSH server is running,  you can do a remote login to this machine and install Slackware.

I hear you say, “why would I want to install Slackware over a ssh session at all”? Well, this feature is particularly important for people who need to install Slackware on a headless server – think of a server in a data center. You still need to boot the Slackware installer of course, but you do not need a DVD for that. If you have a PXE server, you can boot the installer over the network and never have to visit your computer “in the flesh”.

If you are familiar with Slackware’s installation, you know that you have to answer a few questions before you can start with a network installation. At a minimum, you need to

  • configure your keyboard layout, and
  • the configuration of your network card.

For these to be configured automatically, you must provide the installer with the answers. If both answers are known, then the installer can configure your network card with an IP address and start the embedded SSH server (Slackware uses dropbear as the SSH server). You can then do a remote login as root (no password will be asked! Be sure that your network is secure before you attempt this).

After you have logged on to the dropbear SSH server (you must know what IP address your to-be-installed computer has been configured with of course) you can remotely start Slackware’s “setup” (but first you have to run the command “. /etc/profile” – watch the dot! – which initializes the environment so that the setup utilities become available).

Burning question: how do you tell the installer the answers to the above two questions?

I am assuming you are booting the installer from the network, using a PXE server. Now, let’s assume your keyboard layout is “us“, your network interface is called “eth0” and you have a DHCP server in your network. Then, you need to change the “pxelinux.cfg/default” file like this:  add the following string to the “append” line for your boot kernel:

kbd=us nic=auto:eth0:dhcp

If instead, you want to use a static IP address of “192.168.0.11/255.255.255.0” (i.e. a netmask of 24 bits) the appended string becomes:

kbd=us nic=auto:eth0:static:192.168.0.11:24

Slackware’s installer uses udev for automatic hardware initialization and configuration. If you don’t want to use udev but want to determine yourself what module to load then this would be the appended string (I also added a default gateway of “192.168.0.254” to the mix):

noudev kbd=us nic=e1000:eth0:static:192.168.0.11:24:192.168.0.254

The generic notation for the kbd= and nic= parameters is:

kbd=<keyboard_layout>
nic=<driver>:<interface>:<dhcp|static>[:ipaddr:netmask[:gateway]]

If your installer uses udev (the installer of Slackware 13.0 and later uses udev by default, earlier versions of Slackware did not have udev in the installer) then the “<driver>” string can be “auto”. Without the use of udev, the “<driver>” must be an actual kernel module for your card, like “e1000” in my example above.

I’d like to hear if you ever used or wanted to use this somewhat hidden feature of the installer!

Eric

Note: If you do a “normal” Slackware installation and want to start the dropbear SSH server manually after configuring the network card, you can do this. Just run:

/etc/rc.d/rc.dropbear start


Compiling vlc (and other software) with gcc 4.4.2

January 11, 2010 / / 1 Comment

Last week, an upgraded gcc compiler suite (version 4.4.2) was added to slackware-current . The new Gnu C compiler reveals software compilation issues in several programs that did not occur with the previous version of the Gnu C compiler. A nice summary of issues you may encounter when building software using the scripts at SlackBuilds.org can be found on Ponce’s blog, along with the solutions he found that fix these errors.

So far, I only ran into one compilation issue (actually it was reported first on LQ: http://www.linuxquestions.org/questions/slackware-14/alien-bobs-vlc-slackbuild-fails-on-current-781414/), when compiling VLC and to be more specific, compiling the twolame library which I add to my VLC package for Slackware.

The error you will get is this:

?psycho_2.c:203: error: array subscript is above array bounds

The fix is simple. One file needs a patch:

--- twolame-0.3.12/libtwolame/psycho_2.c.orig   2008-01-09 12:06:21.000000000 +0100
+++ twolame-0.3.12/libtwolame/psycho_2.c        2010-01-11 15:15:28.000000000 +0100
@@ -121,7 +121,7 @@
        window = mem->window;
        ath = mem->ath;
        numlines = mem->numlines;
-       partition = mem->numlines;
+       partition = mem->partition;
        s = mem->s;
        tmn = mem->tmn;
        fthr = mem->fthr;

I have uploaded this patch as well as a modified vlc.SlackBuild script to my repository: http://slackware.com/~alien/slackbuilds/vlc/build/

Eric

KDE 4.4 release candidate 1 packaged for Slackware

January 11, 2010 / / 4 Comments

Just a quick update:

I have finished building Slackware packages for KDE 4.4 RC1 (aka version 4.3.90). Compared to the previous Beta2, several of the dependencies have been updated. And just as with Beta2, I was unable to create language packs for ca, da, es, et, it, sr due to docbook errors.

Get KDE 4.4.RC1 packages for Slackware-current (64-bit only) here: http://alien.slackbook.org/ktown/4.3.90/ … Because the sources and SlackBuild scripts are available as well, you should be able to create 32-bit packages quite easily yourself.

Have fun, Eric

Robby’s libata switchover howto

January 9, 2010 / / 8 Comments

The new kernels in Slackware (post 13.0) have one important change compared to previous kernels. This change will affect anyone with Slackware installed on an IDE disk (like /dev/hda) who wants to upgrade to the latest state of affairs.

The new kernels exclusively use “libata”. The last bits of the old IDE/ATA subsystem have finally been removed.

This means, that your IDE disk will be recognized as a “SCSI disk”. The device name “/dev/hda” will change to “/dev/sda” when you boot the new kernel. As a result, your computer will refuse to boot because the bootloader (grub or lilo) can not find the root device.

Robby Workman has written a HOWTO for anyone who wants to do this upgrade. The article was published as http://rlworkman.net/howtos/libata-switchover. By following the HOWTO you will not have any issues in upgrading to the new kernel.

I will print Robby’s HOWTO in full below to give it some more coverage:

libata_switchover
20100110
rworkman

/*
Thanks to David Somero, Old_Fogie, gegechris99, and GazL for valuable
feedback and enhancements to this document.
*/

This is written to provide one of several ways to retain a working system after upgrading from Slackware 13.0’s kernel to the newer kernel in -current (which removes support for the “old” ide subsytem, thereby causing all /dev/hd* devices to have /dev/sd* names.

1. Upgrade the kernel and kernel-modules packages normally.

2. Edit /etc/fstab to reflect the change from hd* to sd*.

If you have multiple SATA devices, and especially if you have some of
both hd* and sd* devices present already, then you’re basically going
to be playing a guessing game right now, and you probably want to
consider using some of the persistent symlinks in /dev/disk/by-*/
instead of raw device nodes.

* If you are using one of the generic kernels (requiring an initrd),
then use the sd* name for the root device when creating the image
(edit /boot/initrd-tree/rootdev and then re-run “mkinitrd”).

* You will almost surely want to remove the udev rules file for cdrom
devices (it will be regenerated on the next boot with correct
information reflecting the new libata stuff):
# rm -f /etc/udev/rules.d/70-persistent-cd.rules

* Speaking of optical devices, if you have multiple disk drives and an
optical drive using the old ide subsystem, then be aware that the
optical drive will get a /dev/sr* name instead of /dev/sd* — this is
relevant because you might see something like this (if your optical
drive is currently /dev/hdb):

Old Name –> New Name
/dev/hda /dev/sda
/dev/hdb /dev/sr0
/dev/hdc /dev/sdb

3. Run lilo. Note that you have made no edits at all to it yet, unless
you needed to edit it for the new kernel. Specifically, do not make
any changes with respect to hd* –> sd*.

4. Reboot. At the lilo prompt, press <TAB> and add an append for the
real root device (which will no longer be /dev/hd*). For example, if
the old root device was /dev/hda1, and it will now be /dev/sda1, and
the name of your kernel image is “Linux” then you would type this:

Linux root=/dev/sda1

5. Once the system comes back up, then fix /etc/lilo.conf, run lilo, and
reboot again to be sure everything is correct.

Good luck! Eric

PS: I have refreshed the copy of Robby’s text so that it reflects the updates he made to the original after feedback from several people.

Bleeding at the edges again?

January 5, 2010 / / 4 Comments

… Ok, ok, it is not so bad actually! Au contraire!

Slackware Linux development made a big leap today, when Pat Volkerding updated the distro’s “vital organs” of kernel, glibc and gcc. The “dull” phase of the slackware-current development cycle is over hopefully, and it’s back to the bleeding edge.

To be fair, gcc 4.4.2 has been sitting in “testing” area for quite a while now, and we think it is time to promote it into the core. With glibc 2.11.1 we are pushing it, as this is the most recent stable release, and the 2.6.32.2 kernel was much-anticipated by those who run -current on their computers.

Note that the new kernel has full support for EFI (the Extensible Firmware Interface which is going to be the replacement for the ageing BIOS on modern computers). This means that there is also support for GPT partitions. GUID Partition Table is a standard for the layout of the partition table on a physical hard disk (part of the EFI specification and meant to overcome the 2 TB size limitation of MBR partitions). We still have to look into updating the Slackware installer for automatic GPT partition recognition, but you will be able to use GPT partitions if you do some footwork yourself before running “setup”.

With this update to Slackware’s vitals, the stage is set for further tweaks of the core, but I think that for now, you will have plenty to play with.

And as promised to those running the 64-bit version of Slackware-current, I have made available multilib versions of the new gcc and glibc packages! Thanks to Pat Volkerding who allowed me sufficient time to build and rebuild these packages on my old computer until they were just perfect (I hope) and could be released along with the Slackware originals.

You can get them here: http://slackware.com/~alien/multilib/13.1/ (I took the liberty of assuming that 13.1 will be the version of the next Slackware release, mainly because I needed to give that directory a name).

For detailed instructions about what multilib means to the 64-bit Slackware and how you can add it, read this wiki article: http://alien.slackbook.org/dokuwiki/doku.php?id=slackware:multilib

Have fun! Eric

« Older posts Newer posts »

© 2025 Alien Pastures

Theme by Anders Noren — Up ↑