If you ‘dd’ a single partition into an image file, then this is very straight forward. But if your image file contains multiple partition partitions including the partition table itself, then you need to take additional steps.

So the first thing to know is the exact offset of the partition to be mounted.
You may examine this easily using parted. Just provide it with the path to the image file instead of a block device.

root@debian:~# parted full_hd.dd
GNU Parted 2.3
Using /root/full_hd.dd
Welcome to GNU Parted! Type 'help' to view a list of commands.

Now switch parted to use ‘Byte’ units, then print the partition table:

(parted) unit B
(parted) print
Model: (file)
Disk /root/full_hd.dd: 8012390400B
Sector size (logical/physical): 512B/512B
Partition Table: msdos

Number Start End Size Type File system Flags
1 1048576B 8012169215B 8011120640B primary ext4 boot

Keep a record of the 'Start' offset, you'll need this shortly. Quit parted using the 'quit' command.

Let's look into mounting the partition: pass the partition offset to the mount command using the 'offset=' option like this:

root@debian:~# mount -t ext4 -o loop,offset=1048576 full_hd.dd /mnt/test/

It may well be possible, that receive this error message as a result to your mount command if you try to mount the disk image read-only:


mount: wrong fs type, bad option, bad superblock on /dev/loop0,
missing codepage or helper program, or other error
In some cases useful info is found in syslog - try
dmesg | tail or so


In this case, examining the system logs, may reveal something like this:


[ 8754.209469] EXT4-fs (loop0): VFS: Can't find ext4 filesystem
[ 8758.913583] EXT4-fs (loop0): INFO: recovery required on readonly filesystem
[ 8758.913587] EXT4-fs (loop0): write access unavailable, cannot proceed


To get around this, try adding the 'noload' option to skip journal recovery:

root@debian:~# mount -t ext4 -o loop,ro,noload,offset=1048576 full_hd.dd /mnt/test/

As far as I’m concerned, I can only tell that this issue rises when netbooting Debian-Installer through PXE/TFTP in combination with a preseed.cfg file, while the latter one being downloaded from a HTTP web-server.
This bevahiour has been observed with Debian Lenny and older versions and can cause quiet some headache upon setup automation if not taken into account.

To summarize the situation before we dig into more details:

• I want to netboot Debian-Installer (the Debian “netinst” image) through PXE/TFTP.
• Debian netinst is launched through pxelinux, as supposed by all common documentation out there
• I want a preseed.cfg to be dynamically downloaded from a web-server during installation to achieve an automatic installation
• Issue Observed: Despite of having set the “debian-installer/locale”, “console-keymaps-at/keymap” and other settings within the preseed.cfg, Debian-Installer keeps asking you for language, keyboard and other values straight after bootup

This article won’t dig into the details of setting up the required boot environment and it’s particular configuration.
I assume you have all of that in place already.

Your current configuration will most likely look like this in your pxelinux.cfg/default file:


label debian507
MENU INDENT 1
MENU LABEL -> Debian GNU 5.0.7
kernel /images/Debian/5.0.7/i386/linux
append vga=normal initrd=/images/Debian/5.0.7/i386/initrd.gz ramdisk_size=65536 \
root=/dev/rd/0 devfs=mount,dall rw auto \
url=http://some.webserver/configs/Debian/5.0.7/i386/preseed.cfg --


Within your preseed.cfg you define some settings with the intend of a full automation. Here’s an excerpt of mine:


# keyboard and locale settings
####################################################################

d-i netcfg/disable_dhcp boolean false
d-i netcfg/get_hostname string localhost
d-i netcfg/get_domain string localdomain
d-i netcfg/choose_interface select eth0


You now would propably expect that having these lines in your preseed.cfg would cause Debian-Installation to stop prompting you after bootup. Instead you still end up being bugged with these prompts:

Now to the question, what causes this behaviour.

Essentially this is sort of a chicken-and-egg problem within Debian-Installer.
Due to it’s internal architecture, the installer consists of multiple parts as lined out in the Debian-Installer internals documentation, which take care about the various stages.

First we have the debian-installer-startup and debian-installer binaries, which care about all the init stuff.
Second we have the main-menu component, which does all the questioning and installation using the underlying debconf framework.

Well, so far so good. debian-installer will take care about a preliminary network setup so it can actually download the preseed.cfg file and will launch menu-menu afterwards.
If will however only do so AFTER questioning for system locale, keyboard and basic network settings – just at a stage, where it simply didn’t (and in fact couldn’t) download the preseed.cfg file.

So, here’s the chicken: We want to get rid of the questioning by using a preseed.cfg, which cannot be download before answering some initial questions.
Here’s the egg: To get rid of the questioning, we need the help of a preseed.cfg.

Well, there’s of course the possibility, to include the preseed.cfg to the initrd image.
This imposes however a problem, as it may harden upgrades and especially automatic installation with different configurations.

Luckily, there is a way to work around this is by includubg these settings with the kernel append parameters through PXELinux as shown below:


label debian507
MENU INDENT 1
MENU LABEL -> Debian GNU 5.0.7
kernel /images/Debian/5.0.7/i386/linux
append vga=normal initrd=/images/Debian/5.0.7-2.6.32-bpo/i386/initrd.gz ramdisk_size=65536 \
root=/dev/rd/0 devfs=mount,dall rw auto \
url=http://some.webserver/configs/Debian/5.0.7/i386/preseed.cfg \
locale=en_US console-keymaps-at/keymap=sg-latin1 \
interface=eth0 hostname=localhost domain=localdomain --


This would indeed cause debian-installer to not prompt for the initial settings, continue with the network initialization, download the preseed.cfg and proceed to main-menu, which would then use the downloaded preseed configuration.

So, you’re here reading this. Maybe just because you slipped this little information in the official documentation?
Ahem … it’s right there:

quote
An important difference between the preseeding methods is the point at which the preconfiguration file is loaded and processed. For initrd preseeding this is right at the start of the installation, before the first question is even asked. For file preseeding this is after the CD or CD image has been loaded. For network preseeding it is only after the network has been configured.

Obviously, any questions that have been processed before the preconfiguration file is loaded cannot be preseeded (this will include questions that are only displayed at medium or low priority, like the first hardware detection run). Section B.2.2, “Using boot parameters to preseed questions” offers a way to avoid these questions being asked.
end quote

My point for writing this topic: If you’re just getting started with preseeding using on of the many HowTo’s out there, without reading the official docs as well, this particular issue is very likely to slip

There exists a similar implementation called Gentoo GNU/kFreeBSD, although I had no time yet to review it.

The Debian developers made some notable progress since last year, but there are still lots of issues. Check out the project website for further details.

Now let’s look at an abscure idea, that struck me when I first looked at Debian GNU/kFreeBSD last spring.

Why not try to run Debian GNU/kFreeBSD inside a native FreeBSD jail (or inside a Debian GNU/kFreeBSD jail)?

One might argue where’s the point in doing so. But under that premise I could also ask, what’s the point then in having hundreds of Linux distros which basically do the same thing — only in a different way?

Let’s imagine the possibilities:

• Run native GNU/kFreeBSD hosts with both GNU/kFreeBSD and native FreeBSD userland jails
• Run native FreeBSD hosts with both GNU/kFreeBSD and native FreeBSD userland jails

If you’re familiar with the concepts of OpenVZ/Virtuozzo or the Linux VServer project, you’ll see some similarities and maybe even the reason for trying out this weird idea.

I must admit, that the current implementation is far away from production grade. There’s a lot of dirty handwork involved. Aparently there is no point in trying to streamline the process right now, since GNU/kFreebSD is still under heavy development. Automated setups should be easy to implement as soon as the Debian Installer is ported and package support is fixed in debootstrap.

Are you ready to read on? Ok, let’s go to work then…

Let’s have a look at how to setup at installing Debian GNU/kFreeBSD inside a native FreeBSD jail.

First of all, get the Debian GNU/kFreeBSD netinst cd. You’ll find it at http://glibc-bsd.alioth.debian.org/install-cd

# wget http://glibc-bsd.alioth.debian.org/install-cd/kfreebsd-i386/20061213/debian-20061213-kfreebsd-i386-install.iso

Now attach the iso image to a vnode and mount it.

#mdconfig -a -t vnode -f debian-20061213-kfreebsd-i386-install.iso
md0
#mkdir /mnt/debinst
#mount_cd9660 /dev/md0 /mnt/debinst

Prepare your new root directory for the jail and untar the base dist. The base dist will take up about 120 MB on disk.

#mkdir /var/jails/debian_jail
#tar -xzpvf /mnt/debinst/base/base.tgz -C /var/jails/debian_jail

Edit the installer file at /var/jails/debian_jail/native-install and comment out the ‘set -e’ directive on line 31. The script will throw lot’s of errors when running inside the jail. If you leave the ‘set -e’ directive as is, the script will abort and you will need to start over.

You’re ready now to start the jail. Please do it manually as shown, you will need to fiddle around with it.
You can add it to /etc/rc.conf for regular startup later.

#ifconfig fxp0 inet alias 192.168.0.13/32
#mount_procfs procfs /var/jails/debian_jail/proc
#jail /var/jails/debian_jail debian_jail 192.168.0.13 /bin/sh

You are now inside the jail. Run the installer script from the root directory.
The installer will ask you for time zone settings, set them as required.
Answer to the popularity contest question to your own preferences.

#/native-install

The script will install and configure system packages. This will take a while.
Don’t worry about errors and warnings, they’re ok for now.

After the script has finished it is time for some further work. Don’t leave the jail yet!

First create a valid /etc/resolv.conf. Then make sure your /etc/fstab is empty to prevent mount errors.

#echo>/etc/fstab

And don’t forget to set the root password.

#passwd

Make sure init won’t tamper with /dev.

#update-rc.d -f makedev remove

Replace /etc/init.d/freebsd-utils by a dummy file as shown below and reconfigure the freebsd-utils package.

#echo exit 0>/etc/init.d/freebsd-utils
#dpkg-reconfigure freebsd-utils

