Giving killX some love

Forum rules
Share your brain ;)
User avatar
xaos52
The Good Doctor
Posts: 190
Joined: Thu Aug 15, 2013 11:59 am
Location: Eernegem, Belgium

Giving killX some love

Unread post by xaos52 » Mon Sep 30, 2013 3:15 pm

* Giving killx some love

It is my intention to document here how I got killX installed and configured.

This document is best read with emacs and org-mode installed.

Why killX?

Well, it is really slackware64 thrown on the BBQ by our excellent
grillmeister machinebacon.

Now I am using linux for a long long time, but I had never before
installed any slackware version, so it is totally new to me, which
means I may be using for instance package install tools that are not
the most appropriate for the situation. If that is so, dear
reader, do not hesitate to let me know. Learning all there is to know
about venerable slackware is one of the reasons I am starting this
write-up.

Let me tell you up front that I am already very fond of it. It does
not come with the newest and shiniest in linux land, but it seems to
me like it is an excellent system to learn everything you always
wanted to know about installing and configuring a linux system from
the command line.

Since all we have to start with is an archive, we will have to do the
install from a working linux system.

Here are some details on the system I will be installing from and to:

Image

Now I am peculiar about the disk usage on this system. I use Logical
Volume Manager (LVM) to manage all my Hard Disk disk space, and I do
not want to change that for any reason in the world, unless someone
can convince me that it is bad, bad, bad...

So we impose ourselves an additional hurdle. KillX has to go to a
Logical Volume (LV).

I am using a pretty standard Debian Jessie system to do the install
from.

** Preparations on the jessie system

*** create a new logical volume

Setting up the Physical Volumes is outside the scope of this report.
el_koraco has an excellent tutorial on it over at the #! forum.

Creating the logical volume:

Creating a 20GB logical volume here because I am not short on space.
If you are followingd this just for testing, 6GB is probably more
than enough.

BTW: I use _ as an alias for 'sudo'. It is the command I use more
than any other command, so a one-character alias is handy. You get
used to it.

Code: Select all

_ lvm
lvm> lvcreate -L 20G -n killX-nietzsche /dev/mapper/VG10
  Logical volume "killX-nietzsche" created
lvm> lvs
  LV                    VG   Attr      LSize  Pool Origin Data%  Move Log Copy%  Convert
  VG10-waldorf          VG10 -wi-a---- 20.00g                                           
  arch                  VG10 -wi-a---- 40.00g                                           
  jessy                 VG10 -wi-ao--- 10.00g                                           
  killX-nietzsche       VG10 -wi-a---- 20.00g                                           
  linuxBBQ-rice         VG10 -wi-a---- 20.00g                                           
  linuxBBQ-yuebing      VG10 -wi-a---- 20.00g                                           
  livarp                VG10 -wi-a---- 10.00g                                           
  vsido                 VG10 -wi-a---- 24.00g                                           
  waldorf-fresh-install VG10 -wi-a---- 30.00g                                           
lvm>
*** create an ext4 filesystem on /dev/mapper/VG10-killX-nietzsche

Code: Select all

_ mkfs.ext4 /dev/mapper/VG10-killX--nietzsche
*** untar the killx archive to the logical volume
create a temporary directory to store everything related to killx and
cd to that directory. Then run

Code: Select all

wget http://iso.killx.org/killX-nietzsche-64.tar.bz2
_ mkdir -p /mnt/killx
_ mount /dev/mapper/VG10-killX--nietzsche /mnt/killx
_ tar xf killX-nietzsche-64.tar.bz2 -C /mnt/killx/
_ umount /mnt/killx
The tar command takes some time without any output.

*** run update-grub

Code: Select all

_ update-grub
> _ update-grub
Generating grub.cfg ...
Found background image: /usr/share/images/desktop-base/desktop-grub.png
Found linux image: /boot/vmlinuz-3.10-2-amd64
Found initrd image: /boot/initrd.img-3.10-2-amd64
Found linux image: /boot/vmlinuz-3.9-1-amd64
Found initrd image: /boot/initrd.img-3.9-1-amd64
Found Windows 7 (loader) on /dev/sda2
Found Slackware Linux (Slackware 14.0) on /dev/sdb3
Found Debian GNU/Linux (jessie/sid) on /dev/mapper/VG10-VG10--waldorf
Found Arch on /dev/mapper/VG10-arch
Found killX 0.1 R1 (Wagner) (killX 0.1 R1) on /dev/mapper/VG10-killX--nietzsche
Found LinuxBBQ Rice 64 (3.3) on /dev/mapper/VG10-linuxBBQ--rice
Found LinuxBBQ Yuebing (3.5) on /dev/mapper/VG10-linuxBBQ--yuebing
Found Debian GNU/Linux (7.1) on /dev/mapper/VG10-livarp
Found VSIDO 1_2 (1_2) on /dev/mapper/VG10-vsido
Found Debian GNU/Linux (7.1) on /dev/mapper/VG10-waldorf--fresh--install
done
Verify that there is a stanza for booting into killX

Code: Select all

