Vista/Ubuntu Dual Boot desperate help needed :(
May 24, 2008 8:51 PM Subscribe
How to dual boot vista/ubuntu hardy heron and get everything set up. More details Inside. Starting to pull hair out :(
Just a warning guys im just going to spill every piece of info i think might help solve this problem below. Sorry in advance but im at wits end.
I was planning on dual booting Vista/Hardy Heron on my compalIFL90 notebook. To do this i completely formatted the harddrive and installed vista first, giving it 40 gigs and leaving the other 120 gigs as free space. After i had installed vista i went back and installed ubuntu using the desktop 32 bit cd and just told it to use the largest contigous file. After i started playing around with my new ubuntu desktop i heard that it would be nice if i got my own home, root, and swap partitions so i went back and deleted my ubuntu partition,this time starting the manual partition mode. I made a 20 gig root, 4 gig swap and the rest of the gigs as home. I thought i was home free.
I tried following THIS GUIDE to set up my Compal, as it seems some hardware was not supported out of the box. I also installed compiz fusion and emerald theme manager, as well as the restricted drivers for my nvidia card.
and now all of a sudden im getting all these problems:
1. When i start up the computer sometimes all it says is GRUB loading stage 1.5 and just hangs there. I have to manually shut down the computer to get it back up, and then it allows me to boot into ubuntu or vista.
2. When i boot into ubuntu i just come to a white screen with a cursor sometimes, and i again have to manually shut down.
3. Once when just surfing the web this pink or purple fuzz started to border my windows and just mysteriously diapeared when i restarted.
4. I cant hibernate or sleep in my ubuntu.... while this is discussed in the above link i really dont get it.
So basically my whole installation is just crapping itself up and i have no idea why. Im not sure what i did wrong :(
So any help would be appreciated guys, and I wouldnt mind reformmating everything and starting over if i know it would work Thanks :D for reading this long post and i really hope i can get this to work i wanna learn linux :(
Just a warning guys im just going to spill every piece of info i think might help solve this problem below. Sorry in advance but im at wits end.
I was planning on dual booting Vista/Hardy Heron on my compalIFL90 notebook. To do this i completely formatted the harddrive and installed vista first, giving it 40 gigs and leaving the other 120 gigs as free space. After i had installed vista i went back and installed ubuntu using the desktop 32 bit cd and just told it to use the largest contigous file. After i started playing around with my new ubuntu desktop i heard that it would be nice if i got my own home, root, and swap partitions so i went back and deleted my ubuntu partition,this time starting the manual partition mode. I made a 20 gig root, 4 gig swap and the rest of the gigs as home. I thought i was home free.
I tried following THIS GUIDE to set up my Compal, as it seems some hardware was not supported out of the box. I also installed compiz fusion and emerald theme manager, as well as the restricted drivers for my nvidia card.
and now all of a sudden im getting all these problems:
1. When i start up the computer sometimes all it says is GRUB loading stage 1.5 and just hangs there. I have to manually shut down the computer to get it back up, and then it allows me to boot into ubuntu or vista.
2. When i boot into ubuntu i just come to a white screen with a cursor sometimes, and i again have to manually shut down.
3. Once when just surfing the web this pink or purple fuzz started to border my windows and just mysteriously diapeared when i restarted.
4. I cant hibernate or sleep in my ubuntu.... while this is discussed in the above link i really dont get it.
So basically my whole installation is just crapping itself up and i have no idea why. Im not sure what i did wrong :(
So any help would be appreciated guys, and I wouldnt mind reformmating everything and starting over if i know it would work Thanks :D for reading this long post and i really hope i can get this to work i wanna learn linux :(
If you're going to reinstall everything and are just doing this to learn linux then I'd suggest:
Reformat everything as one big ol' drive.
Install Windows.
Download and install Wubi
Wubi is an Ubuntu installation that is installed like a normal Windows program and actually runs from a file that exists inside your windows partition. If you get sick of it you just uninstall. It adds itself to your Windows boot menu (there's no GRUB or LILO to worry about) and can be deleted by just uninstalling the program from windows. No mess no fuss.
posted by schwa at 9:56 PM on May 24, 2008
Reformat everything as one big ol' drive.
Install Windows.
Download and install Wubi
Wubi is an Ubuntu installation that is installed like a normal Windows program and actually runs from a file that exists inside your windows partition. If you get sick of it you just uninstall. It adds itself to your Windows boot menu (there's no GRUB or LILO to worry about) and can be deleted by just uninstalling the program from windows. No mess no fuss.
posted by schwa at 9:56 PM on May 24, 2008
When i start up the computer sometimes all it says is GRUB loading stage 1.5 and just hangs there. I have to manually shut down the computer to get it back up, and then it allows me to boot into ubuntu or vista.
I had this problem on an old XP/Gusty Gibbon dual-boot. I solved the problem by deleting the stage 1.5 files (they're optional). Someone else suggests the same here.
posted by Nelsormensch at 10:16 PM on May 24, 2008
I had this problem on an old XP/Gusty Gibbon dual-boot. I solved the problem by deleting the stage 1.5 files (they're optional). Someone else suggests the same here.
posted by Nelsormensch at 10:16 PM on May 24, 2008
I second schwa's recommendation. It's REALLY, REALLY clean -- it just sticks itself in the vista boot loader and you're ready to go. (Although I've noticed troubles recovering into ubuntu after a vista crash -- have to get vista running first then reboot into ubuntu for some reason. But that's a minor thing.)
posted by paultopia at 10:27 PM on May 24, 2008
posted by paultopia at 10:27 PM on May 24, 2008
A Wubi install option is already included on the HH live cd, no need to download anything else.
posted by T.D. Strange at 11:58 PM on May 24, 2008
posted by T.D. Strange at 11:58 PM on May 24, 2008
Before going nuclear and repaving with Wubi, try reinstalling the boot loader stage 1 and stage 1.5, as follows. These instructions assume that you only have one physical hard disk in your computer, and that /boot is on the second one (Windows being on the first one).
1. Boot into Ubuntu and start up a terminal.
2. Type sudo grub and hit Enter.
3. Sudo will ask for your password, then you'll get the Grub command prompt.
4. Type root (hd0,1) and hit Enter.
5. Type setup (hd0) and hit Enter.
6. Type quit and hit Enter.
Ubuntu should now boot reliably. If it starts acting weird again following a Windows boot, it's almost certain that Windows or something running under Windows (possibly an overzealous antivirus program?) is trashing Grub stage 1.5, which lives in the normally-unused space between block 0 of the physical disk drive (the Master Boot Record or MBR) and the start of partition 1 (usually block 63).
On the other hand, if you've picked ReiserFS as the filesystem for your Ubuntu root partition, and Ubuntu has been shut down uncleanly (perhaps as part of a failed recovery from a failed hibernation?) you will find that on next boot it takes a completely unreasonable amount of time (30 seconds or so) for Grub to switch from stage 1.5 to stage 2. I was convinced something was badly wrong the first time this happened to me.
posted by flabdablet at 2:34 AM on May 25, 2008
1. Boot into Ubuntu and start up a terminal.
2. Type sudo grub and hit Enter.
3. Sudo will ask for your password, then you'll get the Grub command prompt.
4. Type root (hd0,1) and hit Enter.
5. Type setup (hd0) and hit Enter.
6. Type quit and hit Enter.
Ubuntu should now boot reliably. If it starts acting weird again following a Windows boot, it's almost certain that Windows or something running under Windows (possibly an overzealous antivirus program?) is trashing Grub stage 1.5, which lives in the normally-unused space between block 0 of the physical disk drive (the Master Boot Record or MBR) and the start of partition 1 (usually block 63).
On the other hand, if you've picked ReiserFS as the filesystem for your Ubuntu root partition, and Ubuntu has been shut down uncleanly (perhaps as part of a failed recovery from a failed hibernation?) you will find that on next boot it takes a completely unreasonable amount of time (30 seconds or so) for Grub to switch from stage 1.5 to stage 2. I was convinced something was badly wrong the first time this happened to me.
posted by flabdablet at 2:34 AM on May 25, 2008
Response by poster: Just to let you guys know i dont really feel like doing wubi, im going all in since i i know i will be using linux. so I would rather have the problem at hand fixed. and Flabdablet ill try what you said doing but i have no idea what ReiserFS is either.
posted by thesonofmorgoth at 7:14 AM on May 25, 2008
posted by thesonofmorgoth at 7:14 AM on May 25, 2008
Best answer: ReiserFS is a kind of filesystem (method of formatting a partition). If you didn't pick it deliberately when your Linux partitions were being formatted, you're probably using ext3 (the default for Ubuntu, and the most commonly used Linux filesystem type) instead. FAT32 and NTFS are commonly-used filesystem types for Windows.
You can actually to the Grub stage 1 and 1.5 reinstall from Grub itself, rather than from the Grub shell inside Linux, if you prefer. Hit Esc as Grub is booting up, to get you the Grub menu, then hit C for the Grub command shell, then use steps 4 and 5 above, then use reboot instead of quit in step 6.
You'd do it from inside Linux (after booting from a live CD) if Grub was too broken to show you the menu.
If you follow the links I provided above, you will see talk of a workaround involving deleting the stage_1.5 files. Here's a quick rundown of the Grub boot sequence, just so you'll understand what the consequences of that are, and understand why the workaround works.
Grub stage 1 fits entirely inside the first 512-byte disk block, the MBR, which also holds the partition table. There's not much room there for clever code, so all it does is consult a smallish list of block numbers, loads those disk blocks sequentially into RAM and jump to code contained in them.
Normally, that list of block numbers simply identifies blocks 1 through about 17, the stage_1.5 boot loader. This is traditionally unused space on a disk using the MBR partitioning scheme. Partition 1 is supposed to start on a track boundary; it can't start at the start of track 0, since the MBR occupies the first block of that; so it generally starts on track 1 instead, which on a drive marked as having 63 heads puts it on block 63, leaving blocks 1 through 62 available for stage 1.5.
There's enough room in Stage 1.5 to put code that implements just enough of a filesystem to look up files in directories and read them into RAM, regardless of which disk blocks they actually occupy. There's a different version of the stage_1.5 boot loader for each of the file system types supported by Grub - there's a FAT one, an ext2/ext3 one, a ReiserFS one, an XFS one and so on.
Stage_1.5 looks up the /boot/grub directory on the appropriate partition and runs the Stage 2 bootloader file inside it. The Stage 2 bootloader is what's actually responsible for interpreting the Grub config file (usually /boot/grub/menu.lst), displaying any menus and doing the loading of the OS proper. As you can imagine, Stage 2 is a fair bit more complicated than Stage 1.5, and its code is correspondingly larger.
If Grub can't find an appropriate stage_1.5 file while you're running its setup command, it won't copy one to blocks 1-17; instead, it makes a list of the disk blocks currently occupied by whichever Stage 2 bootloader it's going to need, and puts that block list directly into the MBR. The net effect is that Stage 1 blindly loads Stage 2 right out of its containing filesystem, without needing any knowledge of how that filesystem is organized, and Windows can no longer screw things up by overwriting "unused" space between blocks 1 and 62.
So why doesn't it always work this way? Well, consider what happens if you back up and restore your /boot/grub folder, or if you update or upgrade the Stage 2 bootloader. It's pretty unlikely that the Stage 2 file would end up occupying the same disk blocks it did before; so unless you also remember to run Grub setup again after doing such an update, stage 1 will read a list of bogus blocks and probably just die.
With stage 1.5 occupying the "unused" space between the MBR and partition 1 (provided Windows keeps its filthy claws off it), Grub will just keep working across stage 2 updates or /boot/grub moves, without needing to be reinstalled - since stage 1.5 contains the logic to find stage 2 properly regardless of what actual disk blocks it happens to occupy today. The only time you should need to redo a Grub setup that includes stage 1.5 is if you change the filesystem type for /boot (since each filesystem needs its own variant of stage 1.5), or put /boot on its own partition (since in that case Grub will need to look for stage 2 in (hd0,1)/grub instead of (hd0,1)/boot/grub).
If you can figure out exactly what it is that's trashing your stage 1.5, and stop it from doing that, I think that's a better thing than making Grub go straight from stage 1 to stage 2. Look for "virus protection" in your BIOS settings and turn that off while you're messing with your bootloader, for a start; most of the time, all that stuff does is screw up your ability to write to the MBR, but I wouldn't be surprised to find that somebody has coded something to tromp on the "unused" blocks following the MBR as well.
If you're using any of the Big Three antivirus suites on your Windows (Norton, McAfee, Trend) give it the arse and install AVG 8.0 Free instead. As far as I know, AVG won't mess with Grub.
If it turns out that this is a Vista thing: well, I wouldn't really be surprised to find MS adding "security" features that "just happen" to nobble the free opposition.
I'd be interested to hear what you end up finding out, since I'm booked to convert a customer's Vista machine to a Vista/Ubuntu dual boot this Thursday.
posted by flabdablet at 8:10 AM on May 25, 2008
You can actually to the Grub stage 1 and 1.5 reinstall from Grub itself, rather than from the Grub shell inside Linux, if you prefer. Hit Esc as Grub is booting up, to get you the Grub menu, then hit C for the Grub command shell, then use steps 4 and 5 above, then use reboot instead of quit in step 6.
You'd do it from inside Linux (after booting from a live CD) if Grub was too broken to show you the menu.
If you follow the links I provided above, you will see talk of a workaround involving deleting the stage_1.5 files. Here's a quick rundown of the Grub boot sequence, just so you'll understand what the consequences of that are, and understand why the workaround works.
Grub stage 1 fits entirely inside the first 512-byte disk block, the MBR, which also holds the partition table. There's not much room there for clever code, so all it does is consult a smallish list of block numbers, loads those disk blocks sequentially into RAM and jump to code contained in them.
Normally, that list of block numbers simply identifies blocks 1 through about 17, the stage_1.5 boot loader. This is traditionally unused space on a disk using the MBR partitioning scheme. Partition 1 is supposed to start on a track boundary; it can't start at the start of track 0, since the MBR occupies the first block of that; so it generally starts on track 1 instead, which on a drive marked as having 63 heads puts it on block 63, leaving blocks 1 through 62 available for stage 1.5.
There's enough room in Stage 1.5 to put code that implements just enough of a filesystem to look up files in directories and read them into RAM, regardless of which disk blocks they actually occupy. There's a different version of the stage_1.5 boot loader for each of the file system types supported by Grub - there's a FAT one, an ext2/ext3 one, a ReiserFS one, an XFS one and so on.
Stage_1.5 looks up the /boot/grub directory on the appropriate partition and runs the Stage 2 bootloader file inside it. The Stage 2 bootloader is what's actually responsible for interpreting the Grub config file (usually /boot/grub/menu.lst), displaying any menus and doing the loading of the OS proper. As you can imagine, Stage 2 is a fair bit more complicated than Stage 1.5, and its code is correspondingly larger.
If Grub can't find an appropriate stage_1.5 file while you're running its setup command, it won't copy one to blocks 1-17; instead, it makes a list of the disk blocks currently occupied by whichever Stage 2 bootloader it's going to need, and puts that block list directly into the MBR. The net effect is that Stage 1 blindly loads Stage 2 right out of its containing filesystem, without needing any knowledge of how that filesystem is organized, and Windows can no longer screw things up by overwriting "unused" space between blocks 1 and 62.
So why doesn't it always work this way? Well, consider what happens if you back up and restore your /boot/grub folder, or if you update or upgrade the Stage 2 bootloader. It's pretty unlikely that the Stage 2 file would end up occupying the same disk blocks it did before; so unless you also remember to run Grub setup again after doing such an update, stage 1 will read a list of bogus blocks and probably just die.
With stage 1.5 occupying the "unused" space between the MBR and partition 1 (provided Windows keeps its filthy claws off it), Grub will just keep working across stage 2 updates or /boot/grub moves, without needing to be reinstalled - since stage 1.5 contains the logic to find stage 2 properly regardless of what actual disk blocks it happens to occupy today. The only time you should need to redo a Grub setup that includes stage 1.5 is if you change the filesystem type for /boot (since each filesystem needs its own variant of stage 1.5), or put /boot on its own partition (since in that case Grub will need to look for stage 2 in (hd0,1)/grub instead of (hd0,1)/boot/grub).
If you can figure out exactly what it is that's trashing your stage 1.5, and stop it from doing that, I think that's a better thing than making Grub go straight from stage 1 to stage 2. Look for "virus protection" in your BIOS settings and turn that off while you're messing with your bootloader, for a start; most of the time, all that stuff does is screw up your ability to write to the MBR, but I wouldn't be surprised to find that somebody has coded something to tromp on the "unused" blocks following the MBR as well.
If you're using any of the Big Three antivirus suites on your Windows (Norton, McAfee, Trend) give it the arse and install AVG 8.0 Free instead. As far as I know, AVG won't mess with Grub.
If it turns out that this is a Vista thing: well, I wouldn't really be surprised to find MS adding "security" features that "just happen" to nobble the free opposition.
I'd be interested to hear what you end up finding out, since I'm booked to convert a customer's Vista machine to a Vista/Ubuntu dual boot this Thursday.
posted by flabdablet at 8:10 AM on May 25, 2008
which on a drive marked as having 63 heads
Sorry. Should be "which on a drive marked as having 63 sectors per track". Number of heads defines tracks per cylinder, not blocks per track.
posted by flabdablet at 8:13 AM on May 25, 2008
Sorry. Should be "which on a drive marked as having 63 sectors per track". Number of heads defines tracks per cylinder, not blocks per track.
posted by flabdablet at 8:13 AM on May 25, 2008
Response by poster: hmm also Flabdablet, that Grub fix did not work :( I did it on ubuntu, then restarted into vista and had to dload some security fix as always and when i was done and restarted it just hanged on grub loading stage 1.5 again :(
posted by thesonofmorgoth at 8:30 AM on May 25, 2008
posted by thesonofmorgoth at 8:30 AM on May 25, 2008
Best answer: That makes sense, if it's Vista, or some "security" garbage running under Vista, trashing Grub stage 1.5. Try doing the fix again, and see if you can boot into Ubuntu straight away. Then do that a few more times to see if it's reliable. Then go visit Vista, and see if Grub is now broken again. If it is, try doing the stage 1.5 deletion thing before reinstalling Grub.
posted by flabdablet at 8:50 AM on May 25, 2008
posted by flabdablet at 8:50 AM on May 25, 2008
Response by poster: oh yeah its vista. I booted into ubuntu and restarted 3 times fine. i boot into vista and restart and i just get the hang again. sigh. so your telling me to delete the stage 1.5 and then reinstall? is there a guide on how to delete stage 1.5 and reinstall grub? (i am always scared to experiment with mbr stuff :/ sorry for sounding cautious) Otherwise just to make sure, from your above post your saying that the only bad things about deleting the stage 1.5 are that i cant put boot on a seperate partition or change my file system from ext3? Thats not really that bad is it? when/why would i do any of these? I mean i have a root partition and a home partition (both ext3) and swap right now and I plan on using that forever no real reason to switch right? The only things i would need to change are when update time comes around it just rewrites root and i have my home partition with all my settings and files still saved for the new update.
posted by thesonofmorgoth at 8:03 PM on May 25, 2008
posted by thesonofmorgoth at 8:03 PM on May 25, 2008
Best answer: is there a guide on how to delete stage 1.5 and reinstall grub?
Yes. I linked to it above (it's here).
your saying that the only bad things about deleting the stage 1.5 are that i cant put boot on a seperate partition or change my file system from ext3
You'd need to re-run grub setup to make your system bootable again after doing either of those, even with stage 1.5 in place. With stage 1.5 missing, you also need to re-run grub setup after doing anything that could move the stage 2 file to a different set of disk blocks (e.g. upgrading it).
If Vista is eating stage 1.5, it doesn't look like you have much choice but to leave it out. So if a regular Ubuntu upgrade ever leaves your system in an unbootable state, booting from a live CD and re-running grub setup should be all that's required to fix it.
posted by flabdablet at 2:58 AM on May 26, 2008
Yes. I linked to it above (it's here).
your saying that the only bad things about deleting the stage 1.5 are that i cant put boot on a seperate partition or change my file system from ext3
You'd need to re-run grub setup to make your system bootable again after doing either of those, even with stage 1.5 in place. With stage 1.5 missing, you also need to re-run grub setup after doing anything that could move the stage 2 file to a different set of disk blocks (e.g. upgrading it).
If Vista is eating stage 1.5, it doesn't look like you have much choice but to leave it out. So if a regular Ubuntu upgrade ever leaves your system in an unbootable state, booting from a live CD and re-running grub setup should be all that's required to fix it.
posted by flabdablet at 2:58 AM on May 26, 2008
Response by poster: Ok, i downloaded SuperGrub and followed the instructions to bypass stage 1.5, and booted into vista, which made me dload service pack 1. I restarted and grub loaded correctly this time! I selected vista again but it wouldnt load up however :( manually restarted computer and vista loaded up this time though i think it was just a fluke not loading up the first time since it had to install service pack crap. Tried restarting about 3 times and grub loaded up everytime! So i think it works :D Thank you so much flabdablet for putting up with me haha, now i can move onto fixing more minor problems :)
YAY I GET TO USE LINUX NOW! Thank you again!
posted by thesonofmorgoth at 12:42 PM on May 26, 2008
YAY I GET TO USE LINUX NOW! Thank you again!
posted by thesonofmorgoth at 12:42 PM on May 26, 2008
This thread is closed to new comments.
This sounds like the Compiz pink shadows bug. Workaround.
posted by Inspector.Gadget at 9:14 PM on May 24, 2008