Now you must leave the jail for a minute. ‘exit’ should return you to your host.
Back on the host you need to attach devfs to your jail.

#mount_devfs devfs /var/jails/debian_jail/dev

Then re-enter the jail:

#jail /var/jails/debian_jail debian_jail 192.168.0.13 /bin/sh

It’s time to import the gpg keys into apt and refresh your package list.

#gpg –keyserver subkeys.pgp.net –recv CD02E583 && gpg –export CD02E583 | apt-key add -
#apt-get update

As ssh is not part of the base system, I’d recommend to install it now.

#apt-get install ssh

Maybe you’d like to have aptitude as well? Feel free to install whatever you like.

#apt-get install aptitude

Depending on your software choice your jail will now use around 220 MB or more on disk.
Leave the jail by entering ‘exit’ on the prompt.
Then try to start the jail as shown below.

#jail /var/jails/debian_jail debian_jail 192.168.0.13 /etc/init.d/rc 2
Not starting internet superserver: no services enabled.
Starting OpenBSD Secure Shell server: sshd.

Check if your jail shows up and your processes are running.

#jls
JID IP Address Hostname Path
71 192.168.0.13 debian_jail /var/jails/debian_jail

#pgrep -lfj 71
95086 /usr/sbin/sshd

Your jail should now be accessible through SSH.

#ssh root@192.168.0.13
The authenticity of host ’192.168.0.13 (192.168.0.13)’ can’t be established.
DSA key fingerprint is c5:02:ad:c6:a8:43:30:25:4a:d0:bd:71:ca:cc:f0:25.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added ’192.168.0.13′ (DSA) to the list of known hosts.
root@192.168.0.13′s password:

The programs included with the Debian GNU/kFreeBSD system are free software;
the exact distribution terms for each program are described in the
individual files in /usr/share/doc/*/copyright.

Debian GNU/kFreeBSD comes with ABSOLUTELY NO WARRANTY, to the extent
permitted by applicable law.
debian_jail:~#

So far, so good. Your jail Debian GNU/kFreebSD is now up and running, sort of…

There’s a caveat that you may already have noticed. init(8) is not yet working as supposed to, so there’s actually no parent init process as it should. Neither is there proper resource or runlevel control. This is definitely an issue which would require further investigation.

Furthermore when playing around with it you’ll notice that there are other things not working properly, like process information tools (ps, top, etc), a multitude of errors in init scripts, most of them being access errors due to the jail enviroment, erratic behaviour on package configuration when it comes to accessing device nodes, and many, many more.

However one must consider Debian GNU/kFreeBSD still being under development on one hand, and it was never meant to be actually run inside a jail on the other.

It would be nice if it became a standing feature in the future, maybe even for sidekicks like Gentoo GNU/kFreeBSD and other distros out there.

Another task would be checking the jail functionality vice-versa to see, how a native FreeBSD userland can be run inside a jail on a Debian GNU/kFreeBSD host.
As to my understanding of the existing implementation that shouldn’t be too tricky as FreeBSD userland is already fully jail-aware.

I’m looking forward to trying this on my own as soon as the jail utilities become available on Debian GNU/kFreeBSD one day.

One caveat is the fact the manual was written for a bootstrap server running Linux in mind (have a look at section 4.3.2 Enabling the TFTP Server).

Since my bootstrap server is running FreeBSD a slight variation of the steps as lined out in section 4.3.2 is needed.

Path MTU discovery is disabled like this:

#sysctl net.inet.tcp.path_mtu_discovery=0

To further restrict source ports for TFTP to stay below 32767 as required by most elder SGI PROM versions these additional commands must be run:

#sysctl net.inet.ip.portrange.first=2048
#sysctl net.inet.ip.portrange.last=32767

This will effectively allow bootstrapping the Debian/mips netinst image from a FreeBSD host.

After plugging in a dual Intel Pro 1000 into my Debian box and hooking it up to my ancient Cisco 1924 switch, I noticed this in the kernel logs:

Jul 31 09:10:35 localhost kernel: e1000: eth0: e1000_watchdog: NIC Link is Up 100 Mbps Half Duplex

I though it should be fairly easy set the interface speeds properly so the devices would actually talk to each other.

While doing so on the Cisco was actually easy, the Linux box would refrain from doing so at a first glance.

#ethtool -s eth0 speed 100 duplex full

Running the command given above resulted in an error preventing me to set the parameters. It took me a while to find out that I had to actually turn off auto negotiation to make it work, too.

#ethtool -s eth0 speed 100 duplex full autoneg off

Now I had to make this change permanent as it would reset to defaults after the next reboot. I did so by adding the post-up line to my /etc/network/interfaces file:

auto eth0
iface eth0 inet static
post-up /usr/sbin/ethtool -s eth0 speed 100 duplex full autoneg off
address 192.168.0.100
netmask 255.255.255.0
gateway 192.168.0.1

It should be noted, that the module documention at Intel’s website does not actually state that auto-negotiation must be turned off when setting interface speed and duplex modes. The question remains if this was only the case on my particular setup or if it is an absolute requirement after all.