_ grep -EA8 '^menuentry "killX' /boot/grub/grub.cfg
Here is what I got:
> _ grep -EA8 '^menuentry "killX' /boot/grub/grub.cfg
menuentry "killX 0.1 R1 (Wagner) (killX 0.1 R1) (on /dev/mapper/VG10-killX--nietzsche)" --class gnu-linux --class gnu --class os {
insmod lvm
insmod part_msdos
insmod ext2
set root='(VG10-killX-nietzsche)'
search --no-floppy --fs-uuid --set=root b14b6e29-6398-4e11-a629-1cde281b8d5f
linux /vmlinuz root=/dev/dm-10
initrd /initrd.img
}
menuentry "killX 0.1 R1 (Wagner) (killX 0.1 R1) (on /dev/mapper/VG10-killX--nietzsche)" --class gnu-linux --class gnu --class os {
insmod lvm
insmod part_msdos
insmod ext2
set root='(VG10-killX-nietzsche)'
search --no-floppy --fs-uuid --set=root b14b6e29-6398-4e11-a629-1cde281b8d5f
linux /vmlinuz root=/dev/dm-10
initrd /initrd.img
}
menuentry "killX 0.1 R1 (Wagner) (killX 0.1 R1) (on /dev/mapper/VG10-killX--nietzsche)" --class gnu-linux --class gnu --class os {
insmod lvm
insmod part_msdos
insmod ext2
set root='(VG10-killX-nietzsche)'
search --no-floppy --fs-uuid --set=root b14b6e29-6398-4e11-a629-1cde281b8d5f
linux /boot/vmlinuz-huge-3.10.9 root=/dev/dm-10
}
menuentry "killX 0.1 R1 (Wagner) (killX 0.1 R1) (on /dev/mapper/VG10-killX--nietzsche)" --class gnu-linux --class gnu --class os {
insmod lvm
insmod part_msdos
insmod ext2
set root='(VG10-killX-nietzsche)'
search --no-floppy --fs-uuid --set=root b14b6e29-6398-4e11-a629-1cde281b8d5f
linux /vmlinuz root=/dev/dm-10
initrd /initrd.img
}
menuentry "killX 0.1 R1 (Wagner) (killX 0.1 R1) (on /dev/mapper/VG10-killX--nietzsche)" --class gnu-linux --class gnu --class os {
insmod lvm
insmod part_msdos
insmod ext2
set root='(VG10-killX-nietzsche)'
search --no-floppy --fs-uuid --set=root b14b6e29-6398-4e11-a629-1cde281b8d5f
linux /vmlinuz root=/dev/dm-10
initrd /initrd.img
}
You can use the output of

Code: Select all

_ blkid
to verify that the UUID of the filesystem on /dev/mapper/killX is correct.

Try to boot into any of these grub2 entries. They will all fail with
either a kernel panic or by spitting out some errors, dropping you into
a shell and telling you that you can solve it from there. Press
Control-D when you are done.

Is that so?

More...
Last edited by xaos52 on Tue Oct 01, 2013 10:42 am, edited 1 time in total.
Connected. Take this REPL, brother, and may it serve you well.

User avatar
DebianJoe
Frame Buffer
Posts: 1915
Joined: Mon Jul 01, 2013 5:41 am
Location: emacs.d

Re: Giving killX some love

Unread post by DebianJoe » Mon Sep 30, 2013 10:52 pm

xaos52 wrote: Now I am using linux for a long long time, but I had never before
installed any slackware version, so it is totally new to me, which
means I may be using for instance package install tools that are not
the most appropriate for the situation.
I certainly do not wish to derail this thread, but I don't believe that there is a "most appropriate" way of installing anything here. I've been using killx on and off since the day of release, and I have built everything with git packages or tarballs. I'm sure that if we looked at Pidsley's, Wux, or MB's setups, they would probably have done it differently. I believe that part of the joy of it is that nobody has specified a "best practices," so if it works....must have been the right way to do it.

Interesting reading, Doc.
|>>BBQ Roaster, Alpha Branch<< | >> clinky << | >> X11 must die << |
Thanks BASIC

machinebacon
Baconator
Posts: 10253
Joined: Thu Sep 16, 2010 11:03 am
Location: Pfälzerwald
Contact:

Re: Giving killX some love

Unread post by machinebacon » Tue Oct 01, 2013 3:26 am

Thanks Doc, especially the LVM part is highly interesting, because to me this is completely new. Wish I knew that's going on there :)

About the package installation, you can use the slackpkg for the base (binutils, kernel, GNU) and git or sbopkg for everything else. The idea originally to have a git-based distro -- so these two tools are the preferred applications. For convenience (and testing) I added some others like bowser and emerge, this way we can use binaries, tarballs, sources, clone from git, try with ports, even rpms and debs work, if you love the hassle. For the future pacman-g2 will join the club (the difference, by the way, between Wagner and Nietzsche is minimal, Wagner was a pre-release, so don't wonder about the labels)

Good reading, very interesting to see how others do it :) Please continue and good luck fixing the LVM.
..gnutella..

