Ubuntu Lucid grub2 dist-upgrades result in confusion

[Erick Brunzell]

Binary package hint: grub-pc

This is a horrible way to file a bug report and I'm aware of that, but this needs to be considered.

Throughout various upgrade and/or update procedures in Ubuntu and its variants the user gets a display asking where to install grub(2). There is a suggestion that if in doubt to install to the mbr of all drives.

Unfortunately most new (and some old) users have no idea how drives/partitions are designated in Ubuntu, and they're clueless as to what an mbr is!

So basically you see a screen that says, "if in doubt select all", and you do so. Now, I'm aware those are not the exact words but I've been following (and trying to help folks fix) these problems since Lucid was released.

It's particularly troublesome when someone installs grub2 to an NTFS partition with a Win OS so I'd at least suggest making grub installation to an NTFS (or any FAT) partition very difficult.

Honestly I'm not sure what the solution should be, but I know Colin Watson deals with a lot of these grub2 issues and I've come to trust his judgment. Consider the following options:

#1: Display nothing but drives, that is "sda", "sdb", etc, and NO individual partitions. But create another "advanced" tab/option to allow installation to a partition.

#2: Increase the amount of text explaining the difference between drives and partitions, why it's a bad idea to install to a partition etc. IMHO that's a horrible option. (The more text the less likely a new user is to read it.)

#3: Figure out a way to always have grub(2) install itself where it was to begin with. (maybe a bad idea if the original install was wrong.)

While I think option #1 is great I have no idea how complicated that would be.

Does any of that make sense?

I'd be glad to test any potential "fixes" :^)

SRU justification:

IMPACT: I concur with the problems described above. We often see people turning up in #grub who've been affected by this, and it's often the least capable users who are suddenly hit by an unbootable Windows system which can be quite a challenge to fix. We need to clear this up in a stable update to limit the damage.

DEVELOPMENT BRANCH: While I haven't uploaded this yet due to the Alpha-2 freeze, I've committed it to the Maverick branch for grub2 1.98+20100614-2ubuntu4: http://bazaar.launchpad.net/~ubuntu-core-dev/ubuntu/maverick/grub2/maverick/revision/1999

PATCH: http://bazaar.launchpad.net/~ubuntu-core-dev/ubuntu/lucid/grub2/lucid/revision/1973

TEST CASE: The simplest way to force this confusing screen to appear is by running 'sudo dpkg-reconfigure grub-pc'. The broken state is that all partitions are offered, including Windows partitions which will be broken by installing GRUB to them; the desired state is described in comment 56.

REGRESSION POTENTIAL: I can hardly have made the dialog any more harmfully misleading, but if I got my change badly enough wrong then upgrades might break (along with dpkg-reconfigure). I think it would be worth testing an upgrade from Karmic on a two-disk system and making sure that the experience is vaguely reasonable. You may be able to save time by testing this together with bug 580408.

[quixote (commer-greenglim)]

I've been helping plenty of people over on the forums who install/upgrade to Lucid and are faced with a nonfunctional computer on the next boot because they misunderstood something in the grub install or upgrade process. It's not always this particular bug, but all user interface issues in grub are astronomically important.

Please mark this important! The trauma for new users whose computer seems to have died on them post-ubuntu is huge.

[arpanaut (johnmac)]

I have to agree with Erick that the suggestion "if in doubt select all" is an incorrect direction to give and is causing various degrees of problems for many. Especially those with Windows and are installing grub to many partitions rather than just to the MBR of their first boot hard drive. I was taken aback when this was offered to me upon a fresh install of Lucid, luckily I knew better because of experience with grub2, and I knew exactly where I wanted grub installed. I see better direction and advice within the installer as one possible solution for this serious bug. The inexperienced user is going to say "OK when in doubt, go for all" because that is what the installer is telling them to do.

[Erick Brunzell (lbsolost)]

Just a couple of examples:

http://ubuntuforums.org/showthread.php?p=9257870#post9257870

http://ubuntuforums.org/showthread.php?p=9261910#post9261910

That was just in the past 12 hours or so and there were more :^(

Recently received this PM:

"Well.... my challenge is within swedish forums

Example....
http://www.swedroid.se/forum/showthread.php?t=10609

You are mentioned in my last message as reference."

Followed by:

"Hi again....

Testdisk solved this and its because of you !

I have helped 3 users today with Testdisk !

What I mean is that we must find or start a new bug-report for this !

Developers doesn't read forums."

That was one week ago and he referenced this thread:

http://ubuntuforums.org/showthread.php?t=1466648

These are popping up by the dozens.

Therefore I'm changing this to confirmed.

[Erick Brunzell (lbsolost)]

I suspect this is actually a duplicate of this bug report:

https://bugs.launchpad.net/ubuntu/+source/grub2/+bug/571893

I would however prefer the devs decide.

[Takkat (takkat-nebuk)]

I agree that bug #571893 is a duplicate of this one here. We do experience the same trouble here with grub in wrong places when upgrading.

[Takkat (takkat-nebuk)]

To add a suggestion that can be included very quickly and easily and may well be sufficient to unexperienced user:

#5: Change the help text from the tickbox when asked where to install grub:

It should recommend unexperienced users to keep the default setting rather than mislead users "to install GRUB to all of them" (Drives a meant but this could easily be misinterpreted to partitions as well). The note at the bottom on partition boot records should be changed to a clear warning that other OSs may not be able to boot if Grub is installed to their boot partition record. I would suggest someting like "In dual or multi boot installations make sure to NOT install Grub to your Windows or other OSs boot partition".

[Erick Brunzell (lbsolost)]

@ Takkat, from what I've seen the "default" is that nothing is "ticked" and in my experience most novices simply don't know what the various alpha-numerical symbols mean in a drive/partition designation. Surprisingly there is still confusion over the "h" or "s" at the beginning and the need for UUID's etc, but my point is that we have a serious problem.

I'm part of the problem because I blew it off for weeks blaming it on "the bug between the chair and the keyboard" so you can blame me for not more aggressively pursuing this throughout iso-testing and upgrade testing.

I'm almost certain that once Colin Watson, who seems to get stuck with a lot of these grub2 bugs, get's wind of exactly what the issue is it will be addressed in some manner. Right now we must be patient because of UDS, but I'd expect action on this within 10 to 14 days.

It could have been sooner if I'd done a better job of testing and remembering to put my "noob" shoes on ;^(

[Peter Lenny (lenny-alternex)]

Noob sez:

It's torture reading this thread! The agony of hindsight.

From an existing two-disk, two-OS dual-boot setup - and as a newcomer to Ubuntu - I followed the kindly (over-kindly?) advice - "if in doubt select all" - not because I was unaware of what the partition names mean, but because I had no idea Grub shouldn't be installed to the Windows disk. I mean it's my BIOS priority boot disk and Grub is the boot-loader: so why not?

I have been banging my head against this for a week, to no avail. I will now be patient, safe in the knowledge that those-who-know are getting prodded (I am adding my prod to both threads).

[Erick Brunzell (lbsolost)]

Peter, for what it's worth my Ubuntu forum name is "kansasnoob". I in no way meant the "noob shoes" comment to seem derogatory. I had not looked at Linux since "Lindows" until just over two years ago so I am a noob.

But since I'm retired this has become my main hobby and I do sometimes forget that others don't know what I've learned, occasionally I need to stand back and ask myself, "would I have understood that two years ago"?

I blew it this time! But, that aside, did you figure out how to fix your problem? If not look here:

http://sourceforge.net/apps/mediawiki/bootinfoscript/index.php?title=Boot_Problems:Boot_Sector

[Peter Lenny (lenny-alternex)]

Kansasnoob (capitalised as a mark of respect)

I wasn't taking umbrage, just hooking in - and following your posts with interest.

Yes, the week of head-banging has included taking your advice, but at testdisk Screen 3, I got a non-standard response, which I have posted at:

http://ubuntuforums.org/showthread.php?t=1477410&highlight=testdisk

Thank you for asking.

[Justin Miller (superslacker87)]

I was affected on my most recent upgrade as well.

http://ubuntuforums.org/showthread.php?p=9270190#post9270190

[dino99 (9d9)]

this installer is a pure nightmare: in douth never trust it

some neurons are hardly needed and this installer with its silly comments breaking everything around, might be redesigned.

The grub installer need to remove/purge the previous grub release if it exist, then select the ubuntu partition to be installed on it, no need to drop each user and newcomer into confusions and breakages.

[Erick Brunzell (lbsolost)]

Still getting these:

http://ubuntuforums.org/showthread.php?p=9289108#post9289108

To quote the OP there:

"During the upgrade it complained about grub not working. It said if i didnt know what drive to mount i had to select all of them, which i did."

These are constant. I really can't imagine a much more serious bug (security bugs aside).

[chris (cosaki)]

This bug makes my dual-boot not work anymore. I've been trying all the recommended fixes, but still have no luck. If anyone has any other suggestions, please look over my thread and let me know. Thank you!

http://ubuntuforums.org/showthread.php?t=1480451

[Erick Brunzell (lbsolost)]

I was just fiddling with Debian Squeeze trying to figure out an unrelated issue but it required my changing from legacy grub to grub2, and IMO their approach at this is much safer and saner. I posted a screenshot in this thread at the forums (post #16):

http://ubuntuforums.org/showthread.php?p=9305905#post9305905

My shot:

http://ubuntuforums.org/attachment.php?attachmentid=157072&d=1273960112

A shot of the typical Ubuntu behavior (same thread post #1):

http://ubuntuforums.org/attachment.php?attachmentid=155778&d=1273197137

You'll see they only display the drive designations rather than both drive and partition designations. I do realize that in rare occasions when someone does require grub on a partition they'll have to resort to CLI, but I think that's a much wiser approach.

Now to see if my links work ;^)

[Erick Brunzell (lbsolost)]

This is a perfect example of the problem:

http://ubuntuforums.org/showthread.php?t=1484965

BTW I've linked less than 10% of these "examples" that I've personally helped to fix.

Please, please help us.

[Erick Brunzell (lbsolost)]

Apologies in advance if I overstepped my bounds here, but I subscribed Colin Watson in hopes that he can shed some insight on this.

I promise I won't make such behavior a common practice but I feel this is giving Ubuntu a real "black eye" so to speak, and I trust Colin's judgment based on previous involvement with grub2 issues.

[Erick Brunzell (lbsolost)]

In post #4 I'd mentioned this being a duplicate, here's another:

https://bugs.launchpad.net/ubuntu/+source/grub2/+bug/552056

That one's much older, prior to my being aware of the issue. Sadly I overlooked the issue earlier :^(

After seeing the earliest reports of this I even tried a distribution upgrade but failed to recognize that people simply don't understand the difference between drive and partition designations, thus my (invalid) bug report:

https://bugs.launchpad.net/ubuntu/+source/grub2/+bug/567015

I'm sure if I spent more time I could yield more results.

[arjun (ajn-menon)]

I'm also affected by this. It messed up my windows boot sector because it suggested i install to all if I am unsure.

[Paul Murphy (pm-66)]

I got caught by this too, dual hard drives one XP one Ubuntu, followed the recommendadtion and lost XP
A week of searching and then help...
Hopefully this is a simple fix

[bcbc (bcbc)]

Just to add to Erick's comment, I am still seeing users being hit by this problem on a daily basis. Although this report says 9 people affected I can assure you it's much higher. Unfortunately most of these people are new users attracted to Ubuntu and it's not very good advertising.

So, isn't it about time someone changing the importance from 'undecided'?

Note also that for some people the proposed fixes work easily, but there are some where the fix does not work and a reinstall is required.

Questions:
Why does the install program encourage installing grub2 to a partition with no warning, whereas if you try and install grub2 manually you have to force it to do this?
Why can't grub2 detect that it doesn't belong on a windows partition?
Why does grub2 try and install bootloaders on a wubi upgrade and then when you select no MBR's or partitions give you a big warning about how the system could be unbootable?

Opinion:
Grub2 is an important piece of Ubuntu, and it needs to fit with all officially supported uses of Ubuntu. This includes dual boots and Wubi installs. I know it's not simple, but it seems to me that it could be a lot simpler.

[Peter Lenny (lenny-alternex)]

Unfortunately, there's a thread at http://ubuntuforums.org/showthread.php?t=1469755 entitled "How many users have dual boot unavailable after upgrading to Lucid?" and marked "Solved"...

[sojourner (itsmealso2)]

unfortunately the situation is even worse than portrayed here so far , the order of the drives as displayed by the installer is not the same as the BIOS order or the order as presented in Gparted (which I use for all formating and partitioning ) or even consistent from one release to the next . I test on a multi drive ( 6 hds 2 dvds ) box, multi partition 2 to 6 per drive and the only way to really know which is which is to label each partition with a distintive name . and BTW ubiquity sometime refuses to put grub ANYWHERE except the mbr fo what it is calling SDA ( which ) may infact actually be and IDE drive not a sata . some consistency please .

[Tom Pino (metalsmith-rangeweb)]

As you can see from the comments on this bug this is something of a pain.

I am guessing but i really think about a third of the problems with booting MS installs that show up on the forums is due to the installation of grub on the MS boot sector.

While I do not have that problem as I will not have MS in the house, I do try to sort this out for folks because I really like the new grub.

Something needs to change here or we are going to drive a lot of good folks somewhere else.

[bcbc (bcbc)]

Here are a few from the last week that I've personally been involved with.

http://ubuntuforums.org/showthread.php?t=1494021
http://ubuntuforums.org/showthread.php?t=1491780
http://ubuntuforums.org/showthread.php?t=1492209
http://ubuntuforums.org/showthread.php?t=1490763
http://ubuntuforums.org/showthread.php?t=1490399
http://ubuntuforums.org/showthread.php?t=1490469
http://ubuntuforums.org/showthread.php?t=1486718

[bcbc (bcbc)]

A search of ubuntuforums.org with the following search string: "Boot sector info: Grub 2 is installed in the boot sector" (quotes included) returned 154 results.

[Erick Brunzell (lbsolost)]

I know I'd mentioned previously how updates that triggered reconfiguration of grub 2 in Squeeze follows the safer and saner behavior of displaying only drives rather than drives and partitions, but I recently did a reinstall of Karmic and it does likewise. So this only effects Lucid, and having followed it's development from day one I'd swear this behavior changed only towards the end of the Lucid development cycle.

How critical is this bug? Well, to quote Arpanaut on the forums:

"We want them to throw windows out of their PC's
Not their PC's out the window."

This effects anyone and everyone who is not familiar with Linux device designations, and it's extremely critical for Windows users. I'd guess about 2% of Windows users effected by this have been unable to recover from this without having to reinstall.

[Darko Dimitrovski (darkodimitrovski)]

Let me add my humble opinion.

1. This confusing matter is definitely turning people away from ubuntu. I also think the user should have some knowledge to make a difference between a partition and a disk, or where grub2 is installed at all, but we simply can not blame only the user. You simply can not offer a list of all disks and partitions, and add to it "if in doubt select all". Period...

2. The more important thing, and I think this deserves URGENT BUG REPORT ON ITS OWN, IMMEDIATELY!!!! Have you noticed that if you do this upgrade in wubi, it will actually write to the real hdd MBR and partitions???

I am relatively new to ubuntu and I don't know the correct terminology, but: wubi is sort of virtual install of ubuntu inside windows. It places a file and everything is inside that file, allowing the user not to partition before installing and keeping his partitions safe. That was the point if I understand it, right?

Well, has anyone noticed that this upgrade in wubi is writing grub2 to the hdd MBR and the partitions (depending which boxes you select when it asks you where to install grub2)? And, while selecting wrongly all partitions in a dual boot allows you to at least continue booting ubuntu, because only booting windows will suffer, with wubi you are almost certain to lose booting capability completely. Because grub2 was never on the MBR, windows bootloader is there. So even if you select grub2 to be installed only to the MBR, it will write to the real MBR of the disk, not to the virtual one.

How did you allow a virtual system to write on the real partitions? For example, if you have a test OS in Virtual Box, you expect it to stay there, right? And even if you trash it completely, who cares. Now imagine your test OS writing and messing up your real partitions, not only the virtual hdd. What is that if not complete disaster???

Anyone familiar with meierfra's boot info script will notice it right away, others may need to look little closer. Take a look at the results in post #13 here: http://ubuntuforums.org/showthread.php?t=1500321&page=2

The user never had a full dual boot, only wubi installed inside windows. After upgrading the wubi to 10.04 and unfortunately selecting all boxes when asked what to do, the MBR and all partitions ended up with grub2, regardless that wubi should be virtual only. Thus, the computer is completely unbootable because it was using windows bootloader on the MBR to boot, with an ubuntu entry in it. And even if the user had selected only /dev/sda when asked, that would still mess up everything because it would overwrite the windows bootloader with a grub2 install which has no /boot/grub files to turn to, because full ubuntu is not even installed on the machine.

[Jan Claeys (janc)]

@Darko: Wubi is not a virtual system but a real dual boot system, the only difference being that Ubuntu is installed and runs from a disk image file located on your Windows disk. That said, people shouldn't be presented with such an easy way to break their system.

[Erick Brunzell (lbsolost)]

@ Jan Claeys,

Please tell me that your address means you might be able to get someone to focus on this nasty, nasty bug!

While I think my description is more appropriate this is a duplicate of:

https://bugs.launchpad.net/ubuntu/+source/grub2/+bug/571893

And more! But more importantly perhaps this is partly my fault! I consider myself a devoted "early tester", I think I'm reliable with iso-testing (as Lance) and I like to think I help in some minor way to shape the future of Ubuntu.

That said, I blew it! When I first noticed this behavior I tried to duplicate and just didn't "get it"! After the release of Lucid and seeing the ongoing problem I finally woke up and asked myself, "did I understand the drive and partition designations in Linux when I started"?

Of course the answer is no.

I'll be glad to test any potential remedies to this bug. Let's squash it fast!

[Darko Dimitrovski (darkodimitrovski)]

Latest example:
http://ubuntuforums.org/showthread.php?t=1504665

The user did nothing wrong, but having wubi and grub2 overwriting his /dev/sdc there was nothing to do. Sorry if this is not the proper place, maybe this needs to be separate bug report for wubi.

[Nicolò Chieffo (yelo3)]

I don't think it's only about wubi. I'm not using wubi but grub2 still suggests to install on all devices (so it would override my windows bootloader)

[Erick Brunzell (lbsolost)]

@ Darko D,

I guess I should try a Wubi test on my own to be sure (I'd have to dig out an old Win puter), but from what I've seen on the forums even Wubi updates result in the suggestion to "install grub everywhere". Of course in this case grub should be installed nowhere because, if as advertised, Wubi should run inside Windows and if someone wishes to remove it they should be able to do so without even recovering the Win MBR!

My real problem is that we can't get any dev activity on this at all!!!!!!!!!

This is IMO the worst bug I've seen in Ubuntu since I began about 2 1/2 years ago!!!!!!!

Hardly a day goes by that we don't see this even though Lucid was released weeks ago, and there's always an uptick during the weekends!!!!!!!!!!!!!!!!!

This is just plain STUPID, we've turned the upgrade (and even update) process into a freakin' nightmare!!!!!!!!!!!!!!

I feel I've done everything humanly possible to gain some attention but, for the first time, I honestly feel like the Ubuntu development and "bug-fixing" process is totally BROKEN!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

Sadly, other than this, grub 2 has improved one heck of a lot.

Why can't we get this fixed???????????????????????????????????????????????????????????????????????

I even fumed at Ayatana, come on devs!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

We're in dire straits here!

[Darko Dimitrovski (darkodimitrovski)]

It's very easy to see the impact. Anyone interested needs only to visit the forum website, and search for threads "Ubuntu upgrade destroyed my windows".
Yes, that's the publicity that ubuntu is getting. That it's destroying windows. If that's fine for the ubuntu team Erick, who am I to complain??? :(

[Darko Dimitrovski (darkodimitrovski)]

PS. By the way I am still trying to help the person in the mentioned above thread to get XP working again. He thinks he lost XP completely together with all of his important files. The first repair attempts were unsuccessful.
But I guess nobody cares about that too.

[Erick Brunzell (lbsolost)]

@ Darko D,

For about 10 to 12 days I've suffered random DSL outages. Only today I was able to get "the right guy" on the phone, and they identified it as their problem. So I have someone from AT&T coming tomorrow to try and fix this.

Hopefully once my DSL is restored I can spend a bit more time and try to help with these, but I've said previously that I know about 2% of those effected are unable to recover without totally reinstalling Windows! That's probably a conservative estimate!

Great advertising, duh!!!!!!!!!!!!!!!!!!!!!!!

Lot's of folks saying, "I tried Ubuntu once and after the first grub update it destroyed my Windows"!

Stupidest thing I've seen in 2 1/2 years!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

[Takkat (takkat-nebuk)]

@Erick: sadly, this report is getting more and more off-topic. I doubt any dev will find the time to go through all of this. The overall relevance of this "bug" is also questionable as almost exclusively people are affected that work for at least months on Ubuntu and are very happy with it.

Again, I 'd like to point out that this is neither a bug in grub2 nor in the installer but rather in the way inexperienced users are misled by insufficient help during the grub installation process. The installer simply does what you tell it - so what's buggy about this? Sure it would be nice to not have to tell it anything at all but this may lead to problems in non-standard environments where at least Ubuntu must always be bootable after an upgrade.

Those Users that are unable to restore the Windows boot record are to my experience most likely affected by a bug in the Windows repair tools that in rare instances are unable to correctly restore a single byte in the affected boot sector.

I do agree however that the issue is there and needs some urgent action. We still see many people every day that are affected and need help from the support forums.

As any constructive ideas are missing here I'd like to point again on my suggestion made earlier in bug #571893: Please change the help text from the grub installer so that it really helps the inexperienced and warns from possible side-effects. I do believe this would be sufficient for now. And, at least the issue should be mentioned in the release or upgrade notes.

[Nicolò Chieffo (yelo3)]

The installer should suggest to install grub only in those places:
- the current root partition
- the MBR, but if and ONLY if during the latest configure grub was
installed to it

I can't find why grub should suggest to be installed to other partitions too.

[Erick Brunzell (lbsolost)]

"As any constructive ideas are missing here", huh?????????????????????

In my initial post I say:

"Consider the following options:

#1: Display nothing but drives, that is "sda", "sdb", etc, and NO individual partitions. But create another "advanced" tab/option to allow installation to a partition.

#2: Increase the amount of text explaining the difference between drives and partitions, why it's a bad idea to install to a partition etc. IMHO that's a horrible option. (The more text the less likely a new user is to read it.)

#3: Figure out a way to always have grub(2) install itself where it was to begin with. (maybe a bad idea if the original install was wrong.)

While I think option #1 is great I have no idea how complicated that would be."

Also this has absolutely nothing to do with the "installer".

This occurs during distribution upgrades and I assume even grub 2 package updates in Lucid.

The behavior is much safer and saner in both Karmic and Squeeze as it displays only drive designations as install points rather than including partition designations.

Whether this is a function of the grub-pc package or not I'm unsure.

[Takkat (takkat-nebuk)]

@Erick: Sorry if my point has been misinterpreted. Of course I did not overlook your constructive and very precious ideas in the initial post. I should have written 'further' ideas instead of 'any', sorry for that. However from then on the postings basically come down to me toos and complaints with only minor discussions on the solutions you suggested.

Still IMHO, your idea #2 is sure not the best but the the easiest and safest way for a quick solution. Maybe not even the amount of text needs to increased. What about: "It is recommeded to install Grub2 to the MBR (e.g. /sda) of the disk where Ubuntu resides. Installing Grub to partitons (e.g. /sda1) is usually not a good idea as it may lead to problems booting other operating systems in a multi-boot environment"

@Nicolò: Sure, your suggestion is exactly what we expect how it should be handled. However, I'm not shure how fast this could be implemented as it needs changes to the code with further testing needed.

[bcbc (bcbc)]

@Takkat - I agree, let's change the help text... but let's get it done quickly: we are still seeing people affected by this on a daily basis.

And no, it's not just inexperienced users. I've seen long-term ubuntu users upgrading from 8.04 get hit by this. To be more precise it's users that don't need to know about where to install grub2 (maybe they've only ever used grub) and getting confused by the help text. Many figure out right away that that was where they went wrong, but by then, the damage is done.

Regarding long term changes, I notice if you run "grub-install /dev/sda1" you get an error and it tells you to use --force. I think a long term fix would (at the least) have an additional confirmation solely for partition installs with a dire warning (similar to requiring a --force, but obviously this it is not possible during an upgrade/new install).

[oldfred (oldfred)]

Part of the problem is windows refers to drives when they really are partitions. In windows you have a C: drive and a D: drive when you only have one hard drive and two partitions. All those windows users that then have not installed Ubuntu other than the auto installer really do not know about partitions. So when the grub installer says to install to all drives the average windows user thinks that has to include everything. Then list list presented does not clearly list drives separate from partitions. If you have a lot of partitions it becomes a very long list.
The average user see this and will check off everything because they were told to install to all drives;
[ ] /dev/sda 640135MB,WDC_WD6400AAKS-00A7B0)
[ ] - /dev/sda1 (13209 MB)
[ ] - /dev/sda10 (41948 MB)
[ ] - /dev/sda11 (10988 MB)
[ ] - /dev/sda12 (48002 MB)
[ ] - /dev/sda3 (429877 MB)
[ ] - /dev/sda4 (0 MB)
[ ] - /dev/sda5 (13152 MB)
[ ] - /dev/sda6 (11531 MB)
[ ] - /dev/sda7 (10001 MB)
[ ] - /dev/sda8 (50420 MB)
[ ] - /dev/sda9 (10997 MB)
[ ] /dev/sdb (160041 MB, ST3160811AS)
[ ] - /dev/sdb1 (75039MB)
[ ] - /dev/sdb2 (55002MB)
[ ] - /dev/sdb3 (10997 MB)
[ ] - /dev/sdb4 (19000 MB)

[Darko Dimitrovski (darkodimitrovski)]

@Takkat
That´s exactly the point: making it better and trouble free for non-experienced users. This is about making ubuntu easy to use and accepted by them.
If we start thinking that the user should know what is a disk, what a partition and what to select, going by the same logic should we drop the guided methods in the installer too? You should know how to partition, right? Why not leave only manual partitioning option.

Instead of making it easier for the non-experienced users you are worried about "this may lead to problems in non-standard environments"??? Excuse me, but ANYONE able to create non-standard environment is probably able to use any ubuntu cd, super grub, system rescue cd, or what ever and get the system online.

Besides, why not hide advanced options under a button "Advanced Options for Advanced Users". Lets worry about the non-experienced users first, the others will find their way.

And the fact that doing the upgrade in a wubi install makes grub2 install to your MBR or/and partitions has at least some elements of a bug, right? You don´t use grub2 in wubi. Everything the upgrade process does should be within the root.disk file, never on your disk MBR or partitions.

[Erick Brunzell (lbsolost)]

To me the easiest short term fix would be to revert to the Karmic "behavior" which displayed only the drive designations. Since this effects only updates/upgrades that shouldn't be too difficult since those updates must (I assume) come from a Canonical server. One exception might be upgrading using an Alternate CD but I've never used that method to upgrade so I can't be sure.

That does not mean reverting to the Karmic "package" but only the behavior of displaying only drive designations rather than drive and partition designations. It's seldom wise to install grub 2 to a partition anyway and, since that option is rarely wise, it should be difficult (but not impossible) to accomplish.

So there are great suggestions for "long term" redesigning in the long term, given the number of people selecting all designations displayed, this really needs to be addressed in a short term manner to quell the number of update/upgrade failures.

Regardless, nothing we say makes any difference if we can't get a dev to look at this. I feel I've tried everything I can other than buying airfare and dancing naked in the street in front of Canonical headquarters ;^)

I subscribed Colin Watson to the thread and I posted this at Ayatana:

http://<email address hidden>/msg02554.html

I even cc'ed SABDFL :^/

And most recently I posted this at Maverick testing:

http://ubuntuforums.org/showthread.php?t=1504847

I don't know what else to do and, while I recognize my overuse of exclamation and question marks in a recent post as immature, I'm just frustrated.

Certainly the easiest thing would be for me unsubscribe myself from this bug report and let someone else worry about it but that's not in my nature.

Due to poor visual acuity I've found IRC to be too difficult for me, could someone else try to draw some devs to this through IRC?

[Erick Brunzell (lbsolost)]

Stepping outside the bounds once again I decided to subscribe Steve Langasek to this bug out of true desperation.

Please Steve can you give us some guidance in getting this fixed?

I know you're busy and I wouldn't do this if I felt it was not urgent.

[Takkat (takkat-nebuk)]

@Darko:

> "this may lead to problems in non-standard environments"??? Excuse me, but ANYONE able to create non-standard environment is probably able to use any ubuntu cd, super grub, system rescue cd, or what ever and get the system online.

There are easy to handle bootloaders other than GRUB2 around that we need to take care of during an update. Under no circumstance these should be overwritten thus making automatic installation procedures difficult. The upgrade as it is now is very comfortable in this respect.

However for a long-term solution I vote for Erick's idea #3, i.e. leaving Grub where it is during an update. This may need two different operation modes of the installer, one for updates only, and one for fresh installs (or repair).

[bcbc (bcbc)]

Quote from bug #1
"2. Ubuntu should be marketed in a way such that its amazing features and benefits would be apparent and known by all.
3. The system shall become more and more user friendly as time passes."

Quote from http://ubuntuforums.org/showthread.php?t=1505663
"Lessons I've learned:
1. Avoid dual-boot machines. I liked Linux just fine, but would only return to it if I could dedicate a machine to it.
2. If you must use a dual boot machine, avoid upgrading GRUB if your current version is working just fine."

Is it just me, or are the developers not on the same page as Mr. Shuttleworth? Or is this an ego thing that no-one will fix it?

It is a bug - really it is. Please don't hide behind "MS calls partition drives" or other such stuff. If I wrote a piece of code that caused 200+ users to break their Windows, I'd be pretty embarrassed - regardless of how smart I figured the users were. In fact, that's EVEN MORE reason to fix this. You always have to address the lowest common denominator.

In fact I'd expect to be fired or resign on my own and take up stamp collecting instead. haha.

Fix please.... (this is my last post on the matter). yawn

[Steve Langasek (vorlon)]

Hi Erick,

I agree that this is an important problem to resolve, and am marking it as such. However, I don't think I'm in a position to work on this directly, Colin has a much better understanding of the grub2 packages than I do - so we're still dependent on his availability in order to resolve this.

Looking at the maintainer script and debconf template, there are two issues that I see:

- AFAICS, the question is always asked at high priority on upgrade, regardless of whether a sensible answer has been successfully autoprobed (a missing 'break' statement?)
- As pointed out here, the debconf question as worded doesn't make it very clear to novice users what precisely they should do if they're uncertain.

Both of these seem like things we can and should fix for .1.

[Erick Brunzell (lbsolost)]

@ Steve Langasek,

Is there at least some way we could almost immediately amend the upgrade section of the Lucid release notes?

I've also wondered if everyone shouldn't be presented with the option/suggestion to read the release notes when they choose to download Ubuntu from Canonical, but that's something I should perhaps bring up at Ayatana.

Thank you for at least responding.

I've also suggested at the forums we should create "upgrade-testing" similar to how we do iso-testing:

http://ubuntuforums.org/showthread.php?p=9438347#post9438347

I think you'd agree that distro-upgrades are just as critical to Ubuntu's success as iso-testing. I know I'd be perfectly willing to install a previous release and look for bugs during the upgrade.

In this case I actually did so but failed to recognize the problem. As I said earlier, I forgot to think what I'd have understood 2 1/2 years ago :^(

Thanks again.

[Erick Brunzell (lbsolost)]

@ Steve Langasek,

I noticed in Maverick that upgrades of the packages "grub-common" and "grub-pc" on both the 21st and 23rd resulted in Maverick's grub 2 "grabbing" the mbr of /dev/sda with no user interaction whatsoever.

To be a bit more specific I multi-boot and currently I have Karmic's grub 2 in charge of booting, but the aforementioned package upgrades automatically resulted in Maverick's grub 2 installing to the mbr of /dev/sda.

I don't currently have Windows installed so I can't see what would happen if, for instance, I had a Windows mbr on /dev/sda and grub 2 on /dev/sdb. Does grub 2 now just automatically install to /dev/sda always?

As I think about this there is testing I can do such as installing lilo or legacy grub to various mbrs and then trying some test installs followed by updating the aforementioned packages.

Or maybe the grub 2 devs could briefly explain the new behavior?

I did start a thread at the forums to hopefully gather more info:

http://ubuntuforums.org/showthread.php?t=1516153

I realize this is a different issue (totally different behavior) so if this is a bug (and it may not be) I anticipate the possible need for a new bug report.

My time is seriously limited ATM but I will try my best to set aside whatever time is needed to address this issue. I'd think it's far from critical since Maverick is still in early alpha testing.

[Colin Watson (cjwatson)]

To gather more information:

  debconf-show grub-pc

[Erick Brunzell (lbsolost)]

I'm glad I hadn't rebooted or changed anything yet ;^)

It's short so just using text:

 grub-pc/kopt_extracted: false
  grub2/kfreebsd_cmdline:
* grub-pc/install_devices: /dev/disk/by-id/ata-WDC_WD5000AAKS-00V1A0_WD-WCAWF1406318
  grub-pc/postrm_purge_boot_grub: false
  grub-pc/disk_description:
* grub2/linux_cmdline:
  grub-pc/install_devices_empty: false
  grub2/kfreebsd_cmdline_default: quiet
  grub-pc/partition_description:
  grub-pc/install_devices_failed: false
  grub-pc/install_devices_disks_changed:
* grub2/linux_cmdline_default: quiet splash
  grub-pc/chainload_from_menu.lst: true
  grub-pc/hidden_timeout: false
  grub-pc/timeout: 60

To better understand my layout you might find this attachment useful.

My sdb drive is always "fluid" as I use it for testing, but I've been using Karmic's grub 2 on sda2 to boot for some time.

[Colin Watson (cjwatson)]

There's been a lot of discussion on this bug, and I confess with apologies that I haven't had enough time to read it all. However, I entirely agree with Erick's original point and I intend to figure out a way to rework this set of dialogs, since it obviously isn't working in its current state. The reason why I haven't dealt with it until now is essentially that I've been buried trying to get grub2 into a decent state for Maverick, but I'm finally getting around to looking at the upgrade issues. There's no need to shout, scream, talk about how people should resign, etc., as some people have been doing in this bug log; that sort of thing is entirely unproductive. Still, I realise that it's frustrating when developers fail to respond to well-formed bug reports, so I'll try to keep up at least with this one a bit better.

I feel I should give a few explanations to address particular questions people have raised:

1) While it would be nice to simply revert to Karmic's presentation, as it was undeniably much simpler, it just wasn't meeting everyone's needs. The GRUB 2 development team, including myself, strongly believe that people should be encouraged to install GRUB to disk devices where possible, and that's the only mode Karmic supported. However, lots of people find it necessary or preferable to install to partition devices instead, whether for interoperability with certain pieces of third-party Windows software, or because they have a heavily customised boot loader already in their MBR, or various other reasons. GRUB 2's design means that running grub-install on the wrong device on upgrade can lead to an unbootable system, and so we cannot simply ignore these use cases; we have to accommodate them.

