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=192.168.40.2:/mnt/amd64
timeout 50
totaltimeout 300
This effectively bypasses most of the other files (and their screwy
paths)
/mnt/amd64 has the results of running
debootstrap --arch=amd64 --foreign --include openssh-server
--variant=minbase testing amd64 http://debian.betterworld.us:\
3142/mainline
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
further.
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
unknown-block(0,255)
Possibilities:
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.
Ross
Reply to: