Boot-repair is a product that has appeared in the past year or so and has speedily been incorporated in community-editable support documentation (basically all Ubuntu documentation). There's no question that the author has put a lot of effort has gone into creating and maintaining Boot-repair and it has apparently been embraced as a very useful tool by the community at large.
But I wouldn't recommend it for Wubi installations and here's why...
Wubi boot problems are different
There are some key differences in the way that Wubi boots. It uses the Windows boot mangler, not the bootloader in the drive MBR to boot. So that's the first thing to check... do you actually have boot problems or is it something different?
If Windows boots okay then boot-repair is not for you
As mentioned, Wubi boots via the Windows boot manager (yes that was a deliberate typo before). So technically your computer boots okay. Boot-repair is more concerned with the boot mechanisms that occur prior to the Windows boot manager showing e.g. the bootloader (drive MBR), the boot flag, etc. So running it isn't going to help. In one case it has stopped Windows booting. To be fair to the author, the problem mentioned in that thread has apparently been fixed, but I'm not sure that boot-repair is mature enough to handle all the myriad of Windows configurations out there.
If Windows doesn't boot, then you should use Windows Repair instead
As stated before, if you do have issues with Windows, then your best bet is a Windows repair disk. Windows repair is an official Windows repair mechanism supported by Microsoft, who hopefully understand their product.
If Wubi isn't booting then probably you need to run chkdsk
This cannot be done using boot-repair, only through Windows or Windows Repair. The most popular post on this blog is all about the damaged root.disk. This is by far the most common problem with Wubi installs, and the first thing you should consider when you have issues.
What Boot-repair will do
Boot-repair detects Wubi installs and will fsck the root.disk (fsck will fix any ext4 file system damage on the virtual disk). It's not always clear to new Ubuntu users how to do this, since you need to create an Ubuntu CD/USB, boot from it, mount the partition containing the root.disk and then fsck it. There are many guides on how to do all this, but of course it's easier to have this all automated for you.
Summary
I have no doubt that boot-repair has helped many people - and there don't seem to be too many misgivings about it out there in the community. But at the same time, in my opinion, it's been incorporated too rapidly into the official documentation e.g. here without sufficient warning that the tool is not officially supported by Canonical, and in some cases, might be classified as experimental.
Showing posts with label boot. Show all posts
Showing posts with label boot. Show all posts
Monday, August 20, 2012
Wednesday, June 20, 2012
Edubuntu - it burns!!!
Lately I've decided to use Edubuntu... But there have been some pain points, none more-so than the boot splash screen. You know, that white Edubuntu spash screen that modern laptops on full brightness just about shatter your retina as it boots? If all you know is the soothing Ubuntu purple screen (haha) then consider yourself fortunate.
So what can you do... surely you can just change it? Yeah, go to software center and search on boot and/or splash and/or eye's burning and ... nothing. But surely you know the boot process thing is called "Plymouth"? Oh yeah, okay try that... nothing!
No, you have to search on plymouth-theme. That will trick Software Center's advanced heuristic irritation algorithm to show you what you want!? (Why on earth would a search on plymouth not produce results that plymouth-theme produces?)
So, there it finally is - the Solar Theme I love. It's darker blues will soothe my eyes and not excite the senses (like that rude purple). Install it... bing, bang, boom, done!!! Ah, no, that's not the way it's done. It still comes up all whitey-brighty.
Well, duh, I didn't tell it to use Solar as default. How would it know!!! (Stupid me). What you obviously have to do is go to a terminal and run:
sudo update-alternatives --config default.plymouth
And select the number that matches the Solar Theme. Enjoy.
Please someone post a comment and tell me what I missed - there must be an easier way!!!
So what can you do... surely you can just change it? Yeah, go to software center and search on boot and/or splash and/or eye's burning and ... nothing. But surely you know the boot process thing is called "Plymouth"? Oh yeah, okay try that... nothing!
No, you have to search on plymouth-theme. That will trick Software Center's advanced heuristic irritation algorithm to show you what you want!? (Why on earth would a search on plymouth not produce results that plymouth-theme produces?)
So, there it finally is - the Solar Theme I love. It's darker blues will soothe my eyes and not excite the senses (like that rude purple). Install it... bing, bang, boom, done!!! Ah, no, that's not the way it's done. It still comes up all whitey-brighty.
Well, duh, I didn't tell it to use Solar as default. How would it know!!! (Stupid me). What you obviously have to do is go to a terminal and run:
sudo update-alternatives --config default.plymouth
And select the number that matches the Solar Theme. Enjoy.
Please someone post a comment and tell me what I missed - there must be an easier way!!!
Tuesday, August 2, 2011
Missing the root.disk
I wrote earlier about the Mystery of the disappearing root.disk. I've seen a number of additional cases since that post - and not all have been catastrophic, so thought I'd discuss what the steps are to attempt recovery.
My belief is that this problem is largely the result of manually shutting down your computer when the Wubi install is hanging. But there have been cases where corruption has occurred without manual poweroffs and I've noticed that some files I delete from within Wubi are 'recovered' later by Windows.
But it is important for users to resist the urge to 'hit the restart/power button' when the Wubi install is hanging. For any OS this is a bad idea and can lead to problems. For Wubi installs it can be fatal. Instead refer to the Wubi Guide for other options.
The first thing you'll notice may be Windows running an automatic CHKDSK or when you try to boot Ubuntu you end up at a GRUB> prompt.
Then when you boot Windows and look in the C:\ubuntu\disks directory you'll notice the root.disk is missing. In some cases, the \ubuntu\disks directory is missing completely or is corrupted.
Running chkdsk
Depending on the problem, Windows may have run an automatic chkdsk or you may need to run it manually. It's not always necessary, but it will never hurt, so the first thing is to run it.
Go to My Computer on XP or Computer on Vista/7, right click the drive you installed Ubuntu on e.g. right click on C:, select Properties, select the Tools tab, then under Error-checking click Check now. Select to Automatically fix file system errors or Scan for and attempt recovery of bad sectors (I usually don't use this, but if you hard drive has problems it's a good idea). When the drive you installed on is C: the computer will tell you it has to schedule the scan for the next time you start your computer. Reboot to complete.
Locate recovered files/directories
The first thing to do is to look for the \found.000 folder on the drive in question i.e. C:\found.0000. This is hidden by default and (on my Windows 7 install) I also had to tell Windows not to "Hide protected OS files" just to see it. You may also have to recover from an administrator command prompt on Win7 (see below).
So now you look for your root.disk (or other .disk files) and copy them back to the \ubuntu\disks folder. If the entire \ubuntu\disks folder is missing, you'll likely find a dir0000.chk directory and within that the root.disk, swap.disk and empty \boot\grub folders. Copy this back to \ubuntu renaming the directory to disks.
If you're missing the root.disk but there is no file of that name, it may have been renamed chk0000.chk. Rename this to root.disk and copy back to \ubuntu\disks.
If the corruption was minor, then likely everything will work fine. If the corruption is major Windows may not even recover the root.disk at all.
Win7/Vista command line instructions
Hit the START key, enter CMD, then look above and right click on CMD.exe and select "Run as Administrator", as shown below. From Windows 8, type "CMD" on the Metro page, right click, and then look on the bottom for "Run as administrator.
Check for the hidden recovery directories: dir /a:h
Check each \found.??? directory:
Or if the whole \ubuntu\disks folder is missing:
My belief is that this problem is largely the result of manually shutting down your computer when the Wubi install is hanging. But there have been cases where corruption has occurred without manual poweroffs and I've noticed that some files I delete from within Wubi are 'recovered' later by Windows.
But it is important for users to resist the urge to 'hit the restart/power button' when the Wubi install is hanging. For any OS this is a bad idea and can lead to problems. For Wubi installs it can be fatal. Instead refer to the Wubi Guide for other options.
The first thing you'll notice may be Windows running an automatic CHKDSK or when you try to boot Ubuntu you end up at a GRUB> prompt.
Then when you boot Windows and look in the C:\ubuntu\disks directory you'll notice the root.disk is missing. In some cases, the \ubuntu\disks directory is missing completely or is corrupted.
Running chkdsk
Depending on the problem, Windows may have run an automatic chkdsk or you may need to run it manually. It's not always necessary, but it will never hurt, so the first thing is to run it.
Go to My Computer on XP or Computer on Vista/7, right click the drive you installed Ubuntu on e.g. right click on C:, select Properties, select the Tools tab, then under Error-checking click Check now. Select to Automatically fix file system errors or Scan for and attempt recovery of bad sectors (I usually don't use this, but if you hard drive has problems it's a good idea). When the drive you installed on is C: the computer will tell you it has to schedule the scan for the next time you start your computer. Reboot to complete.
Locate recovered files/directories
The first thing to do is to look for the \found.000 folder on the drive in question i.e. C:\found.0000. This is hidden by default and (on my Windows 7 install) I also had to tell Windows not to "Hide protected OS files" just to see it. You may also have to recover from an administrator command prompt on Win7 (see below).
So now you look for your root.disk (or other .disk files) and copy them back to the \ubuntu\disks folder. If the entire \ubuntu\disks folder is missing, you'll likely find a dir0000.chk directory and within that the root.disk, swap.disk and empty \boot\grub folders. Copy this back to \ubuntu renaming the directory to disks.
If you're missing the root.disk but there is no file of that name, it may have been renamed chk0000.chk. Rename this to root.disk and copy back to \ubuntu\disks.
If the corruption was minor, then likely everything will work fine. If the corruption is major Windows may not even recover the root.disk at all.
Win7/Vista command line instructions
Hit the START key, enter CMD, then look above and right click on CMD.exe and select "Run as Administrator", as shown below. From Windows 8, type "CMD" on the Metro page, right click, and then look on the bottom for "Run as administrator.
Check for the hidden recovery directories: dir /a:h
Check each \found.??? directory:
C:\>cd \found.000
C:\found.000>dir
Volume in drive C is OS
Volume Serial Number is B4B7-99A8
Directory of C:\found.000
19/07/2011 02:02 PM 15,000,000,000 file0000.chk
1 File(s) 15,000,000,000 bytes
0 Dir(s) 222,258,069,504 bytes free
C:\found.000>move file0000.chk \ubuntu\disks\root.disk
1 file(s) moved.Or if the whole \ubuntu\disks folder is missing:
C:\>cd \found.000
C:\found.000>dir
Volume in drive C is OS
Volume Serial Number is B4B7-99A8
Directory of C:\found.000
19/10/2012 04:51 PM <DIR> .
19/10/2012 04:51 PM <DIR> ..
19/07/2011 02:02 PM <DIR> dir0000.chk
0 File(s) 0 bytes
3 Dir(s) 222,258,069,504 bytes free
C:\found.000>dir dir0000.chk
Volume in drive C is OS
Volume Serial Number is B4B7-99A8
Directory of C:\found.000\dir0000.chk
19/10/2012 04:51 PM <DIR> .
19/10/2012 04:51 PM <DIR> ..
24/02/2012 12:22 AM <DIR> boot
06/11/2012 09:28 AM 13,000,000,000 root.disk
15/11/2011 09:28 PM 268,435,456 swap.disk
2 File(s) 13,268,435,456 bytes
3 Dir(s) 127,904,968,704 bytes free
C:\>move dir0000.chk \ubuntu\disks
1 dir(s) moved.
I hope this helps you to recover your files. Remember to backup important data on your Wubi install. There's no reason to install important personal files on a root.disk - you can access them easily on the /host partition.
Updated 2012-11-06: added some more screenshots, enhanced DOS commands
Updated 2012-11-06: added some more screenshots, enhanced DOS commands
Tuesday, December 21, 2010
Wubi and grub problem update
It's been one month since the latest grub-pc update in version 10.04.1 Lucid Lynx, started breaking Wubi installs. And that's a good time to reassess the situation.
I'm not sure how I noticed it - maybe I was browsing Wubi bugs that day - but my quick alert to the issues didn't help. Again, I was hoping for a quick response, maybe the update being pulled - I don't know. But apparently launchpad doesn't have a recall mechanism. At the time I thought it would only affect users who didn't install on the same partition as Windows - the usual grub trick that gets users to install the grub bootloader to their drive masterbootrecord MBR caused by a bug in the 'lupin' package (see here, or here).
But quickly it became apparent that it also affected users who installed on the same partition - a problem we already knew about as it was discovered in the Maverick upgrade. But for 10.04.1 the problem is worse, and requires a manual loop mount of the virtual disk and an edit of the grub configuration file from a live CD.
So now we are on the Christmas break, and the developers get a well-needed rest from all the Natty development, but sadly noone has taken the time to patch lupin, for the many existing users on the supported releases. Still, the volunteers on ubuntuforums.org will soldier on, steering Wubi users to the solution... the Wubi megathread. It's interesting to note that since this thread was created 2 weeks ago, it's had over 2600 visits. And that's not including the number of people who had to be helped before it was created.
So... where are we at? There's not much really to be done to warn users unless they happen to post a support request for an unrelated Wubi question. I'm loathe to join the Wubi-bashing crowd (although it's tempting): there's still a niche market for users that might cause more damage trying to do a proper partitioned Ubuntu installation. In fact, the new Ubiquity installer has it's own issues and has already caught out a few users and overwritten Windows and all other partitions - see bug 659106.
And in any case, despite all the Wubi-bashing, Wubi appears to be growing in popularity, fueled by its new prominent place on the ubuntu.com download page.
So... I guess we just wait it out, and hope that eventually the grub devs will grace us with their attention and provide a fix.
I'm not sure how I noticed it - maybe I was browsing Wubi bugs that day - but my quick alert to the issues didn't help. Again, I was hoping for a quick response, maybe the update being pulled - I don't know. But apparently launchpad doesn't have a recall mechanism. At the time I thought it would only affect users who didn't install on the same partition as Windows - the usual grub trick that gets users to install the grub bootloader to their drive masterbootrecord MBR caused by a bug in the 'lupin' package (see here, or here).
But quickly it became apparent that it also affected users who installed on the same partition - a problem we already knew about as it was discovered in the Maverick upgrade. But for 10.04.1 the problem is worse, and requires a manual loop mount of the virtual disk and an edit of the grub configuration file from a live CD.
So now we are on the Christmas break, and the developers get a well-needed rest from all the Natty development, but sadly noone has taken the time to patch lupin, for the many existing users on the supported releases. Still, the volunteers on ubuntuforums.org will soldier on, steering Wubi users to the solution... the Wubi megathread. It's interesting to note that since this thread was created 2 weeks ago, it's had over 2600 visits. And that's not including the number of people who had to be helped before it was created.
So... where are we at? There's not much really to be done to warn users unless they happen to post a support request for an unrelated Wubi question. I'm loathe to join the Wubi-bashing crowd (although it's tempting): there's still a niche market for users that might cause more damage trying to do a proper partitioned Ubuntu installation. In fact, the new Ubiquity installer has it's own issues and has already caught out a few users and overwritten Windows and all other partitions - see bug 659106.
And in any case, despite all the Wubi-bashing, Wubi appears to be growing in popularity, fueled by its new prominent place on the ubuntu.com download page.
So... I guess we just wait it out, and hope that eventually the grub devs will grace us with their attention and provide a fix.
Thursday, December 16, 2010
Canonical has a strange sense of priorities
So it's nearly a month since the latest Grub update in the current Long Term Release, Lucid Lynx 10.04, put the boots to Wubi installs. In addition to the usual alarming, but generally harmless, grub rescue> prompt problem, which has been around since Lucid was first released in April, the newer failure to boot issue has been totally ignored by Canonical.
This boot failure problem started cropping up in July with grub errors about 'loadfont', but didn't seem to affect everyone. With the November 20 release it now appears to be much more widespread - a fresh install of 10.04.1 with the updates applied does not boot. (*Ubuntu must be installed to the same partition as Windows for this problem to occur).
The reason that it only affects Wubi installs on the same partition as Windows is that it is the grub-install command that is corrupting the /boot/grub directory, and when you update package grub-pc it runs grub-install to try to update the wubildr (Wubi bootloader) - believed by the grub devs to be a required action; BUT, Wubi installs on a different partition slip through the net as the buggy code fails to identify them as Wubi installs. This means that grub-install aborts and the wubildr is not updated - but ironically these still boot.
So the whole idea of updating wubildr and breaking Wubi installs in the process is pointless - why don't they just bypass the update altogether.
So... why haven't the devs rushed to fix this? Even the Ubuntu Release Manager Steve Langasek was notified of the 'critical' issue... but no response at all. The devs appear to be hard at work preparing for the next Ubuntu release (11.04 Natty Narwhal) - in the meantime, unsuspecting users who decide to try out Ubuntu are left to discover what a grub rescue prompt is, or why their new OS fails to boot.
So, in summary, Canonical doesn't seem to give a hoot about the current users who are breaking their computers trying out the 'user friendly' Wubi option. Are they just blindly churning out (buggy) release after (buggy) release as though this is a strategy for long-term success? Hard to say, but let's just say - I'm confused. If they don't want to support Wubi, why don't they just pull it from their main download site to protect the computers of unsuspecting users?
And thanks to everyone on Ubuntuforums.org who are working hard to help the affected users. It's great to have such strong community support, but if Canonical is relying on this for current release support it's pretty pathetic.
This boot failure problem started cropping up in July with grub errors about 'loadfont', but didn't seem to affect everyone. With the November 20 release it now appears to be much more widespread - a fresh install of 10.04.1 with the updates applied does not boot. (*Ubuntu must be installed to the same partition as Windows for this problem to occur).
The reason that it only affects Wubi installs on the same partition as Windows is that it is the grub-install command that is corrupting the /boot/grub directory, and when you update package grub-pc it runs grub-install to try to update the wubildr (Wubi bootloader) - believed by the grub devs to be a required action; BUT, Wubi installs on a different partition slip through the net as the buggy code fails to identify them as Wubi installs. This means that grub-install aborts and the wubildr is not updated - but ironically these still boot.
So the whole idea of updating wubildr and breaking Wubi installs in the process is pointless - why don't they just bypass the update altogether.
So... why haven't the devs rushed to fix this? Even the Ubuntu Release Manager Steve Langasek was notified of the 'critical' issue... but no response at all. The devs appear to be hard at work preparing for the next Ubuntu release (11.04 Natty Narwhal) - in the meantime, unsuspecting users who decide to try out Ubuntu are left to discover what a grub rescue prompt is, or why their new OS fails to boot.
So, in summary, Canonical doesn't seem to give a hoot about the current users who are breaking their computers trying out the 'user friendly' Wubi option. Are they just blindly churning out (buggy) release after (buggy) release as though this is a strategy for long-term success? Hard to say, but let's just say - I'm confused. If they don't want to support Wubi, why don't they just pull it from their main download site to protect the computers of unsuspecting users?
And thanks to everyone on Ubuntuforums.org who are working hard to help the affected users. It's great to have such strong community support, but if Canonical is relying on this for current release support it's pretty pathetic.
Thursday, December 9, 2010
Wubi Mega-help-thread
There is now a one-stop Wubi 'megathread' on ubuntuforums.org to repair the grub issues Wubi users have been experiencing. Recommended reading if you are using Wubi, even if you haven't had any issues yet.
The thread is: http://ubuntuforums.org/showthread.php?t=1639198
The thread is: http://ubuntuforums.org/showthread.php?t=1639198
Subscribe to:
Posts (Atom)