Mint stops booting after drive fscks, but allows CTL-ALT-DEL to reboot
 

Hello all

I've got an odd problem. Ever since I installed Mint, things have been... quirky...

Long --> Short, if my computer works, great; if I move it, it might stop working. Implies a hardware problem, but the Mint LiveCD works fine with no issue, and the last time I had a quirky issue with Mint, I reinstalled and all was fine, implying software or configuration issue.

I don't *think* I've changed anything WRT configs.

In fact, my system has decided to stop working a few times, once requiring a complete reinstall (grub issues), and all with no changes made by me. I never had this problem with Debian or the brief time I tried Ubuntu, and like I said before the LiveCD works fine, so I'm ruling out hardware at least for now.

Symptoms:

I can determine that the kernel has loaded nouveau (sp?) driver, and it switches to graphical framebuffer at that time. I've gotten it to stop loading the Plymouth splash screen (GOD I hate Windows) as default, but I can still hit the up-arrow to switch between splash and text. Watching the text boot, it gets past fscking each of my linux-readable partitions and then stops at "ureadahead-other process (###) terminated with status 4" (where ### is a PID I think). Sometimes it says that twice, but sometimes once (I think it's related to the number of non-root drives I have installed).

I can still use my up and down arrows to switch between mint splash and text boot, and I can use CTL-ALT-DEL to reboot, so I know the machine isn't hard locked up... but that's it. I can load the livecd, and mount the hard drive and chroot to it successfully, but that's a PITA to do with every boot and it ties up my DVD-ROM drive.


But here's the big PITA of the issue: No logs. For whatever reason, the logs are not being written to the hard drive, which implies to me that the drives are not being mounted at boot like they should. Of course, not being in the system, I can't tell, but it *is* immediately after fsck that the system lists my drives/partitions then stops.

The bottom section of my bootup (parts edited b/c I'm lazy and it's easier to type words than copy number-for-number unimportant data -- I'll get it if it's really necessary)


I've even gone so far as to undo changes to my fstab. I had removed the UUID lines and replaced them with traditional /dev/sda5 type lines. My understanding was that UUIDs don't change, but I read somewhere that they can. Could this be the culprit? Still, that shouldn't have affected the /dev/sda5 type, should it have?

Any help is very much appreciated. I'm no noob, so no need to water it down too much, but I'm not seasoned kernel hacking programmer expert, so... obviously I need help, and I'd like to avoid yet another reinstall.

Thank you so much, anyone who can help.

and "blkid" by itself returns nothing.

if I run "blkid -o list" I can see all partitions but none show UUID (does it matter that I'm running it from LiveCD? Let me try a chroot...)


YES! It matters! wait... why? It shouldn't...


Well, the UUIDs of fstab and the drive (when chrooted) match, so that doesn't look like the problem...

*bump*

Any ideas from anyone?

Normally I don't bump my own thread, but I'm at a loss. I'm at the point now of disabling services (which shouldn't matter since they weren't an issue before). I'm booting a liveCD and chrooting to use my install, which seems to be working beautifully but it's still clumsy to set it up.


[EDIT]

Nevermind. I just reinstalled Mint from the OEM CD.

Again.

This makes something like the third or fourth reinstall.

I wonder if this is the first thread where I've been the only poster.

Either way, [SOLVED]

in fstab, there's a line for each mountpoint and on the end of each line is a pair of numbers. In most distros they're 0 and 0, but in mint they're 0 and 2 for one of them, 0 and 1 for another, and 0 and 0 for the rest. Changed ALL to be 0 and 0, and suddenly everything is fine.

Now, to figure out the ath5k bug...