Bug 485478 - iSCSI boot problems when /var is a separate fs
Summary: iSCSI boot problems when /var is a separate fs
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: anaconda
Version: 5.3
Hardware: All
OS: Linux
high
high
Target Milestone: rc
: ---
Assignee: Anaconda Maintenance Team
QA Contact: Release Test Team
URL:
Whiteboard:
: 445776 (view as bug list)
Depends On:
Blocks: 5.5_Known-Issues 577695
TreeView+ depends on / blocked
 
Reported: 2009-02-13 18:00 UTC by Bryn M. Reeves
Modified: 2019-06-13 07:50 UTC (History)
8 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
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.
Clone Of:
: 577695 (view as bug list)
Environment:
Last Closed: 2009-09-10 13:23:59 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)

Description Bryn M. Reeves 2009-02-13 18:00:26 UTC
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

Comment 2 Hans de Goede 2009-03-04 09:09:49 UTC
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

Comment 3 Bryn M. Reeves 2009-03-05 11:36:33 UTC
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.

Comment 5 Denise Dumas 2009-06-30 20:43:05 UTC
Moving to RHEL 5.5 so it doesn't get mistakenly closed by the bot

Comment 6 Alexander Todorov 2009-08-27 08:41:01 UTC
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.

Comment 8 Joel Andres Granados 2009-09-02 10:00:14 UTC
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

Comment 9 Chris Lumens 2009-09-02 20:53:10 UTC
*** Bug 445776 has been marked as a duplicate of this bug. ***

Comment 11 Denise Dumas 2009-09-10 13:23:59 UTC
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.

Comment 12 Denise Dumas 2009-09-10 13:23:59 UTC
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.

Comment 13 Issue Tracker 2009-09-11 01:19:55 UTC
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

Comment 14 Bryn M. Reeves 2009-09-14 13:11:14 UTC
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 :)

Comment 15 Denise Dumas 2009-09-14 14:33:49 UTC
Yes - thanks - good catch


Note You need to log in before you can comment on or make changes to this bug.