Red Hat Bugzilla – Bug 169403
Automount of the emcpower device fails if fsck is enabled for the device in /etc/fstab.
Last modified: 2014-03-16 22:56:17 EDT
From Bugzilla Helper: User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0; .NET CLR 1.0.3705) Description of problem: With the following entry in /etc/fstab the automount of the emcpower device fails if fsck is enabled for the device. /dev/emcpowera /a ext3 _netdev 1 1 I believe this is ocurring because fsck is called before netfs has had an opportunity to mount the _netdev device. Version-Release number of selected component (if applicable): RHEL 3.0 U6 (lk 2.4.21-37EL) How reproducible: Always Steps to Reproduce: 1.edit /etc fstab with an iscsi device setting fsck on 2.reboot the server 3. Actual Results: fsck fails on the iscsi device. Expected Results: fsck should occur on the iscsi device. Additional info: This should be an issue in RHEL 4.0 as well.
I guess this is fixed in U2/U6 already. The initsripts maintainer suggested to look at this bug 148764.
Mike, this bug is being reported against RHEL 3.0 U6 which BZ #148764 states as having been fixed.
I believe the issue may be related to dealing with an emcpower pseudo device at this time. fsck() is trying to run before the emcpower pseudo can be created. And in there may lay the rub.
We've re-run the test against RHEL 3.0 U6 without the use of the emcpower psuedo device with the same results, fsck() on the native iSCSI device fails. Here are the server's particulars: [root@libg184 root]# rpm -qa |grep init initscripts-7.31.27.EL-1 iscsi-initiator-utils-3.6.3-3 [root@libg184 root]# uname -a Linux libg184 2.4.21-37.ELsmp #1 SMP Wed Sep 7 13:28:55 EDT 2005 i686 i686 i386 GNU/Linux The /dev/sd device is set in /etc/fstab with the fsck on boot flag and the _netdev option.
Just changing component to initscripts becuase there is not a iscsi component anymore, and this does not look like a iscsi-initiator-utils or kernel problem.
I think the problem is that we have been running with fastboot. When this is set rc.sysint
The fixes for RHEL3 and RHEL4 to the netfs scripts that were made in this BZ 148764 work and are ok. For RHEL4, and probably RHEL3, the problem seems to be in rc.sysinit. I think some of use have been testing with fastboot set. With this set, rc.sysinit does not fsck the /etc/fstab devices, and everything works fine. When fastboot is not set, the rc.sysinit fsck code blows up on NFS, iscsi, and other weirdo devices/filesystems. What is the proper fix here? Should rc.sysinit skip _netdev devices, or is there a fstab variable we should be setting, or are we supposed to be running with fastboot set? Thanks
_netdev devices are explicitly fscked in the netfs initscript, as I recall. Don't set the auto-fsck flag in fstab, and things should be fine.
netfs does this fsck -A -T -R -a -t opts=_netdev But fsck still obeys the fs_passno numbering so if it is zero then fsck (run from rc.sysinit and netfs) will not check the fs.
Do you think this is a fsck bug. Is the "-t opts=_netdev" argument supposed to mean that fsck is supposed to check all entries with _netdev ignoring the fs_passno.
Oops, I misunderstood the behavior. Does adding -t opts=!_netdev in rc.sysinit fix it?
yeah that works.
Will this fix go into RHEL 3.0 U7? Is a similar fix needed for RHEL 4.0?
We cloned this bug for RHEL4 https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=172804 It looks like you did not get added becuase the reported does not get copied over when someone else clones it. And it looks like Bill added the fixes to the newest builds so I think it will be in both RHEL3 U7 and RHEL4 U3.
Huh, not sure what the problem was before, but I did a clean install and updated the initscripts and it works. Sorry about that.
Clean install for RHEL 3.0 U7 or RHEL 4.0 U3?
Hey Wayne, it was for RHEL3 but you can disregard my comment. It was in regards to some other chitchat on the bug.
Created attachment 125416 [details] boot.log boot.log from server
Created attachment 125417 [details] messages from server
What should be the expected results when the changes take affect? The filesystems mounts; however, there are errors reported by fsck() and it doesn't appear that fsck is run on the filesystem after it does finally mount. See the preceeding attachments for boot.log and messages. Regards, Wayne. Server: [root@l82bi121 root]# cat /etc/redhat-release Red Hat Enterprise Linux AS release 3 (Taroon Update 7 Beta) [root@l82bi121 root]# uname -a Linux l82bi121.lss.emc.com 2.4.21-40.EL #1 SMP Thu Feb 2 22:14:00 EST 2006 x86_64 x86_64 x86_64 GNU/Linux [root@l82bi121 root]# rpm -qa | grep init initscripts-7.31.30.EL-1 xinitrc-3.32-1 SysVinit-2.85-4.4 mkinitrd-3.5.13.6-1 iscsi-initiator-utils-3.6.3-3 [root@l82bi121 root]# cat /etc/fstab LABEL=/ / ext3 defaults 1 1 LABEL=/boot /boot ext3 defaults 1 2 none /dev/pts devpts gid=5,mode=620 0 0 none /proc proc defaults 0 0 none /dev/shm tmpfs defaults 0 0 /dev/sda3 swap swap defaults 0 0 /dev/cdrom /mnt/cdrom udf,iso9660 noauto,owner,kudzu,ro 0 0 /dev/fd0 /mnt/floppy auto noauto,owner,kudzu 0 0 128.221.37.21:/pub /pub nfs defaults 0 0 128.221.37.21:/pub/wayne/extra /extra nfs defaults 0 0 172.23.189.135:/wide_open/misc/open /extra/open nfs defaults 0 0 /dev/emcpowera1 /zoner/emcpowera auto _netdev 1 1 [root@l82bi121 root]# df Filesystem 1K-blocks Used Available Use% Mounted on /dev/sda2 68445304 4147292 60821148 7% / /dev/sda1 101089 13926 81944 15% /boot none 1977152 0 1977152 0% /dev/shm 128.221.37.21:/pub 138733088 128333024 10400064 93% /pub 128.221.37.21:/pub/wayne/extra 138733088 128333024 10400064 93% /extra 172.23.189.135:/wide_open/misc/open 413815392 72922760 319871984 19% /extra/open /dev/emcpowera1 8620700 2468 8180320 1% /zoner/emcpowera [root@l82bi121 root]#
Is there fsck error we are talking about the one where it cannot autodetect the /zoner/emcpowera partition? What happens when you just put the filesystem type in fstab?
[root@l82bi121 root]# fsck /dev/emcpowera1 fsck 1.32 (09-Nov-2002) e2fsck 1.32 (09-Nov-2002) /dev/emcpowera1 is mounted. WARNING!!! Running e2fsck on a mounted filesystem may cause SEVERE filesystem damage. Do you really want to continue (y/n)? no check aborted. [root@l82bi121 root]# umount /zoner/* umount: /zoner/emcpowerb: not mounted umount: /zoner/emcpowerc: not mounted umount: /zoner/emcpowerd: not mounted umount: /zoner/emcpowere: not mounted umount: /zoner/emcpowerf: not mounted umount: /zoner/emcpowerg: not mounted umount: /zoner/emcpowerh: not mounted umount: /zoner/emcpoweri: not mounted umount: /zoner/emcpowerj: not mounted umount: /zoner/emcpowerk: not mounted umount: /zoner/emcpowerl: not mounted umount: /zoner/emcpowerm: not mounted umount: /zoner/emcpowern: not mounted umount: /zoner/emcpowero: not mounted umount: /zoner/emcpowerp: not mounted [root@l82bi121 root]# df Filesystem 1K-blocks Used Available Use% Mounted on /dev/sda2 68445304 4153792 60814648 7% / /dev/sda1 101089 13926 81944 15% /boot none 1977152 0 1977152 0% /dev/shm 128.221.37.21:/pub 138733088 125748160 12984928 91% /pub 128.221.37.21:/pub/wayne/extra 138733088 125748160 12984928 91% /extra 172.23.189.135:/wide_open/misc/open 413815392 74102784 318691960 19% /extra/open [root@l82bi121 root]# fsck /dev/emcpowera1 fsck 1.32 (09-Nov-2002) e2fsck 1.32 (09-Nov-2002) /dev/emcpowera1: clean, 169/1095584 files, 35006/2189564 blocks [root@l82bi121 root]# It doesn't seem to be an fsck() issue. I'll change the fstype in /etc/fstab to see if that mitigates the failure.
Hi Mike. With the following entry in /etc/fstab I see an error message from init:mount:fsck: "Could not determine filesystem type for /dev/emcpowera1" and init:netfs:fsck is successful. /dev/emcpowera1 /zoner/emcpowera auto _netdev 1 1 If I change the entry in /etc/fstab to the following there are no error messages from init:netfs:fsck and init:netfs:fsck is successful. /dev/emcpowera1 /zoner/emcpowera ext2 _netdev 1 1 Regards, Wayne.
An advisory has been issued which should help the problem described in this bug report. This report is therefore being closed with a resolution of ERRATA. For more information on the solution and/or where to find the updated files, please follow the link below. You may reopen this bug report if the solution does not work for you. http://rhn.redhat.com/errata/RHSA-2006-0015.html