Bug 481178
| Summary: | LVM Incorrect metadata area header checksum after update from UP kernel to SMP | ||
|---|---|---|---|
| Product: | Red Hat Enterprise Linux 4 | Reporter: | Jan Tluka <jtluka> |
| Component: | anaconda | Assignee: | Anaconda Maintenance Team <anaconda-maint-list> |
| Status: | CLOSED ERRATA | QA Contact: | Alexander Todorov <atodorov> |
| Severity: | medium | Docs Contact: | |
| Priority: | high | ||
| Version: | 4.8 | CC: | agk, atodorov, ddumas, dwysocha, edamato, heinzm, jbrassow, jgranado, mbroz, mgahagan, prockai, syeghiay |
| Target Milestone: | beta | ||
| Target Release: | --- | ||
| Hardware: | i386 | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2009-05-18 20:16:03 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: | |||
|
Description
Jan Tluka
2009-01-22 16:23:29 UTC
I expect that there was just old metadata of the same VG name which appeared during boot (or anaconda didn't wiped all metadata properly). See the anaconda log, there are also some errors: * WARNING: Installing on a USB device. This may or may not produce a working system. ... * parted exception: Error: File system has an invalid signature for a FAT file systems. * parted exception: Error: File system has an invalid signature for a FAT file systems. * parted exception: Error: Can't have the end before the start! ... Isn't possible that anaconda just didn't initialized some device during install and this device re-appered during the system boot with wrong lvm metadata? Reassigning to anaoconda, if you still see it is bug in lvm2, please provide full lvm2 debug log (run commands with -vvvv) and if possible, "lvmdump -m" diagnostic data from the machine.) It is completely possible that anaconda did not initialize the disk. but as I see on the parted messages, this might be that the partition table was corrupted and anaconda just ignored the disk. did something change in the kernel partitioning code? anaconda and parted where built on Jan 15. This means that the test was done with the rhel4.7 anaconda version. Please test with current nightly and confirm that the behavior persists. The new anaconda was modified in such a way that it uses vgreduce before vgremove. Please test with current anaconda version anaconda-10.1.1.94-1 I'm also thinking that this bug is a dup of 481698. But pls test and post your findings. Following job was queued in RHTS: http://rhts.redhat.com/cgi-bin/rhts/jobs.cgi?id=43499 This is about to install RHEL4-U8-re20090126.2 tree. I'm aware that it will fail because of udev bug but for our purpose should be sufficient. Anyway does this tree include anaconda version you mentioned in comment 5? Jan: RHEL4-U8-re20090126.2 does not have the latest anaconda. Please wait for today's compose. Jan 27. It has a new lvm fix and could make the difference. For this reason, I will ignore comment #6 and wait for a test that includes anaconda-10.1.1.94-1 RHTS job running RHEL4-U8-re20090128.1 installation: http://rhts.redhat.com/cgi-bin/rhts/jobs.cgi?id=43883 (In reply to comment #8) > RHTS job running RHEL4-U8-re20090128.1 installation: > http://rhts.redhat.com/cgi-bin/rhts/jobs.cgi?id=43883 This link does not show me any relative info. Do you have the link to the test logs? Test logs available here: http://rhts.redhat.com/cgi-bin/rhts/test_log.cgi?id=6301495 We have built a new anaconda, this new version erases stale lvm metadata before doing anything. Can you please retest with new nightly. FYI anaconda version you need is anaconda-10.1.1.95-1 Using nightly from 3rd Feb I got these test logs: http://rhts.redhat.com/cgi-bin/rhts/test_log.cgi?id=6331359 Unless I am missreading the logs.... this seems ok now. I see that the job passed. If you see anymore missbehavior pls reopen this bug. 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 therefore 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/RHBA-2009-0978.html |