https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=250934
Aleksandr Fedorov changed:
What|Removed |Added
CC||afedo...@freebsd.org,
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=250934
Li-Wen Hsu changed:
What|Removed |Added
Assignee|b...@freebsd.org|virtualizat...@freebsd.org
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
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
>
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
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
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 fro
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!Be
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 eac
* 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 lis
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 i
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 reproducibl
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
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 sign
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].
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
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
(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
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
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
# 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
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
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.
___
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:
>
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
?? ()
#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 -
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.
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
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.
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
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:
>&
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
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
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
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
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 p
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 p
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/Ubu
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 wait
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 th
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,
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
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 uns
43 matches
Mail list logo