LMDE switching boot drives (and crashing)

[Lolo Uila]

Sorry for such a long post. I've been having a frustrating time with LMDE and this is both a request for help and a little venting...

I've been messing with LMDE for quite a while now, and have had no luck getting a stable install. The problems varied enough that I had trouble figuring out what was going on. Sometimes it would boot and run fine (quite often, actually). Other times it would crash with a Gnome error, or a Dbus error, or a file system error, or some other error... It almost seemed like there was a random crash generator in my system. It was driving me crazy because lots of searching turned up nothing.

I know what you're thinking... must be hardware, right? That's what I thought too, but the system in question has run just about every other version of Linux Mint, and several other non-Mint distros as well, and they all ran fine (or at least they crashed consistently if there was a hardware incompatibility). I have successfully run Mint distros going back to at least Mint-3 (Cassandra) and all ran fine. I remember the occasional tricky install, but once I got it going it was solid.

Not LMDE though. Install, crash! Re-install, crash! Re-install again, and finally it seems to be working. Update, and it's still working. Then a few days later, boom! Re-install again, and hey it worked first time this time. Update, boom! Re-install and don't update, and still it goes boom after a few reboots. It seemed like I had about a 1 in 3 chance of crashing each time I booted. Sometimes a reboot after a crash would get me going again. Other times things were broken and had to be reinstalled (Dbus was a common one).

It really seemed like it was bad memory or a bum HDD, but I run Mint-9 daily as my main OS, and occasionally run Windows XP SP3 and both run fine (even ran Windows 7 RC for several months without incident).

Out of desperation I did the whole hardware check thing anyway. Memory test, pass. Hard disk diagnostics, pass (even tried a different HDD). Checked the DVD-burner, it's working perfectly. Checked the install DVD several different ways, all passed. Test installed a few versions of Mint-10 (Gnome, KDE, LXDE) and they all worked fine. I really wanted to switch this machine to Debian, but, well, it just ain't working.

So today, while watching yet another boot fail - I can always see it coming because there are lots of red fail messages - noticed that LMDE was trying to boot from the WRONG DRIVE! What the... ??

Okay, this system has a lot of hard drives. 5 to be exact. 3 single drives and 2 RAID-0 stripes. I always install Linux to the first drive and Windows is on the 2nd. So, SDA1=Linux, SDB1=Windows. The 3rd single drive and the 2 striped arrays are strictly data. GRUB is installed to SDA, and that drive is in a swappable bay, so when I want to test a different distro I just yank the drive and put in another one (there is never more than one Linux distro on the system). So it's a fresh install and fresh GRUB on a clean drive each time. This system works well, because after each crash & burn with LMDE I can just pop my Mint-9 HDD back in and I'm back in business.

It seems that LMDE will start the boot process from SDA1, which is where it's installed, and then the drive order occasionally switches, (a different drive becomes SDA) and boom, crash. I'm not really sure what could cause this, but it only happens in the Debian edition of Mint. And the most frustrating thing is it doesn't happen every time.

So... anyone got any ideas about this?

[Sleven]

Just a thought, this may take some time but it is what I would try.

Disconnect all HDD except SDA and reinstall LMDE and see how it acts.
If it stops crashing, reconnect SDB, and reinstall.
Continue reconnecting each HDD and reinstalling until you find out which HDD is causing the problem.

[Lolo Uila]

Thanks for the suggestion, but I just found something interesting that is likely the cause of the problem.

There are TWO entries for / (root filesystem) in fstab!! I couldn't understand how that whole drive order issue could happen since I thought everything had switched to UUID a while back. But I guess that's an Ubuntu thing, because I took a look at my LMDE fstab, with the plans to add my nfs shares, and I noticed that both "/" and "swap" have 2 entries, one using UUID, and the other using /dev/...

That rung a great big bell for me, because when the boot fails it seems to happen after I see a message about waiting for /dev/ to be populated (or something of that nature). Why would there be TWO entries, using different ID systems?

This is my fstab:

Code: Select all

# <file system> <mount point>   <type>  <options>       <dump>  <pass>
proc            /proc           proc    defaults        0       0
# / was on /dev/sda1 during installation
UUID=39dce7bc-28c6-4d48-a3e1-b2d48712856e /               ext3    errors=remount-ro 0       1
# swap was on /dev/sda5 during installation
UUID=f5355ad1-6de9-497b-a8d4-e2abe7336d4d none            swap    sw              0       0
/dev/scd0       /media/cdrom0   udf,iso9660 user,noauto     0       0
proc	/proc	proc	nodev,noexec,nosuid	0	0
/dev/sda5	/home	ext4	rw,errors=remount-ro	0	0
/dev/sda6	/var	ext4	rw,errors=remount-ro	0	0
/dev/sda7	/tmp	ext2	rw,errors=remount-ro	0	0
/dev/sda8	swap	swap	sw	0	0
/dev/sda1	/	ext4	rw,errors=remount-ro	0	0

Notice /, swap, and even proc all have dual entries... what's up with that?

The first / entry uses UUID and says it's an ext3 filesystem. The second says /dev/sda1 and ext4 (it is, in fact, ext4). The options are slightly different as well. Okay, and this gets even stranger, the UUIDs used do not match anything in my system? Where the heck did those come from?

Is there some reason Debian needs 2 entries in fstab for /, swap and proc? I'm wondering what would happen if I trimmed down fstab to be more Ubuntu like?

[altair4]

That is very peculiar.

What should happen I think is that the second reference to "/" should be ignored since it's already mounted but there may be a problem with the UUID.

Run the following command to get an accurate listing of the UUID:

Code: Select all

sudo blkid -c /dev/null

If you run it without the "-c /dev/null" you may get an output that reflects old data since blkid doesn't clear out it's cash in a coherent manner.

[Lolo Uila]

Yea, that seemed very odd... especially since that was the default fstab on a fresh install.

Anyway, I trimmed down my fstab, removing the dual entries and using only the /dev/sd.. entries for now (no UUID), and it rebooted fine.

I tried your suggestion and got the same UUID results as I did before (using just sudo blkid). So it seems there were odd UUIDs in the fstab. I had pre-formatted the drive with GParted and created all my partitions in advance. During the install I just edited the partition info to tell it what partition was what mount point, but I believe the installer forces a format of / and I wonder if something odd happens there (like it got the UUID before it reformatted)?

Now that I think about it, that may be it. The only 2 partitions that had the format fields filled in were / and swap, and those were the ones with the mystery UUIDs that didn't match. Could this be a bug in the installer, something related to your comment above about blkid not clearing its cache properly? Since I started with a pre-formatted and partitioned drive, might it have used the UUIDs created by Gparted and not updated them when those partitions got reformatted?