Heads up for anyone using Rawhide with Secure Boot enabled: *do not*
update to grub2 version 2.0.6-27! Due to a chain of unfortunate events,
it is in today's Rawhide compose, but is not signed with the official
Fedora SB keys and will not be trusted. If you update to it, your
system will not
> >>>> # rpm -qa | egrep 'grub|prober|shim'
> >>>> #
> >
> >>>> This F34 installation has no need of any bootloader. Yet:
> >>>> # dnf system-upgrade download --releasever=35 --skip-broken
> --allowerasing --best
> >&g
em-upgrade download --releasever=35 --skip-broken --allowerasing
--best
...
Error:
Problem: package grubby-8.40-55.fc35.x86_64 requires grub2-tools-minimal, but
none of the providers can be installed
- conflicting requests
- package grub2-tools-minimal-1:2.06-6.fc35.x86_64 is filtered out
;>> # dnf system-upgrade download --releasever=35 --skip-broken --allowerasing
>>> --best
>>> ...
>>> Error:
>>> Problem: package grubby-8.40-55.fc35.x86_64 requires grub2-tools-minimal,
>>> but
>>> none of the providers can be insta
upgrade download --releasever=35 --skip-broken --allowerasing
> > --best
> > ...
> > Error:
> > Problem: package grubby-8.40-55.fc35.x86_64 requires grub2-tools-minimal,
> > but
> > none of the providers can be installed
> > - conflicting requests
> Problem: package grubby-8.40-55.fc35.x86_64 requires grub2-tools-minimal, but
> none of the providers can be installed
> - conflicting requests
> - package grub2-tools-minimal-1:2.06-6.fc35.x86_64 is filtered out by
> exclude
> filtering
>
Do you have soft dependencies
r:
> Problem: package grubby-8.40-55.fc35.x86_64 requires grub2-tools-minimal, but
> none of the providers can be installed
> - conflicting requests
> - package grub2-tools-minimal-1:2.06-6.fc35.x86_64 is filtered out by
> exclude
> filtering
> #
>
> Does anyone know w
# rpm -qa | egrep 'grub|prober|shim'
#
This F34 installation has no need of any bootloader. Yet:
# dnf system-upgrade download --releasever=35 --skip-broken --allowerasing
--best
...
Error:
Problem: package grubby-8.40-55.fc35.x86_64 requires grub2-tools-minimal, but
none of the pro
Hi,
I wrote this problem as a bug, Bug ID: 1945821, a few days ago. Has anyone else
seen this?
Best regards,
George...
___
test mailing list -- test@lists.fedoraproject.org
To unsubscribe send an email to test-le...@lists.fedoraproject.org
Fedora Code
On Tue, Mar 16, 2021 at 10:50 AM David wrote:
>
> I have about an hour of usage with my new fresh install of Rawhide WS on
> my old NVMe. Working great so far.
>
> The following grub2 packages came pre-installed
>
> grub2-common.noarch 1:2.04-35.f
I have about an hour of usage with my new fresh install of Rawhide WS on
my old NVMe. Working great so far.
The following grub2 packages came pre-installed
grub2-common.noarch 1:2.04-35.fc34
grub2-efi-x64.x86_64 1:2.04-35.fc34
grub2
On Mon, Sep 7, 2020 at 10:14 AM George R Goffe wrote:
>
> Chris,
>
> Thank you for your help.
>
> I had to re-create the initramfs as well and, change fstab too. The process
> was up hill in both directions... due to my fumbling. Sigh.
>
> I now have a VM FC34 x86_64 (Rawhide) running with btrfs
ith FC34 ina VM and have backed up /boot; put a btrfs fs
> on the partition; restored from the backup, updated fstab but grub2 still
> goes into rescue mode. This tells me that there's something I don't know
> which is entirely possible. Could it be a missing driver in the i
On Wed, Sep 2, 2020 at 3:42 PM George R Goffe via test
wrote:
>
> Hi,
>
> I'm playing around with FC34 ina VM and have backed up /boot; put a btrfs fs
> on the partition; restored from the backup, updated fstab but grub2 still
> goes into rescue mode. This tells me t
Hi,
I'm playing around with FC34 ina VM and have backed up /boot; put a btrfs fs on
the partition; restored from the backup, updated fstab but grub2 still goes
into rescue mode. This tells me that there's something I don't know which is
entirely possible. Could it be a missin
Igor, I rejected your message for the list as the screenshot was far
too large a file - there's no need for >1MB screenshots, just resize it
to a smaller size before attaching.
openQA already caught that bug and I filed it:
https://bugzilla.redhat.com/show_bug.cgi?id=1624532
it is specific to x8
On Wed, 31 Jan 2018 13:58:52 -0800
Kevin Fenzi wrote:
> Hey stan.
>
> I ran into this same issue here. It seems it's caused by
> environment-modules. There's a bug on it:
>
> https://bugzilla.redhat.com/show_bug.cgi?id=1539856
Thanks, that's it! I checked, and that package was updated on the
Hey stan.
I ran into this same issue here. It seems it's caused by
environment-modules. There's a bug on it:
https://bugzilla.redhat.com/show_bug.cgi?id=1539856
kevin
signature.asc
Description: OpenPGP digital signature
___
test mailing list -- test
On Wed, 31 Jan 2018 07:40:43 +0100
Adam Williamson wrote:
> That's definitely weird! My first thought would be that it's possibly
> a profile bug; check ~/.bash_profile , ~/.bashrc and /etc/profile.d/
> for anything that looks odd. Try as a different user; does it happen
> there?
The behavior se
this. There is no issue with dracut or
> grub2-mkconfig themselves.
That's definitely weird! My first thought would be that it's possibly a
profile bug; check ~/.bash_profile , ~/.bashrc and /etc/profile.d/ for
anything that looks odd. Try as a different user; does it happen there?
--
is, the problem is in the automatic routing of
command output to less, like systemd does. Not sure why bash would
suddenly start doing this. There is no issue with dracut or
grub2-mkconfig themselves.
___
test mailing list -- test@lists.fedoraproject.org
To unsubscribe send an email to test-le...@lists.fedoraproject.org
t; you're running, what I have now:
> >
> > 4.14.14-300.fc27.x86_64
> > dracut-046-92.git20180118.fc28.x86_64
> > grub2-tools-2.02-24.fc28.x86_64
>
> > Also I'm using enforcing=0 because I'm getting so many avc and audit
> > related messages it's plugg
On Sun, 2018-01-28 at 18:57 -0700, stan wrote:
> On Mon, 29 Jan 2018 01:34:38 +0100
> Adam Williamson wrote:
>
> Thanks for the reply.
>
> > Hi Stan! One *possible* source of this might be a recent glibc change:
> >
> > * Fri Jan 19 2018 Björn Esser -
> > 2.26.9000-46
> > - Remove deprecated l
On Mon, 29 Jan 2018 01:34:38 +0100
Adam Williamson wrote:
Thanks for the reply.
> Hi Stan! One *possible* source of this might be a recent glibc change:
>
> * Fri Jan 19 2018 Björn Esser -
> 2.26.9000-46
> - Remove deprecated libcrypt, gets replaced by libxcrypt
>
> you could try downgrading
00.fc27.x86_64
> dracut-046-92.git20180118.fc28.x86_64
> grub2-tools-2.02-24.fc28.x86_64
Name: kernel
Version : 4.15.0
Release : 0.rc9.git4.1.20180128.fc28
Architecture: x86_64
Install Date: Sun 28 Jan 2018 10:49:34 AM MST
Name: dracut
Version : 046
Release
On Sun, 2018-01-28 at 11:49 -0700, stan wrote:
> Just compiled a custom kernel. When I tried to create a custom
> initramfs, the job seemed to create the file, but hung indefinitely in
> D status, with call_r. Trying to recreate the grub.cfg file by running
> grub2-mkconfig al
On Sun, Jan 28, 2018 at 11:49 AM, stan wrote:
> Just compiled a custom kernel. When I tried to create a custom
> initramfs, the job seemed to create the file, but hung indefinitely in
> D status, with call_r. Trying to recreate the grub.cfg file by running
> grub2-mkconfig al
Just compiled a custom kernel. When I tried to create a custom
initramfs, the job seemed to create the file, but hung indefinitely in
D status, with call_r. Trying to recreate the grub.cfg file by running
grub2-mkconfig also went into uninterruptable sleep. When I ran this
two weeks ago
ded grub packages, without any
> > > complaints,
> > > even though no F26 grub* rpms were installed, needed or wanted. :-(
> > That is expected because grub2 is one of the packages found in the
> > Fedora Workstation group, and a system upgrade is does distrosync by
> > defa
df /
man dnf
dnf update --releasever=27 dnf* rpm* system* libsol* hawke* fedor* glibc*
dnf update --releasever=27 --allowerasing kd* kf* q* plas* x* gl* y* z*
dnf update --releasever=27 --allowerasing m* n* o* r* s* t* u* v* w*
dnf update a* b* c* d* e* f* g* h* i* j*
rpmqa grub
dnf remove grubby
d
ages, without any
>>> complaints,
>>> even though no F26 grub* rpms were installed, needed or wanted. :-(
>
>> That is expected because grub2 is one of the packages found in the
>> Fedora Workstation group, and a system upgrade is does distrosync by
>> default.
s were installed, needed or wanted. :-(
> That is expected because grub2 is one of the packages found in the
> Fedora Workstation group, and a system upgrade is does distrosync by
> default. One of the upgrade requirements for the various "products" in
> Fedora is that the
On Sat, Nov 11, 2017 at 12:59 PM, Felix Miata wrote:
> Chris Murphy composed on 2017-11-11 12:35 (UTC-0700):
>
>> Chris Murphy wrote:
>
>>> $ sudo dnf system-upgrade download --refresh --releasever=27
>
>>> Error:
>>> Problem: package grub2-efi-modul
Chris Murphy composed on 2017-11-11 12:35 (UTC-0700):
> Chris Murphy wrote:
>> $ sudo dnf system-upgrade download --refresh --releasever=27
>> Error:
>> Problem: package grub2-efi-modules-1:2.02-0.40.fc26.x86_64 requires
>> grub2-tools = 1:2.02-0.40.fc26, but n
On Sat, Nov 11, 2017 at 12:35 PM, Chris Murphy wrote:
> But in order to get dnf system-upgrade to proceed, I had to remote
> both grub2 and grub2-efi-modules packages.
s/remote/remove
--
Chris Murphy
___
test mailing list -
On Fri, Nov 10, 2017 at 11:41 PM, Chris Murphy wrote:
> $ sudo dnf system-upgrade download --refresh --releasever=27
>
> Error:
> Problem: package grub2-efi-modules-1:2.02-0.40.fc26.x86_64 requires
> grub2-tools = 1:2.02-0.40.fc26, but none of the providers can be
> installed
&
Hi, folks. jsedlak asked me something on IRC but he was gone when I
woke up, so I figured I'd send the answer here in case it was of
interest to anyone else =) He asked:
06:19:28> adamw: why isn't grub2-2.02-0.34 in stable
repos? I'm hitting #1320273 with windows dualboot
I'm getting this on a clean Rawhide UEFI install, which includes
grub2-2.02-0.6.fc21.x86_64.
[root@localhost ~]# grub2-mkconfig -o /boot/efi/EFI/fedora/grub.cfg
Generating grub configuration file ...
Found linux image: /boot/vmlinuz-3.16.0-0.rc3.git2.1.fc21.x86_64
Found initrd image:
Hi, folks. Trying to keep the F19 release week experience as good as we
can make it, it'd be great if we could get karma on these updates:
https://admin.fedoraproject.org/updates/grub2-2.00-23.fc19
https://admin.fedoraproject.org/updates/os-prober-1.58-3.fc19
grub2 fixes the Obsolete
On 06/23/2013 10:04 PM, Frank McCormick wrote:
On 06/23/2013 08:18 PM, Matthew Miller wrote:
On Sun, Jun 23, 2013 at 03:54:33PM -0600, Chris Murphy wrote:
bash -x grub2-mkconfig -o /boot/grub2/grub.cfg
Post the result somewhere, then post the URL here. Sounds like an OS Prober
issue, which is
On Sun, Jun 23, 2013 at 03:54:33PM -0600, Chris Murphy wrote:
> bash -x grub2-mkconfig -o /boot/grub2/grub.cfg
> Post the result somewhere, then post the URL here. Sounds like an OS Prober
> issue, which is more problematic on UEFI than BIOS usually.
Try fpaste:
$ echo foo |fpaste
On 06/20/2013 08:04 PM, Kevin Fenzi wrote:
> On Thu, 20 Jun 2013 11:18:18 +0530
> Kashyap Chamarthy wrote:
>
>> On 06/20/2013 11:12 AM, Kashyap Chamarthy wrote:
>>> Heya,
>>>
>>> I've been using F19 for a while. For the past couple of days, I
>>> don't see grub picking up latest kernel.
>
> ...s
t; $ uname -r
> 3.10.0-0.rc2.git1.2.fc20.x86_64
> --
>
>
> -> Available kernels:
> --
> $ rpm -q kernel
> kernel-3.10.0-0.rc2.git1.2.fc20.x86_64
> kernel-3.10.0-0.rc5.git0.1.fc20.x86_64
> kernel-3.10.0-0.rc6.git0.4.fc20.x86_64
> --
>
> ->
-q kernel
kernel-3.10.0-0.rc2.git1.2.fc20.x86_64
kernel-3.10.0-0.rc5.git0.1.fc20.x86_64
kernel-3.10.0-0.rc6.git0.4.fc20.x86_64
--
-> I only notice 2 Kernel entries in grub2.conf: (shouldn't it be 3?)
--
$ grep menuentry /etc/grub2.cfg
if [ x"${feature_menuentry_id}" = xy ]
On Mon, 2013-06-17 at 02:22 -0700, Chuck Forsberg WA7KGX N2469R wrote:
> On 06/17/2013 02:10 AM, Ed Greshko wrote:
> > On 06/17/13 16:49, Joachim Backes wrote:
> >> sudo yum install grub2-starfield
> >> Loaded plugins: langpacks, refresh-packagekit
> >>
e old installs work - we don't want to
> Require the subpackage, because we don't want it installed on fresh
> installs (and especially on live images where space is critical),
> but obviously we've got no other way to pull it in on old installations.
Have them both obsolete
On Mon, Jun 17, 2013 at 12:55:40AM -0700, Adam Williamson wrote:
> On Mon, 2013-06-17 at 08:55 +0200, Joachim Backes wrote:
> > Hi all testers,
> >
> > the "jumbo" update from this morning (Germany!) includes an update of
> > grub2 and grub2-tool
On 06/17/2013 11:10 AM, Ed Greshko wrote:
On 06/17/13 16:49, Joachim Backes wrote:
sudo yum install grub2-starfield
Loaded plugins: langpacks, refresh-packagekit
No package grub2-starfield available.
Error: Nothing to do
grub2-starfield-theme
Hi Ed,
thanks. I could install it, but this
On 06/17/2013 02:10 AM, Ed Greshko wrote:
On 06/17/13 16:49, Joachim Backes wrote:
sudo yum install grub2-starfield
Loaded plugins: langpacks, refresh-packagekit
No package grub2-starfield available.
Error: Nothing to do
grub2-starfield-theme
I installed that, and memtest*, then redid the
On 06/17/13 16:49, Joachim Backes wrote:
> sudo yum install grub2-starfield
> Loaded plugins: langpacks, refresh-packagekit
> No package grub2-starfield available.
> Error: Nothing to do
grub2-starfield-theme
--
The only thing worse than a poorly asked question is a cryptic answ
On 06/17/2013 09:55 AM, Adam Williamson wrote:
On Mon, 2013-06-17 at 08:55 +0200, Joachim Backes wrote:
Hi all testers,
the "jumbo" update from this morning (Germany!) includes an update of
grub2 and grub2-tools to the version given in the subject.
Problems:
1. If booting, grub2
On Mon, 2013-06-17 at 08:55 +0200, Joachim Backes wrote:
> Hi all testers,
>
> the "jumbo" update from this morning (Germany!) includes an update of
> grub2 and grub2-tools to the version given in the subject.
>
> Problems:
>
> 1. If booting, grub2 compl
On 06/17/2013 09:32 AM, Ed Greshko wrote:
On 06/17/13 14:55, Joachim Backes wrote:
Hi all testers,
the "jumbo" update from this morning (Germany!) includes an update of grub2 and
grub2-tools to the version given in the subject.
Problems:
1. If booting, grub2 complains about
/
On 06/17/2013 09:32 AM, Ed Greshko wrote:
On 06/17/13 14:55, Joachim Backes wrote:
Hi all testers,
the "jumbo" update from this morning (Germany!) includes an update of grub2 and
grub2-tools to the version given in the subject.
Problems:
1. If booting, grub2 complains about
/
On 06/17/13 14:55, Joachim Backes wrote:
> Hi all testers,
>
> the "jumbo" update from this morning (Germany!) includes an update of grub2
> and grub2-tools to the version given in the subject.
>
> Problems:
>
> 1. If booting, grub2 complains about
>
> /bo
Hi all testers,
the "jumbo" update from this morning (Germany!) includes an update of
grub2 and grub2-tools to the version given in the subject.
Problems:
1. If booting, grub2 complains about
/boot/grub2/themes/system/DejeVuSans-10.pf2 not found
/boot/grub2/themes/system/DejeVuS
On Mon, 10 Jun 2013 17:46:21 +0300
Cristian Sava wrote:
> Sometime back I had a similar problem and I discovered that my old grub
> install (other partition) was used. Do you mind to check?
I don't have an actual problem. It is definitely using the
new install to boot from because it offers the n
Yes. The code in the MBR jumps to a specific LBA in the MBR gap where core.img
is installed. Once that's loaded, grub understands the /boot filesystem, and
can locate and load normal.mod, grub.cfg, and the modules the grub.cfg
specifies for loading.
The prefix for where core.img looks is baked
subdirectory of /, not
> a separate partition).
>
> My old f18 /dev/sda3 partition is the only one marked
> as "boot".
>
> So how the heck is grub2 locating and booting the
> /dev/sda2 /boot stuff? Is there a pointer stashed in
> the MBR telling it where to l
only one marked
as "boot".
So how the heck is grub2 locating and booting the
/dev/sda2 /boot stuff? Is there a pointer stashed in
the MBR telling it where to look?
Just curious :-).
--
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test
https://bugzilla.redhat.com/show_bug.cgi?id=961533
This bug is still a problem even after updating grub and reinstalling the
bootloader code, recreating the grub.cfg, and then updating the kernel. The
grub.cfg doesn't appear to be malformed.
Is this bug properly assigned? It's not getting any a
y but shouldn't cause any critical issues.
I'm not sure we can practically fix it for you, but if you re-generate
your grub2 config it'll go away. Possibly the best thing to do with this
is just to leave it alone.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: Ad
Same with rawhide.
This is just a warning after upgrading.
Prior to this no problems here.
--
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test
On Sat, 2013-05-18 at 09:50 +0200, Joachim Backes wrote:
> On 05/18/2013 08:41 AM, Joachim Backes wrote:
> > Hi F19 testers,
> >
> > after having applied all F19 updates and rebooting, I received a grub
> > error message:
> >
> > */boot/grub2/themes/system/fi
On 05/18/2013 08:41 AM, Joachim Backes wrote:
Hi F19 testers,
after having applied all F19 updates and rebooting, I received a grub
error message:
*/boot/grub2/themes/system/fireworks.png not found*
It seems that I got rid from this file by the updates.
I could solve the problem by copying
Hi F19 testers,
after having applied all F19 updates and rebooting, I received a grub
error message:
*/boot/grub2/themes/system/fireworks.png not found*
It seems that I got rid from this file by the updates.
I could solve the problem by copying that file from a backup.
Anybody sees this
I installed today's F19 rsync on my office machine.
As usual, the install discovered the Win7 partition
but not the Spherical Cow partition.
After installing memtest and running memtest-seup
I copied/pasted the displayed command to update grub.cfg.
Upon rebooting and selecting Spherical Cow the s
On Sat, 10 Nov 2012 02:27:48 -0800 (PST)
Sergio wrote:
> Have you fixed /etc/default/grub ?
Got it:
/etc/sysconfig/i18n
cat SYSFONT...
--
Regards,
Frank
--
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test
On Sat, 10 Nov 2012 02:27:48 -0800 (PST)
Sergio wrote:
> > --
>
> Have you fixed /etc/default/grub ?
Yes, all the obvious things seem to be done.
--
Regards,
Frank
--
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test
--- Em sáb, 10/11/12, Frank Murphy escreveu:
> De: Frank Murphy
> Assunto: Rawhide /etc/grub2.cfg KEYTABLE SYSFONT
> Para: test@lists.fedoraproject.org
> Data: Sábado, 10 de Novembro de 2012, 6:45
> After each kernel update,
> KEYTABLE, SYSFONT
> re-appear on the kerne
After each kernel update,
KEYTABLE, SYSFONT
re-appear on the kernel line.
This box has been yum-updated
F16>F17(Rawhide)>F18>Rawhide>F19-Rawhide
So what do I extra manual steps to remove "old Stuff" from the system.
Fully updated using, kernel-nodebug.repo Xfce
--
Regards,
Frank
--
test maili
ake sure that the lastest kernel is booted?
>>
>> I don't know if a bugzilla exists for this situation. Grub 2 appears to be
>> misbehaving as I cannot add FreeBSD to the menu. The trick worked in Fedora
>> 17 but not here :(
>
> Possibly GRUB2's grub.c
or this situation. Grub 2 appears to be
> misbehaving as I cannot add FreeBSD to the menu. The trick worked in Fedora
> 17 but not here :(
Possibly GRUB2's grub.cfg format has changed, and grubby needs to be updated
since that's what updates grub.cfg after a kernel update, not
Dear folks,
running Fedora 18 alpha and have seen new kernel releases, but the older kernel
still boots :(
[olivares@localhost ~]$ rpm -qa kernel*
kernel-modules-extra-3.6.0-0.rc4.git2.1.fc18.i686
kernel-modules-extra-3.6.0-0.rc7.git1.4.fc18.i686
kernel-devel-3.6.0-0.rc7.git1.4.fc18.i686
kernel-
#235: request: add tests for new grub2 stage2 device types
-+--
Reporter: dlehman | Owner: pschindl
Type: task| Status: new
Priority: major | Milestone:
Component: Test cases |Version:
Resolution
#235: request: add tests for new grub2 stage2 device types
--+--
Reporter: dlehman | Owner: pschindl
Type: task | Status: new
Priority: major| Milestone:
Component: Test Review |Version:
Resolution
### BEGIN /etc/grub.d/10_linux ###
menuentry 'Red Hat Linux (3.5.0-0.rc6.git0.2.fc18.x86_64)' --class
fedora --class gnu-linux --class gnu --class os $menuentry_id_option
'gnulinux-simple-34748375-c797-4d5c-9990-3e46f3f74b6f'
grubby-8.15-1.fc18.x86_64
grub2-2.00-1.fc18.x86
https://www.virtualbox.org/ticket/10709
--
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test
I've installed rawhide throught the method of using fc17 x86_64
netboot.iso and specifying inst.repo=
currently works like a charm.
In the current rawhide: control-center has some serious problems.
Authentication dialogues for unlock requests put the dialog box behind
the main box and it wont
start --console some rawhide\branched guest
and prevent grub2 updates from changing it
it's in /etc/grub.d/10_linux I believe.
Bash scripting being one of thing, I'll eventually get to,
currently might as well be looking up a Beefy Miracles
in it's raw organic state.
I
--
Regar
On Mon, May 14, 2012 at 12:40 AM, cornel panceac wrote:
>
>
>> https://bugzilla.redhat.com/show_bug.cgi?id=801535
>
>
>
Thanks for pointing that out.
--
Regards,
Pratyush Sahay
--
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/te
2012/5/13 Pratyush Sahay
> Hello,
>
> Today installed F17-TC5 from DVD, and have F16(upgraded from F15) and LMDE
> pre-installed. The menu entries in grub2 seem to be showing some anomalous
> behaviour:
>
> 1) The main grub2 menu shows F17, F16 and LMDE along with their
Hello,
Today installed F17-TC5 from DVD, and have F16(upgraded from F15) and LMDE
pre-installed. The menu entries in grub2 seem to be showing some anomalous
behaviour:
1) The main grub2 menu shows F17, F16 and LMDE along with their respective
advanced options list item. An 'e' on F16
t pci=nomsi noapic irqpoll"
#GRUB_BACKGROUND=/boot/danbo_cold_evening-wallpaper-1680x1050.jpg
GRUB_DISABLE_RECOVERY="true"
>
Initially I wanted to add background which was not taken up after I did
"grub2-mkconfig -o /boot/grub2/grub.cfg". But then I commented it out.
later
Dear Folks,
On 06/05/12 23:09 -0400, Jayson Rowe wrote:
I have /boot on RAID 1, (all my partitions are RAID 1).
What finally got me able to boot was (using a live USB image,
F17-Beta), I changed the /boot partition from RAID 1 to two non-raid
ext4 partitions. Then I could run grub2-install
On Mon, May 07, 2012 at 01:00:42PM +1000, Nick Urbanik wrote:
> Dear Jayson,
>
> THank you!
>
> On 06/05/12 22:36 -0400, Jayson Rowe wrote:
> >On Mon, May 07, 2012 at 12:22:32PM +1000, Nick Urbanik wrote:
> >Possibly could be related to this bug:
> >https://bugzilla.redhat.com/show_bug.cgi?id=809
On 05/07/2012 10:57 AM, Nick Urbanik wrote:
> No, and I am still running the old F16 kernel:
> $ uname -r
> 3.3.4-1.fc16.x86_64
Oh, so they you didn't fully update to an F17-Beta..
So, my other suggestion about specifying "--target=i386-pc" doesn't apply
Yeah...
https://bugzilla.redha
Dear Jayson,
THank you!
On 06/05/12 22:36 -0400, Jayson Rowe wrote:
On Mon, May 07, 2012 at 12:22:32PM +1000, Nick Urbanik wrote:
Possibly could be related to this bug:
https://bugzilla.redhat.com/show_bug.cgi?id=809111
Exactly!
Did a little searching and found this GRUB bug on gnu.org as w
Dear Ed,
On 07/05/12 10:37 +0800, Ed Greshko wrote:
On 05/07/2012 10:22 AM, Nick Urbanik wrote:
Forgot to ask from your question on the users list Is this a 32-bit
installation?
No, and I am still running the old F16 kernel:
$ uname -r
3.3.4-1.fc16.x86_64
--
Nick Urbanik http://nicku.org
gt; seems okay so far, except for this:
>>
>> $ sudo grub2-install /dev/sda
>> /usr/share/grub/grub-mkconfig_lib: line 53: 29562 Segmentation fault
>> (core dumped) "${grub_probe}" -t fs "$path" > /dev/null 2>&1
>> Path `/boot/grub2'
On 05/07/2012 10:22 AM, Nick Urbanik wrote:
> Dear Folks,
>
> I've upgraded from F16 to F17 on this machine with yum,
> [https://fedoraproject.org/wiki/Upgrading_Fedora_using_yum] and it
> seems okay so far, except for this:
>
> $ sudo grub2-install /dev/sda
> /usr
On Mon, May 07, 2012 at 12:22:32PM +1000, Nick Urbanik wrote:
> Dear Folks,
>
> I've upgraded from F16 to F17 on this machine with yum,
> [https://fedoraproject.org/wiki/Upgrading_Fedora_using_yum] and it
> seems okay so far, except for this:
>
> $ sudo grub2-install
Dear Folks,
I've upgraded from F16 to F17 on this machine with yum,
[https://fedoraproject.org/wiki/Upgrading_Fedora_using_yum] and it
seems okay so far, except for this:
$ sudo grub2-install /dev/sda
/usr/share/grub/grub-mkconfig_lib: line 53: 29562 Segmentation fault (core d
On Tue, Apr 24, 2012 at 8:56 AM, Frank Murphy wrote:
>
> The last F17 update
> Gave a grub2.cfg entry similar to:
>
> Fedora Linux
> Advanced options for Fedora Linux xxx
>
> I have since upgrade this vm to Rawhide\F18 (7 fc18 kernels)
> Thought I can click on the abov
The last F17 update
Gave a grub2.cfg entry similar to:
Fedora Linux
Advanced options for Fedora Linux xxx
I have since upgrade this vm to Rawhide\F18 (7 fc18 kernels)
Thought I can click on the above entry, which is listed at the end of
the kernel list.
As I have no fc17 kernels installed
So, if the trend of the future is to use the new grub2
multiboot stuff instead of chain loading, shouldn't there
be some way to tell grub2-install: "Hey, I want you
to install in this partition so I can make you a
multiboot target".
As near as I can tell, the way grub2-install work
On Tue, Apr 17, 2012 at 12:03 PM, Tom Horsley wrote:
> On Tue, 17 Apr 2012 17:49:46 +0200 (CEST) Adam Pribyl wrote:
>>
>> The only reason I know is, that "people tend to modify grub.cfg manually",
>> but with grub2 this is plain wrong anyway. Why do we s
On Tue, 2012-04-17 at 12:03 -0400, Tom Horsley wrote:
> On Tue, 17 Apr 2012 17:49:46 +0200 (CEST)
> Adam Pribyl wrote:
>
> > The only reason I know is, that "people tend to modify grub.cfg manually",
> > but with grub2 this is plain wrong anyway. Why do we sup
On Tue, 17 Apr 2012 17:49:46 +0200 (CEST)
Adam Pribyl wrote:
> The only reason I know is, that "people tend to modify grub.cfg manually",
> but with grub2 this is plain wrong anyway. Why do we support this messy
> setup then?
Because the reverse is true - requiring a tool to
There are at least two bugs that sum the confusion and remains in F17:
https://bugzilla.redhat.com/show_bug.cgi?id=755272
https://bugzilla.redhat.com/show_bug.cgi?id=768106
In short: kernel install adds option to grub.cfg using grubby, while
grub2-mkconfig generates a different menuentries
1 - 100 of 336 matches
Mail list logo
