Bug 737731

We don't have another blocker review till Friday but we need to decide on blocker status of all uncertain bugs by tomorrow, so can people please vote here?

As I'm proposing it, obviously, I'm +1 blocker for beta.

+1 for blocker

+1 for blocker.

+1 for beta blocker

I'm also +1 beta blocker.

We have enough votes to make this a blocker now, changing status.

hongqing confirmed this in https://bugzilla.redhat.com/show_bug.cgi?id=735016 , for the record.

+1 for blocker, as well.

This ought to be fixed by anaconda 16.18 , as it changes the default to 'install new boot loader' and fixes that. I'm hoping preupgrade uses the same default as the interactive install.

note that this is not currently testable; it won't be until 16.18 is pushed stable and mirrors sync, as preupgrade gets its anaconda from development/16/x86_64/os/ .

setting to ON_QA as we expect anaconda 16.18 to fix this, we just need mirror images to verify it.

Created attachment 524132 [details]
log from preupgrade done with anaconda-16.18

I tested preupgrade 15->16 (checked logs to verify that anaconda-16.18 was used) and still end up with the same problem - the system is still booting with grub and configured to boot with the old f15 kernel.

I'm not sure what other logs are needed but I'm attaching anaconda.log and can supply other logs if needed.

OK, think I've got this. I looked at /boot/upgrade/ks.cfg on a system after preupgrade has run and told you to reboot, and I see this:

bootloader --upgrade --location=none

that's not going to work, because the 'upgrade' option isn't there any more. When upgrading to f16, preupgrade should probably write:

bootloader --location=mbr

i'm not sure if it should specify any other options. back to preupgrade for this one.

something like 'if source_version less than 16 and target version 16 or greater, write bootloader --location=mbr, otherwise write bootloader --upgrade --location=none' would probably be the right logic. I don't see straight off the bat that there *is* a variable for the source version right now, though.

Now, while it makes sense to change the default in preupgrade, why aren't we giving users the option to just upgrade their GRUB 1 configuration rather than switching to GRUB 2? GRUB 1 is able to boot Fedora 16, isn't it?

Created attachment 526060 [details]
test patch

(In reply to comment #13)
> something like 'if source_version less than 16 and target version 16 or
> greater, write bootloader --location=mbr, otherwise write bootloader --upgrade
> --location=none' would probably be the right logic. I don't see straight off
> the bat that there *is* a variable for the source version right now, though.

Something like this? Can somebody please test the rpm here http://people.freedesktop.org/~hughsient/fedora/15/i386/ as I don't have a machine capable of virt handy. Thanks.

That looks about right, yup. Thanks. We'll test shortly.

test didn't work :( still grub1 and f15 kernel after upgrade. investigating.

even using http://people.freedesktop.org/~hughsient/fedora/15/i386/preupgrade-1.1.10-0.22.20111003git.fc16.noarch.rpm , the bootloader line is still incorrect:

bootloader --upgrade --location=none

I suspect the comparison >= 16.0 doesn't work right (the version may be '16', for e.g., which might not match >= 16.0; we have this trouble in RPMs sometimes). I'm testing with it changed to > 15.0.

that doesn't help, still get the wrong line. maybe we need some debug prints in there.

ah. I think the source version is the problem. I added a couple of debug prints to __init__.py:

print _("current version: ") + self.conf.yumvar['releasever']
print _("target version: ") + self.target_version

and the result is:

current version: 16
target version: 16

so the yum releasever variable is coming out as the target version, not the source version...

added to commonbugs, since it has not been fixed in time for Beta release :(

(In reply to comment #20)
> print _("current version: ") + self.conf.yumvar['releasever']

Urgh, the yum config gets re-written.

Can you try with build preupgrade-1.1.10-0.22.20111003git or newer from my repo please. I've cached the original releasever before it got overwritten. This at least gives me the right values.

releases.txt got broken somehow, so have to wait for that to be fixed before i can test this :/ eta 1hr or so.

partway through testing, the bootloader line looks better now:

bootloader  --location=mbr

so that's promising. we'll see if it actually works for anaconda soon.

Nope, anaconda tbs at bootloader installation. trying to get the tb out right now.

Created attachment 526332 [details]
anaconda traceback when it hits bootloader step

line in the kickstart was "bootloader  --location=mbr"

so, the problem here is simple enough: grub2 package isn't available to anaconda at all, because preupgrade didn't download it. after all, it doesn't know we should be replacing grub with grub2 as part of the upgrade.

there's another complication here, which is that if you're upgrading from an EFI install of f15, we *don't* want to replace grub with grub2. (we'll be replacing it with grub-efi for Final, but for Beta, it's just grub).

if possible, I think preupgrade should make sure grub (or grub-efi) and grub2 packages are both available to anaconda, and let it sort out what to do.

(In reply to comment #27)
> so, the problem here is simple enough: grub2 package isn't available to
> anaconda at all, because preupgrade didn't download it. after all, it doesn't
> know we should be replacing grub with grub2 as part of the upgrade.

Surely shouldn't something depend on grub2?

> there's another complication here, which is that if you're upgrading from an
> EFI install of f15, we *don't* want to replace grub with grub2. (we'll be
> replacing it with grub-efi for Final, but for Beta, it's just grub).

How would preupgrade know it's an EFI install?

> if possible, I think preupgrade should make sure grub (or grub-efi) and grub2
> packages are both available to anaconda, and let it sort out what to do.

Urgh, so basically we need to download grub, grub2 and grub-efi in the releasever of the new install?

It's doable, but it'll just be adding to the multitude of hacks already in preupgrade.

I guess having grub-efi and grub2 both Obsolete grub would make sure they'll get dragged in.

(A versioned Obsoletes capturing the version in F15, but not the one in F16, should be sufficient and not make the virtualization folks unhappy.)

That said, such an Obsoletes will probably break machines upgraded by direct use of yum (or zif or apt or smart or whatever), without Anaconda migrating the bootloader configuration automatically.

By the way, is there any documentation on converting a machine from GRUB 1 to GRUB 2 manually?

(In reply to comment #31)
> That said, such an Obsoletes will probably break machines upgraded by direct
> use of yum (or zif or apt or smart or whatever), without Anaconda migrating the
> bootloader configuration automatically.
Since this kind of upgrade is not officially supported, we could use Obsoletes and just add a note about it in the release notes explaining how to manually upgrade the configuration.

Another possible solution might be adding a migration script to grub2's %post

(In reply to comment #31)
> That said, such an Obsoletes will probably break machines upgraded by direct
> use of yum (or zif or apt or smart or whatever), without Anaconda migrating the
> bootloader configuration automatically.

+1

grub might be deprecated and desupported, but there is no automatic upgrade path so obsoleting it is not an option.

- and I still haven't seen an explanation of why these boot loaders should be conflicting at the package level. IMHO it is up to the user/admin and his tools (such as anaconda) to choose a boot loader and write it to MBR. grubby will maintain all the boot loader configs it can find.

> By the way, is there any documentation on converting a machine from GRUB 1 to
> GRUB 2 manually?

It should be as simple as
grub2-mkconfig -o /etc/grub2.cfg
grub2-install /dev/sdX

Yeah, the Conflicts are also going to make manual conversion much more dangerous than necessary. (What you really want is install GRUB 2, set it up, reboot into it, THEN uninstall GRUB 1. Otherwise, what if power goes out while you're still configuring GRUB 2 and haven't run grub2-install yet, but the GRUB 1 package is already uninstalled?)

mads: "grub might be deprecated and desupported, but there is no automatic upgrade path so obsoleting it is not an option."

it is an option. we explicitly do not support yum distribution upgrades, precisely because of cases like this. grub2 is likely to obsolete grub, though the EFI case will still require special handling.

however we sort this mess out, there are going to be ugly hacks in something, just because of the messiness with using grub-efi to handle EFI installs. if we had it to do over again we'd probably wait until grub2 could handle EFI properly, but that ship has sailed...

anyway, this bug is not about the grub/grub-efi split and grub2 obsoleting grub and so on, we have other bugs for that. it's about preupgrade's handling. if the grub2 obsoletion of grub is implemented in an update soon it would probably solve the BIOS case for preupgrade, I think, but EFI preupgrades would still be broken, and require either documentation or a hack in preupgrade.

(In reply to comment #35)
> it is an option. we explicitly do not support yum distribution upgrades,
> precisely because of cases like this. grub2 is likely to obsolete grub, though
> the EFI case will still require special handling.

1st: If we don't rely on rpm doing the right thing anyway, but rely on anaconda juggling packages and rewriting configuration, then why try to make a partial rpm solution that anaconda will have to work around anyway?

2nd: Correct, manual upgrades are not supported. But the only reason it will break here is that we intentionally break it. There is _no_ technical reason why a previous working grub installation can't continue to be used. (A working BIOS grub setup will however not break just because the grub rpm is removed. It will just be less manageable.)

> however we sort this mess out, there are going to be ugly hacks in something,

FWIW I still don't understand why we don't remove the conflict and install grub (and/or -efi) and grub2 packages side by side. I feel sad that you and the QA team and others have spent so much time on this still incomplete grub2 feature, and installing side by side seems to be the simplest and most safe solution.

+1

I think that:
1. grub and grub2 should not Conflict and
2. upgrading to GRUB 2 should be optional in Anaconda. I can understand making it the default, but I don't see a strong technical reason for completely removing the option to keep the existing boot loader, be it GRUB 1 or 2. That option should be reinstated.

(and #2 would also fix preupgrade, without having to add any special hacks to preupgrade)

(In reply to comment #38)
> (and #2 would also fix preupgrade, without having to add any special hacks to
> preupgrade)

Sure, I know quite a few people that just "yum upgrade" to the new release, and I'd quite like to not break this for no good reason.

Guys I'm "silent reader" of this issue. But now I must add my comment ;). 

I disagree with supporting two boot loaders due to addition maintenance and 2x procedures for 2x boot loaders etc... If there is some one, who need old grub, he could build it, install it into /opt or /usr/local and use it.

This issue shows us how the "yum upgrade" method is insufficient without deployment tool like Anaconda (or whatever else). In case of manual upgrade, you as admin of the system, are responsible to doing additional/manual steps which could be maintenance by Anaconda otherwise. Unfortunately packages itself cannot handle all possibilities ...

mads: we're going to *obsolete* grub, not conflict with it. this is the best thing to do precisely because it means rpm will do 'the right thing' in most cases: in 99% of cases we want people upgrading from f15 to f16 to replace grub with grub2. grub2 is F16's supported bootloader for all cases but EFI and PPC.

even if we punt on this and keep grub in f16 all we're doing is delaying the problem and making extra work for ourselves in the mean time. the whole point of switching is that _we don't want to support grub-legacy any more_: we're not getting a whole lot of actual extra functionality out of grub2, only reducing our maintenance burden. if we introduce grub2 without kicking out grub all we've done is given ourselves extra pain for zero gain. and even if we do it, we can't do it forever: at *some* point we have to obsolete grub and force people to upgrade. if we're going to do it anyway why not do it now and get it all over with in one release?

Created attachment 528916 [details]
grub conf

preupgrade f14 to f16, "Upgrade to Fedora 16 Branched Pre-release (Verne) " is found in the grub, but cannot boot in the entry to continue the preupgrade.

(In reply to comment #42)
> preupgrade f14 to f16, "Upgrade to Fedora 16 Branched Pre-release (Verne) " is
> found in the grub, but cannot boot in the entry to continue the preupgrade.

That is different from what is being discussed here, so you should probably file a new bug. Please also describe why you cannot boot and what happens.

Okay - finally, this is fixed!

With the preupgrade from hughsie's repo and the updated grub, grub2 and grub-efi setup in F16 repos now, preupgrade works as intended: you wind up with grub2 installed and working.

hughsie, can you push out the fixed preupgrade to F15? Thanks!

preupgrade-1.1.10-1.fc15 has been submitted as an update for Fedora 15.
https://admin.fedoraproject.org/updates/preupgrade-1.1.10-1.fc15

*** Bug 747920 has been marked as a duplicate of this bug. ***

I can't restest - I've upgraded the machine. Thanks though.

I was able to preupgrade to F16 with this build.

One desktop upgraded - OK, but I have some problem on my laptop. It looks to anaconda issue (?) so I filled bug report #748119.

Package preupgrade-1.1.10-1.fc15:
* should fix your issue,
* was pushed to the Fedora 15 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing preupgrade-1.1.10-1.fc15'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2011-14766
then log in and leave karma (feedback).

I retried with preupgrade-1.1.10-1.fc15, but I had the same problem - it still tries to boot using grub 0.97, which causes the boot to hang (no output, just a blinking cursor on a blank black screen).

(In reply to comment #51)
> I retried with preupgrade-1.1.10-1.fc15, but I had the same problem - it still
> tries to boot using grub 0.97, which causes the boot to hang (no output, just a
> blinking cursor on a blank black screen).

Please attach anaconda.log from the upgrade.

Are you sure you specified the right device for installing the f16 grub2 boot loader?

Sorry, I'm experiencing the same bug as Hongqing Yang, not this bug. Sorry for the noise.

when preupgrde from F15 to F16, after installation, still cannot boot into F16, the /etc/grub2.cfg is still blank.

This bug report is not for that problem. Please file separately and don't confuse the issue. The bug reported here is fixed.



-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers

hongqing: if grub2.cfg is blank it means the mkconfig failed for some reason. to know the reason, we need to have the anaconda logs from the upgrade.

preupgrade-1.1.10-1.fc15 has been pushed to the Fedora 15 stable repository.  If problems still persist, please make note of it in this bug report.

*** Bug 751131 has been marked as a duplicate of this bug. ***

So I'm going to clear the commonbugs link here because the bug is fixed but we should probably add a commonbugs note to clarify that preupgrade's bootloader behaviour is now fairly...invasive.

basically it IS going to write a bootloader to an MBR. some MBR. if you have multiple disks connected when you do the preupgrade, anaconda will basically go with the first one it likes the look of.

so we should probably document that. in theory at least, wherever grub2 actually gets written, it should be able to boot all installed OSes, so you ought to be happy. in theory.



-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers

-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers

I am wondering if there is a way to get the proper kernel and related configuration manually?

Fedora 14 is still supported and what I find says one should be able to skip a version... i.e. f14 -> f16

As of 11Z November 9th preupgrade-1.1.9-1.fc14.noarch is on the mirror I accessed. 

Is this/has this fix been pushed to f14 mirrors? Otherwise can a quick preupgrade update be pushed to disable preupgrade (if this is not a quick fix or not to be fixed in f14)? Thank you.

I just did a preupgrade from F15->F16 and grub didn't get updated properly and I just had the F15 kernels. I could boot with the latest, and I'm manually changing to grub2 now.

Should I reopen this bug or create a new one?

@Carl-Johan
What steps should I do to bring grub2 into system and end upgrade process? Now i got stuck with downloaded fc16 into /var/cache/yum/preupgrade* and not bootable option in grub: "Upgrade to Fedora 16 (Verne)".
Here my comment on related bug: https://bugzilla.redhat.com/show_bug.cgi?id=752446#c5

(In reply to comment #64)
> What steps should I do to bring grub2 into system and end upgrade process?

yum install grub2        # you might already have it
grub2-install /dev/sda   # or where-ever you want the boot loader installed
grub2-mkconfig -o /boot/grub2/grub.cfg

(In reply to comment #65)
> (In reply to comment #64)
> > What steps should I do to bring grub2 into system and end upgrade process?
> 
> yum install grub2        # you might already have it
> grub2-install /dev/sda   # or where-ever you want the boot loader installed
> grub2-mkconfig -o /boot/grub2/grub.cfg

I tried this on my Macbook Air (F14 only installed). 

In response to the grub-install command, I got the following messages:

warn: This GPT partition label has no BIOS Boot partition; embedding won't be possible!
warn: Embedding is not possible. GRUB can only be installed in this setup by using blocklists. However, blocklists are UNRELIABLE and its use is disouraged..
error: if you really want blocklists, use --force.

Well, I don't want to use something UNRELIABLE. So it seems I can't use grub2. Can i still upgrade to F16, or do I have to switch to another configuration?

> grub2-install /dev/sda   # or where-ever you want the boot loader installed
> grub2-mkconfig -o /boot/grub2/grub.cfg

I think those should be done in the opposite order:
grub2-mkconfig -o /boot/grub2/grub.cfg
grub2-install /dev/sda   # or where-ever you want the boot loader installed

> So it seems I can't use grub2.

So I see only 2 options there:
(a) use --force and hope for the best or
(b) shrink some partition with a partition editor (use some live CD with kde-partitionmanager, GParted and/or QtParted on it, or boot any F15 live CD and yum install them; note that due to functionality removal in the latest libparted, F16 currently does not have kde-partitionmanager nor QtParted available, and GParted on F16 can't shrink HFS+ nor FAT partitions) and create a BIOS Boot partition in the freed space.

> Can i still upgrade to F16, or do I have to switch to another configuration?

AFAIK, grub (version 1) is still available for manual installation, but you'll have to reinstall the package after upgrading (it gets removed during the upgrade), and presumably enter the kernel into the config file manually (see comment #64). (You may need to use rescue media for this purpose.)

(In reply to comment #67)
> > grub2-install /dev/sda   # or where-ever you want the boot loader installed
> > grub2-mkconfig -o /boot/grub2/grub.cfg
> 
> I think those should be done in the opposite order:
> grub2-mkconfig -o /boot/grub2/grub.cfg

I tried this. It found a linux iamge, and an initrd image, and then said:

/etc/grub.d/10_linux: line 61: gettext: command not found

It would appear that there is some missing dependency in the rpm for grub2 on f14.

> > So it seems I can't use grub2.
> 
> So I see only 2 options there:
> (a) use --force and hope for the best or
> (b) shrink some partition with a partition editor (use some live CD with
> kde-partitionmanager, GParted and/or QtParted on it, or boot any F15 live CD
> and yum install them; note that due to functionality removal in the latest
> libparted, F16 currently does not have kde-partitionmanager nor QtParted
> available, and GParted on F16 can't shrink HFS+ nor FAT partitions) and create
> a BIOS Boot partition in the freed space.

Neither is attractive to me.

> > Can i still upgrade to F16, or do I have to switch to another configuration?
> 
> AFAIK, grub (version 1) is still available for manual installation, but you'll
> have to reinstall the package after upgrading (it gets removed during the
> upgrade), and presumably enter the kernel into the config file manually (see
> comment #64). (You may need to use rescue media for this purpose.)

Not attractive either.

I just upgraded, using "preupgrade", two Fedora 15 systems to Fedora 16, and in
both systems the upgrade did NOT replace grub1 with grub2, and I was left
running grub1 configured to run an old Fedora 15 kernel (which was luckily not
deleted yet), and the new Fedora 16 kernels are listed in Grub2's configuration, which wasn't being used.

I had to manually run on each system:

    /sbin/grub2-mkconfig -o /boot/grub2/grub.cfg
    /sbin/grub2-install BOOTDEVICE

(as recommended in
http://fedoraproject.org/wiki/Upgrading_Fedora_using_yum#Fedora_15_-.3E_Fedora_16)
Which worked correctly, and now Fedora boots to the new Fedora 16 kernel.

Preupgrade should have run these two commands, or, if you're afraid that this might cause it to ignore some important configuration the user had in grub1's conf, the least you could do is some big boot-time message (or whatever) urging you to quickly run these commands, or you risk running an old kernel which will
most likely be automatically deleted from your system after a few updates.

Thanks.

> I tried this on my Macbook Air (F14 only installed).

I would use EFI on a Macbook. It is not officially "supported", but I have found that it is better supported than using their BIOS mode.

> Well, I don't want to use something UNRELIABLE.

grub2 blocklists are not more unreliable than they were when similar functionality always was used by grub legacy. grub2 has just done you the service to raise (or lower?) the bar.

> I think those should be done in the opposite order:
> grub2-mkconfig -o /boot/grub2/grub.cfg
> grub2-install /dev/sda   # or where-ever you want the boot loader installed

No, not really; grub2-mkconfig will unfortunately look in /boot/grub2 for files installed by grub2-install (Bug 736993#c13) - but it will probably in most cases not make a big difference. Running grub2-install again after grub2-mkconfig shouldn't be necessary - but doesn't hurt and feels good.

> AFAIK, grub (version 1) is still available for manual installation, but you'll
> have to reinstall the package after upgrading

It will be replaced by grub2 on the first update ... unless you do tricks to avoid it.

> /etc/grub.d/10_linux: line 61: gettext: command not found
>
> It would appear that there is some missing dependency in the rpm for grub2 on
> f14.

f14???

(In reply to comment #69)
> I just upgraded, using "preupgrade", two Fedora 15 systems to Fedora 16, and in
> both systems the upgrade did NOT replace grub1 with grub2, and I was left
> running grub1 configured to run an old Fedora 15 kernel (which was luckily not
> deleted yet), and the new Fedora 16 kernels are listed in Grub2's
> configuration, which wasn't being used.

Did your systems have preupgrade-1.1.10-1.fc15 ?

If not: Yes, you hit this issue. The issue has been fixed in an update.

If so: You must have hit some other issue. Please file a new bug to separate it from the noise here. Make sure to provide as much information as possible, such as log files from the upgrade.

(In reply to comment #70)

> > It would appear that there is some missing dependency in the rpm for grub2 on
> > f14.
> 
> f14???

Yes, I am trying to upgrade f14 to f16. But preupgrade is not working (the fix for this issue has not been propagated to f14 yet).

So I tried a yum install grub2 on my f14 system, in the hope that if I can get grub2 woring on f14, preupgrade might go ahead and work.

#71: How can I check which version of preupgrade I had before the upgrade? I admit I did not "yum update" right before the upgrade, but it also hasn't been very long since I last "yum update".

Is this a common occurance, that preupgrade is improved at the last moment and it is necessary to update it before running it? If so, perhaps preupgrade could verify that it itself is up-to-date before agreeing to run?

Anyway, thanks for the answer. Nadav.

(In reply to comment #72)
> Yes, I am trying to upgrade f14 to f16. But preupgrade is not working (the fix
> for this issue has not been propagated to f14 yet).

Correct. That is known and documented on https://fedoraproject.org/wiki/Common_F16_bugs#preupgrade-bootloader-fail . Unfortunately there is no f14 update pending yet. You will have to use one of the workarounds described there.

> #71: How can I check which version of preupgrade I had before the upgrade? I
> admit I did not "yum update" right before the upgrade, but it also hasn't been
> very long since I last "yum update".

Define "hasn't been very long". :-)

https://admin.fedoraproject.org/updates/FEDORA-2011-14766 was pushed to F15 updates-testing on 2011-10-22 08:31:04 UTC and to F15 updates (stable) on 2011-11-02 06:57:15 UTC.

As for checking, look in /var/log/yum.log, though I'm not sure whether it is preserved during preupgrade.

(In reply to comment #73)
> If so, perhaps preupgrade could
> verify that it itself is up-to-date before agreeing to run?

You could file a separate suggestion/request for that.

It turns out (thanks for the suggestion to look in /var/log/yum.log) that my last "yum update" was in October 27th, so indeed that was before that update to preupgrade... So I was not running the latest and greatest preupgrade :(

This bug has been closed, but preupgrade has only been fixed for f15, not f14.  The common F16 bugs wiki page:

https://fedoraproject.org/wiki/Common_F16_bugs#Upgrade_from_Fedora_14_to_Fedora_16_with_preupgrade_leaves_bootloader_in_previous_configuration

links here, but this f15 package doesn't actually fix the f14 -> f16 case.  So either:

1) this bug should be re-opened until the f14 preupgrade package is fixed
2) another bug should be linked from the wiki page, I suggest: bug #752734 which seems to be the same thing.

The wiki page should not be linking to a closed issue that doesn't actually fix the common f16 bug in question.

(In reply to comment #79)

> 2) another bug should be linked from the wiki page, I suggest: bug #752734
> which seems to be the same thing.

Hmm, looking more closely at that bug, it seems it isn't necessarily the same, so I suggest re-opening this bug or a new bug for f14.

alex: it links here because, hey, at least here explains the bug. I've been meaning to just fix F14 myself but I never seem to get around to it.



-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers

preupgrade-1.1.10-1.fc14 has been submitted as an update for Fedora 14.
https://admin.fedoraproject.org/updates/preupgrade-1.1.10-1.fc14

Phew, after doing in rescue mode:

# chroot /mnt/sysimage
# grub2-install --force /dev/sda
# grub2-mkconfig -o /boot/grub2/grub.cfg

I finally got my preupgrade from f15 to boot.
I *thought* I updated my f15 system beforehand...

I wish I had tested this before GA...

Ok another machine was fine - I guess I must have forgotten
to re-update just before doing preupgrade on the previous machine.

preupgrade-1.1.10-1.fc14 has been pushed to the Fedora 14 stable repository.  If problems still persist, please make note of it in this bug report.

*** Bug 758499 has been marked as a duplicate of this bug. ***

I did do a yum update before preupgrade.

preupgrade loaded F16 and it would NOT boot so

I loaded F16 from scratch using the 3.5 GIG DVD.

Problem persists!

(1) installed MS XP Prof works great...boots right up with no help.......SCSI 0

(2) installed Fedora 16 but cannot reach it         took hours          .......SCSI 1

attached is error_grub.txt with all attempts and results.

I've learned NEVER to install ANYTHING (XP included) with flash or ext HDs plugged in.

Large Bold font is reqd for my bad eyesight

In the F16 install, there is something confusing.

One moves the target drive for install to the right page via ">>"

This was SCSI 1 since XP Prof is on SCSI 0

There is a check box for "install bootloader"

Why would anybody want to install the bootloader on SCSI 1 since it goes on SCSI 0. Remove the check and you go nowhere unless the check is there

 

The following is backward…hd0 really has MS XP Professional

I switched the entries and it did’t work so I switched back

 

(hd1) /dev/disk/by-id/scsi-35000000000000000

(hd0) /dev/disk/by-id/scsi-SSEAGATE_ST336705LW_3DE04EJF000071424BKV

(In reply to comment #87)
> preupgrade loaded F16 and it would NOT boot so
> Problem persists!
> (1) installed MS XP Prof works great...boots right up with no help.......SCSI 0

Sounds like a totally different problem, especially as it does NOT work anymore (see bug summary). Please ask in a forum or file a separate report if you are really sure that you encountered a bug.

Please, reopen the issue. It is not fixed. I have upgraded a couple of weeks ago on my laptop from 15 to 16 using preupgrade and I got a failure popup when installing bootloader. The system previous grub configuration remained with all F15 kernels removed and only the "Upgrade to Fedora 16" there.

The system was fully updated to latest F15 software before starting preupgrade.

This issue definitely is fixed, and has been tested multiple times. It's possible you might have hit another issue with similar symptoms. If you provide your anaconda logs, we could check.



-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers

Well, apparently not. Having done my homework to read all F16 common bugs, I knew about this issue and I was sure that the description matched perfectly my problem. Nevertheless, I should have collected installation /tmp logs.

Is there any way to verify that now? Could the update logs that moved to /root  or the upgraded system's currently situation help (e.g. if grub2 is installed or not etc)?

The logs from the upgrade should be present on the upgraded system in /var/log/anaconda .



-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers

Created attachment 564902 [details]
Anaconda logs of /var/log/anaconda plus /root/upgrade.log*

Hello Adam,

You may check the logs in the zip archive anaconda-logs.zip uploaded. I think you are right. The reported problem is of different nature:

22:49:43,826 INFO program: Running... grub2-install --no-floppy (hd0)
22:49:49,445 ERR program: /sbin/grub2-setup: warn: Your core.img is unusually large.  It won't fit in the embedding area..
22:49:49,448 ERR program: /sbin/grub2-setup: warn: Embedding is not possible.  GRUB can only be installed in this setup by using blocklists.  However, blocklists are UNRELIABLE and their use is discouraged..
22:49:49,450 ERR program: /sbin/grub2-setup: error: will not proceed with blocklists.

I would be very grateful if you could advise me how to proceed. Do you want me to open a new issue? Is there already an existing issue with my problem?

Panos

yep, you're hitting https://bugzilla.redhat.com/show_bug.cgi?id=737508 . all you can really do is manually set up grub-legacy in the mbr and configure it, or move your partitions so the 'embedding area' (the space between the MBR and the first partition) is larger. there's some more detailed instructions for this in the other bug, i think.



-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers

oh - there's actually a contributing bug if you're using preupgrade: https://bugzilla.redhat.com/show_bug.cgi?id=782144 . that results in core.img being bigger than it strictly needs to be; if you use an older grub2 build it may work. to get an older grub2 build, though, you'll need to upgrade with the DVD rather than preupgrade.

Thank you very much Adam. My issue is indeed in the Common F16 bugs already. It confused me that it was referring to raid setup, which is not my case. I'll try the solutions there. The best solution would be the partition alignment to use grub2 for future upgrades. Bug hijacking is over... moving to another bug :)

yeah, I might update the common bugs note to be a bit less specific, since there are other possible reasons for core.img to be big.



-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers