fyi, posting resolution in case others run into LVM checksum errors..
Turns out this is related to two kickstart options: 'clearpart --all' and 'zerombr yes'. The clearpart didn't have '--all --initlabel', so the LVM had some metadata left over from a previous LVM, which led to a checksum error. Used vgcfgrestore to clean this up, which restores the checksum on the physical volume to a known good value. -Brad Martin, Terry R. (CMS/CTR) (CTR) wrote:
Hi Over the last month or so we have had CHECK SUM ERRORS on 3 of our z/Linux hosts. This error stops the Linux host from coming back up after a re-boot or log off. After working with REDHAT they found that there was 2 bit over lay of what amounts to the VTOC which points to the UUIDs. Each time this has happened it has been the same over lay. The common thing on these hosts are that they all run Oracle 10g, REDHAT REL4, and FDR/UPSTREAM. When this happens we must boot in RESCUE mode and re-build the UUIDs (not sure of this process by Linux guy does this). I was just wondering if anyone has seen this type of issue. This is our POC but if this does not get resolved we will be hard pressed to move forward. I have also posted this on the z/VM List Serve. Thanks, Terry ---------------------------------------------------------------------- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
-- Brad Hinson <[EMAIL PROTECTED]> Sr. Support Engineer Lead, System z Red Hat, Inc. (919) 754-4198 www.redhat.com/z ---------------------------------------------------------------------- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
