Bug 603088

Event posted on 05-24-2010 12:02pm EDT by cbuissar

Hi Seg,

Since lvm2-2.02.56-8.el5, LVM commands do not accept a non-writable log file [ lvm.conf : log { file = "/var/log/lvm2.log" } ]
Any command will refuse to process.
Unfortunately, the result is that LVM will fail VG activation during boot as root is still read-only during activation.



SEG Escalation Template
 
All Issues: Problem Description
---------------------------------------------------
1. Time and date of problem:

Any boot since RHEL5.5

2. System architecture(s):

any

3. Provide a clear and concise problem description as it is understood at the
   time of escalation.

Repro step :
-> log { file = "/some/readonly/filesystem"}

   Observed behavior:

----8<----
[root@localhost ~]# grep "^\s*file =" /etc/lvm/lvm.conf
    file = "/mnt/log/lvm2.log"
[root@localhost ~]# mount | grep /mnt/log
/dev/mapper/VolGroup00-lvlog on /mnt/log type ext3 (rw)
[root@localhost ~]# lvs
    Logging initialised at Mon May 24 17:02:41 2010
    Set umask to 0077
    Finding all logical volumes
  LV       VG         Attr   LSize   Origin Snap%  Move Log Copy%  Convert
  LogVol00 VolGroup00 -wi-ao   7.19G                                      
  LogVol01 VolGroup00 -wi-ao 512.00M                                      
  lvlog    VolGroup00 -wi-ao 480.00M                                      
  lvtmp    tmp        -wi--- 492.00M                                      
    Wiping internal VG cache
[root@localhost ~]# mount -o ro,remount /mnt/log
[root@localhost ~]# lvs
  /mnt/log/lvm2.log: fopen failed: Read-only file system
    Logging initialised at Mon May 24 17:02:55 2010
    Set umask to 0077
    Wiping internal VG cache
---->8----
Note that nothing appeared


   Desired behavior:
Same as the good old RHEL5.4 behavior :
----8<----
[root@localhost ~]# rpm -q lvm2
lvm2-2.02.46-8.el5_4.2
[root@localhost ~]# lvs
  /mnt/log/lvm2.log: fopen failed: Read-only file system
    Logging initialised at Mon May 24 16:48:09 2010
    Set umask to 0077
    Finding all logical volumes
  LV       VG         Attr   LSize   Origin Snap%  Move Log Copy%  Convert
  LogVol00 VolGroup00 -wi-ao   7.19G                                      
  LogVol01 VolGroup00 -wi-ao 512.00M                                      
  lvlog    VolGroup00 -wi-ao 480.00M                                      
  lvtmp    tmp        -wi--- 492.00M                                      
    Wiping internal VG cache
---->8----

Note that the error is still there (normal) but command is processed.


4. Specific action requested of SEG:

This can be considered as a regression : A machine will not be able to activate any secondary VG (the root VG is activate without issue from initrd)

5. Is a defect (bug) in the product suspected? yes

6. Does a proposed patch exist? no 
But I will try if I get the chance to find out.



7. What is the impact to the customer when they experience this problem? 
2 workarounds proposed :
-> Activate everything from maintenance mode
-> Cancel the log into file

 
 
All Issues: Supporting Information
------------------------------------------------------
1. Other actions already taken in working the problem :
See next post


2. Attach sosreport.
Attaching sosreport from my test machine.

3. Attach other supporting data (if any).
Attaching boot failing from customer's side

4. Provide issue reproduction information
See above


5. Known hot-fix packages on the system:
None.

6. Customer applied changes from the last 30 days:
updating to RHEL5.5

This event sent from IssueTracker by dejohnso  [Support Engineering Group]
 issue 930623

Event posted on 05-24-2010 12:02pm EDT by cbuissar

Issue Registered (Severity: 2)
This event sent from IssueTracker by dejohnso  [Support Engineering Group]
 issue 930623

NOTE:  I duplicated this problem on RHEL6 Beta (so will be cloning bug.
The boot fails with:

Setting up logical Volume Manager:  /var/log/lvm2.log: fopen failed: Read-only file system
                                   [FAILED]


All I had to do was uncomment the line in /etc/lvm/lvm.conf and reboot.
/var is not a separate file system but is part of /.

We have already z-stream update in QA to fix this issue, please see bug 601079.

*** This bug has been marked as a duplicate of bug 601079 ***