Description of problem: When a system is configured to boot with iSCSI root and /var is a separate file system rc.sysinit does not mount /var as it is marked _netdev in /etc/fstab. As services begin to start up that need to write to /var they fail, causing the boot to fail. The root volume has been marked _rnetdev by anaconda so is checked and remounted for writing by rc.sysinit (see bug 435716 and bug 435358) but /var has the _netdev flag so is deferred until the netfs service starts. Version-Release number of selected component (if applicable): 5.3 GA How reproducible: 100% Steps to Reproduce: 1. Install a system to iSCSI configuring /var as a separate file system 2. Attempt to boot Actual results: Lots of things fail due to readonly /var Expected results: Successful boot Additional info: /etc/fstab: LABEL=/ / ext3 defaults,_rnetdev 1 1 LABEL=/home /home ext3 defaults,_netdev 1 2 LABEL=/var1 /var ext3 defaults,_netdev 1 2 LABEL=/boot /boot ext3 defaults,_netdev 1 2 tmpfs /dev/shm tmpfs defaults 0 0 devpts /dev/pts devpts gid=5,mode=620 0 0 sysfs /sys sysfs defaults 0 0 proc /proc proc defaults 0 0 LABEL=SWAP-sdb5 swap swap defaults,_netdev 0 0
Hi Bryn and Masaki, Having a separate /var on a network filesystem (nfs, iscsi disk, nbd, etc.) is something which has not worked (AFAIK) for any RHEL-5 release, and currently we (the anconda team) have no plans to change that for RHEL-5, nor for RHEL-6. This is basically not supported and will stay that way. Note that this is not strictly an anaconda issue though, but really is an initscripts issue. So you could try asking the initscripts maintainer, but I doubt he will have a different opinion. For example to get the network up with dhcp we need /var/lib/dhcp to write the leases file too. So having /var on the network really is not an option. I also doubt this really is what you want, you probably want /var/spool and/or /var/www or the likes on a separate network disk, not complete /var and this is supported. Closing this as not a bug, as it really is not. Regards, Hans de Goede
Hi Hans, Thank you for the explanation; that's fine. However, I am re-opening this bug as this is not really a satisfactory solution to the problem. If we are choosing not to support a particular file system layout for certain installation types that's perfectly understandable but we need to communicate that to our users. As it stands anaconda allows configuration of the system in a way that has no chance of actually working. If we're not going to support the use of a separate /var on a system installed to an iSCSI root device then anaconda must not permit the system to be configured in this way. Cf. the warnings issued when attempting to configure a system without swap. This should also be clearly documented.
Moving to RHEL 5.5 so it doesn't get mistakenly closed by the bot
qa_ack+ for anaconda giving a warning if /var is on iSCSI and is separate partition. How about kickstart installs ? A warning will cause them to break which is what we probably want because the resulting install will not be fully functional anyway.
And to change bootloader options so the reboot does not work. Or not to install the Base group so one does not have yum in the installation. Or create 4 primary partitions that don't span the whole size of the drive. I totally agree with Hans here. There lots of ways that things can go wrong because of an installation detail. I propose a release note for this issue that includes the explanation on comment #0 and #2
*** Bug 445776 has been marked as a duplicate of this bug. ***
We are "fixing" this with a 5.5 release note, see text included above. Ryan, this is a release note that we should continue to carry for future RHEL releases.
Release note added. If any revisions are required, please set the "requires_release_notes" flag to "?" and edit the "Release Notes" field accordingly. All revisions will be proofread by the Engineering Content Services team. New Contents: RHEL5 does not support having a separate /var on a network filesystem (nfs, iscsi disk, nbd, etc.) This is because /var contains the utilities required to bring up the network, for example /var/lib/dhcp. However, you may have /var/spool, /var/www or the like on a separate network disk, just not the complete /var filesystem.
Event posted on 09-11-2009 10:19am JST by mfuruta Hi Ishida-san, We will add following New Contents to Release Note to RHEL5.5 and could not fix this problem as a bug... For detailed reason, please refer comment at "Event posted 09-02-2009 07:00pm JST by bugzilla" Please check Contents as below and provide your concern? New Contents: RHEL5 does not support having a separate /var on a network filesystem (nfs, iscsi disk, nbd, etc.) This is because /var contains the utilities required to bring up the network, for example /var/lib/dhcp. However, you may have /var/spool, /var/www or the like on a separate network disk, just not the complete /var filesystem. Thanks in advance. Regards, Masaki Furuta Internal Status set to 'Waiting on Customer' Status set to: Waiting on Client This event sent from IssueTracker by mfuruta issue 241813
Wording in comment #12 doesn't seem quite right: "This is because /var contains the utilities required to bring up the network, for example /var/lib/dhcp" There should be no executable utilities installed under /var[1] - from the FHS: "/var/ Variable files—files whose content is expected to continually change during normal operation of the system—such as logs, spool files, and temporary e-mail files. Sometimes a separate partition." It might be better to say something like "This is because the /var directory contains critical data that must be read from or written to during the boot process before establishing network services" or something along those lines? [1] weren't there some NIS scripts installed somewhere murky under /var at some point? These aren't afaik related to this problem though and still shouldn't be installed in /var :)
Yes - thanks - good catch