gcc-4.6.0-10.fc15.x86_64 breaks grub-0.97-71.fc15 and later
by Joshua C.
I've been testing with grub and found an interesting problem. When I
install the package
http://kojipkgs.fedoraproject.org/packages/grub/0.97/71.fc15/x86_64/grub-...
everything is fine and grub works as it should:
[root@localhost x86_64-redhat]# grub
Probing devices to guess BIOS drives. This may take a long time.
GNU GRUB version 0.97-71.fc15 (640K lower / 3072K upper memory)
[ Minimal BASH-like line editing is supported. For the first word, TAB
lists possible command completions. Anywhere else TAB lists the possible
completions of a device/filename.]
grub> root (hd0,1)
root (hd0,1)
Filesystem type is ext2fs, partition type 0x83
grub> setup (hd0)
setup (hd0)
Checking if "/boot/grub/stage1" exists... yes
Checking if "/boot/grub/stage2" exists... yes
Checking if "/boot/grub/e2fs_stage1_5" exists... yes
Running "embed /boot/grub/e2fs_stage1_5 (hd0)"... 26 sectors are embedded.
succeeded
Running "install /boot/grub/stage1 (hd0) (hd0)1+26 p
(hd0,1)/boot/grub/stage2 /boot/grub/grub.conf"... succeeded
Done.
grub> quit
quit
[root@localhost x86_64-redhat]#
When I recompile the grub-rpm and reinstall it I get this:
[root@localhost x86_64-unknown]# grub
Probing devices to guess BIOS drives. This may take a long time.
GNU GRUB version 0.97-71.fc15 (640K lower / 3072K upper memory)
[ Minimal BASH-like line editing is supported. For the first word, TAB
lists possible command completions. Anywhere else TAB lists the possible
completions of a device/filename.]
grub> root (hd0,1)
root (hd0,1)
Filesystem type is ext2fs, partition type 0x83
grub> setup (hd0)
setup (hd0)
Checking if "/boot/grub/stage1" exists... yes
Checking if "/boot/grub/stage2" exists... yes
Checking if "/boot/grub/e2fs_stage1_5" exists... yes
Running "embed /boot/grub/e2fs_stage1_5 (hd0)"... 31 sectors are embedded.
succeeded
Running "install /boot/grub/stage1 (hd0) (hd0)1+31 p
(hd0,1)/boot/grub/stage2 /boot/grub/grub.conf"... failed
Error 6rd: Mismatched or corrupt version of stage1/stage2
grub> quit
quit
[root@localhost x86_64-unknown]#
---------------
As you can see the difference is in the following lines:
Running "embed /boot/grub/e2fs_stage1_5 (hd0)"... 26 sectors are
embedded. (with the downloaded package)
Running "embed /boot/grub/e2fs_stage1_5 (hd0)"... 31 sectors are
embedded. (with the recompiled package)
All newer packages result in the same error "Error 6rd: Mismatched or
corrupt version of stage1/stage2" and grub reports that 31 sectors
have been embedded.
So why does the gcc-4.6.0-10.fc15.x86_64 breaks my package???
12 years, 11 months
Re: GRUB 2 in Ubuntu 9.10
by Neal Gompa
On Wed, Jun 10, 2009 at 9:50 AM, Dennis J. <dennisml(a)conversis.de> wrote:
> On 06/10/2009 10:43 AM, Christopher Brown wrote:
>
>> 2009/6/10 King InuYasha<ngompa13(a)gmail.com>:
>>
>> I would like to see GRUB Legacy replaced in Fedora 12 with GRUB 2,
>>> especially with a couple odd systems here that don't seem to like GRUB
>>> Legacy all that much....
>>>
>>
>> Actually the reverse is true, in that you will find that GRUB 2 will
>> support fewer machines than GRUB Legacy. This is why, as the ubuntu
>> page quite correctly states, "upgrading a bootloader is at best
>> frightening and risky".
>>
>>
> So what is the deal with GRUB development? I find it strange that upstream
> already has declared the old GRUB "Legacy" even though GRUB 2 isn't ready
> for prime time yet. Has the patch for full ext4 support that has been
> mentioned before landed in upstream yet? What is the timetable to get GRUB 2
> ready for primetime?
>
> Regards,
> Dennis
>
>
> --
> fedora-devel-list mailing list
> fedora-devel-list(a)redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-devel-list
>
Well, the existing GRUB used in distros was declared Legacy a long time ago.
GRUB 2 is a rewrite that is supposed to include all the features the various
vendors have been patching into GRUB Legacy, as well as being able to
support EFI and basically supporting what the Chameleon bootloader does in
addition to the GRUB Legacy's support. Though I doubt fake-EFI would be
implemented in GRUB 2....
15 years
Re: Fedora 32/33 livedisks do not boot on M$ system(s)
by Marius Schwarz
Am 03.10.20 um 11:43 schrieb Tomasz Torcz:
> If you do not state the devicename, how does grub choose the correct
>> drive? I don't want to overwrite the bootloader on the ssd.
> There is only one correct ESP partition in EFI system to install
> bootloader to. You can read the code finding it at
> https://github.com/rhboot/grub2/blob/master/util/grub-install.c#L1029
>
>
That seems to be commented incorrectly:
L1045:
/*
The EFI System Partition may have been given directly using
--root-directory.
*/
there is no such option according to man and --help .
grub-install [--modules=MODULES] [--install-modules=MODULES]
[--themes=THEMES] [--fonts=FONTS] [--locales=LOCALES]
[--compress[=no,xz,gz,lzo]] [-d | --directory=DIR]
[--grub-mkimage=FILE] [--boot-directory=DIR]
[--target=TARGET] [--grub-setup=FILE]
[--grub-mkrelpath=FILE] [--grub-probe=FILE]
[--allow-floppy] [--recheck] [--force]
[--force-file-id]
[--disk-module=MODULE] [--no-nvram] [--removable]
[--bootloader-id=ID] [*--efi-directory=DIR*]
INSTALL_DEVICE
could --efi-directory be meant?
### UPDATE ###
.... after investigating the problem with not finding grub.cfg in the
proprosed bootpath /boot/ .. the solution was simple.
The system died not use secure boot, as secure-boot was disabled for the
kernel-surface kernelseries. They are not signed, so no secure boot
possible.
Means: bios is loading "/boot/grub2/grub.cfg" but it can't find it,
because those are symlinks to "/boot/efi/fedora/grub.cfg" but that is
not accessible, because the partition it's linked to, is not mounted
there when grub starts.
those symlinks where necessary to fix some other bugs with grubby,
which has a slight different imagination where to do updates to
grub.cfg, as grub itself has. In other words, one loads from efi path,
one not . So symlinks were there to keep them in Sync. ( documented in a
grub/grubby br @ bz )
Because it worked before the grub2-install with those symlinks (grub.cfg
& grubenv) , there needs to be a different grub-install cmd needed :
which could that be?
(for now my system starts again)
best regards,
Marius
3 years, 8 months
Boot fails with "No Setup Signature" after update following YumUpdateFaq
by rrankin＠ihug.com.au
The Problem:
I recently upgraded a system from Fedora Core 6 to Fedora 8 using the
YumUpdateFaq as a guide. When I tried to reboot the system with kernel
2.6.23.9-85.fc8 the system hung in the boot process with the message "No
Setup Signature". However I could boot the system with kernel
2.6.22.14-72.fc6.
The investigation:
I tried reinstalling the kernel without success. I found on a mailing
list a case where this problem was fixed by running grub-install. When I
did this it also resolved my problem. I also remembered there has a note
in the YumUpdateFaq about possibly needing to do this with a TODO note
by Mads Kiilerich asking when this was required.
I contacted Mads, who acted as a sounding board as I investigated why I
needed to run grub-install. I determined by running "less -f
/boot/grub/stage2" on a backup taken before I ran grub-install that the
version of the GRUB files in /boot/grub was 0.92 whereas the current
GRUB version, since Fedora Core 5, is 0.97.
I determined that when YUM/RPM upgrades or installs GRUB, the files in
/boot/grub do not get updated. This only happens when grub-install is
run. When the system is upgraded from CD/DVD, Anaconda runs
grub-install, although this can be bypassed. I had updated the system
several times up to Fedora Core 6 using CD/DVD but skipped the GRUB
update part of the install.
To run grub-install in Fedora 8 (or 7) it is necessary that
/boot/grub/device.map has the new drive device naming. This file, which
is created by Anaconda, needs to be modified from "(hd0) /dev/hda" to
"(hd0) /dev/sda" if it was created in Fedora core 6 or earlier.
The Solution:
Mads and I came up with the following changes to the YumUpdateFaq.
1> In section 4 "Do the upgrade", the following was added
Before booting you should usually install the bootloader from your
new grub by running
* grub-install BOOTDEVICE
- where BOOTDEVICE usually is /dev/sda
2> To the end of the first paragraph under "Fedora Core 6->Fedora 7"
discussing the IDE drive device name change, the following was added.
In /boot/grub/device.map change /dev/hd.. to /dev/sd.. before
running grub-install - and don't change (hd0). Changing
/boot/grub/grub.conf may also be required.
Regards,
Roy Rankin
16 years, 4 months
Re: [Test-Announce] Note for people with EFI installs: install grub-efi!
by Kalev Lember
On 10/12/2011 04:17 AM, Adam Williamson wrote:
> Hey, folks. There's a grub update in updates-testing atm (being pushed
> stable soon) which splits the EFI stuff off into a new grub-efi
> subpackage. If you have an EFI install of F16 you will need to have
> grub-efi installed or else your system won't boot any more. So, if you
> have an EFI install, install the grub-efi package!
Turning Beta installs into unbootable bricks doesn't sound very good. If
installing grub-efi on upgrades is enough to make it work, this should
be easy to solve.
I can think of two ways to convince yum to always install grub-efi on
upgrades:
a) have grub2 require grub-efi; or
b) have grub-efi obsolete grub.
I would personally prefer (a), but (b) should also work. grub2 is
already obsoleting grub, and if grub-efi was made to _also_ obsolete
grub, then yum should install _both_ grub2 and grub-efi on upgrades.
--
Kalev
12 years, 8 months
Re: [Test-Announce] Note for people with EFI installs: install grub-efi!
by Adam Williamson
On Wed, 2011-10-12 at 12:29 +0300, Kalev Lember wrote:
> On 10/12/2011 04:17 AM, Adam Williamson wrote:
> > Hey, folks. There's a grub update in updates-testing atm (being pushed
> > stable soon) which splits the EFI stuff off into a new grub-efi
> > subpackage. If you have an EFI install of F16 you will need to have
> > grub-efi installed or else your system won't boot any more. So, if you
> > have an EFI install, install the grub-efi package!
>
> Turning Beta installs into unbootable bricks doesn't sound very good. If
> installing grub-efi on upgrades is enough to make it work, this should
> be easy to solve.
>
> I can think of two ways to convince yum to always install grub-efi on
> upgrades:
> a) have grub2 require grub-efi; or
> b) have grub-efi obsolete grub.
>
> I would personally prefer (a), but (b) should also work. grub2 is
> already obsoleting grub, and if grub-efi was made to _also_ obsolete
> grub, then yum should install _both_ grub2 and grub-efi on upgrades.
Yes - it's not that we necessarily intended to leave it that way, but I
wanted to give people a heads-up as the problem exists _now_.
I think b) sounds closer to our goal here, if it does actually work that
way (I thought yum would just pick one of the obsoleting packages).
Peter?
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
http://www.happyassassin.net
12 years, 8 months
Re: [Test-Announce] Note for people with EFI installs: install grub-efi!
by Peter Robinson
On Wed, Oct 12, 2011 at 4:26 PM, Adam Williamson <awilliam(a)redhat.com> wrote:
> On Wed, 2011-10-12 at 12:29 +0300, Kalev Lember wrote:
>> On 10/12/2011 04:17 AM, Adam Williamson wrote:
>> > Hey, folks. There's a grub update in updates-testing atm (being pushed
>> > stable soon) which splits the EFI stuff off into a new grub-efi
>> > subpackage. If you have an EFI install of F16 you will need to have
>> > grub-efi installed or else your system won't boot any more. So, if you
>> > have an EFI install, install the grub-efi package!
>>
>> Turning Beta installs into unbootable bricks doesn't sound very good. If
>> installing grub-efi on upgrades is enough to make it work, this should
>> be easy to solve.
>>
>> I can think of two ways to convince yum to always install grub-efi on
>> upgrades:
>> a) have grub2 require grub-efi; or
>> b) have grub-efi obsolete grub.
>>
>> I would personally prefer (a), but (b) should also work. grub2 is
>> already obsoleting grub, and if grub-efi was made to _also_ obsolete
>> grub, then yum should install _both_ grub2 and grub-efi on upgrades.
>
> Yes - it's not that we necessarily intended to leave it that way, but I
> wanted to give people a heads-up as the problem exists _now_.
>
> I think b) sounds closer to our goal here, if it does actually work that
> way (I thought yum would just pick one of the obsoleting packages).
> Peter?
It will only pick up the replacement package if the package has a
provides line as well.
Peter
12 years, 8 months
Re: [Test-Announce] Note for people with EFI installs: install grub-efi!
by Peter Jones
On 10/12/2011 11:26 AM, Adam Williamson wrote:
> On Wed, 2011-10-12 at 12:29 +0300, Kalev Lember wrote:
>> On 10/12/2011 04:17 AM, Adam Williamson wrote:
>>> Hey, folks. There's a grub update in updates-testing atm (being pushed
>>> stable soon) which splits the EFI stuff off into a new grub-efi
>>> subpackage. If you have an EFI install of F16 you will need to have
>>> grub-efi installed or else your system won't boot any more. So, if you
>>> have an EFI install, install the grub-efi package!
>>
>> Turning Beta installs into unbootable bricks doesn't sound very good. If
>> installing grub-efi on upgrades is enough to make it work, this should
>> be easy to solve.
>>
>> I can think of two ways to convince yum to always install grub-efi on
>> upgrades:
>> a) have grub2 require grub-efi; or
>> b) have grub-efi obsolete grub.
>>
>> I would personally prefer (a), but (b) should also work. grub2 is
>> already obsoleting grub, and if grub-efi was made to _also_ obsolete
>> grub, then yum should install _both_ grub2 and grub-efi on upgrades.
>
> Yes - it's not that we necessarily intended to leave it that way, but I
> wanted to give people a heads-up as the problem exists _now_.
>
> I think b) sounds closer to our goal here, if it does actually work that
> way (I thought yum would just pick one of the obsoleting packages).
> Peter?
Yeah, b definitely looks like the right thing to do.
--
Peter
12 years, 8 months
Re: grub-efi replaces grub and grub2 along the way?
by Adam Williamson
On Thu, 2011-10-13 at 23:32 -0700, darrell pfeifer wrote:
> I did an update which I thought was going to do everything but grub
> but this happened:
>
>
> # yum update --exclude=grub
> Loaded plugins: langpacks, presto, refresh-packagekit
> Setting up Update Process
> Resolving Dependencies
> --> Running transaction check
> ---> Package grub.x86_64 1:0.97-79.fc16 will be obsoleted
> ---> Package grub-efi.x86_64 1:0.97-83.fc17 will be obsoleting
> ---> Package grub2.x86_64 1:1.99-9.fc17 will be obsoleting
>
>
>
> the final result was
>
>
> Dependencies Resolved
>
>
> ========================================================================================================================
> Package Arch Version
> Repository Size
> ========================================================================================================================
> Installing:
> grub-efi x86_64
> 1:0.97-83.fc17 koji 120 k
> replacing grub.x86_64 1:0.97-79.fc16
> grub2 x86_64
> 1:1.99-9.fc17 koji 1.2 M
> replacing grub.x86_64 1:0.97-79.fc16
>
Yes, that's intended.
> which wasn't why I wanted at all since I was trying to avoid grub2 for
> the moment. I also thought from the list that grub-efi was going to be
> a subpackage of grub but maybe I read too quickly.
It is.
>
> I didn't look too closely and did a kernel update later. This resulted
> in another problem with grubby
> But in fact grub.conf did get updated.
Yup, that seems to be what happens.
> So the question is, what do I have now? My guess is that while I have
> this system running I should quickly follow the instructions to boot
> with grub2.
Actually booting should still work, as grub will still be in the MBR.
But to be 'supported' you should switch to grub2, yes.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
http://www.happyassassin.net
12 years, 7 months
Re: grub (v1) in f18?
by Matthew Miller
On Fri, Dec 07, 2012 at 10:56:44AM +0200, Panu Matilainen wrote:
> >>I haven't experienced this with F16, F17 or so far F18. What I'm seeing is:
> >>
> >>yum install/update grub gets me grub legacy.
> >>yum install/update grub-efi gets me grub legacy efi.
> >>yum install/update grub2 gets me grub2.
> >>yum install/update grub2-efi gets me grub2 efi.
> >
> >If you have *both* installed, grub2 will want to nuke grub every time an
> >update shows up, IIRC.
>
> Yum and rpm refuse to install packages which are obsoleted by an
> installed package, so you can't really have both. Unless you first
> install grub2 and then grub with 'rpm --nodeps'...
But, it's not just if both installed, is it? The grub2 package obsoletes
grub, and yum follows obsoletes by default in dependency resolution.
Panu, you would know this better than I, so clearly I'm going crazy
somewhere. If you could explain how, I'd appreciate it. :)
Here's on an F17 image booted in a cloud service (so no grub at all
installed initially):
$ rpm -qa |grep grub
grubby-8.11-1.fc17.x86_64
(As expected, just grubby; nothing else matches.)
$ sudo yum install grub
[...]
Package grub is obsoleted by grub2, trying to install
1:grub2-2.0-0.39.fc17.x86_64 instead
Resolving Dependencies
--> Running transaction check
---> Package grub2.x86_64 1:2.0-0.39.fc17 will be installed
--> Processing Dependency: grub2-tools = 1:2.0-0.39.fc17 for package:
--> 1:grub2-2.0-0.39.fc17.x86_64
[...and so on]
Even "yum install grub-0.97" gets this behavior. Now, I can set
"obsoletes=0" in /etc/yum.conf if I _really_ want to get grub installed, but
a) I don't actually want to change the default behavior of yum on the final
image
b) I don't want users to get messed up if they innocently change that back
to its default
c) I'm not even sure how I would go about changing that pre-transaction in
appliance-creator and other tools
--
Matthew Miller ☁☁☁ Fedora Cloud Architect ☁☁☁ <mattdm(a)fedoraproject.org>
11 years, 6 months
