Have you tried running a tool over the hard drive to find any errors, other than fsck.<br><br>As recommended in another topic Ultimate Boot CD will scan your drive with the manufacturers tools and detect any errors, among other things...<br>
<br>If there are errors we can cross that bridge then.<br><br>Regards<br>Nathan<br><br><br><div class="gmail_quote">On Sat, Sep 26, 2009 at 6:50 AM, MDM Productions <span dir="ltr"><<a href="mailto:thefrasers@clear.net.nz">thefrasers@clear.net.nz</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div><div></div><div class="h5">Jonathan Harker wrote:<br>
> MDM Productions wrote:<br>
><br>
>> Xav: All the other drives are there, and all have UUID's except for<br>
>> hda6. Will that be restored automagically once we get the show on the road?<br>
>><br>
><br>
> UUIDs are optional. Their only advantage is if you introduce another<br>
> hard disk, and your Linux kernel decides to shift what used to be your<br>
> /dev/sda to /dev/sdb or something, and your /dev/sda6 partition becomes<br>
> /dev/sdb6 which fouls up your /etc/fstab. Using UUIDs instead would<br>
> prevent that from happening.<br>
><br>
> Depending on your distribution (I think you said Mandriva?) you should<br>
> be able to see which UUIDs correspond to which devices:<br>
><br>
> ls -l /dev/disk/by-uuid<br>
><br>
> For instance, mine says:<br>
><br>
> bda665d9-eb5e-49c2-9ad4-dd9359eb5778 -> ../../sda1<br>
> 06B89BA8B89B9531 -> ../../sdb1<br>
> D0CC7172CC715426 -> ../../sdb5<br>
> 0277438a-55fa-4fa4-aa5d-80f2e1e08ef0 -> ../../sdb6<br>
> 06305be6-cafa-449e-b3cb-c79806f76996 -> ../../sdb7<br>
> 130d8080-5895-4014-88ed-7d8ce139c8d3 -> ../../sdb8<br>
> 3a18306b-aeee-4933-b137-b14f81bb6fcd -> ../../sdc1<br>
><br>
> I'm using Ubuntu though, so you might have to poke around a bit, not<br>
> sure if that's a Debian-specific arrangement.<br>
><br>
> Anyway<br>
><br>
> Does the message output say anything about why it is dropping you into a<br>
> maintenance shell? Is it because the timestamp is wrong? I got this once<br>
> because it detected the date it was last mounted was "in the future"<br>
> because of the way Windows and Linux were dual-booting, and one was<br>
> treating the system clock as GMT, the other as NZST.<br>
><br>
> HTH<br>
> J<br>
><br>
><br>
><br>
</div></div>Dear All,<br>
<br>
To clear up a couple of things, the OS, _/single booting,/_ is PCLOS. I<br>
had it set up to suspend to disk on lid close which it would do reliably<br>
about half the time in that it might not wake. I hadn't stopped it doing<br>
suspend despite best intentions (I just hadn't, OK?) and despite being<br>
careful about this it might well have been writing something when I shut<br>
the lid enough to trigger the switch. I believe I had closed out and was<br>
putting it away and might have just shut the lid a moment too soon.<br>
What I get on start is now the verbose parade ticking off down to<br>
Remounting root file system in read-write mode OK, then Invalidating<br>
stale software suspend images...done, then Checking file systems, then<br>
fsck.ext3: Unable to resolve 'UUID=454f....etc etc' , then /dev/hda6:<br>
recovering journal, then /dev/hda6: clean, 4416/13123584 files<br>
1629111/26236145 blocks [FAILED] and the drop to shell after ***An error<br>
occurred... etc.<br>
Has any of this helped explain further?<br>
Thanks people.<br>
<div><div></div><div class="h5"><br>
<br>
--<br>
Wellington Linux Users Group Mailing List: <a href="mailto:wellylug@lists.wellylug.org.nz">wellylug@lists.wellylug.org.nz</a><br>
To Leave: <a href="http://lists.wellylug.org.nz/mailman/listinfo/wellylug" target="_blank">http://lists.wellylug.org.nz/mailman/listinfo/wellylug</a><br>
</div></div></blockquote></div><br>