User avatar
xaos52
The Good Doctor
Posts: 190
Joined: Thu Aug 15, 2013 11:59 am
Location: Eernegem, Belgium

Re: Giving killX some love

Unread post by xaos52 » Tue Oct 01, 2013 9:50 am

My first guess was 'the LVM packages are probably not in place for
the killx system'. So, lets install them and see if that gets us any
further.

Couple of questions:

Where do I get the packages?
What packages do I need?
How can I install them?

Complicated by the fact that I only have a wifi connection to the
internet, and I can not boot into the system for the moment.

Do I try to get networking up first or install LVM first?

Lets tackle them one by one:

*** Where do I get the packages?

In the killX archive there is a config file
/etc/slackpkg/mirrors containing a list of mirrors per country. I
picked one for BELGIUM:

http://hydra.belnet.be/mirror/ftp.slack ... are64-14.0

which gave me a 'server not found' when I tried to open it in my
browser.

I had better luck with

http://ftp.belnet.be/ftp.slackware.com/

serving slackware versions as old as 3.3, where 14.0 was the most
recent one. They are at 14.1 now.

But there is a directory slackware64-current in there that seemed to
serve everything I needed.

Another subdirectory slackware64 leads to the goodies.

FILE_LIST contains a list of all the packages and the sudirectory
where you can find the packages themselves.

Search FILE_LIST for 'lvm' and it seems there are 2 packages we need:
llvm and lvm2.

I have a little script here to get those packages. You can either use
the same server I used or choose one nearer to your location:

Code: Select all

#!/bin/sh

set -e

server=http://ftp.belnet.be/ftp.slackware.com/slackware64-current/slackware64

wget -c $server/a/lvm2-2.02.100-x86_64-1.txz
wget -c $server/d/llvm-3.3-x86_64-2.txz


Put the script in your working subdirectory, chmode +x it and run it.

*** What packages do I need?
Answered above

*** How can I install them?
I have got the (binary) packages on jessie now.

To get them on killx and install them I will chroot into killx.
Here are 2 scripts of mine to make that easy peasy.

Just copy them into your work folder on the installing system and
make the chroot script executable.

chroot_functions

Code: Select all

#!/bin/bash

# This is a bash library of functions used in the changeroot_xxxx scripts

usage () {
    echo -e "Usage:\n \
       $0 CHROOT_DEVICE CHROOT_MOUNTPOINT"
    exit 1
}


# as_fn_set_status STATUS
# -----------------------
# Set $? to STATUS, without forking.
as_fn_set_status ()
{
  return $1
} # as_fn_set_status

# as_fn_exit STATUS
# -----------------
# Exit the shell with STATUS, even in a "trap 0" or "set -e" context.
as_fn_exit ()
{
  set +e
  as_fn_set_status $1
  exit $1
} # as_fn_exit

setup () {
    [[ "$1" ]] || return 1
    local chroot_mountpoint="$1"
    if [[ ! -d "$chroot_mountpoint" ]]; then
        mkdir -p "$chroot_mountpoint"
    fi
}

breakdown () {
    [[ "$1" ]] || return 1
    local chroot_mountpoint="$1"
    do_bind_unmounts $chroot_mountpoint
    umount "$chroot_mountpoint"
}

bind_it () {
    [[ "$1" ]] || return 1
    [[ "$2" ]] || return 1
    mount --bind $1 $2
}

do_bind_mounts () {
    [[ "$1" ]] || return 1
    local mountpoint chroot_mountpoint="$1"
    for mountpoint in "/dev/" "/dev/pts" "/dev/shm" "/proc" "/sys"; do
        bind_it "$mountpoint" "${chroot_mountpoint}${mountpoint}"
    done
}

do_bind_unmounts () {
    [[ "$1" ]] || return 1
    local mountpoint chroot_mountpoint="$1"
    for mountpoint in "/dev/pts" "/dev/shm" "/dev" "/proc" "/sys"; do
        umount "${chroot_mountpoint}${mountpoint}"
    done
}

