<table cellspacing="0" cellpadding="0" border="0" ><tr><td valign="top" style="font: inherit;">Julie:<div><br></div><div>    Most of the Googling on this turns up partition table disk order errors:</div><div><br></div><div>http://stringofthoughts.wordpress.com/2009/05/24/grub-error-17-debianubuntu/</div><div>http://iknowkungfoo.com/blog/index.cfm/2008/6/16/Stupid-solution-for-Grub-error-17</div><div><br></div><div>Note in the second one that people who have other drives plugged in sometimes get relief by disconnecting them.  Any chance that in the field your units have USB drives plugged/unplugged into the Alix that werent/were present at the factory?  Does simply reinstalling grub (regular, not debug version) do the trick as well?<br><div><br></div><div>--Frank</div><div><br>--- On <b>Fri, 3/23/12, jfh@greenhousepc.com <i><jfh@greenhousepc.com></i></b> wrote:<br><blockquote style="border-left: 2px solid rgb(16, 16, 255);
 margin-left: 5px; padding-left: 5px;">From: jfh@greenhousepc.com <jfh@greenhousepc.com><br>Subject: [Voyage-linux] grub 17 errors<br>To: voyage-linux@voyage.hk<br>Date: Friday, March 23, 2012, 10:25 AM<br><br><div id="yiv1551372724"><div><span style="font-family:Verdana;color:#000000;font-size:10pt;"><div>Greets,<br></div><div><br></div><div>I have a client who has been plagued by Grub 17 errors for the longest time.  I'm using grub 0.97 ("legacy") on a version 0.6 version of Voyage.  Please don't tell me to upgrade -- it takes months to verify that a change of that nature is going to be safe.<br></div><div><br></div><div>I've done everything I can to debug the problem, but the error path in fsys_ext2fs.c doesn't seem applicable -- the partition sizes have been verified to be correct, there are no errors from fsck (other than the expected ones because the ALIX.3D2 was power cycled just before it happened) indicating the superblock had a
 bad magic number.</div><div><br></div><div>I'm not able to recreate the problem here, and updating the filesystem so it has a debugging version of grub fixes the problem.</div><div><br></div><div>The systems are cloned from an image using "dd", but grub is then re-installed manually.  All of the system I have in house, and all of the tests that I perform on systems I ship, are successful.  When they receive the systems they perform the exact same test, which is also successful.  It isn't until the systems are installed in the field that they fail.</div><div><br></div><div>I'm using Kingston "Elite Pro" 8GB compact flash for the O/S image and application.  Although it isn't "industrial" grade flash, the application was written so it minimizes the number of modified filesystem blocks as much as possible.</div><div><br></div><div>Help?<br></div><div>--<br>Julie Haugh<br>Senior Design Engineer<br>greenHouse Computers, LLC // jfh at <a
 rel="nofollow" target="_blank" href="http://greenhousepc.com">greenhousepc.com</a> // greenHousePC on Skype</div></span></div>

</div><br>-----Inline Attachment Follows-----<br><br><div class="plainMail">_______________________________________________<br>Voyage-linux mailing list<br><a ymailto="mailto:Voyage-linux@list.voyage.hk" href="/mc/compose?to=Voyage-linux@list.voyage.hk">Voyage-linux@list.voyage.hk</a><br><a href="http://list.voyage.hk/mailman/listinfo/voyage-linux" target="_blank">http://list.voyage.hk/mailman/listinfo/voyage-linux</a><br></div></blockquote></div></div></td></tr></table>