On Sun, Jan 5, 2014 at 5:27 PM, Mark Martinec wrote:
I was playing with bhyve on 10.0-RC4, trying to install another
10.0-RC4
into a 16 GB ZFS volume using the network installation DVD. Mostly
kept
defaults, except that I chose a ZFS-on-root installation. The amd64
[guest]
was given 1 GB of RAM on the first attempt, but failed. It fails on 2
GB RAM
too, but succeeds when given 4 GB of RAM.
2014-01-06 22:13, Craig Rodrigues wrote:
How far did you get with this? If you use BHyve to boot FreeBSD,
the loader which is used is in /usr/src/sys/boot/userboot, and
this loader does not support a complete ZFS-only install.
I recently tried to do this, and the install worked (with 4G of RAM),
but when I tried to reboot the BHyve VM, the VM did not boot.
You are right, I wasn't able to boot such newly-installed disk
under bhyve. But I was able to verify that the installation was
successful: copied the created zfs volume to another host (running
9.2), pointed a VirtualBox .vmdk disk description file to that
zfs volume, and VirtualBox was able to successfully boot and run
from such disk. So the installer running under bhyve did its job,
successfully installed a root-on-zfs 10-RC4.
If you look at: https://admbugs.freebsd.org/show_bug.cgi?id=428#c7
you will see I had to use a variation of these steps:
https://wiki.freebsd.org/RootOnZFS/UFSBoot
where the /boot directory which contained the kernel and loader was on
a
UFS partition, but everything else was on ZFS. That's the only way I
could get the BHyve VM to boot, with userboot.
Thanks, useful link. I wish the bhyve would be able to boot off the
freebsd-boot partition containing a gptzfsboot bootcode.
Devin writes:
- let the installer mount the available swap partitions before jumping
into heavy installation work;
That sounds reasonable enough.
Thanks for considering!
- avoid covering an underlying failure with a quickly-redrawn
installer
menu; at least some delay after a failure but before erasing the
screen
would be useful, avoiding the user to go to great lengths to be able
to
capture the failure reason.
While the error reporting could be improved in that area of bsdinstall
that
you fingered, the perception that the errors are quickly being erased
is
incorrect. What's actually going on is the errors are being shunted
over to
vty1 (Alt+F2)
Under bhyve there is only a serial console currently, afict.
as well as /tmp/bsdinstall_log
Didn't know that. Thanks for the useful information.
But granted... the error messages that are displayed on vty0 could
certainly
be improved (which will take time).
Mark
_______________________________________________
freebsd-virtualization@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-virtualization
To unsubscribe, send any mail to
"freebsd-virtualization-unsubscr...@freebsd.org"
