Ask Your Question

djcf's profile - activity

2017-03-20 05:34:12 -0500 received badge  Famous Question (source)
2016-12-12 04:24:53 -0500 received badge  Notable Question (source)
2016-12-12 04:24:53 -0500 received badge  Popular Question (source)
2016-05-11 05:23:09 -0500 commented answer Grub wont pick up new kernels (was: Can't update kernel)

You're right about grub, but I'm still not able to update the grub config. I've updated my answer accordingly.

2016-05-11 05:21:51 -0500 commented answer Grub wont pick up new kernels (was: Can't update kernel)

As grub isn't picking up the new kernels, this doesn't fix the problem for me I'm afraid...

2016-05-10 12:35:57 -0500 received badge  Editor (source)
2016-05-10 12:24:41 -0500 received badge  Supporter (source)
2016-05-10 11:49:36 -0500 received badge  Student (source)
2016-05-10 11:40:15 -0500 asked a question Grub wont pick up new kernels (was: Can't update kernel)

In a seemingly endless quest to get Vagrant working I am trying to update Fedora. Vagrant needs VirtualBox, VirtualBox needs kernel sources, and kernel sources are only available for the latest kernel version.

$ uname -r
4.3.5-300.fc23.x86_64

I tried updating the system.

$ sudo dnf update
Last metadata expiration check: 2:03:57 ago on Tue May 10 11:20:17 2016.
Dependencies resolved.
Nothing to do.
Complete!

Clearly the system is already updated.

$ sudo dnf install kernel

Last metadata expiration check: 2:05:00 ago on Tue May 10 11:20:17 2016.
Package kernel-4.4.8-300.fc23.x86_64 is already installed, skipping.
Dependencies resolved.
Nothing to do.
Complete!

I tried removing the current kernel:

$ sudo dnf remove kernel-(uname -r)

Complete. Let's see what's installed:

$ rpm -qva "kernel-*"
kernel-core-4.4.8-300.fc23.x86_64
kernel-core-4.4.4-301.fc23.x86_64
kernel-headers-4.4.8-300.fc23.x86_64
kernel-modules-4.4.8-300.fc23.x86_64
kernel-devel-4.4.8-300.fc23.x86_64
kernel-modules-4.4.4-301.fc23.x86_64

All good so far.

So I rebooted....

Only to find that three kernels were listed in Grub: 4.3.5-300.fc23.x86_64, and two much older ones from the 4.2 branch.

$ rpm -qva "kernel-*"
kernel-modules-4.3.5-300.fc23.x86_64
kernel-core-4.4.8-300.fc23.x86_64
kernel-core-4.4.4-301.fc23.x86_64
kernel-core-4.3.5-300.fc23.x86_64
kernel-headers-4.4.8-300.fc23.x86_64
kernel-modules-4.4.8-300.fc23.x86_64
kernel-devel-4.4.8-300.fc23.x86_64
kernel-modules-4.4.4-301.fc23.x86_64

What on earth is going on here?

Edit: I later attempted to update grub to pick up the new kernel.

$ cd /boot/grub2
$ mv grub.cfg grub.cfg.old
$ sudo grub2-mkconfig -o grub.cfg.new
Generating grub configuration file ...
Found linux image: /boot/vmlinuz-4.4.8-300.fc23.x86_64
Found initrd image: /boot/initramfs-4.4.8-300.fc23.x86_64.img
Found linux image: /boot/vmlinuz-4.4.4-301.fc23.x86_64
Found initrd image: /boot/initramfs-4.4.4-301.fc23.x86_64.img
Found linux image: /boot/vmlinuz-4.3.5-300.fc23.x86_64
Found initrd image: /boot/initramfs-4.3.5-300.fc23.x86_64.img
Found linux image: /boot/vmlinuz-0-rescue-0468365313db460f867aa0a7c6284ace
Found initrd image: /boot/initramfs-0-rescue-0468365313db460f867aa0a7c6284ace.img

I can confirm that the new config file has the correct entries:

 $ grep 4.4 grub.cfg
  menuentry 'Fedora (4.4.8-300.fc23.x86_64) 23 (Workstation Edition)' --class fedora --class gnu-linux --class gnu --class os --unrestricted $menuentry_id_option 'gnulinux-4.3.5-300.fc23.x86_64-advanced-29e2d74b-255e-44fa-b8e7-edb54b33f225' {
linux16 /vmlinuz-4.4.8-300.fc23.x86_64 root=/dev/mapper/fedora_deepwinter-root ro rd.lvm.lv=fedora_deepwinter/root rd.luks.uuid=luks-b09d62d7-9782-42d5-890d-f117ccb8a1cc rd.lvm.lv=fedora_deepwinter/swap rhgb quiet splash acpi_backlight=vendor acpi_osi='!Windows 2013' acpi_osi='!Windows 2012' LANG=en_GB.UTF-8
initrd16 /initramfs-4.4.8-300.fc23.x86_64.img
    menuentry 'Fedora (4.4.4-301.fc23.x86_64) 23 (Workstation Edition)' --class fedora --class gnu-linux --class gnu --class os --unrestricted $menuentry_id_option 'gnulinux-4.3.5-300.fc23.x86_64-advanced-29e2d74b-255e-44fa-b8e7-edb54b33f225' {
linux16 /vmlinuz-4.4.4-301.fc23.x86_64 root=/dev/mapper/fedora_deepwinter-root ro  rd.lvm.lv=fedora_deepwinter/root rd.luks.uuid=luks-b09d62d7-9782-42d5-890d-f117ccb8a1cc rd.lvm.lv=fedora_deepwinter/swap rhgb quiet splash acpi_backlight=vendor acpi_osi='!Windows 2013' acpi_osi='!Windows 2012' LANG=en_GB.UTF-8
initrd16 /initramfs-4 ...
(more)
2016-05-10 11:40:04 -0500 asked a question Fedora, vagrant and libvirt

In my continuing attempts to get vagrant up (* http://superuser.com/questions/105697... ) I have been trying to use the libvirt provider because libvirt is faster and does not require installing virtualbox. It is my preferred provider for fedora-based systems.

I am trying to debug a client's wordpress installation and am using the box here: http://vccw.cc/

Of course it is a virtualbox. After mutating it (via the vagrant-mutate plugin) to libvirt, I encounter a strange problem.

vagrant up --provider=libvirt
Bringing machine 'vccw.dev' up with 'libvirt' provider...
==> vccw.dev: Creating image (snapshot of base box volume).
==> vccw.dev: Creating domain with the following settings...
==> vccw.dev:  -- Name:              vccw-2190_vccwdev
==> vccw.dev:  -- Domain type:       kvm
==> vccw.dev:  -- Cpus:              1
==> vccw.dev:  -- Memory:            512M
==> vccw.dev:  -- Management MAC:    
==> vccw.dev:  -- Loader:            
==> vccw.dev:  -- Base box:          miya0001/vccw
==> vccw.dev:  -- Storage pool:      default
==> vccw.dev:  -- Image:             /var/lib/libvirt/images/vccw-2190_vccwdev.img (40G)
==> vccw.dev:  -- Volume Cache:      default
==> vccw.dev:  -- Kernel:            
==> vccw.dev:  -- Initrd:            
==> vccw.dev:  -- Graphics Type:     vnc
==> vccw.dev:  -- Graphics Port:     5900
==> vccw.dev:  -- Graphics IP:       127.0.0.1
==> vccw.dev:  -- Graphics Password: Not defined
==> vccw.dev:  -- Video Type:        cirrus
==> vccw.dev:  -- Video VRAM:        9216
==> vccw.dev:  -- Keymap:            en-us
==> vccw.dev:  -- INPUT:             type=mouse, bus=ps2
==> vccw.dev:  -- Command line : 
==> vccw.dev: Auto-generating node name for Chef...
==> vccw.dev: Creating shared folders metadata...
==> vccw.dev: Starting domain.

... And this is where it hangs.

Sometimes it gets one step further:

 ==> vccw.dev: Waiting for domain to get an IP address...

Assuming that it could be a problem with dnsmasq and DHCP, I tried changing the Vagrantfile in a number of ways.

First, I decided to manually specify the hostname:

 config.vm.hostname = "vccw.dev"

Then I decided to manually specify the IP address:

 #config.vm.network :private_network, ip: "192.168.33.10"
 config.vm.network :private_network,
        :ip => "192.168.33.10"

However, nothing seems to prevent the vagrant from hanging on "Waiting for domain to get an IP address."