starting gentoo from network runs /etc/init.d/checkroot. checkroot runs fsck, remounts rw /. My nfs is alraydy mounted as rw, and i didn't have fsck.nfs :) Reproducible: Always Steps to Reproduce: 1. 2. 3.
I've done a little work along these lines. We are working on a cluster of net-booting diskless servers. I modified checkroot to see if /nfsroot exists, and if it does, it doesn't try the remount. Additionally it then mounts /tmp (defined in fstab). Generally, I don't think you can just say that all NFS roots should be read-only. An alternate approach would be to have a variable like READ_ONLY_ROOT (and MOUNT_TMP) defined in /etc/conf.d/checkroot and check that. I also made a netvar script that mounts /var. The given path to the remote filesystem is appended with the host's IP address, so you have a separate /var for each system. There are some other little bits and pieces to tweak as well, but you've probably already run into them.
My nfsroot is alraidy mounted in rw But in my uni, all linux workstaitions have single ro rootfs over nfs.
Is it an issue if it tries to remount it 'rw' ? The fsck I will fix.
what?
Ok, I do not use NFS, so you need to help me out. I will fix it not to run fsck for NFS, but I need to know: 1) Is it an issue if you remount NFS as 'rw' if its already mounted 'rw' ? It should not be, but its easier to just remount anyhow, and not try to figure out if its mounted 'ro' or 'rw' ....
Created attachment 8954 [details, diff] some fast hack
there can be many variants: 1. server nfs root give rw, dhcp/kernel setings mounts it rw 2. server nfs root give rw, dhcp/kernel setings mounts ir ro 3. server nfs root give ro, dhcp/kernel setings mounts ir rw 4. server nfs root give ro, dhcp/kernel setings mounts ir ro I have 1st situasion. 3nd situacion is incorect setings on dhcp/nfs server and gentoo in this way can't fix 2nd there must be user option to leave it ro, or remount 4nd situaction is on my uni, and it works! single root for 50 workstation. gentoo isn't adapted for 3, and 4 isn't, but thats is another one problem. I testet 1st situation and work almost all, execep that on boot in /etc/init.d/checkroot do: fsck -a / does warning: error fsck.nfs not found. and then /sbin/sulogin :( i did some fast hack (see patch), this help's for me.
Yep, looks fine. All I wanted to know basically was if its only the fsck that is a showstopper, and that the remount is ok ... Can you test a case where the nfs is mounted ro, and then it remounts ? Will it fail? Or rather, in what cases will it fail ? Like I said, I do not use nfs myself, so difficult to test ....
tests all that i made: output | checkroot | server | kernel* | result 1: res1 | checkroot1 | ro | - | fail 2: res2 | checkroot1 | rw | - | fail 3: res3 | checkroot1 | rw | ro | fail 4: res4 | checkroot2 | rw | ro | fail 5: res5 | checkroot2 | rw | - | fail 6: res6 | checkroot2 | ro | - | fail 7: res7 | checkroot2 | ro | ro | fail - thease and only thease test was made. - for checkroot, checkroot1, checkroot2 see atachments - checkroot boots corectly, whithout critical stops/error, it prints some warnings - for res{1-7} see atachments - * - i'm not 100% sure, bu think that if kernel didn't has option ro on apend line then asumes that file system (root fs over nfs) is rw. - if you need some aditional tests please write excacly what you want, and please do it as fast as you can, becouse you have 10 days. I leave my network with rootnfs, server and etc. I will comme back after 0.5 year, then I can continue thease tests. btw. it isn't hard or recueres any aditional hw to test it at home. hw: 2 box, 1 free hdd ~1GB, 1 fdd, 2 any linux suportble netcard (cat be without boot rom), 1 netwire. soft: basic linux, dhcp/bootp, tfpt, nfs-server, linuxkernel, mknbi, etherboot. if you intersing in it I can give some info about how to setup all this thing. roma1390 plese give me some script or something becouse you say very unclear: boot .. remount ... when remont? in checkroot, on fail? mount ro with kernel command line (aka append="ro") or by hand/another way?
Created attachment 9001 [details] almoust works bugzila bug/mozilla bug: how to submit many file in one action
Created attachment 9002 [details] checkroot1. see previous comment
Created attachment 9003 [details] rez1. see previous comment
Created attachment 9004 [details] rez2. see previous comment
Created attachment 9005 [details] rez3. see previous comment
Created attachment 9006 [details] rez4. see previous comment
Created attachment 9007 [details] rez5. see previous comment
Created attachment 9008 [details] rez6. see previous comment
Created attachment 9009 [details] rez7. see previous comment
Ok, so basically the script should not try to remount / on NFS 'ro' or 'rw' ? It was basically what I wanted to make sure of ... if the script should try to remount / on NFS 'rw' (read/write) ... What is still wrong with the modified script you have ? Can we use that as is? If not, could you try to include some output from the boot scripts themselfs?
Created attachment 9087 [details] boot output this is output of system boot with checroot == attachment 9001 [details] but shotdown isn't nice :) stops on: unmouting network file systems. but i dont care on it, becouse linux is ready only for one boot, and for long work :)
as You can see, one small warning is network statup over dhcp or something. boot scripts neet to know that we have network, and we need to start net.eth0 but kernel alraidy did it. I didn't try to start sshd without net.eth0. on shutdown/reboot/halt/etc. we have the same problem wen we try remount / in ro.
In my own netbooting setup, I simply don't start net.eth0, because the DHCP is done by a) MBA/PXE, b) pxelinux (from syslinux), and finally c) the kernel. Since all my filesystems are NFS, I usually don't worry too much about shutting down (usually we hit the reset button). But it probably would be a good thing if netmount avoided trying to umount /.
Created attachment 9147 [details] /etc/init.d/netmount Ok, have a look if this netmount does as expected.
Created attachment 9150 [details] /etc/init.d/net.eth0 Ok, I am assuming that for setups like yours, only dhcpcd bitch about it being up ? See if this net.eth0 fixes it.
Comments guys ?
Like I said earlier, in my netbooting setups, I do not start net.eth0, because the kernel has already done the dhcp. So long as the IP is permanently assigned to that MAC, this should not be a problem. I guess if I needed to add aliases, I'd just do this in /etc/conf.d/net: iface_eth0="up" alias_eth0="..." So I don't think you need to make this change to net.eth0. (Side note: On my cluster, net.lo is a copy of net.eth0, because I need to have a number of aliases on lo; the machines are behind a load balancer.)
If there are more issues with latest unstable baselayout's, please reopen and explain what, thanks.
As of baselayout version 1.8.6.10-r1 /etc/init.d/checkroot still try to fsck nfs root filesystem -> not fixed /etc/init.d/netmount still try to umount the nfs root filesystem -> not fixed about net.eth0 while the kernel already assigned an ip it seems fixed, you just need to add net.lo (to satisfied the net dependency) to your default runlevel and don't need net.eth0 if you /etc/conf.d/rc contains: RC_NET_STRICT_CHECKING=no
