Linux

Once every other while it's useful to have a browser that's not connected to the normal browsing profile (I know. Don't say it. I've been here a while).

These are two shell scripts that create a new profile for Firefox and Chrome in a temporary directory, start the browser using that profile and remove the directory afterwards.

Chrome

#!/bin/bash
trap cleanup EXIT
die() {
    echo $@
    exit 1
}
cleanup() {
    [ -d ${CHROMETMP} ] && rm -rf ${CHROMETMP}
}
CHROMETMP=$(mktemp -d)
[ -d ${CHROMETMP} ] || die "Could not create temp dir"
chromium-browser --user-data-dir="${CHROMETMP}"

Firefox

#!/bin/bash
trap cleanup EXIT
die() {
    echo $@
    exit 1
}
cleanup() {
    [ -d ${FIREFOXTMP} ] && rm -rf ${FIREFOXTMP}
}
FIREFOXTMP=$(mktemp -d)
[ -d ${FIREFOXTMP} ] || die "Could not create temp dir"
export HOME=${FIREFOXTMP}
firefox -no-remote -CreateProfile 'throwaway' || die "Could not create profile"
firefox -no-remote -P 'throwaway'

I recently accquired a root server hosted by Manitu. It was planned to run Centos 6 on that server, but unfortunately that is not in the list of operating systems that can be preinstalled (or reinstalled) via the management web page.

There is, however, a rescue system, an option to remotely boot the server into a bare bones Linux system via the network. Since an OS is basically a bunch of bits on a hard disk it should be possible to get said bits onto the hard disk from the rescue system.

How hard can it be?

Now, there are some things to consider. First of all, this is not for someone new to Linux or CentOS. There are lots of ways for things to go wrong or not end up as expected. The usual failure mode for this is the remote system not booting, which is kind of hard to debug without any further information. Also, this will erase all data on the hard disks in the system.

The partitioning scheme is what I needed for my system. Adjust as needed. If you don't know how that's the first clue that you should not be doing this in the first place.

Preconditions

Some of the things needed for this to work:

• The rescue system has to support the hardware you want to install on (mainly network and hard disk controllers). Since the rescue system is provided by the hoster this is usually the case, but it does not hurt to check.
• The rescue system has to support software RAID (if you want it), LVM (if you want it) and all file systems you want to use (or at least the ones needed to boot the system)
• The rescue system kernel has to be reasonably similar to the CentOS installer kernel. Being newer is usually not a problem, being much older can be.
• wget (or some other way to download files via HTTP)
• File system support in the kernel for ISO9660, squashfs and ext3
• At least 2GB of RAM
• Hardware supported by CentOS 6. If CentOS 6 would not install or boot on the system when doing a normal (CD/DVD based or network) install then chances are that installing it this way will not work either.

It is further assumed that a tmpfs file system is mounted at /dev/shm.

Install plan

The hardware in question here has two SATA HDDs on AHCI compatible controllers without any hardware RAID. The final hard disk layout will be as follows:

• /dev/md0, 1GB, consisting of /dev/sda1 and /dev/sdb1, ext3, mounted at /boot
• /dev/md1, 64GB, consisting of /dev/sda2 and /dev/sdb2, LVM PV

The PV is part of a volume group which contains an LV holding the root file system.

Prepare the Live CD

The rescue system usually has no CentOS specific tools (like RPM) which are needed to install the OS packages. In order to get a usable install environment we'll commandeer the CentOS 6 live CD. It contains a complete root file system image.

• Download the current live CD ISO image from "http://mirror.centos.org":http://mirror.centos.org, putting the file into /dev/shm. Be sure to grab the CD for the right architecture (the right architecture is x86_64, by the way).
• Create a bunch of directories

  mkdir /loop1 /loop2 /sysroot

• Mount the root image (this is a bit recursive)

  mount -o ro /dev/shm/CentOS-6.2-x86_64-LiveCD.iso /loop1
  mount -o ro /loop1/LiveOS/squashfs.img /loop2
  mount -o ro /loop2/LiveOS/ext3fs.img /sysroot

