Re: Help netbooting a diskless, headless system
On Tuesday, November 13, 2012 12:19:34 PM Ross Boylan wrote:
> 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.
Internal/External SATA, USB2, USB3, Firewire. You've plenty of disk attachment
points. You should be able to use a USB-to-EIA232 adapter (that uses the USB
Serial Class) to provide a serial port for console control. Do you have a
modern TV (with HDMI) handy? Does your computer monitor have two inputs?
Were I in your shoes, I would use any kbd/monitor I had handy to learn how to
control/configure the BIOS. I would learn how to do all of it using an
existing 32-bit system. I'd install to a bootable USB thumb drive. Once I
learned the ins and outs, I'd then set up another bootable thumb drive with
just initramfs and kernel configured to use a serial console and to boot
diskless.
In short, you're poking in the dark. Connect a keyboard and monitor to it so
you can see what you're doing and to configure the BIOS. I did this sort of
thing years back installing Linux on a CompactPCI system. First I had to
figure out how to build a kernel since the standard kernels back then didn't
support PREP/CHRP (and never did); I ended up installing SuSE/PPC to my BeBox
and building there. Once I learned the ins and outs, I could boot it from the
built in CF to either TFTP or internal HD. The whole purpose of that SBC was
to set up a automatic PPP-over-SSH tunnel; and it worked well. But I
wouldn't've succeeded working in the dark.
Reply to: