yum update from 3.14.4 looks ok in /boot vmlinuz-3.14.3-200.fc20.x86_64 vmlinuz-3.14.4-200.fc20.x86_64 vmlinuz-3.14.7-200.fc20.x86_64
I can't seem to get 3.14.7 to 'take' after reboot still in 3.14.4
exact command used for update:
yum update && grub2-mkconfig -o /boot/grub2/grub.cfg
followed by a reboot,
still get: $ uname -r 3.14.4-200.fc20.x86_64
On 06/14/2014 05:19 PM, Jackson Byers wrote:
yum update && grub2-mkconfig -o /boot/grub2/grub.cfg
Unless there's something very, very strange going on with your machine, the second half of that command is redundant, because AFAIK, part of installing a new kernel is rebuilding grub2. I do know that I've never had to rebuild grub manually after an update. For me, at least, It Just Works.
On 15/06/14 03:29, Joe Zeff wrote:
On 06/14/2014 05:19 PM, Jackson Byers wrote:
yum update && grub2-mkconfig -o /boot/grub2/grub.cfg
Unless there's something very, very strange going on with your machine, the second half of that command is redundant, because AFAIK, part of installing a new kernel is rebuilding grub2. I do know that I've never had to rebuild grub manually after an update. For me, at least, It Just Works.
AFAIK, kernel updates never run grub2-mkconfig. Instead grubby is used to update the existing grub.cfg and add an entry for the newly installed kernel.
Solved:aaaaaa after "grub2-install /dev/sda" and rebooting, I now get 3.14.7: $ uname -rsvp Linux 3.14.7-200.fc20.x86_64 #1 SMP Wed Jun 11 22:38:05 UTC 2014 x86_64
what still puzzles me : sometimes I don't need the "grub2-install /dev/sda" when doing yum update...
Jack
On Sat, Jun 14, 2014 at 5:19 PM, Jackson Byers byersjab@gmail.com wrote:
yum update from 3.14.4 looks ok in /boot vmlinuz-3.14.3-200.fc20.x86_64 vmlinuz-3.14.4-200.fc20.x86_64 vmlinuz-3.14.7-200.fc20.x86_64
I can't seem to get 3.14.7 to 'take' after reboot still in 3.14.4
exact command used for update:
yum update && grub2-mkconfig -o /boot/grub2/grub.cfg
followed by a reboot,
still get: $ uname -r 3.14.4-200.fc20.x86_64
On Sun, Jun 15, 2014 at 8:09 AM, Jackson Byers byersjab@gmail.com wrote:
Solved:aaaaaa after "grub2-install /dev/sda" and rebooting, I now get 3.14.7: $ uname -rsvp Linux 3.14.7-200.fc20.x86_64 #1 SMP Wed Jun 11 22:38:05 UTC 2014 x86_64
what still puzzles me : sometimes I don't need the "grub2-install /dev/sda" when doing yum update...
Jack
On Sat, Jun 14, 2014 at 5:19 PM, Jackson Byers byersjab@gmail.com wrote:
yum update from 3.14.4 looks ok in /boot vmlinuz-3.14.3-200.fc20.x86_64 vmlinuz-3.14.4-200.fc20.x86_64 vmlinuz-3.14.7-200.fc20.x86_64
I can't seem to get 3.14.7 to 'take' after reboot still in 3.14.4
exact command used for update:
yum update && grub2-mkconfig -o /boot/grub2/grub.cfg
followed by a reboot,
still get: $ uname -r 3.14.4-200.fc20.x86_64
-- users mailing list users@lists.fedoraproject.org To unsubscribe or change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines Have a question? Ask away: http://ask.fedoraproject.org
You only have to do "grub2-install /dev/sda" when you install the system, Anaconda does that for you, or if you mess your grub. And after that you recreate grub.cfg. When a new kernel is installed, it automatically recreates the grub.cfg.
If you have to reinstall grub2 at every kernel upgrade that should probably go to bugzilla.
On Jun 14, 2014, at 6:19 PM, Jackson Byers byersjab@gmail.com wrote:
yum update from 3.14.4 looks ok in /boot vmlinuz-3.14.3-200.fc20.x86_64 vmlinuz-3.14.4-200.fc20.x86_64 vmlinuz-3.14.7-200.fc20.x86_64
I can't seem to get 3.14.7 to 'take' after reboot still in 3.14.4
exact command used for update:
yum update && grub2-mkconfig -o /boot/grub2/grub.cfg
I'm not sure what sequence this translates into. I'm pretty sure yum only completes once rpm completes, and rpm includes running new-kernel-pkg which runs grubby which is what updates the grub.cfg. But is it possible that grub2-mkconfig runs before all child processes of yum are done?
Anyway this is not the correct command to run. What I'd like to see is the grub.cfg before running yum update, and after. That grub2-install fixed it makes me wonder if there was grubenv corruption (?) which is responsible for the default entry to boot, maybe grub2-install is resetting grubenv.
Normally you do not need to do a grub2-mkconfig after a kernel update, let alone a grub2-install. If you are, it's a bug, so open one up and post as much info you can including the results from bootinfoscript off sourceforge. The CentOS folks also have a script that will collect basic information like this for troubleshooting. The one case I'm aware of where we have to run grub2-mkconfig after each kernel update is if /boot is on a Btrfs subvolume, and that's because grubby doesn't yet understand subvolumes (patch is upstream finally, yay!).
Chris Murphy
On 06/19/14 12:03, Chris Murphy wrote:
I'm not sure what sequence this translates into. I'm pretty sure yum only completes once rpm completes, and rpm includes running new-kernel-pkg which runs grubby which is what updates the grub.cfg. But is it possible that grub2-mkconfig runs before all child processes of yum are done?
The && says..... run the next command only if the previous command exits with a status of "0".
On Jun 18, 2014, at 10:14 PM, Ed Greshko Ed.Greshko@greshko.com wrote:
On 06/19/14 12:03, Chris Murphy wrote:
I'm not sure what sequence this translates into. I'm pretty sure yum only completes once rpm completes, and rpm includes running new-kernel-pkg which runs grubby which is what updates the grub.cfg. But is it possible that grub2-mkconfig runs before all child processes of yum are done?
The && says….. run the next command only if the previous command exits with a status of "0".
Hmm well then it ought to work, I'm not sure why it doesn't. In that case if it happens again the output from grub command line (press c at the grub menu): pager=1 set
It might require 2 cellphone jpg photos. And also the /boot/grub2/grub.cfg [1] and /etc/default/grub file.
Chris Murphy
[1] On UEFI it's tragically at /boot/efi/EFI/fedora/grub.cfg