Bug 594649

Summary: Read-only root FS with iSCSI target
Product: Red Hat Enterprise Linux 6 Reporter: Marian Ganisin <mganisin>
Component: dracutAssignee: Harald Hoyer <harald>
Status: CLOSED CURRENTRELEASE QA Contact: Release Test Team <release-test-team-automation>
Severity: high Docs Contact:
Priority: high    
Version: 6.0CC: azelinka, harald, notting, pknirsch
Target Milestone: rc   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: dracut-004-21.el6 Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2010-11-10 20:18:59 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On:    
Bug Blocks: 582286    
Attachments:
Description Flags
boot.log and messages none

Description Marian Ganisin 2010-05-21 09:02:03 UTC
Created attachment 415615 [details]
boot.log and messages

Description of problem:
lvm lv '/' belongs to vg, it is spread across local drive and iSCSI target.
'/' is read-only (mount says 'rw', however /proc/mounts claims correct 'ro').
Impossible to remount with 'rw'.

Version-Release number of selected component (if applicable):
RHEL6.0-20100512.0
initscripts-9.03.7-1.el6.i686

Additional info:
Tested in kvm virtual machine with scsi-target-utils providing target

Comment 1 Bill Nottingham 2010-05-21 15:26:09 UTC
There are no errors in that log.

Comment 2 Ales Zelinka 2010-06-01 09:47:07 UTC
So, this is not a bug or it just doesn't manifest itself in the logs?

Comment 3 Bill Nottingham 2010-06-01 21:38:57 UTC
The latter; the logs do not show any data as to why it's happening.

Comment 4 Marian Ganisin 2010-06-02 12:02:39 UTC
This happens because of network init script. eth0 (device used for iscsi) is using dhcp, network script is starting it again, connection to iscsi target is lost, pv of lvm is lost, integrity of lv is lost, lv is remounted as 'ro'.

Error message:

Bringing up interface eth0:  EXT4-fs error (device dm-0): ext4_journal_start_sb: Detected aborted journal
EXT4-fs (dm-0): Remounting filesystem read-only

Determining IP information for eth0... done.
[  OK  ]

Comment 5 Bill Nottingham 2010-06-02 15:12:38 UTC
Is the lease file properly ending up in /dev/.dhclient-<foo>.leases or /dev/.initramfs/net.<foo>.lease ?

Comment 6 Marian Ganisin 2010-06-09 10:30:36 UTC
(In reply to comment #5)
> Is the lease file properly ending up in /dev/.dhclient-<foo>.leases or
> /dev/.initramfs/net.<foo>.lease ?    

How can I check that? Executing this on running system:

# find /dev | grep lease

didn't find anything

When running boot with rdbreak rdshell options, I can find these files in ramfs:

/tmp/net.eth0.lease
/tmp/dhclient.eth0.lease

but this is not probably much useful information.

Basically issue occurs if ifcfg-eth0 contains:
IPV6INIT=yes
IPV6_AUTOCONF=yes

Anyway, it isn't so simple, it is little bit weird, once issue occurs 'no' for these options isn't enough, some (nearly random) magic has to be done with disabling/enabling network, iscsi and iscsid services. Hard to say if it is caused by system or testing evironment.

Comment 7 Bill Nottingham 2010-06-09 17:50:36 UTC
CC'ing Harald about lease location... they should be ending up in /dev/.initramfs/ for initscripts to find them properly, not /tmp. (Which may still be happening after the rdshell invocation).

Comment 8 Harald Hoyer 2010-06-10 08:15:42 UTC
(In reply to comment #7)
> CC'ing Harald about lease location... they should be ending up in
> /dev/.initramfs/ for initscripts to find them properly, not /tmp. (Which may
> still be happening after the rdshell invocation).    

first they are in /tmp and get copied over to /dev/.initramfs

After double checking the scripts, I figured, that the "copy-script" is not installed due to a bug.

Comment 11 Marian Ganisin 2010-07-02 12:19:22 UTC
Working as expected in RHEL6.0-20100701.0

Comment 12 releng-rhel@redhat.com 2010-11-10 20:18:59 UTC
Red Hat Enterprise Linux 6.0 is now available and should resolve
the problem described in this bug report. This report is therefore being closed
with a resolution of CURRENTRELEASE. You may reopen this bug report if the
solution does not work for you.