• Bind mount needed virtual file systems

  mount -o bind /dev /sysroot/dev
  mount -o bind /proc /sysroot/proc
  mount -o bind /sys /sysroot/sys

Now chroot into /sysroot and try running some commands (RPM, yum). If this does not work then the rescue system kernel is probably too far from the live CD kernel, and this adventure ends here.

The image mounted at /sysroot is read only. This will not do, since we need to change DNS entries, so create a writable /etc:

  mount -t tmpfs tmpfs /tmp
  rsync -a /etc /tmp
  mount -o bind /tmp/etc /etc

Ignore the mtab warning the first command produces. After this, fill in /etc/resolv.conf with some name servers and try to pinging something by name.

Prepare for installation

Leave the chroot again (working with LVM does not work within it).

Remove and stop any existing volume groups and software raids. Then partition the hard disks according to the new scheme and create the new software RAIDs and LVMs.

  fdisk -u -c /dev/sda
  sfdisk -d /dev/sda | sfdisk --force /dev/sdb
  mdadm --create /dev/md0 -n 2 --level 1 --metadata=0.90 /dev/sda1 /dev/sdb1
  mdadm --create /dev/md1 -n 2 --level 1 /dev/sda2 /dev/sdb2
  pvcreate /dev/md1
  vgcreate -s 64M vg_tara_root /dev/md1
  lvcreate -n lv_swap -L 8G vg_tara_root
  lvcreate -n lv_c6_root -L 16G vg_tara_root
  mkfs.ext3 /dev/md0
  mkfs.ext4 /dev/mapper/vg_tara_root-lv_c6_root
  tune2fs -c0 -i0 -r32000 -L boot /dev/md0
  tune2fs -c0 -i0 -r32000 -L lv_c6_root /dev/mapper/vg_tara_root-lv_c6_root

It's probably a good idea to wait for the RAID resync, that should not take long. The metadata version on /dev/md0 is needed to help the boot loader.

