[Bug 250934] grub-bhyve "ls" causes kernel panic
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=250934 Aleksandr Fedorov changed: What|Removed |Added CC||afedo...@freebsd.org, ||osho...@freebsd.org --- Comment #1 from Aleksandr Fedorov --- I think this is not a virtualization problem. It's looks like a ZFS issue. https://github.com/openzfs/zfs/pull/11152 Here, the same trace: https://drive.google.com/file/d/1-dvj8eoUNqRWL5mcVtH5Px4NbrhLfzML/view https://github.com/openzfs/zfs/commit/ae37ceadaa2a8cf09fbf1a9baafaa6dc6e24318a -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-virtualization@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-virtualization To unsubscribe, send any mail to "freebsd-virtualization-unsubscr...@freebsd.org"
[Bug 250934] grub-bhyve "ls" causes kernel panic
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=250934 Li-Wen Hsu changed: What|Removed |Added Assignee|b...@freebsd.org|virtualizat...@freebsd.org CC||lw...@freebsd.org -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-virtualization@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-virtualization To unsubscribe, send any mail to "freebsd-virtualization-unsubscr...@freebsd.org"
Re: grub-bhyve device map file usage
On Mon, Sep 14, 2020 at 4:28 PM Chuck Tuffli wrote: > > Hi > > I'm working on an update to grub-bhyve and wanted to know if people's > map files differ from: > (hd0) /some/path/to/the/disk.img > Primarily, I'm interested if the map files use a device other than > 'hd', but I'd also be curious about use cases involving more than one > entry. TIA! Thank you to all for the feedback! --chuck ___ freebsd-virtualization@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-virtualization To unsubscribe, send any mail to "freebsd-virtualization-unsubscr...@freebsd.org"
Re: grub-bhyve device map file usage
On 2020-09-14T16:28:15 -0700 Chuck Tuffli wrote: > Hi > > I'm working on an update to grub-bhyve and wanted to know if people's > map files differ from: > (hd0) /some/path/to/the/disk.img > Primarily, I'm interested if the map files use a device other than > 'hd', but I'd also be curious about use cases involving more than one > entry. TIA! From a production machine here: (hd0) /dev/zvol/storage/vm/66d99c52-9be0-434e-935e-7c7105952308/disk-0_1_0 (hd1) /dev/zvol/storage/vm/66d99c52-9be0-434e-935e-7c7105952308/disk-0_5_0 (cd0) /storage/images/debian-10.5.0-amd64-xfce-CD-1.iso hd0 is the boot device. hd1 is a larger disk image used to hold a database. cd0 is the installation media (and kept there in case we need to do some sort of rescue boot). -- Mark Raynsford | https://www.io7m.com pgpW9YPVXGc7Y.pgp Description: OpenPGP digital signature
Re: grub-bhyve device map file usage
Hi Chuck, I'm working on an update to grub-bhyve and wanted to know if people's map files differ from: (hd0) /some/path/to/the/disk.img Primarily, I'm interested if the map files use a device other than 'hd', but I'd also be curious about use cases involving more than one entry. TIA! I use 'cd' as well as 'hd', and often have files with multiple entries for those e.g. "debian.map" that has a cd/hd for each version I was testing. The -r parameter was used to pick which one would be the bootable filesystem image. later, Peter. ___ freebsd-virtualization@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-virtualization To unsubscribe, send any mail to "freebsd-virtualization-unsubscr...@freebsd.org"
grub-bhyve device map file usage
Hi I'm working on an update to grub-bhyve and wanted to know if people's map files differ from: (hd0) /some/path/to/the/disk.img Primarily, I'm interested if the map files use a device other than 'hd', but I'd also be curious about use cases involving more than one entry. TIA! --chuck ___ freebsd-virtualization@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-virtualization To unsubscribe, send any mail to "freebsd-virtualization-unsubscr...@freebsd.org"
Re: grub-bhyve
Grub-bhyve is using Gcc 4.8.5 to copile with. > > I recall compiling with gcc 9.0 with a few updates needed to the> code. Has anyone else tried this? The ports version is using gcc 9 so no issues there. The grub2-bhyve github README has just been updated to remove the versions from gcc/gdb - the most recent versions of those are fine to use. later, Peter. ___ freebsd-virtualization@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-virtualization To unsubscribe, send any mail to "freebsd-virtualization-unsubscr...@freebsd.org"
grub-bhyve
Grub-bhyve is using Gcc 4.8.5 to copile with. I recall compiling with gcc 9.0 with a few updates needed to the code. Has anyone else tried this? -- Member - Liberal International This is doctor@@nl2k.ab.ca Ici doctor@@nl2k.ab.ca Yahweh, Queen & country!Never Satan President Republic!Beware AntiChrist rising! https://www.empire.kred/ROOTNK?t=94a1f39b Look at Psalms 14 and 53 on Atheism Marvelous Truth, confront us at every turn, in every guise. -Denise Levertov ___ freebsd-virtualization@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-virtualization To unsubscribe, send any mail to "freebsd-virtualization-unsubscr...@freebsd.org"
Re: Segmentation fault in grub-bhyve when trying to boot a Linux guest
On 2018-05-01T18:06:38 -0700 Peter Grehan wrote: > >* rosemary_disk0.lzma (the LZMA compressed zvol) > > I was able to boot this image on a 12-current Ryzen system. Debian 9.4 > also installed fine with the netinstall ISO and could boot. Bizarrely, I am also able to boot it without issue now. I worked through this with someone in the #bhyve channel on Freenode. Essentially: I couldn't boot the image with the stripped grub-bhyve binary, this would crash reliably. Restarting the hardware didn't make any difference, and destroying the vm after each attempt didn't make any difference either. I couldn't boot the image with the debug grub-bhyve binary. The same applied to that as above. If I ran the debug binary in gdb 8, the program ran to completion without crashing. After running it a few times without crashing in gdb, both the stripped and debug grub-bhyve binaries would run to completion *outside of the debugger* without crashing! Both the stripped and debug grub-bhyve binaries reliably work now. I can boot the VM, reboot it, whatever. I've restarted the hardware many times and cannot reproduce the original crash. I've never seen anything like this and have no theories as to why it didn't work at all, and now works reliably despite nothing apparently having changed anywhere. -- Mark Raynsford | http://www.io7m.com pgplz2sNvB5QT.pgp Description: OpenPGP digital signature
Re: Segmentation fault in grub-bhyve when trying to boot a Linux guest
* rosemary_disk0.lzma (the LZMA compressed zvol) I was able to boot this image on a 12-current Ryzen system. Debian 9.4 also installed fine with the netinstall ISO and could boot. later, Peter. ___ freebsd-virtualization@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-virtualization To unsubscribe, send any mail to "freebsd-virtualization-unsubscr...@freebsd.org"
Re: Segmentation fault in grub-bhyve when trying to boot a Linux guest
On 1 May 2018, at 18:41, Mark Raynsford wrote: > I've recompiled the port with > WITH_DEBUG=yes (which, unfortunately, took most of the day due to > having to compile the gcc-6 dependency). Unfortunately, this didn't > yield a usable backtrace. I'm guessing that the Dwarf debugging > information isn't compatible with the gdb version that's in base? gdb > says: Yes, you need to use gdb from ports for this. Here’s the backtrace: #0 0x0040d506 in grub_memmove (dest=0x80388f000, src=0x0, n=2047) at kern/misc.c:61 #1 0x0049e9eb in grub_memcpy (dest=0x80388f000, src=0x0, n=2048) at ../include/grub/misc.h:75 #2 0x0049f6b2 in grub_linux_boot () at loader/i386/linux.c:577 #3 0x004271af in grub_loader_boot () at commands/boot.c:162 #4 0x0042720e in grub_cmd_boot (cmd=0x80322d140, argc=0, argv=0x80321c138) at commands/boot.c:179 #5 0x004b3a87 in grub_script_execute_cmdline (cmd=0x8032322a8) at script/execute.c:927 #6 0x004b353c in grub_script_execute_cmd (cmd=0x8032322a8) at script/execute.c:753 #7 0x004b3b85 in grub_script_execute_cmdlist (list=0x803221cc8) at script/execute.c:972 #8 0x004b353c in grub_script_execute_cmd (cmd=0x803221cc8) at script/execute.c:753 #9 0x004b3ea1 in grub_script_execute (script=0x803232180) at script/execute.c:1084 #10 0x004b1084 in grub_normal_parse_line (line=0x803220178 "boot", getline=0x4a139a ) at script/main.c:35 #11 0x004a1448 in grub_cmdline_run (nested=0) at normal/main.c:477 #12 0x004a10ad in grub_enter_normal_mode (config=0x803266100 "(host)/storage/vm/rosemary/grub.cfg") at normal/main.c:320 #13 0x004a1154 in grub_cmd_normal (cmd=0x80322ee00, argc=0, argv=0x0) at normal/main.c:356 #14 0x0040cd10 in grub_command_execute (name=0x53120c "normal", argc=0, argv=0x0) at ../include/grub/command.h:120 #15 0x0040d326 in grub_load_normal_mode () at kern/main.c:216 #16 0x0040d391 in grub_main () at kern/main.c:250 #17 0x00406165 in main (argc=12, argv=0x7fffeb48) at kern/emu/main.c:365 I’m pretty sure the src parameter should not be NULL for grub_memcpy. Fabian signature.asc Description: OpenPGP digital signature
Re: Segmentation fault in grub-bhyve when trying to boot a Linux guest
On 2018-05-01T00:56:15 +0200 "Fabian Freyer" wrote: > On 1 May 2018, at 0:05, Mark Raynsford via freebsd-virtualization wrote: > > I've recently attempted to install a Debian 9.4.0 x86_64 guest. The > > installer ran to completion without issue, and I then rebooted into the > > installed system, again without issue. > > > > I then shut the system down and tried to bring it up... > > > > pid 71802 (grub-bhyve), uid 0: exited on signal 11 (core dumped) > > Is this reproducible? If yes, > * is it still reproducible on a freshly built grub-bhyve from ports with > debugging symbols (build the port with WITH_DEBUG=yes)? > * is a core file dumped? > * could you grab a backtrace from the core file? Hello! This is still reproducible, yes. I've recompiled the port with WITH_DEBUG=yes (which, unfortunately, took most of the day due to having to compile the gcc-6 dependency). Unfortunately, this didn't yield a usable backtrace. I'm guessing that the Dwarf debugging information isn't compatible with the gdb version that's in base? gdb says: # gdb /usr/local/sbin/grub-bhyve grub-bhyve.core GNU gdb 6.1.1 [FreeBSD] Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "amd64-marcel-freebsd"...Dwarf Error: wrong version in compilation unit header (is 4, should be 2) [in module /usr/local/sbin/grub-bhyve] Core was generated by `/usr/local/sbin/grub-bhyve -m /storage/vm/rosemary/device.map -r host -d /storag'. Program terminated with signal 11, Segmentation fault. Reading symbols from /lib/libncurses.so.8...(no debugging symbols found)...done. Loaded symbols for /lib/libncurses.so.8 Reading symbols from /lib/libzfs.so.2...(no debugging symbols found)...done. Loaded symbols for /lib/libzfs.so.2 Reading symbols from /lib/libnvpair.so.2...(no debugging symbols found)...done. Loaded symbols for /lib/libnvpair.so.2 Reading symbols from /lib/libgeom.so.5...(no debugging symbols found)...done. Loaded symbols for /lib/libgeom.so.5 Reading symbols from /usr/lib/libvmmapi.so.5...(no debugging symbols found)...done. Loaded symbols for /usr/lib/libvmmapi.so.5 Reading symbols from /lib/libutil.so.9...(no debugging symbols found)...done. Loaded symbols for /lib/libutil.so.9 Reading symbols from /lib/libc.so.7...(no debugging symbols found)...done. Loaded symbols for /lib/libc.so.7 Reading symbols from /lib/libmd.so.6...(no debugging symbols found)...done. Loaded symbols for /lib/libmd.so.6 Reading symbols from /lib/libumem.so.2...(no debugging symbols found)...done. Loaded symbols for /lib/libumem.so.2 Reading symbols from /lib/libuutil.so.2...(no debugging symbols found)...done. Loaded symbols for /lib/libuutil.so.2 Reading symbols from /lib/libm.so.5...(no debugging symbols found)...done. Loaded symbols for /lib/libm.so.5 Reading symbols from /lib/libavl.so.2...(no debugging symbols found)...done. Loaded symbols for /lib/libavl.so.2 Reading symbols from /lib/libbsdxml.so.4...(no debugging symbols found)...done. Loaded symbols for /lib/libbsdxml.so.4 Reading symbols from /lib/libz.so.6...(no debugging symbols found)...done. Loaded symbols for /lib/libz.so.6 Reading symbols from /lib/libzfs_core.so.2...(no debugging symbols found)...done. Loaded symbols for /lib/libzfs_core.so.2 Reading symbols from /lib/libthr.so.3...(no debugging symbols found)...done. Loaded symbols for /lib/libthr.so.3 Reading symbols from /lib/libsbuf.so.6...(no debugging symbols found)...done. Loaded symbols for /lib/libsbuf.so.6 Reading symbols from /libexec/ld-elf.so.1...(no debugging symbols found)...done. Loaded symbols for /libexec/ld-elf.so.1 #0 0x0040d506 in ?? () (gdb) bt #0 0x0040d506 in ?? () #1 0x7fffe620 in ?? () #2 0x0049e9eb in ?? () #3 0x7fffe620 in ?? () #4 0x0800 in ?? () #5 0x in ?? () In the hope that you or someone else can reproduce this, or even get a better trace out of the core file, I've uploaded: * grub-bhyve.core.lzma (the LZMA compressed core file) * grub-bhyve.lzma (the executable that the port produced) * rosemary_disk0.lzma (the LZMA compressed zvol) * checksum.s256 (SHA256 checksums for all of the above) https://drive.google.com/drive/folders/1hxfRqS1b0HYpcN3sglJ_To0fWG22Kjad?usp=sharing Assuming that you want the zvol to be placed at /x/y/z/disk0, I think you should be able to: lzma -d < rosemary_disk0.lzma | zfs recv /x/y/z/disk0 And then: grub-bhyve \ -m /path/to/config/dir/device.map \ -r host \ -d /path/to/config/dir \ -c /dev/nmdm56A \ -M 512M \ rosemary Where
Re: Segmentation fault in grub-bhyve when trying to boot a Linux guest
On 1 May 2018, at 0:05, Mark Raynsford via freebsd-virtualization wrote: > I've recently attempted to install a Debian 9.4.0 x86_64 guest. The > installer ran to completion without issue, and I then rebooted into the > installed system, again without issue. > > I then shut the system down and tried to bring it up... > > pid 71802 (grub-bhyve), uid 0: exited on signal 11 (core dumped) Is this reproducible? If yes, * is it still reproducible on a freshly built grub-bhyve from ports with debugging symbols (build the port with WITH_DEBUG=yes)? * is a core file dumped? * could you grab a backtrace from the core file? Fabian signature.asc Description: OpenPGP digital signature
Segmentation fault in grub-bhyve when trying to boot a Linux guest
Hello. I've recently attempted to install a Debian 9.4.0 x86_64 guest. The installer ran to completion without issue, and I then rebooted into the installed system, again without issue. I then shut the system down and tried to bring it up... pid 71802 (grub-bhyve), uid 0: exited on signal 11 (core dumped) The exact commands I'm using to start the VM are: /usr/local/sbin/grub-bhyve \ -m /storage/vm/rosemary/device.map \ -r host \ -d /storage/vm/rosemary \ -c /dev/nmdm56A \ -M 512M \ rosemary /sbin/ifconfig tap56 create || true /sbin/ifconfig bridge0 addm tap56 || true exec /usr/sbin/bhyve \ -A \ -H \ -P \ -c 1 \ -U a3ca8efb-7a3b-4ad7-b059-85ef739d72f3 \ -m 512M \ -s 0,hostbridge \ -s 4,ahci-hd,/dev/zvol/storage/vm/rosemary/disk0 \ -s 5,virtio-net,tap56 \ -s 31,lpc \ -l com1,/dev/nmdm56A \ rosemary The device.map looks like: (hd0) /dev/zvol/storage/vm/rosemary/disk0 (cd0) /storage/images/debian-9.4.0-amd64-netinst.iso The grub.cfg looks like: linux (hd0,msdos1)/vmlinuz root=/dev/sda1 initrd (hd0,msdos1)/initrd.img boot I see no output after the boot command, the crash occurs seemingly immediately. If there's any information that would be helpful, let me know. I can probably provide the /storage/vm/rosemary/disk0 volume as a compressed "zfs send" if necessary. I'm on a fresh install of FreeBSD 11.1-RELEASE-p9 and am using grub-bhyve (GRUB-BHYVE) 2.00:0.40. I've not had trouble with any other guests (running a mix of FreeBSD and OpenBSD guests without issue). -- Mark Raynsford | http://www.io7m.com pgp6L0nZnVn_4.pgp Description: OpenPGP digital signature
Re: grub-bhyve: support overriding just --root flag
On 12 Nov 2017, at 0:46, Allan Jude wrote: > Does libvirt support using the bhyve UEFI-CSM firmware instead? That > would let the VM boot using the native grub installed inside the VM, and > avoid this issue entirely. It also makes starting a bhyve a single > command instead of 2. Yes it does[1]. Also be aware that bootloader_args has some quoting issues. CC’ing novel@ as he does a lot of the libvirt+bhyve driver stuff. Fabian. [1] https://libvirt.org/drvbhyve.html#uefi signature.asc Description: OpenPGP digital signature
Re: grub-bhyve: support overriding just --root flag
Hi Alan, > Does libvirt support using the bhyve UEFI-CSM firmware instead? That > would let the VM boot using the native grub installed inside the VM, and > avoid this issue entirely. It also makes starting a bhyve a single > command instead of 2. Thanks for the tip, I just converted the disk to GPT and now use UEFI directly. The only problem I encountered with the UEFI firmware is that it will always prefer the virtualized cdrom over hdd or, more generally, one cannot define a boot order. This gist contains a working minimal UEFI-only libvirt domain: https://gist.github.com/problame/79a94ae05f5b17e11c3b5bc2fe5910c8 If you have any idea how to set the boot order via bhyve command line flags I would be "happy" to patch libvirt to support this feature. Otherwise, I hope this helps anyone reading this in the future, Christian ___ freebsd-virtualization@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-virtualization To unsubscribe, send any mail to "freebsd-virtualization-unsubscr...@freebsd.org"
Re: grub-bhyve: support overriding just --root flag
On 11/11/2017 10:38, Christian Schwarz wrote: > (Disclaimer: also submitted this to the libvirt mailing list, but this list > seems more appropriate) > > Hi, > > I was trying to get a GPT-formatted VM boot on FreeBSD using the bhyve driver > and the grub-bhyve bootloader. > > Turns out that libvirt 3.9.0 hardcodes the boot partition to (hd0,msdos1) > or allows overriding it completly using . > > I hacked together a patch that allows overring just the --root argument to > grub-bhyve and updated the documentation: > > https://github.com/problame/libvirt/commit/5fd1265c05987d907d9f1d9913dbee832a227889 > > Obviously, this does not meet quality standards and should not be merged as > is, > but maybe spawn some discussion (if anyone is actually using bhyve + libvirt). > > Cheers, > > Christian > > > freebsd-virtualization@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-virtualization > To unsubscribe, send any mail to > "freebsd-virtualization-unsubscr...@freebsd.org" > Does libvirt support using the bhyve UEFI-CSM firmware instead? That would let the VM boot using the native grub installed inside the VM, and avoid this issue entirely. It also makes starting a bhyve a single command instead of 2. -- Allan Jude ___ freebsd-virtualization@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-virtualization To unsubscribe, send any mail to "freebsd-virtualization-unsubscr...@freebsd.org"
grub-bhyve: support overriding just --root flag
(Disclaimer: also submitted this to the libvirt mailing list, but this list
seems more appropriate)
Hi,
I was trying to get a GPT-formatted VM boot on FreeBSD using the bhyve driver
and the grub-bhyve bootloader.
Turns out that libvirt 3.9.0 hardcodes the boot partition to (hd0,msdos1)
or allows overriding it completly using .
I hacked together a patch that allows overring just the --root argument to
grub-bhyve and updated the documentation:
https://github.com/problame/libvirt/commit/5fd1265c05987d907d9f1d9913dbee832a227889
Obviously, this does not meet quality standards and should not be merged as is,
but maybe spawn some discussion (if anyone is actually using bhyve + libvirt).
Cheers,
Christian
---
commit 5fd1265c05987d907d9f1d9913dbee832a227889
Author: Christian Schwarz
Date: Sat Nov 11 16:15:05 2017 +0100
bhyve: grub-bhyve: support overriding just the --root argument in domain
config
diff --git a/docs/drvbhyve.html.in b/docs/drvbhyve.html.in
index 63260afae..2583bfa01 100644
--- a/docs/drvbhyve.html.in
+++ b/docs/drvbhyve.html.in
@@ -300,17 +300,26 @@ are omitted, libvirt will try and infer boot ordering
from user-supplied
<boot order='N'> configuration in the domain. Failing that, it will boot
the first disk in the domain (either cdrom- or
disk-type devices). If the disk type is disk, it will
-attempt to boot from the first partition in the disk image.
+attempt to boot from the first partition in the disk image, assuming
+an msdos partitioning scheme
+(i.e. grub-bhyve --root hd0,msdos1).
+You can override this behavior using bootloader_args or
bootloader_grub_root.
+
...
<bootloader>/usr/local/sbin/grub-bhyve</bootloader>
+<!-- the following tag overrides all args to grub-bhyve -->
<bootloader_args>...</bootloader_args>
+<!-- the following tag overrides just the --root argument to grub-bhyve
-->
+<bootloader_grub_root>hd0,gpt1</bootloader_grub_root>
...
-Caveat: bootloader_args does not support any quoting.
-Filenames, etc, must not have spaces or they will be tokenized incorrectly.
+Caveats when using bootloader_args: it does not support any
quoting.
+Filenames, etc, must not have spaces or they will be tokenized incorrectly.
+Additionally, you will have to maintain your own --device-map
+file and keep it in sync with the domain XML.
Using UEFI bootrom, VNC, and USB tablet
diff --git a/src/bhyve/bhyve_command.c b/src/bhyve/bhyve_command.c
index 55032ae1d..6cab6e516 100644
--- a/src/bhyve/bhyve_command.c
+++ b/src/bhyve/bhyve_command.c
@@ -774,15 +774,21 @@ virBhyveProcessBuildGrubbhyveCmd(virDomainDefPtr def,
}
virCommandAddArg(cmd, "--root");
-if (userdef != NULL) {
-if (userdef->device == VIR_DOMAIN_DISK_DEVICE_CDROM)
+if (def->os.bootloaderGrubRoot != NULL) {
+virCommandAddArg(cmd, def->os.bootloaderGrubRoot);
+} else {
+
+if (userdef != NULL) {
+if (userdef->device == VIR_DOMAIN_DISK_DEVICE_CDROM)
+virCommandAddArg(cmd, "cd");
+else
+virCommandAddArg(cmd, "hd0,msdos1");
+} else if (cd != NULL) {
virCommandAddArg(cmd, "cd");
-else
+} else {
virCommandAddArg(cmd, "hd0,msdos1");
-} else if (cd != NULL) {
-virCommandAddArg(cmd, "cd");
-} else {
-virCommandAddArg(cmd, "hd0,msdos1");
+}
+
}
virCommandAddArg(cmd, "--device-map");
diff --git a/src/conf/domain_conf.c b/src/conf/domain_conf.c
index 7dfd7b54e..ecd1f71dd 100644
--- a/src/conf/domain_conf.c
+++ b/src/conf/domain_conf.c
@@ -18141,6 +18141,7 @@ virDomainDefParseXML(xmlDocPtr xml,
def->os.bootloader = virXPathString("string(./bootloader)", ctxt);
def->os.bootloaderArgs = virXPathString("string(./bootloader_args)", ctxt);
+def->os.bootloaderGrubRoot =
virXPathString("string(./bootloader_grub_root)", ctxt);
tmp = virXPathString("string(./os/type[1])", ctxt);
if (!tmp) {
diff --git a/src/conf/domain_conf.h b/src/conf/domain_conf.h
index e3f060b12..f969e9195 100644
--- a/src/conf/domain_conf.h
+++ b/src/conf/domain_conf.h
@@ -1884,6 +1884,7 @@ struct _virDomainOSDef {
char *slic_table;
virDomainLoaderDefPtr loader;
char *bootloader;
+char *bootloaderGrubRoot;
char *bootloaderArgs;
int smbios_mode;
___
freebsd-virtualization@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-virtualization
To unsubscribe, send any mail to
"freebsd-virtualization-unsubscr...@freebsd.org"
Re: error running grub-bhyve with -S
The -S option will force allocation of guest memory (required by passthru). Is there 1G of free mem available on the machine when grub-bhyve was run ? Hi, thanks for the response. Yes, the machine had something like 6GB free (not including cache/buf). I also tried running grub-bhyve with smaller memory values down to and including 32MB (just to see if it would work, not because I expect my VM to run with that), and without a -M flag (which, IIRC, defaults to 256MB). I always got the same error. I can get that error if vmm.ko isn't loaded, but in that case the bhyvectl command would also error out and it doesn't appear to in your case. Some questions: Is this on FreeBSD CURRENT ? Does grub-bhyve work without the -S option ? Or, with -S but a different VM name ? Does the issue persist after a reboot ? later, Peter. ___ freebsd-virtualization@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-virtualization To unsubscribe, send any mail to "freebsd-virtualization-unsubscr...@freebsd.org"
Re: error running grub-bhyve with -S
On Oct 22, 2015, at 11:27 AM, Peter Grehan wrote: >> # bhyvectl —vm=vm0 --destroy >> # grub-bhyve -m /images/vm0-device.map -M 1024 -r hd1 -S vm0 >> Could not setup memory for VM >> Error in initializing VM > > The -S option will force allocation of guest memory (required by passthru). > Is there 1G of free mem available on the machine when grub-bhyve was run ? Hi, thanks for the response. Yes, the machine had something like 6GB free (not including cache/buf). I also tried running grub-bhyve with smaller memory values down to and including 32MB (just to see if it would work, not because I expect my VM to run with that), and without a -M flag (which, IIRC, defaults to 256MB). I always got the same error. JN ___ freebsd-virtualization@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-virtualization To unsubscribe, send any mail to "freebsd-virtualization-unsubscr...@freebsd.org"
Re: error running grub-bhyve with -S
# bhyvectl —vm=vm0 --destroy # grub-bhyve -m /images/vm0-device.map -M 1024 -r hd1 -S vm0 Could not setup memory for VM Error in initializing VM The -S option will force allocation of guest memory (required by passthru). Is there 1G of free mem available on the machine when grub-bhyve was run ? later, Peter. ___ freebsd-virtualization@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-virtualization To unsubscribe, send any mail to "freebsd-virtualization-unsubscr...@freebsd.org"
error running grub-bhyve with -S
I’m running bhyve on an Intel machine running FreeBSD 11-CURRENT, updated a few days ago. I have a Debian 8.2 VM that has been running fine but now I’d like to add a PCI pass-through device. Unfortunately, when I add the required “-S” flag to my grub-bhyve command line it doesn’t work: # bhyvectl —vm=vm0 --destroy # grub-bhyve -m /images/vm0-device.map -M 1024 -r hd1 -S vm0 Could not setup memory for VM Error in initializing VM Obviously, running “bhyve” after that fails as well. What would cause that error and what can I do about it? Thanks! JN ___ freebsd-virtualization@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-virtualization To unsubscribe, send any mail to "freebsd-virtualization-unsubscr...@freebsd.org"
Re: grub-bhyve: editing boot commands
Hi Andriy, Fixed upstream https://github.com/grehan-freebsd/grub2-bhyve/commit/a2265476e97afb9b67cfca0d1d9e5be8def01f33 Thank you very much! Do you plan to release a new version and update the port soon? :) Yes, I'll get that done shortly. later, Peter. ___ 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"
Re: grub-bhyve: editing boot commands
On 30/07/2015 21:18, Peter Grehan wrote: > Hi Andriy, > >> In the grub-bhyve menu of boot entries I can press 'e' and enter a screen >> where >> I can modify boot commands for that entry. >> The screen has the following help information at the bootom: >> Minimum Emacs-like screen editing is supported. >> TAB lists completions. >> Press Ctrl-x or F10 to boot, Ctrl-c or F2 for a command-line >> or ESC to discard edits and return to the GRUB menu. >> >> I can make any edits in that screen, but of the mentioned key presses only >> TAB >> and ESC work as advertised. Ctrl-x, F10, Ctrl-c, F2 are all ignored. >> Is there a way to make them work? > > Fixed upstream > > https://github.com/grehan-freebsd/grub2-bhyve/commit/a2265476e97afb9b67cfca0d1d9e5be8def01f33 Thank you very much! Do you plan to release a new version and update the port soon? :) -- Andriy Gapon ___ 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"
Re: Segmentation Fault with grub-bhyve
Hi Manas, Just a follow up, here is the backtrace from GDB Thanks for the core. Appended is a backtrace with symbols. The source may not be an exact match but it's close enough to show the issue is in zfs. Just to check: are you booting a Debian VM with a ZFS filesystem ? The version of ZFS in grub2-bhyve doesn't work with FreeBSD (the supported pool version is too old) so it's never had much of a workout. I'm looking at backporting some of the more recent grub ZFS code but it's going to take a while. later, Peter. Program terminated with signal SIGSEGV, Segmentation fault. #0 0x004798d3 in fill_vdev_info_real (data=0x5304f0 , nvlist=0x0, fill=0x40b5bf , insert=0x7fffe0e0, inserted=0x0, ashift=8) at fs/zfs/zfs.c:639 warning: Source file is more recent than executable. 639 fill->type = DEVICE_LEAF; (gdb) where #0 0x004798d3 in fill_vdev_info_real (data=0x5304f0 , nvlist=0x0, fill=0x40b5bf , insert=0x7fffe0e0, inserted=0x0, ashift=8) at fs/zfs/zfs.c:639 #1 0x00481864 in grub_zfs_read (file=0x481864 , buf=0x7fffe190 "\340\341\377\377\377\177", len=33443870448) at fs/zfs/zfs.c:3627 #2 0x00481977 in fill_fs_info (info=0x0, mdn=..., data=0x0) at fs/zfs/zfs.c:3675 #3 0x0047ae4e in recovery (bufs=0x7fffe238, s=1536, nbufs=0, powers=0x7fffe1e0, idx=0x80221900c) at fs/zfs/zfs.c:1130 #4 0x0047b3e6 in recovery (bufs=0x8020e4000, s=34389098696, nbufs=8, powers=0x11f, idx=0x8000) at fs/zfs/zfs.c:1173 #5 0x00482024 in grub_zfs_dir (device=0x802219018, path=0x7fffeb30 "\b") at fs/zfs/zfs.c:3748 #6 0x004830d3 in grub_memcpy (dest=0x7fffe8e0, src=0x8020f4800, n=18446744065119617024) at ../include/grub/misc.h:74 #7 0x in ?? () ___ 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"
Re: Segmentation Fault with grub-bhyve
Just a follow up, here is the backtrace from GDB #0 0x004798d3 in hexdump () #1 0x00481864 in hexdump () #2 0x00481977 in hexdump () #3 0x0047ae4e in hexdump () #4 0x0047b3e6 in hexdump () #5 0x00482024 in hexdump () #6 0x004830d3 in hexdump () #7 0x0040c132 in ?? () #8 0x7fffe8e0 in ?? () #9 0x000802006120 in ?? () #10 0x002902006050 in ?? () #11 0x00759340 in __progname () #12 0x7fffe930 in ?? () #13 0x0040be18 in ?? () #14 0x00546334 in ?? () #15 0x00080204c200 in ?? () #16 0x000802006050 in ?? () #17 0x00080200b1a6 in ?? () #18 0x00080204c20c in ?? () #19 0x in ?? () On 30/07/15 11:27 AM, Manas Bhatnagar wrote: > Hello, > > I am experiencing a problem with grub-bhvye on FreeBSD 10.1-RELEASE > > # grub-bhyve -m device.map -r hd0,msdos1 -M 8192M debian64 > zsh: segmentation fault (core dumped) grub-bhyve -m device.map -r > hd0,msdos1 -M 8192M debian64 > > The core dump is here: https://transfer.sh/NHdHX/grub-bhyve.core > > Any suggestions are appreciated. > > Thanks, > Manas > ___ 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"
Re: grub-bhyve: editing boot commands
Hi Andriy, In the grub-bhyve menu of boot entries I can press 'e' and enter a screen where I can modify boot commands for that entry. The screen has the following help information at the bootom: Minimum Emacs-like screen editing is supported. TAB lists completions. Press Ctrl-x or F10 to boot, Ctrl-c or F2 for a command-line or ESC to discard edits and return to the GRUB menu. I can make any edits in that screen, but of the mentioned key presses only TAB and ESC work as advertised. Ctrl-x, F10, Ctrl-c, F2 are all ignored. Is there a way to make them work? Fixed upstream https://github.com/grehan-freebsd/grub2-bhyve/commit/a2265476e97afb9b67cfca0d1d9e5be8def01f33 later, Peter. ___ 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"
Segmentation Fault with grub-bhyve
Hello, I am experiencing a problem with grub-bhvye on FreeBSD 10.1-RELEASE # grub-bhyve -m device.map -r hd0,msdos1 -M 8192M debian64 zsh: segmentation fault (core dumped) grub-bhyve -m device.map -r hd0,msdos1 -M 8192M debian64 The core dump is here: https://transfer.sh/NHdHX/grub-bhyve.core Any suggestions are appreciated. Thanks, Manas ___ 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"
Re: grub-bhyve: editing boot commands
Hi Andriy, In the grub-bhyve menu of boot entries I can press 'e' and enter a screen where I can modify boot commands for that entry. The screen has the following help information at the bootom: Minimum Emacs-like screen editing is supported. TAB lists completions. Press Ctrl-x or F10 to boot, Ctrl-c or F2 for a command-line or ESC to discard edits and return to the GRUB menu. I can make any edits in that screen, but of the mentioned key presses only TAB and ESC work as advertised. Ctrl-x, F10, Ctrl-c, F2 are all ignored. Is there a way to make them work? P.S. I tried running grub-bhyve in KDE's konsole and xterm. I've never been able to get those to work. I suspect it's that the curses terminal code hasn't been exercised a lot. I'll have a look. later, Peter. ___ 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"
grub-bhyve: editing boot commands
In the grub-bhyve menu of boot entries I can press 'e' and enter a screen where I can modify boot commands for that entry. The screen has the following help information at the bootom: Minimum Emacs-like screen editing is supported. TAB lists completions. Press Ctrl-x or F10 to boot, Ctrl-c or F2 for a command-line or ESC to discard edits and return to the GRUB menu. I can make any edits in that screen, but of the mentioned key presses only TAB and ESC work as advertised. Ctrl-x, F10, Ctrl-c, F2 are all ignored. Is there a way to make them work? P.S. I tried running grub-bhyve in KDE's konsole and xterm. -- Andriy Gapon ___ 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"
Re: bhyve -> grub-bhyve without intermediate destroy
On 22/06/2015 22:08, Peter Grehan wrote: > Hi Andriy, > >> This is what happens if I create and run a VM by using grub-bhyve and bhyve, >> then exit from the VM via shutdown -r within it, and then try to run it >> again by >> using grub-bhyve and bhyve: >> >> Assertion failed: (error == 0), function fbsdrun_addcpu, file >> /usr/src/usr.sbin/bhyve/bhyverun.c, line 261 >> >> grub-bhyve apparently succeeds, but bhyve can't start up. >> Both invocation of bhyve are with "-c 1". > > This was fixed in grub2-bhyve upstream with > > https://github.com/grehan-freebsd/grub2-bhyve/commit/370fa455d41212282bf63cea7b048e87a821a31a > > > I'm gathering a few more fixes before doing a point release of grub2-bhyve, > at > which point the FreeBSD port will be updated. > > You'll need to do a 'bhyvectl --destroy' until then, or build grub2-bhyve > from > upstream. Thank you! Will the release that you are planning include the ext4 64-bit patch? -- Andriy Gapon ___ 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"
Re: bhyve -> grub-bhyve without intermediate destroy
Hi Andriy, This is what happens if I create and run a VM by using grub-bhyve and bhyve, then exit from the VM via shutdown -r within it, and then try to run it again by using grub-bhyve and bhyve: Assertion failed: (error == 0), function fbsdrun_addcpu, file /usr/src/usr.sbin/bhyve/bhyverun.c, line 261 grub-bhyve apparently succeeds, but bhyve can't start up. Both invocation of bhyve are with "-c 1". This was fixed in grub2-bhyve upstream with https://github.com/grehan-freebsd/grub2-bhyve/commit/370fa455d41212282bf63cea7b048e87a821a31a I'm gathering a few more fixes before doing a point release of grub2-bhyve, at which point the FreeBSD port will be updated. You'll need to do a 'bhyvectl --destroy' until then, or build grub2-bhyve from upstream. later, Peter. ___ 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"
bhyve -> grub-bhyve without intermediate destroy
This is what happens if I create and run a VM by using grub-bhyve and bhyve, then exit from the VM via shutdown -r within it, and then try to run it again by using grub-bhyve and bhyve: Assertion failed: (error == 0), function fbsdrun_addcpu, file /usr/src/usr.sbin/bhyve/bhyverun.c, line 261 grub-bhyve apparently succeeds, but bhyve can't start up. Both invocation of bhyve are with "-c 1". -- Andriy Gapon ___ 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"
Re: Running grub-bhyve in the background???
On 8-2-2015 21:53, Jason Tubnor wrote: > For my OpenBSD guests, I just re-direct the grub-bhyve output to > /dev/null while feeding in my step-through configuration for > grub-bhyve. > > If I know how grub-bhyve is going to behave, I don't really need to > see what is happening at that level and just hook bhyve to nmdm. I agree with the later... And connecting stdout of grub-bhyve to /dev/null would probably work as well Will give it a shot. --WjW > On 9 February 2015 at 01:53, Willem Jan Withagen > wrote: >> On 8-2-2015 2:35, Allan Jude wrote: >>> On 2015-02-07 20:04, Willem Jan Withagen wrote: >>>> Hi (Peter), >>>> >>>> I'm trying to run grub-bhyve completely automated but when I >>>> run my version of vmrun.sh like ../bin/bhyve-run -f >>>> /usr/local/etc/ezbhyve/Ubuntu1204A/rc.conf & >>>> >>>> Thegrub-bhyve loader waits for me to forground it again, >>>> because it wants to write to the output. Probably this is due >>>> to the use of curses, which only continues if it is actually >>>> connected to the foreground. >>>> >>>> + /usr/local/sbin/grub-bhyve -e -vvv -r hd0,msdos1 -m >>>> ./ubuntu-12.04.map -M 2048M ubuntu-12.04.1 >>>> >>>> [2] + Suspended (tty output)../bin/bhyve-run -f >>>> /usr/local/etc/ezbhyve/Ubuntu1204A/rc.conf >>>> >>>> Is it possible on the commandline to get grub-bhyve to >>>> continue regardless the backgrounded state? >> >>> In newer versions of the bhyve loader, you can redirect the >>> output to a nmdm (null modem) device, so it can run unattended >> >> bhyveloader does work like this. And even if there is nobody to >> listen to the loader, things to continue. It just takes 10 sec. >> >> But once in a while I have trouble getting grub-bhyve to act the >> same. If I connect it to a nmdm-device it just waits for me to >> connect. And if I do not specify a device, it is nog possible to >> run it in the background. >> >> A inbetween sulution at the moment is to run grub-bhyve -c >> /dev/null. That continues, dus does not offer the possibility to >> interfere in the boot process. At least not for my ubuntu-12.04 >> VMs. >> >> So a flag with grub-bhyve to not require a forground process, or >> even better: ignore flowcontrol on the -c device, would be nice. >> >> --WjW ___ >> 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" > > > ___ 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"
Re: Running grub-bhyve in the background???
For my OpenBSD guests, I just re-direct the grub-bhyve output to /dev/null while feeding in my step-through configuration for grub-bhyve. If I know how grub-bhyve is going to behave, I don't really need to see what is happening at that level and just hook bhyve to nmdm. On 9 February 2015 at 01:53, Willem Jan Withagen wrote: > On 8-2-2015 2:35, Allan Jude wrote: >> On 2015-02-07 20:04, Willem Jan Withagen wrote: >>> Hi (Peter), >>> >>> I'm trying to run grub-bhyve completely automated but when I run my >>> version of vmrun.sh like >>> ../bin/bhyve-run -f /usr/local/etc/ezbhyve/Ubuntu1204A/rc.conf & >>> >>> Thegrub-bhyve loader waits for me to forground it again, because it >>> wants to write to the output. Probably this is due to the use of curses, >>> which only continues if it is actually connected to the foreground. >>> >>> >>> + /usr/local/sbin/grub-bhyve -e -vvv -r hd0,msdos1 -m ./ubuntu-12.04.map >>> -M 2048M ubuntu-12.04.1 >>> >>> [2] + Suspended (tty output)../bin/bhyve-run -f >>> /usr/local/etc/ezbhyve/Ubuntu1204A/rc.conf >>> >>> >>> Is it possible on the commandline to get grub-bhyve to continue >>> regardless the backgrounded state? > >> In newer versions of the bhyve loader, you can redirect the output to a >> nmdm (null modem) device, so it can run unattended > > bhyveloader does work like this. And even if there is nobody to listen > to the loader, things to continue. It just takes 10 sec. > > But once in a while I have trouble getting grub-bhyve to act the same. > If I connect it to a nmdm-device it just waits for me to connect. > And if I do not specify a device, it is nog possible to run it in the > background. > > A inbetween sulution at the moment is to run grub-bhyve -c /dev/null. > That continues, dus does not offer the possibility to interfere in the > boot process. At least not for my ubuntu-12.04 VMs. > > So a flag with grub-bhyve to not require a forground process, or even > better: ignore flowcontrol on the -c device, would be nice. > > --WjW > ___ > 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" -- "Roads? Where we're going, we don't need roads" - Dr. Emmett "Doc" Brown ___ 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"
Re: Running grub-bhyve in the background???
On 8-2-2015 21:04, Yamagi Burmeister wrote: > On Sun, 08 Feb 2015 15:53:45 +0100 > Willem Jan Withagen wrote: > >> A inbetween sulution at the moment is to run grub-bhyve -c /dev/null. >> That continues, dus does not offer the possibility to interfere in the >> boot process. At least not for my ubuntu-12.04 VMs. > > I hacked around that problem by writing one bit into the nmdm device. > Or to say it in code: > > true > $NMDMB & > sleep 0.5 > /usr/local/sbin/grub-bhyve -r $BOOT -m $MAP -M $MEMORY -c $NMDMA $NAME & > > It's not a nice solution but at least it works reliable. Hi Yamagi, Nice trick. The advantage is probably that you can use the nmdm device in the grub-session if things do go south? I've starting ripping the guts out of Grub2 But it really looks like a huge swiss-army knive and has several stacked layers of routines. Even ignoring all languages, modules and odd platforms.. I've got it loading now, but very little output trace. Curses is taking most of it. :( --WjW ___ 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"
Re: Running grub-bhyve in the background???
On Sun, 08 Feb 2015 15:53:45 +0100 Willem Jan Withagen wrote: > A inbetween sulution at the moment is to run grub-bhyve -c /dev/null. > That continues, dus does not offer the possibility to interfere in the > boot process. At least not for my ubuntu-12.04 VMs. I hacked around that problem by writing one bit into the nmdm device. Or to say it in code: true > $NMDMB & sleep 0.5 /usr/local/sbin/grub-bhyve -r $BOOT -m $MAP -M $MEMORY -c $NMDMA $NAME & It's not a nice solution but at least it works reliable. Regards, Yamagi -- Homepage: www.yamagi.org XMPP: yam...@yamagi.org GnuPG/GPG: 0xEFBCCBCB ___ 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"
Re: Running grub-bhyve in the background???
On 8-2-2015 2:35, Allan Jude wrote: > On 2015-02-07 20:04, Willem Jan Withagen wrote: >> Hi (Peter), >> >> I'm trying to run grub-bhyve completely automated but when I run my >> version of vmrun.sh like >> ../bin/bhyve-run -f /usr/local/etc/ezbhyve/Ubuntu1204A/rc.conf & >> >> Thegrub-bhyve loader waits for me to forground it again, because it >> wants to write to the output. Probably this is due to the use of curses, >> which only continues if it is actually connected to the foreground. >> >> >> + /usr/local/sbin/grub-bhyve -e -vvv -r hd0,msdos1 -m ./ubuntu-12.04.map >> -M 2048M ubuntu-12.04.1 >> >> [2] + Suspended (tty output)../bin/bhyve-run -f >> /usr/local/etc/ezbhyve/Ubuntu1204A/rc.conf >> >> >> Is it possible on the commandline to get grub-bhyve to continue >> regardless the backgrounded state? > In newer versions of the bhyve loader, you can redirect the output to a > nmdm (null modem) device, so it can run unattended bhyveloader does work like this. And even if there is nobody to listen to the loader, things to continue. It just takes 10 sec. But once in a while I have trouble getting grub-bhyve to act the same. If I connect it to a nmdm-device it just waits for me to connect. And if I do not specify a device, it is nog possible to run it in the background. A inbetween sulution at the moment is to run grub-bhyve -c /dev/null. That continues, dus does not offer the possibility to interfere in the boot process. At least not for my ubuntu-12.04 VMs. So a flag with grub-bhyve to not require a forground process, or even better: ignore flowcontrol on the -c device, would be nice. --WjW ___ 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"
Re: Running grub-bhyve in the background???
On 2015-02-07 20:04, Willem Jan Withagen wrote: > Hi (Peter), > > I'm trying to run grub-bhyve completely automated but when I run my > version of vmrun.sh like > ../bin/bhyve-run -f /usr/local/etc/ezbhyve/Ubuntu1204A/rc.conf & > > Thegrub-bhyve loader waits for me to forground it again, because it > wants to write to the output. Probably this is due to the use of curses, > which only continues if it is actually connected to the foreground. > > > + /usr/local/sbin/grub-bhyve -e -vvv -r hd0,msdos1 -m ./ubuntu-12.04.map > -M 2048M ubuntu-12.04.1 > > [2] + Suspended (tty output)../bin/bhyve-run -f > /usr/local/etc/ezbhyve/Ubuntu1204A/rc.conf > ==== > > Is it possible on the commandline to get grub-bhyve to continue > regardless the backgrounded state? > > Regards, > --Willem Jan > ___ > 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" > In newer versions of the bhyve loader, you can redirect the output to a nmdm (null modem) device, so it can run unattended -- Allan Jude signature.asc Description: OpenPGP digital signature
Running grub-bhyve in the background???
Hi (Peter), I'm trying to run grub-bhyve completely automated but when I run my version of vmrun.sh like ../bin/bhyve-run -f /usr/local/etc/ezbhyve/Ubuntu1204A/rc.conf & Thegrub-bhyve loader waits for me to forground it again, because it wants to write to the output. Probably this is due to the use of curses, which only continues if it is actually connected to the foreground. + /usr/local/sbin/grub-bhyve -e -vvv -r hd0,msdos1 -m ./ubuntu-12.04.map -M 2048M ubuntu-12.04.1 [2] + Suspended (tty output)../bin/bhyve-run -f /usr/local/etc/ezbhyve/Ubuntu1204A/rc.conf Is it possible on the commandline to get grub-bhyve to continue regardless the backgrounded state? Regards, --Willem Jan ___ 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"
Re: does grub-bhyve limit guest ram?
Hi Aryeh, When I try to run a guest with 4G it fails but with 2GB it works What does the failure look like ? grub-bhyve doesn't support the humanized mem syntax - the memory amount has to be specified in units of MB. later, Peter. ___ 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"
Re: does grub-bhyve limit guest ram?
2014-01-29 Aryeh Friedman : > When I try to run a guest with 4G it fails but with 2GB it works > It doesn't seem to have such a limit. My instances happily use 4096 MBytes of RAM (I'm with 32G on the host machine). -- Markiyan. > -- > Aryeh M. Friedman, Lead Developer, http://www.PetiteCloud.org > ___ > 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" ___ 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"
does grub-bhyve limit guest ram?
When I try to run a guest with 4G it fails but with 2GB it works -- Aryeh M. Friedman, Lead Developer, http://www.PetiteCloud.org ___ 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"
