[SOLVED] Diskless Question

hamhock · 2017-01-14 17:03:56

I have setup PXE with tftp, http and NFS capability. I'm presently booting a headless server (the client) via PXE and can have it boot either it's minimal arch install off hd0 or several arch ISO options, e.g., Arch Live Netboot or Archboot.

what I want to be able to do is to:

1. ssh into client with no manual intervention on client
2. load arch into ram
3. do admin tasks, and install packages that may need, e.g., partclone

I can do #1 and #2 with archboot, but not #3

I believe diskless is probably my best option unless I can spin my own archiso and have it load into ram.

Are these my only two choices? Is diskless the better of the two for my use case?

Last edited by hamhock (2017-01-18 21:09:46)

hamhock · 2017-01-15 16:53:16

I'm going give diskless a try.

this is the pacstrap command in the Diskless wiki:

# pacstrap -d "$root" base mkinitcpio-nfs-utils nfs-utils

I assume "$root" is a variable. would I run this before the pacstrap command?

# root=/srv/tftp/nfs/arch

Last edited by hamhock (2017-01-15 17:03:29)

Trilby · 2017-01-15 17:53:33

That's correct for interpreting the instructions. But you don't really need to define the variable then use a variable - you certainly can, but you can also just put /srv/tftp/nfs/arch in place of it:

pacstrap -d /srv/tftp/nfs/arch base ...

It's common to use a variable like that in instructions. It doesn't mean you need a variable, it's just to indicate what part of the instructions you need to replace with something specific to your system. Sometimes people will also use angled brackets for this purpose `pacman -Syu <pkgname>` to install a package, for example. But in actual code tags in the wiki, angled brackets are a bit informal and ambiguous - so variables are more clear.

hamhock · 2017-01-16 03:26:54

diskless install went without a hitch. When I boot the client everything starts ok, then get these errors:

starting version 232
:: running hook [udev]
:: triggering uevents...
:: running hook [net_nfs4]
ERROR: device '' not found.  Skipping fsck.
ERROR: Unable to find root device "".
You are being dropped to a recovery shell

nomorewindows · 2017-01-16 04:34:06

hamhock wrote:

diskless install went without a hitch. When I boot the client everything starts ok, then get these errors:
starting version 232
:: running hook [udev]
:: triggering uevents...
:: running hook [net_nfs4]
ERROR: device '' not found.  Skipping fsck.
ERROR: Unable to find root device "".
You are being dropped to a recovery shell

You may need to chroot your PXE installation root to be able to (only once though)

systemctl enable sshd

&
You will probably need to redo (also under chroot)

mkinitcpio -p linux

after making sure that you have the right options set in mkinitcpio.conf. All you need in hooks is base, udev, net[4], autodetect. You can remove the rest of them.
And you need to make your pxelinux.cfg/default read something like this (should be in the wiki):

label xyz
kernel /whereever/boot/vmlinuz-linux
append init=/usr/lib/systemd/systemd initrd=/whereever/boot/initramfs-linux.img root=/dev/nfs rootfstype=nfs nfsroot=xxx.xxx.xxx.xxx:/wherever ip=::::::dhcp

Arch made this process so easy...

Last edited by nomorewindows (2017-01-16 04:37:49)

hamhock · 2017-01-16 06:44:29

thanks for the help. I followed your steps and the boot process goes a bit further:

IP-Config: etho0 complete (from 192.168.0.1)
...
domain : home
rootserver: 192.168.0.1 rootpath:
filename  : 
NFS-Mount: 192.168.0.20:/srv/tftp/nfs/arch
Waiting 10 seconds for device /dev/nfs ...
mount.nfs4: rpc.statd is not running but is required for remote locking.
mount.nfs4: Either use '-o nolock' to keep locks local, or start statd.
:: running cleanup hook [udev]
ERROR: Failed to mount the real root device.
Bailing out ...

rpc services:

rpc-statd.service                                                      loaded active running NFS status monitor for NFSv2/3 locking.
rpcbind.service                                                        loaded active running RPC Bind

here's my syslinux default

label arch-diskless-2
        Menu LABEL arch-diskless2-NFS
        kernel nfs/arch/boot/vmlinuz-linux
        append init=/usr/lib/systemd/systemd initrd=nfs/arch/boot/initramfs-linux.img root=/dev/nfs rootfstype=nfs nfsroot=192.168.0.20:/srv/tftp/nfs/arch ip=::::::dhcp

Last edited by hamhock (2017-01-16 06:57:18)

nomorewindows · 2017-01-16 17:02:27

hamhock wrote:

thanks for the help. I followed your steps and the boot process goes a bit further:

IP-Config: etho0 complete (from 192.168.0.1)
...
domain : home
rootserver: 192.168.0.1 rootpath:
filename  : 
NFS-Mount: 192.168.0.20:/srv/tftp/nfs/arch
Waiting 10 seconds for device /dev/nfs ...
mount.nfs4: rpc.statd is not running but is required for remote locking.
mount.nfs4: Either use '-o nolock' to keep locks local, or start statd.
:: running cleanup hook [udev]
ERROR: Failed to mount the real root device.
Bailing out ...

rpc services:

rpc-statd.service                                                      loaded active running NFS status monitor for NFSv2/3 locking.
rpcbind.service                                                        loaded active running RPC Bind

here's my syslinux default

label arch-diskless-2
        Menu LABEL arch-diskless2-NFS
        kernel nfs/arch/boot/vmlinuz-linux
        append init=/usr/lib/systemd/systemd initrd=nfs/arch/boot/initramfs-linux.img root=/dev/nfs rootfstype=nfs nfsroot=192.168.0.20:/srv/tftp/nfs/arch ip=::::::dhcp

You might check on the differences between using nfs 3 and nfs 4.
You may have to specify a full path for kernel and intird, and you may have to use another nfs/rpcbind/something for nfs4....

hamhock · 2017-01-16 18:26:11

appreciate the help.

nomorewindows wrote:

You might check on the differences between using nfs 3 and nfs 4.

seems others have had issues with nfsv4. I would prefer to stay with nfsv4, unless nfsv3 is the only way.

You may have to specify a full path for kernel and intird

tried that - but unfortunately no change in boot result.

and you may have to use another nfs/rpcbind/something for nfs4....

not sure if I understand. Is there another service I should use instead of rpcbind.service?

nomorewindows · 2017-01-16 19:56:17

hamhock wrote:

appreciate the help.
nomorewindows wrote:
You might check on the differences between using nfs 3 and nfs 4.
seems others have had issues with nfsv4. I would prefer to stay with nfsv4, unless nfsv3 is the only way.
You may have to specify a full path for kernel and intird
tried that - but unfortunately no change in boot result.
and you may have to use another nfs/rpcbind/something for nfs4....
not sure if I understand. Is there another service I should use instead of rpcbind.service?

I am running v3 nfs and net in mkinitcpio instead of net_nfs4, you maybe able to just append

,v3

to the end of your nfsroot and see if nfs4 will use nfs3. According to the wiki it looks like you have to have net and net_nfs4 in hooks for nfs4.
So you have nfs-server running, and possibly nfs-idmapd, nfs-statd, nfs-mountd and rpcbind, rpc-statd?

hamhock · 2017-01-16 20:29:17

nomorewindows wrote:

I am running v3 nfs and net in mkinitcpio instead of net_nfs4, you maybe able to just append
,v3
to the end of your nfsroot and see if nfs4 will use nfs3.

I appended ",v3" with slightly different result:

mount.nfs4: Protocol not supported
:: running cleanup hook [udev]
ERROR: Failed to mount the real root device.

nomorewindows wrote:

According to the wiki it looks like you have to have net and net_nfs4 in hooks for nfs4.

so I added "net" to the HOOKS list, but no change in boot result.

HOOKS="base udev block filesystems net net_nfs4"

nomorewindows wrote:

So you have nfs-server running, and possibly nfs-idmapd, nfs-statd, nfs-mountd and rpcbind, rpc-statd?

these are all running:

gssproxy.service 
nfs-server.service  
nfs-idmapd.service 
nfs-mountd.service
nfs-server.service
rpc-statd.service
rpcbind.service

you mentioned "nfs-statd" so i tried to start that:

Failed to start nfs-statd.service: Unit nfs-statd.service not found.

nomorewindows · 2017-01-17 06:39:09

hamhock wrote:

nomorewindows wrote:
I am running v3 nfs and net in mkinitcpio instead of net_nfs4, you maybe able to just append
,v3
to the end of your nfsroot and see if nfs4 will use nfs3.
I appended ",v3" with slightly different result:
mount.nfs4: Protocol not supported
:: running cleanup hook [udev]
ERROR: Failed to mount the real root device.
nomorewindows wrote:
According to the wiki it looks like you have to have net and net_nfs4 in hooks for nfs4.
so I added "net" to the HOOKS list, but no change in boot result.
HOOKS="base udev block filesystems net net_nfs4"
nomorewindows wrote:
So you have nfs-server running, and possibly nfs-idmapd, nfs-statd, nfs-mountd and rpcbind, rpc-statd?
these are all running:
gssproxy.service 
nfs-server.service  
nfs-idmapd.service 
nfs-mountd.service
nfs-server.service
rpc-statd.service
rpcbind.service  
you mentioned "nfs-statd" so i tried to start that:
Failed to start nfs-statd.service: Unit nfs-statd.service not found.

nfsroot like this?

nfsroot=192.168.0.20:/srv/tftp/nfs/arch,v3

It might need a nfs4 module in modules or maybe if you take all that out with the v3 (which maybe redundant anyhow) and just net by itself. You did

 mkinitcpio -p linux

under chroot for PXIE installation root for any changes made to /srv/tftp/nfs/arch/etc/mkinitcpio.conf?
It won't hurt anything to have block and filesystem in hooks, it just doesn't need it to make your initramfs image for a PXE client. You could actually set your root with the PXE kernel to boot something from the hard drive that way as long as the kernels are the same. IT just work like your regular kernel only it downloaded it over the network instead of the hard drive.
I guess it's rpc-statd not nfs-statd, but you already have it...
You can try mounting your root from the emergency shell...of course if you had a keyboard (or another test machine with a keyboard, maybe even a usb keyboard and may need keyboard hook for that).

hamhock · 2017-01-17 17:10:49

nomorewindows wrote:

It might need a nfs4 module in modules

thanks again. it's been there since my first edit of mkinitcpio.conf (chroot)

MODULES="nfsv4"

Here's the most recent boot output:

domain : home
rootserver: 192.168.0.1 rootpath:
filename  : 
NFS-Mount: 192.168.0.20:/srv/tftp/nfs/arch
Waiting 10 seconds for device /dev/nfs ...
mount.nfs4: Protocol not supported
:: running cleanup hook [udev]
ERROR: Failed to mount the real root device.
Bailing out ...

nomorewindows wrote:

or maybe if you take all that out with the v3 (which maybe redundant anyhow) and just net by itself.

when I remove "net_nfs4" from HOOKS ("net" instead) and "nfsv4" from MODULES, I get similar boot output, but instead of "mount.nfs4: Protocol not supported", i get

mount: Protocol not supported

nomorewindows wrote:

You did
 mkinitcpio -p linux
under chroot for PXIE installation root for any changes made to /srv/tftp/nfs/arch/etc/mkinitcpio.conf?

yes - whenever I make a change in mkinitcpio.conf

nomorewindows wrote:

You could actually set your root with the PXE kernel to boot something from the hard drive that way as long as the kernels are the same. IT just work like your regular kernel only it downloaded it over the network instead of the hard drive.

you mean to point it to my desktop's working arch install?

nfsroot=192.168.0.20:/boot,v3

nomorewindows wrote:

You can try mounting your root from the emergency shell...of course if you had a keyboard (or another test machine with a keyboard, maybe even a usb keyboard and may need keyboard hook for that).

when I add "keyboard" to HOOKS, I can use the usb keyboard i attached to the client. I'm just not sure what command to issue.

If trying to force a boot via nfsv3, should I also make a change in the server's /etc/exports? this is what I have presently

/srv/tftp/nfs      *(rw,fsid=0,no_root_squash,no_subtree_check)
/srv/tftp/nfs/arch  *(rw,no_root_squash,no_subtree_check)

Last edited by hamhock (2017-01-17 19:59:43)

nomorewindows · 2017-01-17 20:29:00

hamhock wrote:

nomorewindows wrote:
It might need a nfs4 module in modules
thanks again. it's been there since my first edit of mkinitcpio.conf (chroot)
MODULES="nfsv4"
Here's the most recent boot output:
domain : home
rootserver: 192.168.0.1 rootpath:
filename  : 
NFS-Mount: 192.168.0.20:/srv/tftp/nfs/arch
Waiting 10 seconds for device /dev/nfs ...
mount.nfs4: Protocol not supported
:: running cleanup hook [udev]
ERROR: Failed to mount the real root device.
Bailing out ...
nomorewindows wrote:
or maybe if you take all that out with the v3 (which maybe redundant anyhow) and just net by itself.
when I remove "net_nfs4" from HOOKS ("net" instead) and "nfsv4" from MODULES, I get similar boot output, but instead of "mount.nfs4: Protocol not supported", i get
mount: Protocol not supported
nomorewindows wrote:
You did
 mkinitcpio -p linux
under chroot for PXIE installation root for any changes made to /srv/tftp/nfs/arch/etc/mkinitcpio.conf?
yes - whenever I make a change in mkinitcpio.conf
nomorewindows wrote:
You could actually set your root with the PXE kernel to boot something from the hard drive that way as long as the kernels are the same. IT just work like your regular kernel only it downloaded it over the network instead of the hard drive.
you mean to point it to my desktop's working arch install?
nfsroot=192.168.0.20:/boot,v3 
nomorewindows wrote:
You can try mounting your root from the emergency shell...of course if you had a keyboard (or another test machine with a keyboard, maybe even a usb keyboard and may need keyboard hook for that).
when I add "keyboard" to HOOKS, I can use the usb keyboard i attached to the client. I'm just not sure what command to issue.

If trying to force a boot via nfsv3, should I also make a change in the server's /etc/exports? this is what I have presently
/srv/tftp/nfs      *(rw,fsid=0,no_root_squash,no_subtree_check)
/srv/tftp/nfs/arch  *(rw,no_root_squash,no_subtree_check)

While it doesn't really hurt anything, you could do without the nfs part in your path, and you don't really need both nfs and nfs/arch in your exports. If you are transversing nfs/arch through nfs all you need is just /srv/tftp/nfs or you could just point your root to /srv/tftp/nfs/arch, which it looks that is what you are doing...

I guess I should really try a nfs4 and see what I come up so maybe I can follow what the problem is. I probably have tried it before, and don't remember much about it. And that's probably why I specify v3 is that's what I started out using before nfs4 came along...being that nfs4 is probably more powerful, it also seems to create some more complexity here in diskless land. You can also check your mounts on the PXE server to make sure that everything is ok...

showmount --exports

You could try mounting the nfs share yourself at the emergency shell and see what happens (with your usb keyboard), make sure it still has an ip address (which it still should), with

ip addr

Wait a minute...the rootserver says 192.168.0.1 and you have your nfsroot line pointing to 192.168.0.20, it should probably be pointing to 192.168.0.1 if that's your PXE server...anyhow try

mount  192.168.0.1:/srv/tftp/nfs/arch /new_root

and then exit from the shell. See if it boots....

If you use the PXE's kernel and you want to boot from the hard drive, all you would need is just root=/dev/sdxxxx in your line....just a word of caution, though if the kernels are different, you'll most likely get a fuss...

hamhock · 2017-01-18 17:34:58

Success - finally. here are the pertinent lines in mkinitcpio.conf. i later added "e1000" for testing on a virtualbox client.

MODULES="e1000 nfs"
BINARIES=""
HOOKS="base udev autodetect block filesystems keyboard fsck net"

and the PXE default

label arch-diskless-nfs3
        Menu LABEL arch-diskless-nfsv3
        kernel nfs/arch/boot/vmlinuz-linux
        append init=/usr/lib/systemd/systemd initrd=nfs/arch/boot/initramfs-linux.img root=/dev/nfs rootfstype=nfs nfsroot=192.168.0.20:/srv/tftp/nfs/arch,v3 ip=::::::dhcp

Unless there is a compelling reason to use nfsv4, I think I'll quit trying to make that work and stay with nfsv3.

nomorewindows in the distant past wrote:

just point pacman to your installation directory and away you go.

what did you mean by that?

nomorewindows · 2017-01-18 19:51:32

hamhock wrote:

Success - finally. here are the pertinent lines in mkinitcpio.conf. i later added "e1000" for testing on a virtualbox client.
MODULES="e1000 nfs"
BINARIES=""
HOOKS="base udev autodetect block filesystems keyboard fsck net" 
and the PXE default
label arch-diskless-nfs3
        Menu LABEL arch-diskless-nfsv3
        kernel nfs/arch/boot/vmlinuz-linux
        append init=/usr/lib/systemd/systemd initrd=nfs/arch/boot/initramfs-linux.img root=/dev/nfs rootfstype=nfs nfsroot=192.168.0.20:/srv/tftp/nfs/arch,v3 ip=::::::dhcp
Unless there is a compelling reason to use nfsv4, I think I'll quit trying to make that work and stay with nfsv3.
nomorewindows in the distant past wrote:
just point pacman to your installation directory and away you go.
what did you mean by that?

pacman -S xxxxx -r /srv/tftp/nfs/arch [--config (if needed)] [--arch (if needed)]

or just pacstrap like you've been using...

HOOKS=base udev net autodetect keyboard

is all you really need in HOOKS.
You probably won't need anything in MODULES.
Otherwise looks right...

Don't forget to mark as solved if everything on a real client works...
I'll see if I get around to testing nfsv4 again...

hamhock · 2017-01-18 21:09:31

nomorewindows wrote:

pacman -S xxxxx -r /srv/tftp/nfs/arch [--config (if needed)] [--arch (if needed)]
or just pacstrap like you've been using...

ok - that clears that up.

I'll mark as SOLVED - thanks for your help.

nomorewindows · 2017-01-19 18:47:37

hamhock wrote:

nomorewindows wrote:
pacman -S xxxxx -r /srv/tftp/nfs/arch [--config (if needed)] [--arch (if needed)]
or just pacstrap like you've been using...
ok - that clears that up.
I'll mark as SOLVED - thanks for your help.

Thought of something else...you might want darkhttpd to point at /srv/tftp/nfs/arch/boot instead of the whole installation...if there were any security concerns, this would limit it to just the PXE installation /boot directory for just the /boot files.

Arch Linux

#1 2017-01-14 17:03:56

[SOLVED] Diskless Question

#2 2017-01-15 16:53:16

Re: [SOLVED] Diskless Question

#3 2017-01-15 17:53:33

Re: [SOLVED] Diskless Question

#4 2017-01-16 03:26:54

Re: [SOLVED] Diskless Question

#5 2017-01-16 04:34:06

Re: [SOLVED] Diskless Question

#6 2017-01-16 06:44:29

Re: [SOLVED] Diskless Question

#7 2017-01-16 17:02:27

Re: [SOLVED] Diskless Question

#8 2017-01-16 18:26:11

Re: [SOLVED] Diskless Question

#9 2017-01-16 19:56:17

Re: [SOLVED] Diskless Question

#10 2017-01-16 20:29:17

Re: [SOLVED] Diskless Question

#11 2017-01-17 06:39:09

Re: [SOLVED] Diskless Question

#12 2017-01-17 17:10:49

Re: [SOLVED] Diskless Question

#13 2017-01-17 20:29:00

Re: [SOLVED] Diskless Question

#14 2017-01-18 17:34:58

Re: [SOLVED] Diskless Question

#15 2017-01-18 19:51:32

Re: [SOLVED] Diskless Question

#16 2017-01-18 21:09:31

Re: [SOLVED] Diskless Question

#17 2017-01-19 18:47:37

Re: [SOLVED] Diskless Question

Board footer