Welcome to the Slackware Documentation Project

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revision Previous revision
Next revision
Previous revision
howtos:network_services:nfs_root [2018/05/28 22:09 (UTC)]
bifferos [Creating the kernel]
howtos:network_services:nfs_root [2018/05/28 22:21 (UTC)]
bifferos [First Boot]
Line 97: Line 97:
 Obviously keep your default linux kernel in another image= section so you can switch between booting the nfsroot and the normal kernel to play around with this stuff. Obviously keep your default linux kernel in another image= section so you can switch between booting the nfsroot and the normal kernel to play around with this stuff.
  
-You cannot specify a normal root= entry in this section because ​lilo doesn'​t recognise /dev/nfs for root (the device doesn'​t actually exist to LILO). ​ So instead just specify it in the append= line which lilo doesn'​t try to interpret, and lilo will include this extra nfsroot image without error.+You cannot specify a normal root= entry in this section because ​LILO doesn'​t recognise /dev/nfs for root (the device doesn'​t actually exist to LILO). ​ So instead just specify it in the append= line which LILO doesn'​t try to interpret, and LILO will include this extra nfsroot image without error.
  
 The v3 seems to be really important in making anything at all happen on boot.  If that isn't set, no communication seems to occur. The v3 seems to be really important in making anything at all happen on boot.  If that isn't set, no communication seems to occur.
  
-The '​rw'​ is also important. ​ It prevents the fsck of the root fs. because root is NFS and can't be checked. ​ Slackware won't boot properly if we give '​ro'​. ​ Instead of using '​rw'​ you could optionally hack fsck out of the slackware ​startup scripts on your NFS root, however simply using '​rw'​ is quicker (albeit dirtier).+The '​rw'​ is also important. ​ It prevents the fsck of the root fs. because root is NFS and can't be checked. ​ Slackware won't boot properly if we give '​ro'​. ​ Instead of using '​rw'​ you could optionally hack fsck out of the Slackware ​startup scripts on your NFS root, however simply using '​rw'​ is quicker (albeit dirtier).
  
 With the kernel compilation finished, copy the kernel into the /boot directory and rename it: With the kernel compilation finished, copy the kernel into the /boot directory and rename it:
Line 107: Line 107:
 <​code>​cp /​usr/​src/​linux/​arch/​x86/​boot/​bzImage /​boot/​vmlinuz-nfsroot</​code>​ <​code>​cp /​usr/​src/​linux/​arch/​x86/​boot/​bzImage /​boot/​vmlinuz-nfsroot</​code>​
  
-It may be created elsewhere depending on your architecture,​ e.g. x64, arm.+It may be created elsewhere ​than arch/​x86 ​depending on your architecture,​ e.g. x64, arm.
  
 Don't forget to run LILO: Don't forget to run LILO:
Line 121: Line 121:
 None of the modules have been installed, let's add them.  Shutting down the nfsroot system and booting back into the Slackware kernel compilation virtual machine we can now compile the missing modules. ​ First we will mount the rootfs, just as we did from the installer virtual machine: None of the modules have been installed, let's add them.  Shutting down the nfsroot system and booting back into the Slackware kernel compilation virtual machine we can now compile the missing modules. ​ First we will mount the rootfs, just as we did from the installer virtual machine:
  
-<​code>​mount -o rw,nolock slack-nfs-server:/​nfs_share /​mnt</​code>​+<​code>​mount -o rw,nolock slack-nfs-server:/​nfs_share /mnt/tmp</​code>​
  
 Then we can compile and install the modules: Then we can compile and install the modules:
Line 127: Line 127:
 <​code>#​ cd /​usr/​src/​linux <​code>#​ cd /​usr/​src/​linux
 # make modules # make modules
-# make modules_install INSTALL_MOD_PATH=/​mnt</​code>​+# make modules_install INSTALL_MOD_PATH=/​mnt/tmp</​code>​
  
-For the last command, ​try to avoid adding a trailing slash to /mnt, and try not to forget the INSTALL_MOD_PATH,​ otherwise you'​ve ​just clobbered your system modules. ​ If you gave your kernel a local suffix (e.g. -nfsroot) you'd have been protected against that.+For the last command, avoid adding a trailing slash to /mnt/tmp, and try not to forget the INSTALL_MOD_PATH,​ otherwise you may have just clobbered your system modules. ​ If you gave your kernel a local suffix (e.g. -nfsroot) you'd have been protected against that.
  
 === Swap on NFS === === Swap on NFS ===
Line 157: Line 157:
 <​code>/​nfs_share 172.17.0.81/​32(rw,​sync,​no_root_squash,​no_subtree_check)</​code>​ <​code>/​nfs_share 172.17.0.81/​32(rw,​sync,​no_root_squash,​no_subtree_check)</​code>​
  
-And we presumably don't want all-and-sundry using our newly prepared rootfs directory, so drop it down a level and qualify it by IP address:+And we presumably don't want all-and-sundry using our newly prepared rootfs directory, so drop it down a level and qualify it by IP address ​(on the server):
  
 <​code>#​ cd / <​code>#​ cd /
Line 164: Line 164:
 # mv 172.17.0.81 nfs_share</​code>​ # mv 172.17.0.81 nfs_share</​code>​
  
-Now over on the client ​machine, having booted into the kernel compilation ​machine, configure ​lilo so nfsroot+Now over on the client machine, configure ​LILO so nfsroot
 requests the nfs share based on the client'​s IP address with '​%s':​ requests the nfs share based on the client'​s IP address with '​%s':​
  
Line 174: Line 174:
 NFS Root is never going to be considered secure, but at least this makes cross-contamination of nfsroots less likely. NFS Root is never going to be considered secure, but at least this makes cross-contamination of nfsroots less likely.
  
 +Note that I am using dhcp in the above example, but I've added an entry to /​etc/​dnsmasq.conf on my router mapping the thin client MAC address to the IP address 172.17.0.81 so the client always gets that address.
  
  

In Other Languages
QR Code
QR Code howtos:network_services:nfs_root (generated for current page)