[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Help netbooting a diskless, headless system

On Mon, 2012-11-12 at 21:57 -0500, Neal Murphy wrote:
> Does your box have a serial port? 
No.  USB and LAN ports.  I investigated SOL, serial over LAN, and IPMI,
but can't get access to it; apparently it ordinarily must be enabled on
the target machine as a first step (if it's there at all, which I
suspect it is since an Intel mobo DH77DF).
> Can it be configured to display the BIOS
> screen on the serial port? Can Debian be installed using a serial port? That
> is, connect a null-modem serial cable between the box to be installed and some
> other computer and use minicom (Linux) or Hyperterm (Win).
> Or put the hard drive into another regular computer, 
The system is diskless.  Also, I have no other amd64 computers.
> install there, then move
> the drive back to the target box. And (1) enable a getty on /dev/ttyS0 and (2)
> add 'console=ttys0,115200' to grub. The only oddity you should encounter here
> is that the target box's NIC won't be eth0; this results from how udev works,
> but it can be changed if desired.
> Grub0 can be configured to poll both the VESA console and a serial port, then
> use whichever gets the first keystroke (or time out and use the selected
> default). I don't know how (or if) Grub2 handles this situation. So if the box
> has no drive and no VESA console and you cannot redirect the BIOS to a serial
> port, you'll be blind until grub starts.
> Another possibility. Check if the system has a compact flash socket.
Since it has USB I believe I could boot from that.  But there again, it
would expect me to control it from the local computer .
>  If so,
> you could effectively install a /boot to it with a custom initramfs that
> contains enough command line tools (and libs) to run a fairly minimal 'live'
> system in RAM; this might take a 100-300 MiB. As it boots, it can mount the
> rest of what it needs over the net. My firewall has a smallish initramfs
> (30MiB compressed CPIO, about 100MiB in RAM). It's a fairly fully usable
> environment with a real init and a few real tools with busybox handling
> others; I made it to ease debugging the install process. It works well on
> standard computers and works well on headless systems like the Lanner 7530 and
> 7539 network appliances using a serial console.
> You *can* do what you want, but it requires you to roll up your sleeves and
> get up to your elbows in slimy bits. But then, Debian might have something for
> this already. The hard part will be to redirect the install session to a 
> serial port.

I've gotten a little further, though still no joy.
I took the terminal-based testing netboot material for amd64 (only used
the linux and pxelinux.0 files) and created a config file with the magic
name including the UUID of the new client.  It has
label install
	menu label ^Install
	menu default
	kernel linux
	append vga=788 root=/dev/nfs nfsroot=
	timeout 50
	totaltimeout 300
This effectively bypasses most of the other files (and their screwy

/mnt/amd64 has the results of running
debootstrap --arch=amd64 --foreign --include openssh-server
--variant=minbase testing amd64 http://debian.betterworld.us:\
from my testing chroot.  It's exported via NFS.

The idea was to create enough of a system that it would start and run
the ssh server so I could ssh in.  On reflection, since none of the
packages are fully installed, that probably  won't work even if I get

The the client shows the early linux kernel load but fails with
No Filesystem could mount root, tried:
Kernel panic - not syncing: VFS: Unable to mount root fs on

1. The installer kernel does not support NFS.
2. I needed to load an NFS-related package as part of deboostrap. (Also,
the man page says --include= is the syntax; I'm not sure if omitting the
"=" is a problem).
3. Skipping the initrd suppliedd with the installer messed things up.
(I was worried using it would take me into the installer).
4. The result of deboostrap --foreign is radically incomplete.  /boot is
empty; several other key system files have stubs, including fstab.  I've
been unable to discover exactly what one is supposed to do with the
material created by deboostrap --foreign.  It seems the idea is to run
debootstrap --second-stage on the target system, but how to get to that
point is unclear.


Reply to: