|Summary:||Bootloader is left in F15 configuration when preupgrading to F16|
|Product:||[Fedora] Fedora||Reporter:||Adam Williamson <awilliam>|
|Component:||preupgrade||Assignee:||Richard Hughes <hughsient>|
|Status:||CLOSED ERRATA||QA Contact:||Fedora Extras Quality Assurance <extras-qa>|
|Version:||16||CC:||a9016009, alexl, athmanem, bloch, bugsgentoo, carljohan, colin, collura, couleurfofuca, ddosia, deadletterfile, dennis, dsd, elad, fredsilsbee, greenrd, grgoffe, hoyang, hughsient, initpidzero, jaroslav.pulchart, jdulaney, johannbg, jonathan, js, jsmith, kevin, lsof, mads, mishu, mmello, nyh, Panos.Kavalagios, rbergero, redhat-bugzilla, rhughes, ricardo.arguello, rmarko, robatino, satellitgo, sdodson, tflink, vanmeeuwen+fedora, yann|
|Fixed In Version:||preupgrade-1.1.10-1.fc14||Doc Type:||Bug Fix|
|Doc Text:||Story Points:||---|
|Last Closed:||2011-11-02 06:57:09 UTC||Type:||---|
|oVirt Team:||---||RHEL 7.3 requirements from Atomic Host:|
|Cloudforms Team:||---||Target Upstream Version:|
|Bug Depends On:|
Description Adam Williamson 2011-09-12 23:50:19 UTC
Probably to some degree related to issues discussed in https://bugzilla.redhat.com/show_bug.cgi?id=735730 . When doing a preupgrade from F15 to F16 (current branched tree), the upgraded system winds up with an apparently untouched F15 bootloader configuration - grub1 (not grub2) configured to boot the latest F15 kernel by default, no entry for the F16 kernel. This is likely because the 'update bootloader configuration' option is dead and now anaconda is just defaulting to 'skip bootloader configuration'. In my test this resulted in a booting system, but I suspect in quite a few cases it would not. (And in a VM, booting F16 with an F15 kernel results in https://bugzilla.redhat.com/show_bug.cgi?id=737280 , which makes the system borderline unusable). So, proposing as a Beta blocker, anaconda needs to do something sane with the bootloader for preupgrades as well as 'regular' upgrades.
Comment 1 Adam Williamson 2011-09-13 01:33:06 UTC
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.
Comment 2 Jóhann B. Guðmundsson 2011-09-13 09:04:33 UTC
+1 for blocker
Comment 3 Elad Alfassa 2011-09-13 13:30:03 UTC
+1 for blocker.
Comment 4 Othman Madjoudj 2011-09-13 13:41:12 UTC
+1 for beta blocker
Comment 5 Tim Flink 2011-09-13 15:54:53 UTC
I'm also +1 beta blocker. We have enough votes to make this a blocker now, changing status.
Comment 6 Adam Williamson 2011-09-13 16:13:06 UTC
hongqing confirmed this in https://bugzilla.redhat.com/show_bug.cgi?id=735016 , for the record.
Comment 7 John Dulaney 2011-09-13 19:29:23 UTC
+1 for blocker, as well.
Comment 8 Adam Williamson 2011-09-15 00:42:16 UTC
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.
Comment 9 Adam Williamson 2011-09-17 00:22:38 UTC
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/ .
Comment 10 Adam Williamson 2011-09-21 05:08:21 UTC
setting to ON_QA as we expect anaconda 16.18 to fix this, we just need mirror images to verify it.
Comment 11 Tim Flink 2011-09-21 05:52:38 UTC
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.
Comment 12 Adam Williamson 2011-09-21 18:41:40 UTC
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.
Comment 13 Adam Williamson 2011-09-21 18:47:11 UTC
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.
Comment 14 Kevin Kofler 2011-09-22 05:30:48 UTC
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?
Comment 15 Richard Hughes 2011-10-03 13:22:04 UTC
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.
Comment 16 Adam Williamson 2011-10-03 15:03:08 UTC
That looks about right, yup. Thanks. We'll test shortly.
Comment 17 Adam Williamson 2011-10-03 17:29:41 UTC
test didn't work :( still grub1 and f15 kernel after upgrade. investigating.
Comment 18 Adam Williamson 2011-10-03 17:46:26 UTC
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.
Comment 19 Adam Williamson 2011-10-03 18:07:45 UTC
that doesn't help, still get the wrong line. maybe we need some debug prints in there.
Comment 20 Adam Williamson 2011-10-03 18:21:37 UTC
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...
Comment 21 Adam Williamson 2011-10-04 07:23:19 UTC
added to commonbugs, since it has not been fixed in time for Beta release :(
Comment 22 Richard Hughes 2011-10-04 08:01:16 UTC
(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.
Comment 23 Adam Williamson 2011-10-04 19:07:31 UTC
releases.txt got broken somehow, so have to wait for that to be fixed before i can test this :/ eta 1hr or so.
Comment 24 Adam Williamson 2011-10-04 20:57:09 UTC
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.
Comment 25 Adam Williamson 2011-10-04 21:45:57 UTC
Nope, anaconda tbs at bootloader installation. trying to get the tb out right now.
Comment 26 Adam Williamson 2011-10-04 21:51:29 UTC
Created attachment 526332 [details] anaconda traceback when it hits bootloader step line in the kickstart was "bootloader --location=mbr"
Comment 27 Adam Williamson 2011-10-04 21:56:40 UTC
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.
Comment 28 Richard Hughes 2011-10-05 08:21:44 UTC
(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.
Comment 29 Kevin Kofler 2011-10-05 08:46:54 UTC
I guess having grub-efi and grub2 both Obsolete grub would make sure they'll get dragged in.
Comment 30 Kevin Kofler 2011-10-05 08:49:57 UTC
(A versioned Obsoletes capturing the version in F15, but not the one in F16, should be sufficient and not make the virtualization folks unhappy.)
Comment 31 Kevin Kofler 2011-10-05 08:57:21 UTC
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?
Comment 32 Elad Alfassa 2011-10-05 09:15:48 UTC
(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
Comment 33 Mads Kiilerich 2011-10-05 09:25:50 UTC
(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
Comment 34 Kevin Kofler 2011-10-05 10:02:42 UTC
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?)
Comment 35 Adam Williamson 2011-10-05 20:22:13 UTC
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.
Comment 36 Mads Kiilerich 2011-10-06 08:56:06 UTC
(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.
Comment 37 Kevin Kofler 2011-10-06 10:59:32 UTC
+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.
Comment 38 Kevin Kofler 2011-10-06 11:00:16 UTC
(and #2 would also fix preupgrade, without having to add any special hacks to preupgrade)
Comment 39 Richard Hughes 2011-10-06 11:47:27 UTC
(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.
Comment 40 Jaroslav Pulchart 2011-10-06 16:57:10 UTC
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 ...
Comment 41 Adam Williamson 2011-10-06 21:15:50 UTC
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?
Comment 42 Hongqing Yang 2011-10-19 04:29:16 UTC
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.
Comment 43 Mads Kiilerich 2011-10-19 23:43:11 UTC
(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.
Comment 44 Adam Williamson 2011-10-20 15:59:50 UTC
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!
Comment 45 Fedora Update System 2011-10-21 14:46:08 UTC
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
Comment 46 Adam Williamson 2011-10-21 16:30:35 UTC
*** Bug 747920 has been marked as a duplicate of this bug. ***
Comment 47 Need Real Name 2011-10-21 16:36:08 UTC
I can't restest - I've upgraded the machine. Thanks though.
Comment 48 Julian Sikorski 2011-10-21 22:12:04 UTC
I was able to preupgrade to F16 with this build.
Comment 49 Jaroslav Pulchart 2011-10-22 08:03:28 UTC
One desktop upgraded - OK, but I have some problem on my laptop. It looks to anaconda issue (?) so I filled bug report #748119.
Comment 50 Fedora Update System 2011-10-22 08:31:01 UTC
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).
Comment 51 Robin Green 2011-10-30 15:18:28 UTC
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).
Comment 52 Mads Kiilerich 2011-10-30 15:29:16 UTC
(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?
Comment 53 Robin Green 2011-10-30 20:54:23 UTC
Sorry, I'm experiencing the same bug as Hongqing Yang, not this bug. Sorry for the noise.
Comment 54 Hongqing Yang 2011-10-31 05:56:09 UTC
when preupgrde from F15 to F16, after installation, still cannot boot into F16, the /etc/grub2.cfg is still blank.
Comment 55 Adam Williamson 2011-10-31 07:07:43 UTC
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
Comment 56 Adam Williamson 2011-10-31 07:08:27 UTC
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.
Comment 57 Fedora Update System 2011-11-02 06:57:09 UTC
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.
Comment 58 Richard Marko 2011-11-03 16:08:21 UTC
*** Bug 751131 has been marked as a duplicate of this bug. ***
Comment 59 Adam Williamson 2011-11-03 19:43:05 UTC
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
Comment 60 Adam Williamson 2011-11-08 06:15:16 UTC
-- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
Comment 61 hevauq 2011-11-08 22:47:03 UTC
I am wondering if there is a way to get the proper kernel and related configuration manually?
Comment 62 Ronald L Humble 2011-11-09 11:36:54 UTC
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.
Comment 63 Carl-Johan Kjellander 2011-11-09 16:28:50 UTC
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?
Comment 64 Daniil Churikov 2011-11-10 10:10:07 UTC
@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
Comment 65 Mads Kiilerich 2011-11-10 10:50:41 UTC
(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
Comment 66 Colin Adams 2011-11-10 14:16:37 UTC
(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?
Comment 67 Kevin Kofler 2011-11-10 14:33:49 UTC
> 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.)
Comment 68 Colin Adams 2011-11-10 14:45:29 UTC
(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.
Comment 69 Nadav Har'El 2011-11-10 16:21:12 UTC
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.
Comment 70 Mads Kiilerich 2011-11-10 16:39:01 UTC
> 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???
Comment 71 Mads Kiilerich 2011-11-10 16:45:49 UTC
(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.
Comment 72 Colin Adams 2011-11-10 16:50:41 UTC
(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.
Comment 73 Nadav Har'El 2011-11-10 17:02:06 UTC
#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.
Comment 74 Mads Kiilerich 2011-11-10 17:22:18 UTC
(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.
Comment 75 Kevin Kofler 2011-11-10 17:28:37 UTC
> #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.
Comment 76 Kevin Kofler 2011-11-10 17:31:21 UTC
As for checking, look in /var/log/yum.log, though I'm not sure whether it is preserved during preupgrade.
Comment 77 Mads Kiilerich 2011-11-10 17:33:39 UTC
(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.
Comment 78 Nadav Har'El 2011-11-10 17:47:28 UTC
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 :(
Comment 79 Alex Lancaster 2011-11-14 19:42:38 UTC
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.
Comment 80 Alex Lancaster 2011-11-14 19:54:41 UTC
(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.
Comment 81 Adam Williamson 2011-11-15 00:35:47 UTC
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
Comment 82 Fedora Update System 2011-11-16 12:55:46 UTC
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
Comment 83 Jens Petersen 2011-11-18 14:38:16 UTC
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...
Comment 84 Jens Petersen 2011-11-24 03:40:16 UTC
Ok another machine was fine - I guess I must have forgotten to re-update just before doing preupgrade on the previous machine.
Comment 85 Fedora Update System 2011-11-30 01:58:45 UTC
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.
Comment 86 Mads Kiilerich 2011-12-09 10:54:21 UTC
*** Bug 758499 has been marked as a duplicate of this bug. ***
Comment 87 fredsilsbee 2011-12-31 17:40:17 UTC
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
Comment 88 Andre Klapper 2012-01-01 18:30:59 UTC
(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.
Comment 89 Panos Kavalagios 2012-02-18 09:45:57 UTC
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.
Comment 90 Adam Williamson 2012-02-19 07:30:27 UTC
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
Comment 91 Panos Kavalagios 2012-02-20 08:20:06 UTC
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)?
Comment 92 Adam Williamson 2012-02-21 02:32:08 UTC
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
Comment 93 Panos Kavalagios 2012-02-22 10:11:51 UTC
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
Comment 94 Adam Williamson 2012-02-22 19:22:35 UTC
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
Comment 95 Adam Williamson 2012-02-22 19:24:16 UTC
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.
Comment 96 Panos Kavalagios 2012-02-23 16:57:12 UTC
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 :)