# main program starts here
CHROOT_DEVICE=
CHROOT_MOUNTPOINT=
do_chroot () {
    [[ $# -eq 0 ]] && usage
    [[ "$(id -u)" -eq 0 ]] || { echo -e "\tRoot permissions required...\n"; return 1; }

    # special case - second argument is 'unmount' -> call breakdown and quit
    [[ "x$2" == "xunmount" ]] && {
        breakdown "$1"
        return 0
    }
    
    CHROOT_DEVICE="$1"
    CHROOT_MOUNTPOINT="$2"
    [[ x"$CHROOT_DEVICE" == "x" ]] && usage
    [[ x"$CHROOT_MOUNTPOINT" == "x" ]] && usage
    [[ -b $CHROOT_DEVICE ]] || { echo -e "\t$CHROOT_DEVICE is not a block device...\n"; return 1; }

    # Catch error status, even normal exit. Make sure anything mounted
    # by this script is unmounted, no matter if the script exits
    # normally or not.
    trap 'exit_status=$?
    breakdown $CHROOT_MOUNTPOINT
    exit $exit_status
' 0
    for ac_signal in 1 2 13 15; do
        trap 'ac_signal='$ac_signal'; as_fn_exit 1' $ac_signal
    done
    ac_signal=0

    setup "$CHROOT_MOUNTPOINT"
    
    # Attempt mount
    mount "$CHROOT_DEVICE" "$CHROOT_MOUNTPOINT"
    # returns status 32 when already mounted
    if [[ $? != 0 && $? != 32 ]]; then
        echo "Could not mount $CHROOT_DEVICE on $CHROOT_MOUNTPOINT"
        exit 1
    fi
    do_bind_mounts $CHROOT_MOUNTPOINT
  
    if [[ ${#COMMANDS[@]} != 0 ]]; then
        # run teh command
        for __ in "${COMMANDS[@]}"; do
            chroot "$CHROOT_MOUNTPOINT" $__
        done
    else
        chroot "$CHROOT_MOUNTPOINT" /bin/bash
    fi
}
chroot

Code: Select all

#!/bin/bash

usage () {
    printf '%s\n' "Usage: $0 mountpoint"
    exit 1
}
[[ $# -lt 2 ]] && usage
CWD=$(pwd)
. $CWD/chroot_functions
COMMANDS=()
do_chroot $@
And from the working directory; run

Code: Select all

_ ./chroot /dev/mapper/VG10-killX-nietzsche /mnt/killx
which should give you
> _ ./chroot /dev/mapper/VG10-killX--nietzsche /mnt/killx
[sudo] password for xaos52:
bash-4.2#
We find ourselves chrooted into a bash shell on killx.

Now, I can not possibly get any work done without my favourite
aliases _ and ll, so

Code: Select all

nano /root/.bashrc 

Add the aliases after the ones machinebacon already put in there:

Code: Select all

alias _=sudo
alias ll='ls -al'


and activate them:

Code: Select all

source /root/.bashrc 


Aaaaah, that's better... :)

We are going to transfer the packages from jessie to killx.
I will put them in dir /home/killx/packages, which has to be created
first:

Code: Select all

mkdir -p /home/killx/packages 


Start a new shell on jessy, cd into the working directory and copy
the packages files over:

Code: Select all

 
_ cp -av *.txz /mnt/killx/home/killx/packages/

Should copy the 2 packages.

Back to the shell on killx to install them:

Code: Select all

installpkg /home/killx/packages/*.txz 

Verify the output of that last command.
The lvm packages should be in place now on killx.

So, shutdown your system and try to boot into killx again.

!?*@!!! grmbl grmbl... Still no joy.

Seems like nothing has improved...

Did we install the lvm packages in vain?
All this work for nothing?
Have we missed something?
Are there any other problems?

All we have to go on is those pesky error messages we get when booting into
killx.

Come back tomorrow to find out... :)
Connected. Take this REPL, brother, and may it serve you well.

User avatar
wuxmedia
Grasshopper
Posts: 6454
Joined: Wed Oct 17, 2012 11:32 am
Location: Back in Blighty
Contact:

Re: Giving killX some love

Unread post by wuxmedia » Tue Oct 01, 2013 10:49 am

wow. good exploring, i'd post what i got up to but i mostly followed the README.
MB wrote:the difference, by the way, between Wagner and Nietzsche is minimal
even more by the way; I heard somewhere, Nietzsche composed some classic music, Wagner thought it was shit...

LVM seems like a good idea.

PS xaos, I've fixed your bbcode a bit... as it's all I have to offer 8)
"Seek, and Ye shall find"
"Github | Chooons | Site"

User avatar
xaos52
The Good Doctor
Posts: 190
Joined: Thu Aug 15, 2013 11:59 am
Location: Eernegem, Belgium

Re: Giving killX some love

Unread post by xaos52 » Tue Oct 01, 2013 11:19 am

Thanks wux :)
I did not realize something was wrong with it. Details?
Connected. Take this REPL, brother, and may it serve you well.

User avatar
wuxmedia
Grasshopper
Posts: 6454
Joined: Wed Oct 17, 2012 11:32 am
Location: Back in Blighty
Contact:

Re: Giving killX some love

Unread post by wuxmedia » Tue Oct 01, 2013 11:45 am

sure;
you missed a couple of [/code]'s and a [/quote], thats all.
Sorry - I should have put my reasons in the posts 'reason for editing' bit.
"Seek, and Ye shall find"
"Github | Chooons | Site"

machinebacon
Baconator
Posts: 10253
Joined: Thu Sep 16, 2010 11:03 am
Location: Pfälzerwald
Contact:

Re: Giving killX some love

Unread post by machinebacon » Tue Oct 01, 2013 2:21 pm

:biting my nails: - what went wrong with Ludwig Van Meathoven (lvm)? :D
..gnutella..

User avatar
xaos52
The Good Doctor
Posts: 190
Joined: Thu Aug 15, 2013 11:59 am
Location: Eernegem, Belgium

Re: Giving killX some love

Unread post by xaos52 » Wed Oct 02, 2013 10:29 am

Let's have a closer look at what is in directories / and /boot
bash-4.2# ll /
total 92
drwxr-xr-x 22 root root 4096 Sep 30 18:50 .
drwxr-xr-x 22 root root 4096 Sep 30 18:50 ..
drwxr-xr-x 2 root root 4096 Sep 6 02:48 bin
drwxr-xr-x 2 root root 4096 Sep 6 13:52 boot
drwxr-xr-x 20 root root 3500 Sep 30 22:04 dev
drwxr-xr-x 45 root root 4096 Sep 6 15:55 etc
drwxr-xr-x 3 root root 4096 Sep 6 13:49 home
lrwxrwxrwx 1 root root 15 Sep 5 07:49 initrd.img -> /boot/initrd.gz
drwxr-xr-x 7 root root 4096 Sep 4 17:47 lib
drwxr-xr-x 3 root root 4096 Sep 6 03:13 lib64
-rw-r--r-- 1 root root 220 Sep 5 07:48 lilo.conf
drwx------ 2 root root 16384 Sep 30 18:47 lost+found
drwxr-xr-x 16 root root 4096 Sep 2 17:34 media
drwxr-xr-x 10 root root 4096 Sep 26 2006 mnt
drwxr-xr-x 2 root root 4096 Jun 10 2007 opt
dr-xr-xr-x 153 root root 0 Sep 30 22:04 proc
drwxr-xr-x 5 root root 4096 Sep 7 00:08 root
drwxr-xr-x 2 root root 4096 Jun 23 2012 run
drwxr-xr-x 2 root root 4096 Sep 6 05:04 sbin
drwxr-xr-x 2 root root 4096 Apr 8 2007 srv
dr-xr-xr-x 13 root root 0 Sep 30 22:04 sys
drwxrwxrwt 2 root root 4096 Sep 6 15:49 tmp
drwxr-xr-x 18 root root 4096 Sep 6 05:26 usr
drwxr-xr-x 15 root root 4096 Sep 6 13:38 var
lrwxrwxrwx 1 root root 25 Sep 5 07:50 vmlinuz -> /boot/vmlinuz-huge-3.10.9
bash-4.2#

bash-4.2# ll /boot
total 13208
drwxr-xr-x 2 root root 4096 Sep 6 13:52 .
drwxr-xr-x 22 root root 4096 Sep 30 18:50 ..
lrwxrwxrwx 1 root root 25 Sep 5 01:37 System.map -> System.map-generic-3.10.9
-rw-r--r-- 1 root root 3381832 Aug 22 03:56 System.map-huge-3.10.9
-rw-r--r-- 1 root root 512 Sep 2 15:17 boot.0800
-rw-r--r-- 1 root root 512 Sep 5 07:47 boot.0810
lrwxrwxrwx 1 root root 21 Sep 5 01:37 config -> config-generic-3.10.9
-rw-r--r-- 1 root root 137515 Aug 22 03:56 config-huge-3.10.9
-rw-r--r-- 1 root root 3467042 Sep 6 02:57 initrd.gz
-rw------- 1 root root 82944 Sep 5 07:49 map
lrwxrwxrwx 1 root root 22 Sep 5 01:37 vmlinuz -> vmlinuz-generic-3.10.9
-rw-r--r-- 1 root root 6429712 Aug 22 03:56 vmlinuz-huge-3.10.9
The links in / seem OK at first sight.

The vmlinuz link in /boot on the other hand is clearly
a "dangling link", pointing to vmlinuz-generic-3.10.9 in the same
directory, which does not exist.

That explains why some of the grub2 entries are not working.

Then there are those messages at boot saying something like
initrd.gz: loading kernel module from initrd image
modprobe: ERROR: could not insert 'module_name': Exec format error
Sounds like the initrd is not sane either?

Since solving this requires a kernel compile - I do not want to use
the huge kernel, thank you - why not install the latest stable kernel
from kernel.org.

*** Kernel compilation

So, I removed the 2 links in / and everything but the files boot.*
from /boot. (with 512 bytes they could be copies of the mbr taken at
some time in the past) and start on a fresh slate.

AT the moment of doing this kernel 3.11.2 was the last stable kernel,
so that is the one we will install.

Download it on the working system.

Copy the archive to /mnt/killx/usr/src/

chroot into killx and

Code: Select all

cd /ysr/src
tar xf linux-3.11-2.tar.xz
ln -sf linux-3.11-2 linux
cd /usr/src/linux
We need a working kernel config file.
I will use the one from the jessy system:

Open another terminal window on jessy, and as root copy the config
file over to killx:

Code: Select all

cp -av /boot/config-3.10-2-amd64 /mnt/killx/usr/src/linux/.config
Back in the terminal chrooted into killx:

Code: Select all

make oldconfig
This will ask you a whole series of questions about new kernel
features you want enabled or not.

You can just go with the defaults on all questions by pressing the
enter key.

Before starting the kernel compile, and saving you the trouble to
have to restart it, I found out that the kernel compile needs the
'bc' package installed.

I did not know that either. It is either something new or I have
never before compiled a linux kernel on a system without bc. Either
option is equally probable.

I will not spell out in detail how to download, transfer and
compile the bc package. We did that before with the lvm packages.
Go look there. The bc package name is in the following command:

Code: Select all

wget -c $server/ap/bc-1.06.95-x86_64-2.txz
Now we can start the kernel compile:

I am using the -j 4 option here, because I have 3 processors on the
system, and I believe the rule is you can enable parallelization for
up to one process more than you have processors available.

Anyhow, while the kernel compile was running I could continue working
on the system without noticeable delays.

Code: Select all

make -j 4 bzImage modules && make modules_install
Depending on the system you are using you can now go take a nap, a
bit of fresh air, a can of coffee, work on your condition (DJ), grill
some new distros (MB) ...

After that finished OK - check the status with echo $? - copy the
kernel to /boot:

Code: Select all

cp -v /usr/src/linux/arch/x86/boot/bzImage vmlinuz-3.11.2
Yes, the 'x86' in that last command is correct. You can replace it
with 'x86_64' but then you will be copying a link, and things will
not work.

OK. We got the kernel.

Now we need an initrd to go with it.

*** Make the initrd

LVM can not possibly work without an initrd.

Why?

Because in an early boot stage, the system needs to activate the lvm
functionality from 'user space' before it can mount the root
filesystem, and switch to /sbin/init on the installed root filesystem.

So we need an initrd.

What has to be in it?

- the libraries and commands to activate LVM

- the kernel module to enable access to the ext4 filesystem

- the kernel module to activate access to the hard drive controller.

On my system - yours may need more or less - this is what I concocted
in config file /etc/mkinitrd.conf

Code: Select all

# mkinitrd.conf.sample
# See "man mkinitrd.conf" for details on the syntax of this file
#
SOURCE_TREE="/boot/initrd-tree"
CLEAR_TREE="1"
OUTPUT_IMAGE="/boot/initrd.gz"
# KERNEL_VERSION="$(uname -r)"
KERNEL_VERSION="3.11.2"
KEYMAP="be-latin1"
MODULE_LIST="ext4:ahci:sd_mod"
# LUKSDEV="/dev/sda2"
# LUKSKEY="LABEL=TRAVELSTICK:/keys/alienbob.luks"
ROOTDEV="/dev/mapper/VG10-killX--nietzsche"
ROOTFS="ext4"
RESUMEDEV="/dev/sda1"
RAID="1"
LVM="1"
UDEV="1"
MODCONF="1"
WAIT="1"
Run the mkinitrd command:

Code: Select all

mkinitrd -F
Which produces this output:
bash-4.2# _ mkinitrd -F
ERROR: mdadm and/or mdmon binary is missing, RAID support not installed
OK: /lib/modules/3.11.2/kernel/fs/mbcache.ko added.
OK: /lib/modules/3.11.2/kernel/fs/jbd2/jbd2.ko added.
OK: /lib/modules/3.11.2/kernel/lib/crc16.ko added.
OK: /lib/modules/3.11.2/kernel/fs/ext4/ext4.ko added.
OK: /lib/modules/3.11.2/kernel/drivers/scsi/scsi_mod.ko added.
OK: /lib/modules/3.11.2/kernel/drivers/ata/libata.ko added.
OK: /lib/modules/3.11.2/kernel/drivers/ata/libahci.ko added.
OK: /lib/modules/3.11.2/kernel/drivers/ata/ahci.ko added.
OK: /lib/modules/3.11.2/kernel/drivers/scsi/scsi_mod.ko added.
OK: /lib/modules/3.11.2/kernel/lib/crc-t10dif.ko added.
OK: /lib/modules/3.11.2/kernel/drivers/scsi/sd_mod.ko added.
OK: /lib/modules/3.11.2/kernel/drivers/md/dm-mod.ko added.
63125 blocks
/boot/initrd.gz created.
Be sure to run lilo again if you use it.
bash-4.2#
You can ignore the RAID error, unless you are using that.
You can ignore the lilo advice as well. We will be using grub2 from
the jessie system instead.

mkinitrd creates the file /boot/initrd.gz

As a bonus, mkinitrd creates a file structure in /boot/initrd-tree
with everything that went into the initrd.gz.

You should take a look at the /boot/initrd-tree/init script.

That is the script that activates LVM and other user tools and mounts
the root filesystem from the LV, to finally switch_root into the
installed system. If everything goes right, that is.

Time to test.

On the jessie system, rebuild grub2:

Code: Select all

_ update-grub
Verify our grub entry:

Code: Select all

_ grep -EA8 '^menuentry "killX' /boot/grub/grub.cfg    
menuentry "killX 0.1 R1 (Wagner) (killX 0.1 R1) (on /dev/mapper/VG10-killX--nietzsche)" --class gnu-linux --class gnu --class os {
insmod lvm
insmod part_msdos
insmod ext2
set root='(VG10-killX-nietzsche)'
search --no-floppy --fs-uuid --set=root b14b6e29-6398-4e11-a629-1cde281b8d5f
linux /boot/vmlinuz-3.11.2 root=/dev/dm-8
initrd /boot/initrd.gz
}
Looks good.

Boot into killx.

BINGO!

HOUSTON, WE HAVE LIFT-OFF!

Oh Noooooeeees !!!!!!!!!!!!

I am dropped into a shell. You too?

Asking for the root password - which is 'root'

What is wrong now?

'... could not verify ... sda14...'

sda14???

More trouble ahead?

Find out in the next installment...
Connected. Take this REPL, brother, and may it serve you well.

User avatar
DebianJoe
Frame Buffer
Posts: 1915
Joined: Mon Jul 01, 2013 5:41 am
Location: emacs.d

Re: Giving killX some love

Unread post by DebianJoe » Wed Oct 02, 2013 10:56 am

Xaos, you just copied the stock Jessie kernel config? After being in that perfect place to make EXACTLY the perfect kernel (and subsequently have time to get in a decent workout), and you just "make oldconfig" like it's the right thing to do? It's disappointing the laziness of kids these days. Son, I am disappoint. ;)

edit: reaction
|>>BBQ Roaster, Alpha Branch<< | >> clinky << | >> X11 must die << |
Thanks BASIC

User avatar
wuxmedia
Grasshopper
Posts: 6454
Joined: Wed Oct 17, 2012 11:32 am
Location: Back in Blighty
Contact:

Re: Giving killX some love

Unread post by wuxmedia » Wed Oct 02, 2013 10:58 am

^ I'm gonna have to make a kernel one of these days.
^^ oh oh I know this one!!!!
edit the /etc/fstab in killX
/ is mounted as sda14, edit it to reflect your LVM thing and bingo. I guess because it's copied not generated at install.
"Seek, and Ye shall find"
"Github | Chooons | Site"

User avatar
xaos52
The Good Doctor
Posts: 190
Joined: Thu Aug 15, 2013 11:59 am
Location: Eernegem, Belgium

Re: Giving killX some love

Unread post by xaos52 » Wed Oct 02, 2013 11:17 am

@DJ: I consider kernel configuration an art, and I am not an artist. So I let other, more competent people create kernel config files for me. Only when I have specific problems will I dive into that pool. Thx for the reaction, son :)

BTW: did you not run into any of these problems when installing killx?

@wux: nice :)
Last edited by xaos52 on Wed Oct 02, 2013 11:20 am, edited 1 time in total.
Connected. Take this REPL, brother, and may it serve you well.

User avatar
DebianJoe
Frame Buffer
Posts: 1915
Joined: Mon Jul 01, 2013 5:41 am
Location: emacs.d

Re: Giving killX some love

Unread post by DebianJoe » Wed Oct 02, 2013 11:20 am

xaos52 wrote:Thx for the reaction, son :)
I was afraid of having "cross-cultural confusion" with it...since you got the joke, putting it back. ;)

In response to your BTW: "yes," but I'd decided to make it work for me and then document nothing. It makes for a better learning experience to have to figure it all out the hard way. I still am convinced that it's designed as a "get better at linux" project. Either that, or MB's trolling, and I won't give him the satisfaction of NOT running it.
|>>BBQ Roaster, Alpha Branch<< | >> clinky << | >> X11 must die << |
Thanks BASIC

User avatar
xaos52
The Good Doctor
Posts: 190
Joined: Thu Aug 15, 2013 11:59 am
Location: Eernegem, Belgium

Re: Giving killX some love

Unread post by xaos52 » Thu Oct 03, 2013 9:03 am

Why sda14?

Because this is what is in /etc/fstab:
#
# example fstab
#
/dev/sda14 / ext4 defaults 1 1
/dev/sda6 swap swap defaults 0 0
#/dev/cdrom /mnt/cdrom auto noauto,owner,ro 0 0
#/dev/fd0 /mnt/floppy auto noauto,owner 0 0
devpts /dev/pts devpts gid=5,mode=620 0 0
proc /proc proc defaults 0 0
tmpfs /dev/shm tmpfs defaults 0 0
killx may be installed on /dev/sda14 for machinebacon, it sure is not
for me.

While we are at it, check /etc/mtab as well/

/etc/mtab
/dev/sda14 / ext4 rw 0 0
proc /proc proc rw 0 0
sysfs /sys sysfs rw 0 0


That will have to be changed as well.

Reboot into jessy
chroot into killx
change /etc/fstab to

Code: Select all

# /etc/fstab: static file system information.
#
# Use 'blkid' to print the universally unique identifier for a
# device; this may be used with UUID= as a more robust way to name devices
# that works even if disks are added and removed. See fstab(5).
#
# <file system> <mount point>   <type>  <options>       <dump>  <pass>
/dev/mapper/VG10-killX--nietzsche / 	ext4    errors=remount-ro 	0       1
/dev/sda1                         none	swap    sw        		0       0
/dev/sr0			/media/cdrom0   udf,iso9660 user,noauto 0       0
# for debugging
# mount -t debugfs debugfs /sys/kernel/debug
Notice the double dash in the LV name.

Remove and recreate /etc/mtab

Code: Select all

_ rm /mnt/killx/etc/mtab
_ touch /mnt/killx/etc/mtab
Reboot into killx.

CLEAN BOOT.

First stage of our mission accomplished. Finally.

Keep the /var/log/dmesg file as a reference. We will be trying to
make the boot process faster/

Code: Select all

cp var/log/dmesg /var/log/dmesg.v1
*** Networking

The slackware method for activating wifi seems overly complicated for
my taste. We will create a shortcut for that:

We do need the wireless-tools, libnl3 and wpa_supplicant packages.
You should know the drill by now: wget, transfer, install...

The packages names and directories are:

Code: Select all

#!/bin/sh

set -e

server=http://ftp.belnet.be/ftp.slackware.com/slackware64-current/slackware64

wget -c $server/n/wireless-tools-29-x86_64-9.txz
wget -c $server/n/wpa_supplicant-2.0-x86_64-1.txz
wget -c $server/l/libnl3-3.2.21-x86_64-1.txz
Reboot into killx

change the host name from 'box' to 'medion-vg10-killx' in
/etc/HOSTNAME
/etc/hosts

create/change the conf file for wpa_supplicant. Enable roaming:

/etc/wpa_supplicant.conf

Code: Select all

ctrl_interface=/var/run/wpa_supplicant
ctrl_interface_group=root
update_config=1


network={
	ssid="Example WEP Network"
	key_mgmt=NONE
	wep_key0="abcde"
	disabled=1
	id_str="johns_house"
}

network={
	ssid="your_ssid"
	psk="your_psk_in_ascii"
	id_str="home"
}

network={
	key_mgmt=NONE
	disabled=1
}

Adapt ssid and psk for your situation.

And activate wifi:

Code: Select all

wpa_supplicant -B -c /etc/wpa_supplicant.conf -i wlan0 -Dnl80211,wext
dhcpcd wlan0


That should be sufficient to get your wifi working.
If not, replace the '-B' option by '-ddd' in the wpa_supplicant
command to debug what is going wrong.

If it is ok, put the 2 commands in /etc/rc.d/rc.local so that they
are executed automatically at every boot.

End of install.

Do not go away.

We will be weeding out what we do not need and explore the system
fully in following installments.
Connected. Take this REPL, brother, and may it serve you well.

machinebacon
Baconator
Posts: 10253
Joined: Thu Sep 16, 2010 11:03 am
Location: Pfälzerwald
Contact:

Re: Giving killX some love

Unread post by machinebacon » Thu Oct 03, 2013 9:30 am

Thanks xaos, indeed I uploaded the wrong version :blush:, as you say this is the one with modified fstab and mtab. Damnit :) For luck it's still alpha :D
..gnutella..

User avatar
xaos52
The Good Doctor
Posts: 190
Joined: Thu Aug 15, 2013 11:59 am
Location: Eernegem, Belgium

Re: Giving killX some love

Unread post by xaos52 » Thu Oct 03, 2013 9:35 am

No need to :blush: really. It is an easy thing to forget. What, will all you have to think of it is amazing you get it right so many times:)

No. I am not disappointed in you, son. On the contrary.
Connected. Take this REPL, brother, and may it serve you well.

machinebacon
Baconator
Posts: 10253
Joined: Thu Sep 16, 2010 11:03 am
Location: Pfälzerwald
Contact:

Re: Giving killX some love

Unread post by machinebacon » Thu Oct 03, 2013 9:38 am

Thanks Dad :D And thanks for the LudwigVanMeathoven readme here, it's still something I haven't done yet (and probably never will, hehe)
..gnutella..

User avatar
DebianJoe
Frame Buffer
Posts: 1915
Joined: Mon Jul 01, 2013 5:41 am
Location: emacs.d

Re: Giving killX some love

Unread post by DebianJoe » Thu Oct 03, 2013 11:27 am

...you mean you didn't leave a jacked up fstab/mtab on purpose?
|>>BBQ Roaster, Alpha Branch<< | >> clinky << | >> X11 must die << |
Thanks BASIC

User avatar
wuxmedia
Grasshopper
Posts: 6454
Joined: Wed Oct 17, 2012 11:32 am
Location: Back in Blighty
Contact:

Re: Giving killX some love

Unread post by wuxmedia » Thu Oct 03, 2013 1:21 pm

I thought it a noob filter, no idea how I got past it. 8)
another fun thing -
Dr X very cleverly wgot the wpa package.
I found it was already on killX, but missing a .lib, so i stole it from xfce64, seems to work.
Quite likely I didn't cp it right. in fact i extracted the archive, then copied to /dev/sdaX, then realised /mnt/ should be as '/' so i cp'ed it again... you know me 8)
actually it was the libnl package - I think.
and thanks to DrX for the wifi autoconnect
"Seek, and Ye shall find"
"Github | Chooons | Site"

User avatar
xaos52
The Good Doctor
Posts: 190
Joined: Thu Aug 15, 2013 11:59 am
Location: Eernegem, Belgium

Re: Giving killX some love

Unread post by xaos52 » Fri Oct 04, 2013 11:55 am

Image
Demo of org mode at work in emacs.
Connected. Take this REPL, brother, and may it serve you well.

Post Reply