VM bhyve and Ubuntu 18.04

[Rickinfl]

Hi
I seen you can't install Ubuntu 18.04 on bhyve vm yet because of the kernel. I saw freebsd fixed this. Does anyone know how long before freenas applies the patch? Or is it something we can do? Looks to be just a file? from what I see on freebsd bug forum I'm no programmer.

I figured freenas would get this out pretty quick due to people upgrading kernels. I need to build several Ubuntu servers and what to use 18.04. Just need to figure out how long I have to delay installing these vms.

Thanks
Rick

 

[KrisBee]

See: https://forums.freenas.org/index.php?threads/ubuntu-18-04-boot-to-initramfs.63431/#post-454287

First(?) flagged here: https://forums.freenas.org/index.ph...nt-boot-under-bhyve-4-14-x.62094/#post-446479 on March 3rd

 

[dlavigne]

The developer merged that in earlier today: https://redmine.ixsystems.com/issues/26708. If someone could test a nightly (after today) and leave a comment on that report whether or not it works, that would be great

 

[KrisBee]

@dlavigne Thanks for the notice ... will give it a whirl in 24hrs.

 

[Rickinfl]

Thanks! I knew FreeNAS programmers would be on top of it!

 

[KrisBee]

The developer merged that in earlier today: https://redmine.ixsystems.com/issues/26708. If someone could test a nightly (after today) and leave a comment on that report whether or not it works, that would be great :)

@dlavigne A quick test using the latest ubuntu 18 server iso with the new subuquity installer gives a working VM using the current nightly FreeNAS-11.2-MASTER-201805050407 with the updated bhyve firmware packages:

Code:

[chris@freenas ~]$ pkg info | grep uefi
uefi-edk2-bhyve-0.1,1		  UEFI-EDK2 firmware for bhyve
uefi-edk2-bhyve-csm-0.1,1	  UEFI-EDK2 firmware for bhyve with CSM
[chris@freenas ~]$ 

 

[sk3]

Might be a stupid question but, is the current nightly Stable enough? I would like to upgrade my VMs to ubuntu 18.04 and make some new VMs based on that.

 

[Rickinfl]

But I don't want to run nightly builds. When will this be pushed out as an update? They should really push this ASAP at least this patch a lot of us are stuck until they do.

 

[sk3]

I'm afraid the answer is "when it's ready" unfortunately.

Not blaming anyone but i think FreeNAS updates have became rather slow with the latest versions. I guess it might be related to the new UI since the changelog for 11.2 is quite extensive and mentions a lot of stuff about the new UI.

 

[Rickinfl]

Yes, but I always say... Get your foundation solid. I could care less about the looks. I need it functional not look pretty.

 

[Rickinfl]

Do you think someone over at FreeBSD can give us a patch to fix this so we don't have to wait until FreeNAS gets around to releasing this in stable release? It's fixed in Nighties, But I can't run Nighties last time I did this I was down and had to rebuild my server because they are unstable. Someone needs to release this fix for us even if it's a little patch we can download and run our selves from CLI. Something... Please!

 

[DaPlumber]

Well that explains why the 18.04 LTS installer kernel keeps hanging. I guess I'll use 16.04 in the meantime, since I'm a STABLE-only kinda person. The Redmine for U5 doesn't list this as of today, are the updated uefi-edk2-bhyve packages going to be in U5?

 

[sk3]

That is the question i would like be answered. There is no information about it and if 11.2 is still ways off from being released, i think leaving the current users waiting is not a good idea.

But we'll see

 

[DaPlumber]

That is the question i would like be answered. There is no information about it and if 11.2 is still ways off from being released, i think leaving the current users waiting is not a good idea.

But we'll see

Since it's an upstream update AND U5 is supposed to drop in a few days, that's a bit disappointing.

I know this goes against the FreeNAS philosophy, but it's getting really tempting to work around this by updating the uefi-edk2-bhyve packages manually. I mean what else are they going to affect? (I know, Murphy etc.) It strikes me as less risky than switching the whole installation to nightly builds, and it not like I can't take a system snapshot and roll it back if it all goes sideways. /usr/local/etc/pkg/repos/FreeBSD.conf is your friend. ;)

Not sure if I could try this out in a jail first, the thought of trying to run bhyve in a jail makes my head hurt!

 

[DaPlumber]

OK, so better idea/workaround, since I'm more interested in some cattle for the users space rather than the kernel...

I get going:

1) Fresh install of 16.04
2) apt-get dist-upgrade (after remembering to add /etc/apt/apt.conf.d/99force-ipv4 containing

Code:

Acquire::ForceIPv4 "true"; 

Thanks IPV6! because I wait for no timeouts.)
3) do-release-upgrade -d -m server (eat lunch, play with drone, play with cat, download BMC and BIOS updates for IX Mini and prep, yada, yada, do-release-upgrade takes a while.)
4) As expected 18.04 fails to boot the kernel, and in fact hangs, Doh.
5) Pick "Advanced Options" in grub and select previous 16.04 kernel (4.4.0-124-generic)
6) Whee! All boots correctly! Hello login prompt my old friend!
7) edit /etc/default/grub and change add:

Code:

GRUB_DEFAULT=saved
GRUB_SAVEDEFAULT=true

(This causes grub to "remember" that last selected options, so I can easily go back to using the new 4.15 kernel as soon as the uefi packages get updated. HINT! Release U5 would be nice! HINT!)

So my bionic (!) cow is now ready for cloning:

Code:

me@ubase:~$ uname -a
Linux ubase 4.4.0-124-generic #148-Ubuntu SMP Wed May 2 13:00:18 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux
me@ubase:~$ lsb_release -a
No LSB modules are available.
Distributor ID:	Ubuntu
Description:	Ubuntu 18.04 LTS
Release:	18.04
Codename:	bionic
me@ubase:~$ cat /etc/*release
DISTRIB_ID=Ubuntu
DISTRIB_RELEASE=18.04
DISTRIB_CODENAME=bionic
DISTRIB_DESCRIPTION="Ubuntu 18.04 LTS"\
NAME="Ubuntu"
VERSION="18.04 LTS (Bionic Beaver)"
ID=ubuntu
ID_LIKE=debian
PRETTY_NAME="Ubuntu 18.04 LTS"
VERSION_ID="18.04"
HOME_URL="https://www.ubuntu.com/"
SUPPORT_URL="https://help.ubuntu.com/"
BUG_REPORT_URL="https://bugs.launchpad.net/ubuntu/"
PRIVACY_POLICY_URL="https://www.ubuntu.com/legal/terms-and-policies/privacy-policy"
VERSION_CODENAME=bionic
UBUNTU_CODENAME=bionic

So that fits my needs, your milage may vary depending on what's in kernel 4.15 that's got you all hot and bothered?

 

[Rickinfl]

Well that explains why the 18.04 LTS installer kernel keeps hanging. I guess I'll use 16.04 in the meantime, since I'm a STABLE-only kinda person. The Redmine for U5 doesn't list this as of today, are the updated uefi-edk2-bhyve packages going to be in U5?

I'm still dumb founded that FreeNAS doesn't just put up the Bhyve update. This is just crazy... how hard is it to push it out? It's in the nightly's! But nightly's are unstable. The end user has no power so we have to Wait until June 4th for the patch if there is no delays.

I'm a HEAVY user of VM's and trying to get off my ESXI boxes to FreeNAS. I had some VM's running and they work Great! Upgraded one of my Ubuntu 17 boxes to 18 and that was the end of it never booted again good thing I had a backup on my ESXI box and was able to spin it up to get running again on Ubuntu 17. I'm just going to rebuild all of my VM's on Ubuntu 18, but now I'm stuck waiting.

 

[sk3]

@DaPlumber You can update your kernel up to 4.13 and run it without issues in bhyve. It's only 4.14 that have that issue.

I have a VM working just fine with 4.13. Also, ubuntu 18.04 works with 4.13 kernel just as fine as well.

 

[Rickinfl]

Well I'm not going to hack something to get it to work when Freenas already fixed the issue they just need to push out the update don't understand why they are waiting weeks to do it. Just push the dang update out! Geez this is frustrating.

 

[DaPlumber]

Well I'm not going to hack something to get it to work when Freenas already fixed the issue they just need to push out the update don't understand why they are waiting weeks to do it. Just push the dang update out! Geez this is frustrating.

That’s why I think the combination of upgrade to 18.04 and the 4.13 kernel is the best answer. (Unless there’s something in 4.15 that’s the reason to update to 18.04). That way as soon as FreeNAS ships the update in STABLE, it’s a simple change on the boot of the VM and you get to use 18.04 in the meantime.

Now, as to why there is feet-dragging/lack of interest on getting the packages into 11.1 U5, that’s a different question. In terms of priority: it’s perfectly possible to use FreeNAS with the “classic” interface instead of the current next-gen buggy abomination. Not commiting a major upstream functional fix applied to an important component in a dot release is more than a little concerning.

Anyone care to suggest the best way to raise awareness of this issue?

 

[João Dalvi]

So we've got to wait. When is the next release going to be released as stable?