Linux Mint Forums

Thank you for your interest in Mint
To help you solve your problem we need to know exactly what Mint you use.
By that I mean version (like Celena or Daryna or numerical if you prefer) and edition (main = Gnome, KDE or some of the Community Editions like xfce or fluxbox or the mini edition)
We also need possible error messages, exactly as they appear
We also need information about your hardware. You can obtain that by running
lspci
in a terminal
If it is something connected to USB you run
lsusb
and similarly for other 'buses' like pcmcia....
To copy from a terminal mark (with the mouse) and right click
Then paste into a code box (it does not use as much space then)
Thank you

I'm having the same problem but with Elyssa and have been since RC1 I was hoping it would have been worked out by now. I don't think the prblem is very hardware specific but my system maybe experiencing a conflict due to having a sata and ide drive. If I add a drive remove a drive or change the boot order (even tho grub is setup on either dirve to find root on the one with Mint installed) I get all kinds of wierdness. the grub drive designations change around (HD0 becomes HD1 and vice versa) the SDA and sdB designations in Elyssa get swapped around etc. Even when nothing changes I get the same problem as described above. This is not an acceptable I shoudln't have to edit menu.lst fstab and mtab everytime I add or remove a drive. I do a lot of customer backups so this will be a constant problem for me unless I get a solution. anyone know of anything that might help?

These errors are soon driving me nuts...
I have to leave it for now and try to come back when I h ave been thinking about it for a while (again)
Oh - you can't edit mtab - it's a file that's auto generated (any alteration is ignored)

Actually, I think Hussa is right about mtab I'm not sure any changes I made stuck... It may have auto-generated from the changes I made in fstab. Maybe thats one step I don't have to keep making.

When I edit menu.lst I have to swap all the HD0,1 references to HD1,1 (for instance) and my SDA2 references to SDB2 etc... Unfortunately, since I am running multiple Linux distros and I have been experimenting and installing Elyssa to partitions on both the SATA and the IDE drive I have many entries to modify and on at least two occassions Elyssa has recreated the entries to the active installation in the menu.lst file and I think chnaged my redesignations back. I don't know what triggered Elyssa to do this and no the new or changed entries did not work as Elyssa (or grub) set them up. They had to be re-edited back to my own parameters before I could even boot but then the intramfs boot problem remained.

Fstab also had to be edited to reflect the proper SDA/SDB designations and don't get me started on the uuid thing...

I must say this is particularly disapointing to run in to. I have spent literally hundreds of man hours looking for a distro I would not only use but would endorse for my clients. I really thought Mint was the one but now I'm not so sure. Darnya's ease of installation, out of box support for much of the test platforms I tried it on and general feature set impressed me immensely, it was slower than many other distros forcing me to raise my expectations for minimal harware requirements but when I found I could upgrade a client system to one that would suffice for under $100 I was sold on Mint as my OS of choice. Elyssa's improvements in speed, responsiveness, a few useabilty features and better hardware support esp. for newer notebooks got me to upgrade immediately but this boot problem is a show stopper. Its hard to imagine why it wouldn't be a major priority to fix.

I have spent too much time on this issue and its costing me because I have other projects, paying projects, that need to take priority. Maybe this isn't affecting enough other users for mint/ubuntu or whoever it falls on to work this bug out to worry with. Granted, I have loaded Elyssa beta on at least one client notebook and have had no reports of a boot problem but other than my own systemwith the SATA/IDE setup there are only two other systems I've installed it on and one of them probably hasn't been rebooted in weeks since the install so it wouldn't have exhibited any signs and the other is at my officeand has also seen very little use since the install.

I hope I don't keep running into it or I will have to reevaluate some of the runners up in my distro comparisons.

@ wight
Can we agree on that your problem comes when you connect or disconnect disks?
I have that problem too, but that disk is not supposed to be connected when I boot Mint so it's easy to solve
I'll dive into the grub documentation to see if there's a solution
I think others experience this as well

Husse, that would be great if you could figure this one out... I've done a lot of testing but I'm still a relative newbie and this is really over my head. Of course, even after we get the ability to boot Mint with a customer drive in the system there will still be the iniramfs problem. As I said before though, I don't know how much I might run into the problem but if its not just a SATA/IDE problem then I expect I'll see it again and I can't very well set this up on customer systems if they can't boot but 1-2 times out of 10.

Hi,

I have been running linux mint 4.0 and 5 on my toshiba laptop with absolutely no problems. this morning I tried to install linux mint 5 on my desktop at work. I get the splash screen and then the (initramfs).. so pretty much the same problems as the guys above, except that I cannot get it to install at all no matter how many times I reboot.

Specs. Del, Intel Core 2 Duo. 2gigs memory, 250gig sata hard drive... any clues will help?

For the record, Linux mint is king! Have loved using it since the very start.

I'm working on a solution for the grub thing
After that I'll take a look at the initramfs thing
I suspect that's hardware related in the more normal sense
It should only be on the live CD and may be a showstopper for some hardware

I hope this helps
http://www.linuxmint.com/wiki/index.php ... annot_boot
Edit//
I definitely think this helps for your problems wight

Please start a new topic instead of adding to a similar topic
I now have several people in this topic with different problems and different solutions
@ gryrofx
Which graphics card do you have?
Have you tried compatibility mode?
If not press any key when the live CD boots and time is counted down, the rest is self explanatory
Only one disk? If so the solution in the wiki about failing boot is not for you
@ newio
Test the solution in the link and report back - it might be it - if not we'll have to search deeper
@ hellomoto440
Does Hardy use UUID int menu.lst? I have not installed it - haven't found the time, but soon I'll install 8.04.1
If Hardy uses UUIDin menu.lst the solution in the wiki link is not for you
Have you tried compatibility mode on the live CD, see above

Congratulations Husse, you solved it!

I was experiencing other (as it turns out, unrelated) difficulties and went through a bit of reinstalling from scratch before figuring it out and finally getting around to trying the info on the link but that definitely cured mine. I was having my menu.lst file overwritten and I didn't know why and I lost sound again then finally video. Turns out I didn't quite know what I was doing (surprise, surprise... user created error trying to setup virtualbox and it was installing different kernels and rewriting grub. (It didn't append, it overwrote my old grub).

I was really ticked off about the uuid thing because it was screwing up my system every time I would change my partitioning. I've been experimenting with multiple Linuxes and multibooting but Darnya would need to be reloaded anytime I messed with them till I found the tip on replacing the uuid with the /dev/sdx description. I never had a problem with other distros and was wondering why Mint/Ubuntu would go to something like uuids since it seemed to cause more problems than the other distros. Once I fixed the uuid problem and settled on Mint as my OS of choice, eventually deleted the other OSes. I have no idea if those would have had the same grub problems as Mint 5 (Darnya never gave me any Grub Problems) but I'm still vested in Mint thanks to you Husse.

I'm still not certain whether other distros would have this problem with reordering the drives but uuid solves the problem and if the uuid changes, knowing how to "sudo blkid" to get the new uuids solves that problem so it looks like I don't have to go back to the drawing board on my quest for "The" Linux.

Husse, I can't thank you enough... It seems like such a small thing in retrospect but so far my biggest hurdles in working with Linux have been the little show stoppers that were usually resolved with a rather simple solution once I finally found it (or had it revealed to me .

I thought my hair would be even more gray than it already is over this
For the moment I can tell you that at least Mepis and probably Debian has the problem and it is a problem that should hit any distro that uses menu.lst...
Maybe non Debian based distros has a solution to it but I can't see how...

Nope- not adding it
Unfortunately formatting it may change all (?) UUIDs - but now you know the blkid command
That's why we skipped it in the first place and as I said in the answer to wight this probably goes for all distros and actually also for Windows

Hi, hope it is okay if I add an opinion here. While the uuid solution works, I hate to see all those letters and numbers in my menu.lst and fstab. I give all my drives a label and then, for example, in fstab I do something like this

/dev/disk/by-label/storage /media/storage ntfs-3g defaults 0 0

and then in menu.lst I will do the same like this for the kernel line

/boot/vmlinuz-2.6.24-16-generic root=/dev/disk/by-label/mint ro quiet splash

You can see which partitions have a label with this command

ls -lF /dev/disk/by-label

and you can give your partitions labels using these commands

* swap: Create a new swapspace like this: mkswap -L <label> /dev/XXX
* ext2/ext3: e2label /dev/XXX <label>
* reiserfs: reiserfstune -l <label> /dev/XXX
* jfs: jfs_tune -L <label> /dev/XXX
* xfs: xfs_admin -L <label> /dev/XXX
* fat/vfat: mlabel /dev/XXX:<label> or change it using Windows.
* ntfs: ntfslabel /dev/XXX <label> or change it using Windows.

This info comes from archlinux wiki

I fully agree - but this is to take it one step further and I don't want to go "too far" because that may even seem intimidating to the "mor or less" newbie - that said I don't know the status of the people in this topic
I suppose the labels were storage and mint - you did not say and it immediately becomes confusing

Ya, sorry to confuse you Husse, that was the reason I linked to the wiki article at archlinux wiki. It goes into a little more detail. Really, I wasn't suggesting people do it this way instead of the uuid way. I just prefer this way and thought maybe a few others might.

I just prefer this way and thought maybe a few others might.

Fred among them, perhaps me .... but I'm to lazy/have to much to do with Mint - pick an alternative

I think I should just add that I installed the XFCE beta - first a failed attempt in sda10 and then in sda8 and the UUID did not change
This is contrary to what I remembered from earlier occasions but then I may have changed size of some partition too

With reference to the original query:
Try adding the entry "acpi=off" to the kernel options.
That's what I had to do to even get the LiveCD to boot, as well as to boot the installed system.