• chroot into /sysroot again.
• Prepare a directory tree to hold the system to be installed (it's also called sysroot. Yes, this is intentionally confusing):

  mkdir /tmp/sysroot
  mount /dev/mapper/vg_tara_root-lv_c6_root /tmp/sysroot
  mkdir -p /tmp/sysroot/{boot,dev,proc,sys}
  mount /dev/md0 /tmp/sysroot/boot
  mount -o bind /dev /tmp/sysroot/dev
  mount -o bind /proc /tmp/sysroot/proc
  mount -o bind /sys /tmp/sysroot/sys

Installation

• Prepare the RPM database in the new system:

  rpm --root /tmp/sysroot --rebuilddb

• Download the centos-release RPM from the current CentOS 6 build (again: architecture) into /tmp and install it:

  rpm --root /tmp/sysroot -ihv /tmp/centos-release-6-2.el6.centos.7.x86_64.rpm

• Now install the CentOS base system. This ought to install 300 to 350 packages, depending on the release. Confirm the GPG key import question, and ignore the DBUS error at the end. Depending on network connection and hard disk speed this may take a while.

  yum --installroot=/tmp/sysroot groupinstall base

• Install the bootloader and SSH server package.

  yum --installroot=/tmp/sysroot install grub openssh-server

• Unmount the newly installed system and clean up the chroot

  umount /tmp/sysroot/{boot,dev,proc,sys,} /etc /tmp

• Leave the chroot
• Remove the live CD image

  umount /sysroot/{dev,proc,sys,}
  umount /loop2
  umount /loop1

• Mount the new system under /sysroot

  mount /dev/mapper/vg_tara_root-lv_c6_root /sysroot
  mount /dev/md0 /sysroot/boot
  mount -o bind /dev /sysroot/dev
  mount -o bind /proc /sysroot/proc
  mount -o bind /sys /sysroot/sys

• chroot into /sysroot
• Set the password for root
• Create a symlink for /etc/mtab

  ln -s /proc/mounts /etc/mtab

• Install the boot loader

  grub-install /dev/md0

• Remove /etc/mtab
• Populate /etc/fstab. Do not use raw device names here, especially not for software RAIDs. Use labels or UUIDs.

  LABEL="lv_c6_root"      /                       ext4    defaults        1 1
  LABEL="boot"            /boot                   ext3    defaults        1 2
  tmpfs                   /dev/shm                tmpfs   defaults        0 0
  devpts                  /dev/pts                devpts  gid=5,mode=620  0 0
  sysfs                   /sys                    sysfs   defaults        0 0
  proc                    /proc                   proc    defaults        0 0

• Populate /etc/resolv.conf
• Populate /etc/sysconfig/network

  NETWORKING=yes
  NOZEROCONF=yes
  HOSTNAME=tara.example.org

• Populate /etc/sysconfig/network-scripts/ifcfg-eth0 (use the correct values for IPs, prefixes and gateways)

  DEVICE=eth0
  BOOTPROTO=static
  IPADDR=192.168.0.100
  GATEWAY=192.168.0.1
  PREFIX=24
  ONBOOT=yes

• Populate /boot/grub/grub.conf (mind the line break)

  default=0
  timeout=5
  title CentOS (2.6.32-220.23.1.el6.x86_64)
    root (hd0,0)
    kernel /vmlinuz-2.6.32-220.23.1.el6.x86_64 ro root=LABEL=lv_c6_root LANG=en_US.UTF-8 \
      SYSFONT=latarcyrheb-sun16 KEYBOARDTYPE=pc KEYTABLE=de-latin1-nodeadkeys
    initrd /initramfs-2.6.32-220.23.1.el6.x86_64.img

• populate /root

  cp /etc/skel/.* /root

• Create grub.conf symlinks

  ln -s grub.conf /boot/grub/menu.lst
  ln -s /boot/grub/grub.conf /etc/grub.conf

• Leave the chroot
• Unmount the new system

  umount /sysroot/{boot,sys,dev,proc,}

Now, usually this ought to result in a bootable system which can be accessed via SSH. Only one way to find out.

Just to see what life was like in the dark ages of Linux distributions I ventured to install the earliest RedHat release I could get my hands on in a QEMU virtual machine.

It turns out that this is easier said than done. RedHat does have an archive of old versions (available at http://archive.download.redhat.com), but this is quite incomplete for the earliest version.

Fortunately there's an installable version of Mother's Day 1.1 on ibiblio (the 1.0 release is incomplete as well), which I used.

To make an installable version out of this it's recommened to make a local copy of the complete tree, which is easily done with rsync:

$ rsync -rv --progress www.ibiblio.org::pub/historic-linux/distributions/redhat/mothers-day-1.1 .

This will create a local directory called mothers-day-1.1 containing all needed files, taking up about 360MB.

The installer will need to access the files via a CDROM or a NFS share. I opted for the CD method, so let's create a CD image:

$ chmod +x mothers-day-1.1/bin/*
$ mkisofs -J -R -o mothers-day-1.1.iso mothers-day-1.1

This makes all the files in mothers-day-1.1/bin executable (this is important because the installer will mount the CD and expects to be able to execute these files for the installation) and creates an ISO image called mothers-day-1.1.iso containing all files from the mothers-day-1.1 directory.

The installer will boot from a floppy disk. The release contains a whole bunch of these, for different hardware configurations (a kernel containing all supported configs would not have fitted on one floppy, so one has to choose the right one). For QEMU we'll need standard IDE support (easy) and AMD PCnet support for networking (also easy). The boot image supporting these is located in mothers-day-1.1/images/1211/boot0066.img. These images were meant to be copied to a 1.44MB floppy disk, but the images are only 800k in size. If the images are passed to QEMU as they are QEMU will misinterpret the floppy size, causing the boot loader (LILO) to fail. So QEMU needs a little hint.

$ cp mothers-day-1.1/images/1211/boot0066.img boot.img
$ qemu-img resize boot.img 1440k
Image resized
$ cp mothers-day-1.1/images/rootdisk.img .

This copies the correct boot image to boot.img and resizes it to the correct size for a 1.44MB floppy. For convinience I also copied the root image disk, too. This disk already has the correct size.

All that's missing now is a hard disk image to install to. This should not be too large, as the IDE driver in the kernel has some problems handling this. Fortunately this is the deep past, so 768MB will be plenty.

$ qemu-img create -f qcow2 disk1.img 768MB

Deep past or not, the installer needs memory, and an amazing (for the time) amount of it. 4MB will not be enough, 8MB will do fine. So, let's go.

$ qemu -M pc -m 8 -fda boot.img -drive file=disk1.img,if=ide,media=disk,cache=writeback \
-cdrom mothers-day-1.1.iso -net nic,model=pcnet -net user -boot a

(This adds the hard disk image in writeback cache mode. This is not recommended from a data security standpoint, as data written by the virtual machine is not immediately committed to host storage, but since this is just a for fun exercise and EXT2 formatting takes ages with the default cache strategy I'll pass on data security here)

At the LILO prompt, just press Enter to boot with default options. When prompted, change the floppy to the root disk (change floppy0 rootdisk.img in the QEMU monitor mode) and press Enter to continue. The installer will come up (which is quite nice), prompting to change the floppy back to the boot floppy.

Select an Express install, say "No" to the default package list question, and select CD as the install media. The installer ought to find the CD image on /dev/hdc, which is correct.

There will be no OS/2 on this install, so skip the reboot at the next question.

The hard disk will need to be partitioned. The installer should find a hard disk at /dev/hda (if the installer just presents a list of partitioning programs without a disk device your hard disk image is too large). Partition the disk into one data partition (taking most of the space) and a small swap partition (16MB or so). The installer will ask to reboot if partitions were changed, this is not needed as there were no partitions on the disk to start with.

Confirm /dev/hda2 as a swap partition, and select /dev/hda1 for formatting.

On the package selection screen select whatever needed (or just everything, it does not really matter :) I'd recommend at least the Net Utils, everything X and Utils+. And there's Doom (but more on that later).

When asked for the type of video card select SVGA, and enter a hostname for the machine.

The installer will then format swap and file system, which might take a few seconds. Or even minutes. If you did not change the default caching strategy in the QEMU call above it will definitely take minutes. Or hours.

After the formatting the package installation phase begins. This will also take a few minutes, but at least it has a progress bar. The installer may complain about XF86_SVGA being already installed in the end, this can be ignored.

Then the boot kernel is copied from the boot floppy.

For the mouse, select microsoft-serial, connected to /dev/ttyS0.

The X configuration is a bit wonky (and this would not really change for the next decade or more). Decline autoprobe, select clgd5434 as the chipset (this isn't correct, but close enough). Enter 4096k of video memory, 10-100 for the clocks, and select the Generic Multisync monitor. The configurator will tell you that it failed after that, but never mind.

Configure networking, entering a host name, domain name and fully qualified host name. Select 10.0.2.100 as the IP, 10.0.2.0 as the network, 255.255.255.0 as the netmask, 10.0.2.255 as the broadcast, 10.0.2.2 as the gateway and 10.0.2.3 as the DNS server (QEMU user mode networking is funny).

Select no modem, your keymap, local time and your time zone (the list is sorted upside down, for whatever reason).

Select to install LILO in /dev/hda without specific parameters and without other operating systems.

Create a user account (if you want) and select a root password.

After that, the installation is finished. Select reboot.

The system will be unable to actually reboot, so stop QEMU after the installer has terminated and start it again:

$ qemu -M pc -m 8 -drive file=disk1.img,if=ide,media=disk -net nic,model=pcnet -net user -serial msmouse

This invocation is missing the floppy and CD images (they are not needed anymore) and adds a serial mouse.

At the boot prompt press Enter, and wait until the system has bootet to the login prompt (which will take all of a few seconds). Look around. If you're used to RedHat based systems (or Fedora) most things should look familiar.

Next up: getting X to actually work.

Among the things I carry around is always a collection of USB sticks, for various purposes. One of those is usually dedicated to a Linux rescue system, in order to get somehow broken systems back on their feet.

While it is possible these days to access non Linux systems from a booted Linux system any repair work beyond simple text file editing and file copying usually requires OS specific tools to get the job done. Thus it would be nice not only to have a Linux rescue system at hand, but a Windows one as well. And Solaris, while we're at it. And possibly some more.

USB sticks are cheap, at least in this part of the world. 10EUR will get you 4GB off the shelf in almost any electronics store, a little more money will get you 8GB ordered online. So space is not really an issue.

Actually installing an operating system in a way that allows it to boot off a removable media requires some specific preparations and tools in each case. This means that a running instance of that specific OS is needed to prepare the installation. This means that to get Windows to boot of an USB stick a running Windows installation is needed. The same goes for Solaris and Linux.

Preparations

The USB stick used for this exercise is a 4G Sandisk. This procedure will delete all data currently on the stick, so either make sure there is nothing of any interest on it, or just get a new one.

The initial plan is to have Windows, Linux and Solaris boot off the stick. Each OS will get it's own partition, to keep possible clashes between the files of each system to a minimum (and because Solaris wants and UFS partition, but more on that later).

Installing Windows on USB

The standard Windows installer does not allow for installation on USB devices. The standard tool for those tasks is BartPE, a free tool to create so-called Preinstalled Environments. Those are actually a Microsoft supported way to preinstall an operating system on a PC, which is used by system builders to deliver machines with the OS already installed but not registered. The Microsoft tools to create these environments are not easily available, though, and this is where BartPE came in a few years ago. It's original purpose was to create Live CDs of Windows, but booting from USB was added (experimentally) later.

While BartPE is a very valuable tool there is an even better one for this special purpose: The Ultimate Boot CD for Windows, which is basically a BartPE with a lot of useful tools already tacked to the side, and a completely reworked USB installer.

To use UBCD the following is needed:

• The UBCD installer, which weighs in at 255MB and is available from the projects site
• A Windows XP install CD (32 bit)
• Service Pack 3 for XP, if the Windows CD does not already include it
• A license for the Windows version (this is more a legal than a technical problem, but the Windows install on the USB stick needs a separate license to be legal)
• Drivers

The last point is especially interesting. UBCD will take all drivers whichare contained in the Windows XP install CD, which, as everyone knows who tried to install XP on a reasonably recent machine, is not exactly much. While the USB installed will boot (hopefully), access to hard disk drives on the machine or access to network interfaces may be severely limited due to missing drivers.

UBCD already comes with a largeish selection of updated drivers for mass storage, LAN and WLAN, so simply building an image with the default settings has a good chance of working on a large number of modern machines (although the WLAN drivers are disabled by default).

Install procedure

• Make a copy of the Windows XP CD (that is, just copy all the files on it into a folder on the hard disk drive)
• If the CD did not already contain a Windows copy patched to SP3 download the SP3 install package from Microsoft, and slipstream the Service Pack into the copied files
• Install UBDC
• Start UBCD and enter the path to the copied Windows CD in the first field
• Set Media Output to None
• Click "Build"

The UBCD main screen

This will start a build process with the default settings, which are reasonable for a first build. UBCD is very customizable, most of the options are available by clicking the "Plugins" button on the main screen. Describing the various things that can be done here is beyond this text, but the UBCD home page has details on this.

After the build has finished plug in the USB stick and start ubusb.exe from the UBCD install folder. To make things easier make sure no other USB mass storage devices are connected. Set the options to match those in the screenshot below. Specifically:

• Make sure the right USB device is selected
• Set the partition size to 2048MB (or 2GB)
• Set the file system to FAT32-LBA
• Set the Boot Loader to grub4dos
• Select the right BartPE folder (although it should pick up the correct one automatically)
• Don't create a CD image

UBUSB main screen

Clicking "Go" will start the process of repartitioning, formattingand copying of data to the USB stick. This may take a while.

After the process has finished (hopefully successful) the resulting USB stick can immediately be tested, because UBCD comes with a copy of qemu, which can emulate a PC. Just click the "Test USB" button, and a virtual PC will try to boot off the USB stick just created.

USB boot menu

Windows booted off the USB stick in qemu

One down, two to go.

Note: this was tested only on SATA attached optical drives, not on hard disks. Removing a hard disk with mounted partitions on it (directly or indirectly) is probably not a very smart idea.

A device name of /dev/sr0 is assumed.

• Find out which controller the device is attached to (we'll need this later):

# readlink /sys/block/sr0
../devices/pci0000:00/0000:00:1f.2/host1/target1:0:0/1:0:0:0/block/sr0

The interesting part if the answer is host1, which identifies the controller.

• Disconnect the device

# echo 1 > /sys/block/sr0/device/delete

This will remove the device from the bus (logically). Look in dmesg for confirmation.

• Rescan the controller

# echo "- - -" > /sys/class/scsi_host/host1/scan

host1 is the identifier from step one. Again, dmesg should show the device being rediscovered.

For some reason or another finding instructions on how to actually configure iSCSI for a rather simple and common use case (one target on Solaris, one initiator on Fedora, CHAP authentication) seems to be pretty hard.

Either my google-fu is seriously broken today, or everyone except for me considers this to be so easy and obvious that it does not warrant documentation. Which, having done this for the last three hours, I seriously doubt. The Solaris side is actually documented quite well (I primarily used this blog entry by alasdair), the Linux side is lacking. It does not help matters that both sides use identically named tools that work in completely different ways.

So, the deal is as follows:

One OpenSolaris system, acting as iSCSI target (that is the system presenting the storage space).

One Fedora Linux system, acting as iSCSI initiator (that is the system that wants to use the storage space)

Create 100GB storage space on the target and let the initiator connect to this storage space and create a filesystem on in. The connection has to be authenticated one way (the initiator presents credentials to the target).

h3. The Solaris side

The system is running Nevada, the configuration here was done with build snv_110.

First, the iSCSI target software needs to be installed and enabled:

# gkp.pl -d /mnt/Solaris_11/Product SUNWiscsitgtu
# svcadm enable iscsitgt:default
#

The backing store for the iSCSI volumes shall be provided by ZFS:

# zfs create -o canmount=off tank/iscsi
# zfs create -V 100G -o shareiscsi=on tank/iscsi/vol001
# iscsitadm list target -v
Target: tank/iscsi/vol001
    iSCSI Name: iqn.1986-03.com.sun:02:218c35e0-0881-cb4f-d6bd-80e08bdc98d8
    Alias: tank/iscsi/vol001
[...]
#

The iSCSI Name will be different for each created volume. Per default this target will be available via all interfaces and IPs of the machine. Since this is not what I want in this special case the target is bound to a fixed IP by a construct called a Target Port Group Tag. The TPGT used here has the number 1.

# iscsitadm create tpgt 1
# iscsitadm modify tpgt -i 212.51.12.90 1
# iscsitadm list tpgt -v 1
TPGT: 1
    IP Address: 212.51.12.90
# iscsitadm modify target -p 1 tank/iscsi/vol001
# iscsitadm list target -v
Target: tank/iscsi/vol001
[...]
    TPGT list:
            TPGT: 1
[...]
#

In order to secure access to this volume some more the initiator is required to authenticate itself using CHAP before access is granted. To do this three pieces of information are needed:

• The iqn (basically a unique name) of the initiator
• A username
• A password

The initiator used here has an iqn of iqn.2005-03.com.max:01.cb5c4c (see below for the source of this information). The username is lain and the password is iscsipassword for the purpose of this demonstration. The password has to be between 12 and 16 charcters in length and should definitely be something stronger for production purposes.

# iscsitadm create initiator -n iqn.2005-03.com.max:01.cb5c4c lain
# iscsitadm modify initiator --chap-name lain lain
# iscsitadm modify initiator --chap-secret lain
[...]
# iscsitadm list initiator -v
Initiator: lain
    iSCSI Name: iqn.2005-03.com.max:01.cb5c4c
    CHAP Name: lain
    CHAP Secret: Set
# iscsitadm modify target --acl lain tank/iscsi/vol001
# iscsitadm list target -v
Target: tank/iscsi/vol001
[...]
    ACL list:
            Initiator: lain
[...]
#

This concludes the Solaris side of things.

h3. The Fedora side

The system is running Fedora Rawhide, close to the Fedora 11 Beta release at the time of this writing.

On the Linux side iSCSI is handled by the open-iscsi toolchain, packaged as iscsi-initiator-utils in Fedora. To install it:

# yum install iscsi-initiator-utils
[...]
#

Since the system in question is a notebook, and the iSCSI target may not be available at all times, the iSCSI service must be instructed not to connect to configured devices automatically:

# perl -pi -e 's/node.startup.*/node.startup = manual/' /etc/iscsi/iscsid.conf
#

The initiator name mentioned in the Solaris section above can be configured freely on the system. A random value is created during package installation and saved in /etc/iscsi/initiatorname.iscsi:

# cat /etc/iscsi/initiatorname.iscsi
InitiatorName=iqn.2005-03.com.max:01.cb5c4c
#

Be sure the name configured there matches the name defined in the initiator on the Solaris side. Even though a username/password pair was defined on the target credentials are not needed for target discovery (the process by which an initiator asks a target which iSCSI volumes are available):

# iscsiadm -m discovery -t st -p 212.51.12.90
212.51.12.90:3260,1 iqn.1986-03.com.sun:02:218c35e0-0881-cb4f-d6bd-80e08bdc98d8
# iscsiadm -m node
212.51.12.90:3260,1 iqn.1986-03.com.sun:02:218c35e0-0881-cb4f-d6bd-80e08bdc98d8
#

The discovery process has found a single volume exported by the target and added it to the local node list. The iqn matches the value shown above in the Solaris section. Now the CHAP credentials have to be added to the node so the initiator can actually connect to the volume:

# iscsiadm -m node --target 'iqn.1986-03.com.sun:02:218c35e0-0881-cb4f-d6bd-80e08bdc98d8' \
--name 'node.session.auth.authmethod' -v 'CHAP'
# iscsiadm -m node --target 'iqn.1986-03.com.sun:02:218c35e0-0881-cb4f-d6bd-80e08bdc98d8' \
--name 'node.session.auth.username' -v 'lain'
# iscsiadm -m node --target 'iqn.1986-03.com.sun:02:218c35e0-0881-cb4f-d6bd-80e08bdc98d8' \
--name 'node.session.auth.password' -v 'iscsipassword'
# iscsiadm -m node --target 'iqn.1986-03.com.sun:02:218c35e0-0881-cb4f-d6bd-80e08bdc98d8'
node.name = iqn.1986-03.com.sun:02:218c35e0-0881-cb4f-d6bd-80e08bdc98d8
node.tpgt = 1
node.startup = manual
[...]
node.session.auth.authmethod = CHAP
node.session.auth.username = lain
node.session.auth.password = ********
[...]
#

Now the volume can finally be accessed:

# iscsiadm -m node --target 'iqn.1986-03.com.sun:02:218c35e0-0881-cb4f-d6bd-80e08bdc98d8' --login
Logging in to [iface: default, target: iqn.1986-03.com.sun:02:218c35e0-0881-cb4f-d6bd-80e08bdc98d8,
portal: 212.51.12.90,3260]
Login to [iface: default, target: iqn.1986-03.com.sun:02:218c35e0-0881-cb4f-d6bd-80e08bdc98d8,
portal: 212.51.12.90,3260]: successful
#

After some seconds a device node for this volume should appear in /dev/disk/by-path:

# ls /dev/disk/by-path/
ip-212.51.12.90:3260-iscsi-iqn.1986-03.com.sun:02:218c35e0-0881-cb4f-d6bd-80e08bdc98d8-lun-0
[...]
#

The disk is ready to be used.

Since I tend to forget these things, here's a short list showing various package management tasks.

|_. Task |_. RPM |_. pkg (Solaris) | | List all installed packages | rpm -qa | pkginfo | | Show all files belonging to an installed package | rpm -ql [package] | pkgchk -l [package] | grep Pathname | | Find package owning a file | rpm -qf [filename] | pkgchk -l -p [filename] |

If you ever tried to take a look around an OSX install DVD unter Linux you may have been surprised by the marvelous compression algorithms that Apple uses, because there seems to be preciously little data on those disks:

$ du -sh /media/OSX86DVD/
132K    /media/OSX86DVD/

There is no magic here, as seen by the fact that the same disk inserted into a running OSX system shows a completely different file structure with more than 4GB of data.

The explanation for this is that there are two filesystems on the DVD:

First, a normal ISO9660 CD file system, which contains some bootloader files, and not much else. This filesystem is the one that Linux (and Windows) see by default.

Behind the ISO9660 filesystem there is another one, which spans the rest of the disk. This is a complete hard disk image with it's own partition table, and which contains the real installer data. As Linux does not expect this it does not try to access this filesystem, and the files remain invisible.

In order to get at the files in the second part of the disk some command line magic is necessary. You will need root privileges for the following operations. I assume that the DVD device is /dev/sr0, adjust as neccesary.

The Linux kernel has a nice block device mapping layer which allows us to take a slice out of an existing block device and present this slice as a new device. Even more, there is a helper tool that inspects a block device, looks for partitions and automatically creates such a mapping for each partition. This tool is called kpartx.

So we use kpartx to inspect the DVD device. The command for this is as follows:

# kpartx -a /dev/sr0
device-mapper: reload ioctl failed: Invalid argument
create/reload failed on sr0p1
device-mapper: reload ioctl failed: Invalid argument
create/reload failed on sr0p2
#

That did not work too well. For some reason the device mapper does not like CDROM/DVD devices. So we'll have to get a bit inventive. We create a loop device which is backed by the DVD device, and use that.

# /sbin/losetup /dev/loop0 /dev/sr0
# /sbin/kpartx -av /dev/loop0 
add map loop0p1 (253:5): 0 63 linear /dev/loop0 1
add map loop0p2 (253:6): 0 9178688 linear /dev/loop0 448
#

The command found and created two partitions. The first partition is the ISO9660 file system at the beginning of the disk, the second one is the partition we are interested in. Let's look what's in it.

# file -s /dev/mapper/loop0p2
/dev/mapper/loop0p2: Macintosh HFS Extended version 4 data last mounted by: '10.0', created: 
Tue Oct 30 00:32:01 2007, last modified: Wed Dec 19 16:45:14 2007, last checked: Tue Oct 30 00:32:01
2007, block size: 4096, number of blocks: 1147336, free blocks: 192685
#

That looks good. We could now mount the filesystem and look around.

# mount /dev/mapper/loop0p2 /mnt
# ls /mnt
Applications  Desktop DB  dev  Install Mac OS X.app  mach_kernel  sbin    tmp  vanilla  Volumes
bin           Desktop DF  etc  Library               private      System  usr  var
#

To get rid of all this again we have to unmount the file system, destroy the mappings and release the loop device:

# umount /mnt
# kpartx -d /dev/loop0
# losetup -d /dev/loop0