2) The reason why this dialog sometimes appears on upgrade even though you've already answered its questions beforehand is not just because I enjoy asking users useless questions. :-) The GRUB 2 packaging tries very hard to avoid asking questions when it already knows the answer. Unfortunately, sometimes it simply doesn't know. There are two common reasons for this. Firstly, Karmic stored the answer to that question in a suboptimal way: it stored strings such as "/dev/sda", which may well refer to a different disk from boot to boot! On a multiple-disk system, on upgrade from Karmic, it's entirely possible that the GRUB 2 packaging simply doesn't have the previous answer in a form which is at all reliable. Of course we try to deal with the common cases: if you only have one disk then the answer is obvious - but there are situations where we just have to ask again. From now on the answer is being stored in a more reliable way. Secondly, if some of the disks you installed to don't exist any more (this might happen, for instance, if you simply selected all disks but one of them was a removable USB drive), then we ask again since the correct answer isn't obvious.

In any case, I think a rework of this dialog will be sufficient to address the most pressing concerns here. I rather like part of Nicolò Chieffo's suggestion in comment 38, although I'd modify it a bit: offer disk devices and the partition holding /boot. That seems much more s...

[Colin Watson (cjwatson)]

Also, I believe there are separate bugs about the problems with Wubi, and I would like to keep that separate. (This is not me declaring that I don't plan to fix that, or anything - it's just easier if lots of problems aren't bundled into the one bug report.)

[Colin Watson (cjwatson)]

Update from a conversation on #grub:

<cjwatson> Jordan_U: oh, BTW, regarding that debconf dialog that confuses so many people: what I have in my working tree right now is a rearrangement that offers all the disk devices, and only the partition device containing /boot
<cjwatson> Jordan_U: does that sound reasonable to you?
<Jordan_U> cjwatson: Yes, the only possible issue being people that only install to the partition and so things get out of sync. It seems like most of the people who were messing up were either not reading at all and choosing nothing (fixed) and reading poorly and selecting everything (harmless with proposed change).
<cjwatson> Jordan_U: the worst bit seems to have been people trying to install to NTFS partitions, so that should certainly go away
<cjwatson> Jordan_U: I thought about an Advanced option, but since I can't think of a good reason for people to install other than to the partition containing /boot (actually /boot/grub), there doesn't seem a need for it
<cjwatson> (and Advanced is awkward to cram in there for various reasons, so best avoided if possible)
<cjwatson> Jordan_U: hm, maybe if /boot and / are separate then I should offer / as well, just in case
<cjwatson> I want to minimise the number of people who scream at me for breaking their special configuration
<Jordan_U> cjwatson: Maybe it should warn if grub is only installed to a partition and not to any MBR. That way you have to be really stubborn to do something wrong, but there's no extra cruft for sane (and partially sane) configurations.
<cjwatson> Jordan_U: as well as the warning in the text accompanying the menu?
<Jordan_U> cjwatson: Yes.
<cjwatson> Jordan_U: I can probably live with that. Thanks for the suggestion, I'll have a look
<cjwatson> Jordan_U: (though I don't want to encourage people to install to a partition *and* to an MBR!)
<Jordan_U> cjwatson: What harm does it cause?
<cjwatson> Confusion.
<cjwatson> e.g. you try to debug something and run 'grub-install /dev/sda5' because you think grub is there, only to find out that you were actually booting from /dev/sda all along
<cjwatson> perhaps I'm being over-paranoid

I'm not sure about the install-to-partition warning yet, but the idea is not without merit, so I'll ponder it. If I implement such a warning, I would have to be careful to avoid requiring extra work for preseeded deployments.

[Colin Watson (cjwatson)]

I slept on the problem. I think for the time being I shan't add a warning when installing only to a partition, and I'll just keep things simple. We'll see how it goes, and if there's still substantial confusion evident from user reports then we can revisit this.

The current dialog looks something like this. Please note that I've manually hacked it to include a couple of extra filesystems on my system, for the purposes of testing; /mnt and /media/mybook won't be offered in the finished product.

  The grub-pc package is being upgraded. This menu allows you to select
  which devices you'd like grub-install to be automatically run for, if
  any.

  It is recommended that you do this in most situations, to prevent the
  installed GRUB from getting out of sync with other components such as
  grub.cfg or with newer Linux images it will have to load.

  If you're unsure which drive is designated as boot drive by your BIOS,
  it is often a good idea to install GRUB to all of them.

  Note: It is possible to install GRUB to partition boot records as
  well, and some appropriate partitions are offered here. However, this
  forces GRUB to use the blocklist mechanism, which makes it less
  reliable, and therefore is not recommended.

  GRUB install devices:

    [*] /dev/sda (80026 MB, FUJITSU_MHW2080BJ_G2)
    [ ] - /dev/sda5 (50001 MB, /)
    [ ] - /dev/sda7 (5346 MB, /mnt)
    [ ] /dev/sdb (1000204 MB, My_Book_AV_1020)
    [ ] - /dev/sdb1 (1000203 MB, /media/mybook)

  <Ok>

There may still be some confusion, but at least now if somebody selects all the checkboxes then it's unlikely to be harmful. People with specialised boot loaders that they need to avoid overwriting will likely understand the terminology well enough to be able to select something appropriate.

[bcbc (bcbc)]

Colin Watson wrote: "There's no need to shout, scream, talk about how people should resign, etc., as some people have been doing in this bug log; that sort of thing is entirely unproductive."

Agreed, but in my defence, it seemed no one was listening. Meierfra's bootsector web page fix has been accessed over 26,000 times, so that speaks to the number of people affected by this. In my opinion, this would be a higher priority than maverick.

I'll go back to my hole now.

[Takkat (takkat-nebuk)]

@Colin Watson:

As long as partitions that don't make sense (e.g. NTFS) will not appear in the list of suggested places where to install GRUB your above procedure is to my opinion safe and will avoid most of the problems we had. The new help text is much better.

Thank you for this.

[Colin Watson (cjwatson)]

The installer forbids / and /boot from residing on FAT or NTFS, so that
should indeed be enough.

[Erick Brunzell (lbsolost)]

@ Colin Watson,

This looks good to me. Just so you know, I'm not intentionally ignoring this, I'm simply buried in nightmarish completely unrelated "non-computer" issues (remodeling) :^/

But I should have time to do the SRU testing for this and #580408 very soon (hopefully within 48 hours). Although I'm just a little unclear what exactly to do, sorry :^(

To recap, in this thread you say, "The simplest way to force this confusing screen to appear is by running 'sudo dpkg-reconfigure grub-pc'. The broken state is that all partitions are offered, including Windows partitions which will be broken by installing GRUB to them; the desired state is described in comment 56."

I do understand the command, but is it or is it not necessary to apply any patch first? If yes I'm a bit unclear how to apply the patch. I'm thinking it's applied on the Ubuntu server end but I'm just not sure.

Over at #580408 you say, "Install Karmic on a two-disk system, run 'echo SET grub-pc/install_devices /dev/sda | sudo debconf-communicate' to arrange for initial conditions that trigger this bug, then upgrade to Lucid. The first time round the loop, uncheck all the boxes, and then answer "No" to "Continue without installing GRUB"; it should ask you the same question with a list of checkboxes again, and should have left all of them unchecked. Also try an upgrade from Lucid as released to this update on the same system, running 'echo SET grub-pc/install_devices /dev/hda | sudo debconf-communicate' before starting the upgrade; this should give you a dialog reading "The GRUB boot loader was previously installed to a disk that is no longer present ...", and again if you uncheck all the boxes you should get consistent behaviour the second time round the loop. You may be able to save time by testing this together with bug 576724."

Now my head's kind of spinning ;^)

I do understand the commands, and I have no problem with using a two disk system, but would you prefer I use a two disk system with Windows on one disk? Maybe with a Win MBR on one disc and a grub 2 MBR on the other? Or does that even matter?

And once again, do I need to manually apply any patch first?

And regarding that latter command, "'echo SET grub-pc/install_devices /dev/hda | sudo debconf-communicate', should the "/dev/hda" not be "/dev/sda" for Ubuntu? Sorry to be a pain, I just want to be sure.

The system I'm using now is described in that RESULTS4.txt.tar.gz in post #52 but I have another in the closet that has Win XP on one drive and I can easily hook it up, I've just been waiting until this nightmarish remodel is over but I don't mind spending a little time to help you. After all, you're helping us a lot!

Basically I'm just an end user with very limited technical skills and I want to be certain to test these two bugs fixes in the manner that will be most useful to you, so if you have the time in the next couple of days I'd appreciate a simplified "dummies guide" to testing these for SRU.

I do have one more "dumb" question. I've generally avoided using a separate "/boot" partition unless absolutely necessary to deal with BIOS partition size limits so I know little about such layouts. So this from...

[Colin Watson (cjwatson)]

On Thu, Jul 01, 2010 at 03:18:03AM -0000, Erick Brunzell wrote:
> But I should have time to do the SRU testing for this and #580408 very
> soon (hopefully within 48 hours). Although I'm just a little unclear
> what exactly to do, sorry :^(

Note that my proposed upload hasn't yet been accepted or built. I'll
nudge another member of the SRU team about it in a bit, but we're quite
busy with Maverick Alpha 2 right now which is due today.

> To recap, in this thread you say, "The simplest way to force this
> confusing screen to appear is by running 'sudo dpkg-reconfigure grub-
> pc'. The broken state is that all partitions are offered, including
> Windows partitions which will be broken by installing GRUB to them; the
> desired state is described in comment 56."
>
> I do understand the command, but is it or is it not necessary to apply
> any patch first? If yes I'm a bit unclear how to apply the patch. I'm
> thinking it's applied on the Ubuntu server end but I'm just not sure.

I normally phrase the test case as "if you run this without the update,
it should fail; if you run this with the update, it should succeed", so
that if necessary a previously uninvolved observer can come in and
verify the fix. This is because it does no good to verify that you
don't see a bug with an update unless you also verify that you did see
the same bug without the update.

Once my upload is accepted, there'll be a message sent to this bug with
instructions on where to get the proposed fix; it will be built on our
servers.

> I do understand the commands, and I have no problem with using a two
> disk system, but would you prefer I use a two disk system with Windows
> on one disk? Maybe with a Win MBR on one disc and a grub 2 MBR on the
> other? Or does that even matter?

It doesn't matter what MBRs are present. Some partitions other than
Ubuntu should be present, although it doesn't matter what they are;
Windows is as good as any. It doesn't matter which operating system is
on which disk - I just need it to be a two-disk system because otherwise
you trigger some special cases in the grub2 packaging and it becomes
harder to reproduce this bug.

I was actually imagining that a tester would probably use a throwaway
virtual machine, but if somebody wants to use a real system then that's
even better.

> And once again, do I need to manually apply any patch first?

The way proposed updates work is that they're made available in
"lucid-proposed" until they've been verified, so it's possible to vary
what apt-get will install by adding or removing appropriate lines from
/etc/apt/sources.list and running 'sudo apt-get update'. Once my
proposed fix is published, turning on lucid-proposed and upgrading
grub-pc will pull it in. Full instructions are here:

  https://wiki.ubuntu.com/Testing/EnableProposed

> And regarding that latter command, "'echo SET grub-pc/install_devices
> /dev/hda | sudo debconf-communicate', should the "/dev/hda" not be
> "/dev/sda" for Ubuntu? Sorry to be a pain, I just want to be sure.

No - I deliberately made that "wrong" in order to trigger a certain
special case. ("/dev/ohdearnosuchdevice" would work just as well, so
maybe I should have been ...

[Ype Stisk (ypestis)]

After an Wubi installed Karmic 9.10 completely updated shared on 1 hd with windows xp I upgrade to Lucid just yesterday.
I just answered yes to all the grub updates and after this I can't boot Linux anymore, I get a Grub prompt.
If anyone can help me out to fix it here is my thread: http://ubuntuforums.org/showthread.php?t=1521340
Thanks alot!

[Colin Watson (cjwatson)]

Ype: your problem isn't related to this bug, so it would be best not to
try to handle it in this comment thread - we need to keep bugs focused
on a single problem, really.

[Launchpad Janitor (janitor)]

This bug was fixed in the package grub2 - 1.98+20100614-2ubuntu4

---------------
grub2 (1.98+20100614-2ubuntu4) maverick; urgency=low

  * Rearrange postinst install_devices logic so that preparatory code is run
    only once and the while loop only encloses actual asking of questions,
    and so that the question being asked is always marked for redisplay when
    going round the while loop again (LP: #580408).
  * Only offer partitions containing /, /boot, or /boot/grub for
    grub-install; installing to other partitions may have harmful effects
    such as making Windows unbootable, and installing GRUB to every single
    partition is likely to result in confusion anyway (LP: #576724).
 -- Colin Watson <email address hidden> Thu, 01 Jul 2010 18:26:37 +0100

[Martin Pitt (pitti)]

Accepted grub2 into lucid-proposed, the package will build now and be available in a few hours. Please test and give feedback here. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Thank you in advance!

[dino99 (9d9)]

Hi Martin,

i'm installing this update now and see that the debconf dialog box is still so confusing:

the text is : Continue without installing GRUB ? (with the non selected checkbox)

how people can understand that ?
Looking at "help" even dont answer this question: may i check or not to install.
 Instead of this meaningless question, why not giving a clear choice:

- install grub-pc: check this box

note: the "help" text dont tell if the already installed grub-pc (before update) is removed or not

[dino99 (9d9)]

anyway there is only one choice as this checkbox need to be checked to goes on, so this question has no meaning at all (an other bug)

[dino99 (9d9)]

i've opened bug 600933

[Erick Brunzell (lbsolost)]

I like the way this looks in Maverick after running "dpkg-reconfigure grub-pc". It displayed only /dev/sda, /dev/sda1 (which is Mavericks / partition), and /dev/sdb. None were selected, which is correct since I'm using my Karmic's grub 2 to boot. All worked well.

I'll start an installation of Karmic to thoroughly test #580408 before leaving my desk this AM and hopefully this evening I'll be able to complete testing the Karmic proposed packages.

[Erick Brunzell (lbsolost)]

Just an update on where I'm at with this. I'm still several hours away from the "prescribed test cases" but while taking a break I booted into my installed "stable" Lucid and installed the proposed updates. All went well.

I was first presented with the common options regarding "command line" and "boot parameters", and I accepted the defaults. Next I was presented with whether to keep my modified config and the default was "keep local version". I chose to compare and things looked as they should, that is the dialog was clear. I'd forgotten some of the modifications I'd made until seeing that :^)

Since I'm testing I went for the "maintainers version" and all went well. Things rebooted as they should, that is boot was still handled by my Karmic install. I next booted back into Lucid and ran "dpkg-reconfigure grub-pc" and things appeared as they should.

I will still follow the whole test case scenario described in bug #580408 to be very, very sure but so far this is looking very good to me.

[Erick Brunzell (lbsolost)]

Just following up here, I'm sure you saw my comment #5 in bug #580408 which also applies here.

I had encountered one problem that I suspected was unrelated to these proposed updates, and I still believe it's unrelated. When performing the initial test described in comment #70 above I was asleep at the wheel and installed all proposed updates:

app-install-data-partner (12.10.04) to 12.10.04.3
dpkg (1.15.5.6ubuntu4) to 1.15.5.6ubuntu4.1
empathy (2.30.1.1-0ubuntu1) to 2.30.2-0ubuntu1
empathy-common (2.30.1.1-0ubuntu1) to 2.30.2-0ubuntu1
grub-common (1.98-1ubuntu6) to 1.98-1ubuntu7
grub-pc (1.98-1ubuntu6) to 1.98-1ubuntu7
libatk1.0-0 (1.30.0-0ubuntu2) to 1.30.0-0ubuntu2.1
libatk1.0-data (1.30.0-0ubuntu2) to 1.30.0-0ubuntu2.1
libdbusmenu-glib1 (0.2.9-0ubuntu3) to 0.2.9-0ubuntu3.1
libdbusmenu-gtk1 (0.2.9-0ubuntu3) to 0.2.9-0ubuntu3.1
nautilus-sendto-empathy (2.30.1.1-0ubuntu1) to 2.30.2-0ubuntu1
update-manager (1:0.134.9) to 1:0.134.10
update-manager-core (1:0.134.9) to 1:0.134.10

Following that I encountered bug #529338, but I was wide awake when I performed the test outlined in comment #5 in bug #580408 and I made certain to only apply the proposed grub-pc and grub-common updates, and the behavior described in bug #529338 was NOT duplicated in that test case!

So, I think it's safe to say that's in no way related to your proposed updates, and possibly not even due to the other proposed updates I unwisely applied in my first test case. I have in fact even painstakingly backed out all of the proposed updates, including these grub updates, and I've not been able to escape that behavior where the Login Keyring fails to unlock (it does so only if I'm using auto-login).

Anyway, even though I suspect this is totally unrelated, I thought you should know :^)

[Erick Brunzell (lbsolost)]

Following up again. I've also encountered bug #529338 in Maverick now, but only the Maverick on /dev/sda1, NOT the one on /dev/sdb6. Odd I know??? Both are updated to your new grub packages.

In Lucid things are similar, I have that bug in the Lucid on /dev/sda3, but NOT the Lucid on /dev/sdb3 that I created/upgraded from Karmic for this test. I've even tried backing out some recent upgrades to gnome-keyring and vinagre with no success.

More applicable to your proposed updates, I even renamed /boot/grub, purged grub-common and grub-pc, then installed "grub" and still had the keyring failure with legacy grub. So I'm very convinced that your proposed updates in no way triggered this behavior.

I just want to provide you with the best possible info :^)

ATM the one commonality is that the problem appears only on the two OS's on my 500GB SATA and not the 80GB IDE so just for fun I'm going to try a fresh Lucid on the 500GB, then check for the problem both before and after applying your updates.

RE: Scarecrow = if I only had a brain ;^/

[Erick Brunzell (lbsolost)]

OK, I'm sure I'm the last person in the world that anyone wants to hear from but here I am :^)

I was wrong about the drive being the only commonality, the other was the file system:

lance@lance-desktop:~$ sudo parted /dev/sda print
Model: ATA WDC WD5000AAKS-0 (scsi)
Disk /dev/sda: 500GB
Sector size (logical/physical): 512B/512B
Partition Table: msdos

Number Start End Size Type File system Flags
 1 32.3kB 21.5GB 21.5GB primary ext3 boot
 2 21.5GB 42.9GB 21.5GB primary ext3
 3 42.9GB 96.2GB 53.3GB primary ext3
 4 236GB 500GB 264GB extended
13 236GB 258GB 22.0GB logical ext4
12 258GB 280GB 21.6GB logical ext3
11 280GB 301GB 21.7GB logical ext3
10 301GB 323GB 21.8GB logical ext3
 5 323GB 378GB 55.1GB logical ext3
 6 378GB 432GB 53.6GB logical ext3
 7 432GB 487GB 54.9GB logical ext3
 8 487GB 498GB 10.7GB logical ext3
 9 498GB 500GB 2517MB logical linux-swap(v1)

lance@lance-desktop:~$ sudo parted /dev/sdb print
Model: ATA WDC WD800JB-00JJ (scsi)
Disk /dev/sdb: 80.0GB
Sector size (logical/physical): 512B/512B
Partition Table: msdos

Number Start End Size Type File system Flags
 1 32.3kB 19.4GB 19.4GB primary ext2
 3 19.4GB 38.8GB 19.4GB primary ext4
 2 38.8GB 80.0GB 41.2GB extended
 6 38.8GB 76.7GB 37.9GB logical ext4
 5 76.7GB 80.0GB 3305MB logical linux-swap(v1)

As you can see I'm still using ext3 with all of my "stable" OS's, but I'd used ext4 with all of my test installs on /dev/sdb. The proposed "grub" upgrades resulted in bug #529338 only on the OS's that used ext3.

I tried a test install of Lucid on /dev/sda13 w/ext4 and can NOT duplicate that behavior, does that make sense?

As a developer can you somewhat easily contact everyone that's encountered bug #529338 about the file system used?

My time is limited right now but I do plan on repeating some of these tests to verify what exactly is going wrong. I think next I'll try an ext3 Lucid install on sdb1 (which is vacant) and see what happens. Then maybe another ............. arrgh, just not sure.

I would not be so aggressive about this if I didn't feel it were necessary to move this great update from "proposed" to "stable" ASAP. The first point release of Lucid is creeping up quickly ;^)

[Colin Watson (cjwatson)]

There seems no reason to believe that bug 529338 is connected to this bug; as you suggest, it seems overwhelmingly likely to be coincidental. I'd suggest continuing investigation on that bug.

Thanks again for your diligent testing; this all seems as expected (notwithstanding dino99's comments, which I've followed up to in his separate bug report), and I'll mark this bug as verification-done.

[Erick Brunzell (lbsolost)]

Sorry Colin, I figured this out just moments ago, and feel like a real dunce.

When I was considering using my other computer (necessitating data transfer) I decided to give ubuntuone a "first look", decided it wouldn't do exactly what I wanted, just used an external drive, etc.

So the entire "keyring" debacle was just me being unfamiliar with ubuntuone's behavior :^(

[Launchpad Janitor (janitor)]

This bug was fixed in the package grub2 - 1.98-1ubuntu7

---------------
grub2 (1.98-1ubuntu7) lucid-proposed; urgency=low

  * Update harmfully incorrect German translation of menu legend, which
    omitted mention of pressing Ctrl-x to boot (LP: #580178).
  * Rearrange postinst install_devices logic so that preparatory code is run
    only once and the while loop only encloses actual asking of questions,
    and so that the question being asked is always marked for redisplay when
    going round the while loop again (LP: #580408).
  * Only offer partitions containing /, /boot, or /boot/grub for
    grub-install; installing to other partitions may have harmful effects
    such as making Windows unbootable, and installing GRUB to every single
    partition is likely to result in confusion anyway (LP: #576724).
 -- Colin Watson <email address hidden> Wed, 30 Jun 2010 14:37:47 +0100

[bcbc (bcbc)]

I have started seeing wubi users overwriting their MBR with grub2 after running the latest updates - probably this patch. It's not clear yet whether they are prompted to select the drive or it's doing it automatically - I am trying to get feedback - but either way this seems to be a continuation of the 'confusion'. Unfortunately many new wubi users don't have a live CD either, but from one bootinfoscript it's grub2 in multiple MBRs all pointing to #256.

In light of this, until this can be confirmed or refuted, I recommend pulling the update, as the consequences will be very unfortunate. I am not saying this is 100% the case, but a cluster of these has shown up recently.

Here are what I have been seeing...
http://ubuntuforums.org/showthread.php?t=1538228
http://ubuntuforums.org/showthread.php?t=1537956
http://ubuntuforums.org/showthread.php?t=1538170
http://ubuntuforums.org/showthread.php?t=1482621 (this is an older thread, but a new user (softis) added to it and has the same issue).

[Erick Brunzell (lbsolost)]

@ bcbc,

I'll break out an old Win XP computer and try a Wubi install followed by these updates. It may take quite a while because my house is in total disarray (remodeling), and I'll want to update XP first which could take quite a while because I think it's been about 6 months since it was last used.

I'd never seen this before, "Grub 2 is installed in the MBR of /dev/sda and looks on the same drive in
partition #256 for /boot/grub." Hopefully I can "see" what the problem is, but I haven't messed with Wubi much.

[bcbc (bcbc)]

Thanks Erick.

I don't have my test computer with me, and I don't want to try it on my netbook (I need it functional for work while I am away) until I can confirm that there is a grub prompt involved. The only feedback I've had couldn't recall selecting any drives, so I am not sure if this runs behind the scenes with the grub-pc update or whether it displays the familiar 'select a drive/partition to install to' prompt.

When testing, you might want to try with the wubi on a different partition than windows. It's a theory of mine, that grub-pc recognizes a wubi install when it finds wubildr in /host/, but when wubi is installed to another partition the wubildr is on the windows partition and not in /host (based on my findings with this bug report: https://bugs.launchpad.net/ubuntu/+source/lupin/+bug/604417).

So that's what I'd be looking at.

[Erick Brunzell (lbsolost)]

I'm NOT progressing well at all!

I just let Wubi do it's "automatic download thing" rather than using a local image or disc. After completing I just get the not so uncommon "unrecoverable error" message while trying to boot Ubuntu from the Win XP menu.

I'll delete that Wubi install from Win and try an install off of an original Lucid disc to see what happens, but I must be honest. IMHO Wubi is poorly supported, not just by GRUB devs, but all throughout, and I hate to see those who are effected by this bug have to suffer because the Wubi dev team fails to test as well as they should.

Wubi has always been a real kludge IMHO!!! I'll still do some additional testing to see if I can try to narrow this down.

Should you be interested I'll include the RESULTS.txt from that trial.

[bcbc (bcbc)]

From what I can gather, the users are not selecting to install grub to the MBR. They recall a grub popup during the updates, but did not click on any checkboxes. Haven't been able to figure out if it's always a 'separate partition install' but that's my suspicion.

[bcbc (bcbc)]

They're coming slow, but steady...

http://ubuntuforums.org/showthread.php?t=1540744
http://ubuntuforums.org/showthread.php?t=1540772
http://ubuntuforums.org/showthread.php?t=1539672

The person with the netbook is affected worse as they can't just insert their windows dvd to repair.

I think it's pretty serious when a product like wubi is offered and a simple update renders the computer unbootable. Anybody have an opinion?

[bcbc (bcbc)]

I created a new bug https://bugs.launchpad.net/wubi/+bug/610898

[Takkat (takkat-nebuk)]

New bug is a good idea. Colin already made his point on this (#54).

[bcbc (bcbc)]

It also affects non-wubi installs, by replacing the grub bootloader with what it figures is the correct target, but it sometimes gets it wrong. In one case, the uuid was invalid. In another, it seemed to be pointing at the right partition (but bootinfoscript is not clear on this - it says 'partition #2 on the same drive' even when it's actually on a separate drive) so I suspect it was pointing at the wrong drive. In any case, reinstalling grub fixed the problem.

[bcbc (bcbc)]

@takkat - in any case, this is splitting hairs, more typical of a bureaucracy - the same developer is responsible and can see the issue whether it came in duplicate with a shiny red stamp or not. At the end of the day, my job (as I see it) is to let them know they've made a mistake. Then they can fix it and pass on congratulations for saving the day. [roll eyes].

[bcbc (bcbc)]

I finally got to test the grub update. Before with wubi, when it prompted the checkbox 'skip installing grub' you had to check the box to go forward. Now, if you don't check the box, when you click on Forward, it goes back to the select a device to install grub screen that had been suppressed, and presents a checkbox with the drive /dev/sda. So users who are not paying attention or don't understand grub, might click on this and install grub to the MBR.

I was confused by additional symptoms - in some cases, even after fixing the MBR, wubi would not boot. In other cases (as stated above), users not using wubi had the same symptoms. These may be totally unrelated. In any case, I didn't see any update to wubildr so that theory didn't pan out.

[Alex Cockell (alcockell)]

I have to ask - what about people who bought their computer preinstalled with Ubuntu? Like me, for instance?

How on earth am I supposed to know what options to accept?

[Erick Brunzell (lbsolost)]

@ Alex Cockell,

I took the liberty to subscribe you since you asked a question. First of all I'm not a developer but rather just an end user ;^/

That said the new behavior should show only the mbr's of all drives (both internal and external), and also the partition that Ubuntu's "/boot" lives in.

You didn't say much about the choices offered, what were they?

[Erick Brunzell (lbsolost)]

@ bcbc,

Regarding this:

"It also affects non-wubi installs, by replacing the grub bootloader with what it figures is the correct target, but it sometimes gets it wrong. In one case, the uuid was invalid. In another, it seemed to be pointing at the right partition (but bootinfoscript is not clear on this - it says 'partition #2 on the same drive' even when it's actually on a separate drive) so I suspect it was pointing at the wrong drive. In any case, reinstalling grub fixed the problem."

It might benefit you to read the interaction between me (kansasnoob) and 'seeker5528' here:

http://ubuntuforums.org/showthread.php?t=1516153

To wrap that in a nut shell I multi-boot a lot and I noticed that 'grub-pc' and/or 'grub-common' updates would now install "grub" wherever it was installed initially. So if I had my Maverick's bootloader in charge of boot but later installed something like Lubuntu 10.04, and handed boot off to it, while updating 'grub-pc' or 'grub-common' in Maverick it will install/reinstall grub wherever "dpkg" was originally told to install grub.

Did I say that in a way that makes sense? I hope so.

Regarding the Wubi thing I'm stuck here:

http://ubuntuforums.org/showthread.php?t=1539619

In other words I can't get past GO :^)

[Alex Cockell (alcockell)]

@Erick,

As yet, I don't know. I Am currently using a Thinkpad R61i as supplied by Linux Emporium with 8.04, and an Ideapad S12 - as supplied with 9.10 and 10.04dev (10.04dev on a separate partition, which I accepted updates to - although I am generally using the 9.10 instance). All I've done so far is simply accept updates via Update Manager. Any software I've added - was simply by firing up Synaptic or Software Centre and clicking on the relevant buttons to request it.

I am worried that selecting the wrong option - especially on my netbook - will leave me with an unbootable machine - the only option being to send it back to the vendor to fix it.

[Alex Cockell (alcockell)]

I don;'t intend to replace the OS on my R61i until the Ubuntu 10.04 service pack comes out mid-August...

[Erick Brunzell (lbsolost)]

@ Alex Cockell,

Sorry to take so long but I've had precious little time to spend at my desk. First of all regarding this, "the only option being to send it back to the vendor to fix it", if you don't have any Ubuntu Live media that might be true but you really should have Live Media that will work with both your Thinkpad and Ideapad.

I'm guessing the Thinkpad has an optical drive but the Ideapad most likely does not (unless you have a USB optical drive), so Live USB may be best for you. If you're unsure what to do to create Live Media you could look at these wikis:

https://wiki.ubuntu.com/LiveUsbPendrivePersistent

https://help.ubuntu.com/community/LiveCD

Regardless you should always have Live media before performing an upgrade because things can "break", and not just grub. But a better place to raise these kinds of questions would be Ubuntu Forums:

http://ubuntuforums.org/forumdisplay.php?f=333

Regarding the upgrade from Hardy to Lucid (10.04.1 which is scheduled for release around 08/12) I'm reasonably sure that the upgrade will still leave you with legacy grub so you might encounter this problem:

https://wiki.ubuntu.com/LucidLynx/ReleaseNotes#GRUB%20menu.lst:%20install%20the%20maintainer%27s%20version%20vs.%20keep%20the%20local%20version

I'll probably be involved in the 10.04.1 upgrade testing around the 9th or 10th so you might want to follow the progress on that other bug:

https://bugs.launchpad.net/ubuntu/+source/grub/+bug/470490

All that said this particular bug should not effect you in any way with an upgrade from 8.04 to 10.04 because it will retain legacy grub, but IMHO you should always be prepared for the worst when doing a distro upgrade, 90% of the time everything will go just fine but you must have Live media just in case.

[Alex Cockell (alcockell)]

It sounds like my best option is to wait until after the new 10.04.1 CDs
and USB keys are available, then buy them from said vendor; do my
upgrades from supplied media...

What advice is usually given to non-technical users when it comes to
major updates like this? Or should I do something like - buy the OS
upgrades then take my kit to my local LUG and let them do it?

Or should I just write off my Thinkpad next year and buy a new computer?

--
Alex Cockell
<email address hidden>

[bcbc (bcbc)]

@Erick, sorry can't help you with your wubi problem. It's always just worked for me - on a variety of machines. While I can and do pass on known fixes to others, I haven't come across a known fix or workaround to your issue. I suppose you could install 9.10 wubi and upgrade to 10.04. It's a pain, but should work. Don't forget about the 9,10 wubildr bug.

[Colin Watson (cjwatson)]

For Wubi, let's please make this bug 581760.

[Mikhail Krutov (k-neko)]

Still reproduced at 13.04
Didn't make a screenshot while updating, however when running
#apt-get upgrade
I got a curses window with 'It's a good idea to install grub to every partition'.