<?xml version="1.0" encoding="UTF-8"?>
<rss xmlns:content="http://purl.org/rss/1.0/modules/content/" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:taxo="http://purl.org/rss/1.0/modules/taxonomy/" version="2.0">
  <channel>
    <title>topic Re: Kernel Corruption in Operating System - HP-UX</title>
    <link>https://community.hpe.com/t5/operating-system-hp-ux/kernel-corruption/m-p/4514155#M366184</link>
    <description>take the backup of the kernel (/stand/vmunix &amp;amp; /stand/system) before performing any activity.&lt;BR /&gt;&lt;BR /&gt;If any thing happens to your kernel, then you can boot through alternate kernel</description>
    <pubDate>Wed, 14 Oct 2009 13:31:55 GMT</pubDate>
    <dc:creator>SUDHAKAR_18</dc:creator>
    <dc:date>2009-10-14T13:31:55Z</dc:date>
    <item>
      <title>Kernel Corruption</title>
      <link>https://community.hpe.com/t5/operating-system-hp-ux/kernel-corruption/m-p/4514154#M366183</link>
      <description>Hi,&lt;BR /&gt;&lt;BR /&gt;Recently one of my RP7400 system after reboot (uptime =532 days ) hung on the BCH and . after lots of workaround, it was concluded that kernel was corrupt. and we rebuilded system from Ignite recovery.This supports the statement of kernel corruption or /stand filesystem inconsistancy.Now i have to&lt;BR /&gt;face the problem management and have to mention the corrective action towards this.&lt;BR /&gt;what are the suggestions can be given to check such kernel or /stand health ?&lt;BR /&gt;I think fsck wont help since / and /stand filesystems are always mounted.&lt;BR /&gt;&lt;BR /&gt;any suggestion please.&lt;BR /&gt;</description>
      <pubDate>Wed, 14 Oct 2009 13:12:31 GMT</pubDate>
      <guid>https://community.hpe.com/t5/operating-system-hp-ux/kernel-corruption/m-p/4514154#M366183</guid>
      <dc:creator>sandeepbodkhe_1</dc:creator>
      <dc:date>2009-10-14T13:12:31Z</dc:date>
    </item>
    <item>
      <title>Re: Kernel Corruption</title>
      <link>https://community.hpe.com/t5/operating-system-hp-ux/kernel-corruption/m-p/4514155#M366184</link>
      <description>take the backup of the kernel (/stand/vmunix &amp;amp; /stand/system) before performing any activity.&lt;BR /&gt;&lt;BR /&gt;If any thing happens to your kernel, then you can boot through alternate kernel</description>
      <pubDate>Wed, 14 Oct 2009 13:31:55 GMT</pubDate>
      <guid>https://community.hpe.com/t5/operating-system-hp-ux/kernel-corruption/m-p/4514155#M366184</guid>
      <dc:creator>SUDHAKAR_18</dc:creator>
      <dc:date>2009-10-14T13:31:55Z</dc:date>
    </item>
    <item>
      <title>Re: Kernel Corruption</title>
      <link>https://community.hpe.com/t5/operating-system-hp-ux/kernel-corruption/m-p/4514156#M366185</link>
      <description>Shalom,&lt;BR /&gt;&lt;BR /&gt;hpux -is&lt;BR /&gt;# from the ISL prompt at console&lt;BR /&gt;&lt;BR /&gt;Thake a look at the size and stamps on the vmunix files&lt;BR /&gt;&lt;BR /&gt;boot the system off a previous kernel,&lt;BR /&gt;&lt;BR /&gt;hpux /stand/vmunix.prev &lt;NAME may="" vary=""&gt;&lt;BR /&gt;&lt;BR /&gt;Then build a new kernel.&lt;BR /&gt;&lt;BR /&gt;This kind of corruption does not often happen. If files are missing from /stand you may need to restore them from an Ignite backup.&lt;BR /&gt;&lt;BR /&gt;SEP&lt;/NAME&gt;</description>
      <pubDate>Wed, 14 Oct 2009 14:13:36 GMT</pubDate>
      <guid>https://community.hpe.com/t5/operating-system-hp-ux/kernel-corruption/m-p/4514156#M366185</guid>
      <dc:creator>Steven E. Protter</dc:creator>
      <dc:date>2009-10-14T14:13:36Z</dc:date>
    </item>
    <item>
      <title>Re: Kernel Corruption</title>
      <link>https://community.hpe.com/t5/operating-system-hp-ux/kernel-corruption/m-p/4514157#M366186</link>
      <description>We prepare make_tape_recovery and it completed successfully for last three times with same corrupt image.When we were trying to boot from that, system was getting panic.&lt;BR /&gt;So we used fourth old tape.&lt;BR /&gt;I think make_recovery did not really check the file integrety.instead it just backs it up.</description>
      <pubDate>Wed, 14 Oct 2009 14:26:08 GMT</pubDate>
      <guid>https://community.hpe.com/t5/operating-system-hp-ux/kernel-corruption/m-p/4514157#M366186</guid>
      <dc:creator>sandeepbodkhe_1</dc:creator>
      <dc:date>2009-10-14T14:26:08Z</dc:date>
    </item>
    <item>
      <title>Re: Kernel Corruption</title>
      <link>https://community.hpe.com/t5/operating-system-hp-ux/kernel-corruption/m-p/4514158#M366187</link>
      <description>Well of course.  vmunix is a compiled binary similar to any other 'c' a.out file.  And checking is performed at the time of compilation.</description>
      <pubDate>Wed, 14 Oct 2009 15:10:47 GMT</pubDate>
      <guid>https://community.hpe.com/t5/operating-system-hp-ux/kernel-corruption/m-p/4514158#M366187</guid>
      <dc:creator>Michael Steele_2</dc:creator>
      <dc:date>2009-10-14T15:10:47Z</dc:date>
    </item>
    <item>
      <title>Re: Kernel Corruption</title>
      <link>https://community.hpe.com/t5/operating-system-hp-ux/kernel-corruption/m-p/4514159#M366188</link>
      <description>&lt;!--!*#--&gt;"I think make_recovery did not really check the file integrety.instead it just backs it up."&lt;BR /&gt;&lt;BR /&gt;File integrity is usually handled by CRC checksums embeded in the storege. If there is a problem, you'll find out when the tape drive would actually save the data on tape.&lt;BR /&gt;&lt;BR /&gt;If you have completed archive jobs without any errors, suggests that somehow afther saving the data on media, the media itself is corrupted.&lt;BR /&gt;&lt;BR /&gt;Best regards from Romania,&lt;BR /&gt;Horia Chirculescu.</description>
      <pubDate>Thu, 15 Oct 2009 07:56:19 GMT</pubDate>
      <guid>https://community.hpe.com/t5/operating-system-hp-ux/kernel-corruption/m-p/4514159#M366188</guid>
      <dc:creator>Horia Chirculescu</dc:creator>
      <dc:date>2009-10-15T07:56:19Z</dc:date>
    </item>
  </channel>
</rss>

