You are not logged in.
Greetings all, hope you can help me out.
Been given a task by my company of making a network bootable ICA client (with X and Firefox, with the Citrix ICA client installed) as small as possible to minimize network traffic (as 440 workstations would be downloading the end-product simultaneously, so it'd beat ten bells of proverbial out of the core and edge switches for a little while). I discovered two options. One being to integrate everything in side a cloop image directly inside the INITRD. I have stacks of working INITRDs with their matched kernels yet being my first dabble in to extracting the INITRD, my faffing with CPIO has resulted in me nuking my base layout (Thank god for snapshotting in VMware Workstation!) 4 times, and either getting "Premature end of file" or a copius amount of lines stating "cpio: Malformed Number: <strange characters>" finally ending with "Premature end of file". As a result I went in search of another option, which would be booting off an NFS share. I followed the guide:
http://wiki.archlinux.org/index.php/Dis … t_NFS_root
...in order to set up a network booted install of Arch and hit a few snags along the way, probably a result of using multiple operating systems for the TFTP and NFS server as opposed to using what the guide recommends, but I'm not sure as these seem solvable, although I don't know how right now.
The set up:
DHCP is provided by a Microsoft Windows Server 2003 VM (AD Integrated) on 172.16.10.17 on a box called "Rex".
TFTP is provided by another Windows Server 2003 VM by "TFTPd32" which is a free download. This is located on 172.16.10.158 on a box called "Terra".
The NFS store is provided by OpenFiler 2.3 which is a specialized version of rPath Linux designed specifically for turning boxes in to dedicated NAS stores. This is located on 172.16.10.6, and is called "frcnet-nas-1".
The problem:
DHCP is correctly configured with a Boot Host Name (Which is 172.16.10.158) and a boot file name of "pxelinux.0". This is confirmed as working.
Client gets the kernel and INITRD from TFTP and boots up fine until it hits "Waiting for devices to settle..." by which point it echos out "Root device /dev/nfs doesn't exist, attempting to create it...", which it seems to do so fine. It then passes control over to kinit and echos "INIT: version 2.86 booting" and the archlinux header, and immediately after that it prints:
mount: only root can do that
mount: only root can do that
mount: only root can do that
/bin/mknod: '/dev/null': File exists
/bin/mknod: '/dev/zero': File exists
/bin/mknod: '/dev/console': File exists
/bin/mkdir: cannot create directory '/dev/pts': File exists
/bin/mkdir: cannot create directory '/dev/shm': File exists
/bin/grep: /proc/cmdline: No such file or directory
/etc/rc.sysinit: line 72: /proc/sys/kernel/hotplug: No such file or directory
:: Using static /dev filesystem [DONE]
:: Mounting Root Read-only [FAIL]
:: Checking Filesystems [BUSY]
/bin/grep: /proc/cmdline: No such file or directory
:: Mounting Local Filesystems
mount: only root can do that
mount: only root can do that
mount: only root can do that
[DONE]
:: Activating Swap [DONE]
:: Configuring System Clock [DONE]
:: Removing Leftover Files [DONE]
:: Setting Hostname: myhost [DONE]
:: Updating Module Dependencies [DONE]
:: Setting Locale: en_US.utf8 [DONE]
:: Setting Consoles to UTF-8 mode[BUSY]
/etc/rc.sysinit: line 362: /dev/vc/0: No such file or directory
/etc/rc.sysinit: line 363: /dev/vc/0: No such file or directory
/etc/rc.sysinit: line 362: /dev/vc/1: No such file or directory
/etc/rc.sysinit: line 363: /dev/vc/1: No such file or directory
... all the way down to vc/63 ...
:: Loading Keyboard Map: us [DONE]
INIT: Entering runlevel: 3
:: Starting Syslog-NG [DONE]
Error opening file for reading; filename='/proc/kmsg', error='No such file or directory (2)'
Error initializing source driver; source='src'
:: Starting Network...
Warning: cannot open /proc/net/dev (No such file or directory). Limited output.
eth0: dhcpcd 4.0.3 starting
eth0: broadcasting inform for 172.16.10.154
eth0: received approval for 172.16.10.154
eth0: write_lease: Permission denied
:: Mounting Network Filesystems
mount: only root can do that
[FAIL]
:: Starting Cron Daemon [DONE]...and, nothing after that, it just stops. Kernel doesn't panic, and hitting ctrl+alt+delete does what you'd expect, a clean shutdown minus a few errors about filesystems not being mounted. It seems /proc isn't getting mounted because init apparently doesn't have the appropriate permissions, and /proc not being mounted causes a whole string of other issues. Thing is, proc gets created at boot time as it contains kernel specific information about the system and the kernel's capabilities, right? Why can't it create it? How come init doesn't have the same privileges as root as it usually would, and how would I go about fixing it?
I admit, while I'm fairly competent in Linux, this one has me stumped. Anyone have any ideas?
Last edited by PinkFloydYoshi (2008-11-22 12:29:01)
Offline
The Linux Terminal Server project already provides kernel + initrd that boots without the need for NFS. With X and Firefox too. I've set up RIP linux for PXE booting too. So you can start from those two.
Also, I wonder where did you read that you need cloop?? For commpression?
You can just use a kernel + initrd with everything in it. And makeing an initrd (initramfs actually) is not hard at all.
Just make the / structure and run "find . | cpio -o -Hnewc | zcat > ../initrd.img"
Offline
BTW, I must say I'm astonished you use Windows for DHCP and TFTP.
PXE booting is set with 4 lines of configuration in dnsmasq:
dhcp-range=xx.xx.xx.xx...
enable-tftp
tftp-root=/home/tftproot/
dhcp-boot=/pxelinux.0well, ok then you just need the /home/tftproot/pxelinux.0 (copied or linked from /usr/lib/syslinux/pxelinux.0) and /home/tftproot/pxelinux.cfg/default which is the boot menu configuration. It has the same structure as isolinux.cfg found on bootable Llinux CDs.
Offline
The idea behind the Windows DHCP and TFTP is that we'd be using an existing server and a NetApp box with NFS license to serve everything off. I would have loved to make a new server which is completely Linux, but my boss, nor the other technician have ever used Linux so if I left for any reason, they'd be stuck if ever they ran in to trouble, which is why I've struggled to get Linux to penetrate our all Windows infrastructure.
During my hunting around on Google I found a lot of information on making my own initrd, and a lot of it using all manner of switches. I can make them fine, but I figure that I would need to look at extracting the current working one first, adding X, Firefox and the ICA client to it, then compressing it again. Cloop came about when I was looking at DSL's internals. The smaller the initrd, the better, so utilizing this could possibly be a plus too.
The reason I'm doing this with Archlinux is that I know Arch's internals quite well (and pacman is just wonderous, which is more than I can say for yum), so if I run in to a small problem I'm more likely to fix it without consulting Google. Fair enough though, the NFS booting method is giving me issues I never thought were possible. Ahh, sods law strikes again.
Addendum: I've noticed something which struck me as odd. Files in the NFS share are somehow owned by 96:scanner instead of root:root. Upon attempting changing, it's telling me "Operation Not Permitted". Further prodding has led me to believe it's an Openfiler thing where GID/UID 96 on the OpenFiler box is "ofgroup"/"ofguest". Chowning / to root:root puts NFS boot right ahead and gives me a prompt, however I cannot log in as root. I've also discovered that chrooting in to the base from my Arch workstation and creating a directory makes the directory owned by ofgroup:ofguest again, so it's an Openfiler thing after all this time. Prodding further.
Addendum two: For anyone using Openfiler out there, when you allow guest access to the NFS share, be sure to set the Anonymous GID and Anonymous UID to 0. By default it's 96 and as a result when trying to boot you get the errors I experienced. This is insecure and you should use some sort of network/host/ip range restriction. Because the root filesystem has 96:96 as the owner of everything after you install the base layout using pacman (and any changes you make afterward) init and root no longer have the appropriate permissions, user 96:96 (which is "scanner" in Archlinux) has the permissions instead and init, in order to complete boot would need to be "scanner" in order to boot completely.
Solution is to set Anon GID and Anon UID to 0, chown the entire diskless root filesystem to root, then use a linux desktop to mount the diskless root filesystem, mount /proc, /sys and mount bind /dev, then chroot in to the diskless root filesystem. At this point to clear up any problems with bad passwords, use passwd to change your password. Exit the chroot environment then unmount the diskless proc, sys and dev. Boot up via the network and use your chosen password to log in as root. At this point, start clearing up permissions from the en masse filesystem chown and you should then have a usable diskless root.
I'll experiment further and clear up some of the remaining permission errors that occured during boot and report on my progress in fixing it. Didn't like the idea of chowning the entire share as root. :S
Last edited by PinkFloydYoshi (2008-11-21 19:28:15)
Offline
Are you mounting your NFS root with the initial ramdisk or via kernel command line?
:?
Offline
Are you mounting your NFS root with the initial ramdisk or via kernel command line?
I'm mounting it via the kernel command line. I've compiled nfs, net modules in to the initramfs using mkinitcpio so it was all there, just as the guide suggests to.
In the end, I dumped using Openfiler for the NFS export and just installed nfs-utils. Setting a UID or GID as 0 doesn't seem to save anything. Editing the file manually is useless as clicking anything in the web interface overwrites the changes you made. Openfiler isn't designed for NFS booting it would seem (Although would be convenient for me as I don't have to keep a second storage server up just for booting up a linux box when I need to without having to go through tons of seperate installs - quicker than cloning seperate huge virtual machines in VMware Workstation too).
The whole shebang works a treat now. Essentially, Openfiler tries to "Own" all the files you put in the Openfiler NFS export, which, if you're trying to put a Linux base in, messes up all the permissions according to what the "Anonymous GID" and "Anonymous UID" are set to, which is wonderful.
Offline