hi, im trying to boot and imported win7 img in bhyve. it boots into uefi interactive shell. any ideas how to solve this ?

Was the Windows 7 installation already UEFI-ready?

michaeldexter: dont know.. its from a virtualbox vm

maybe not

virtualbox vdi*

is there an alternatie config from uefi that i could use in the vm.conf ?

michaeldexter: maybe its legacy

hernan: It would need to be converted to UEFI first. Reportedly this can be done with some versions of Windows 7.

this is a fascinating case of dunning kruegerism: bugs.freebsd.org/bugzilla/show_bug.cgi?id=271403

Title: 271403 – System unusable at first boot after install of 13.2-RELEASE amd64

like, yeah, been there, done that

meena: Oh, it's Dennis

vkarlsen: who's Dennis?

grahamperrin: you maybe saw Mina here?

I set up a azure cloud native freebsd instance with 2 vcpus up and running. Trying to make a Orleans bootstrap script soon(tm).

RhodiumToad: a meena, I recall here.

for root on azure you can create a different user in azure console and then # sudo /bin/csh

password based ssh login works there have not tried ssh keys there.

I wonder if this was about cloud-init

meena: Dennis Clarke of Blastwave fame

what might cause zfs send dset@now | cat > /dev/null to only do about 100MB/sec ?

dd read/writes can do 600MB/sec, FTP/SCP transfers of files also net 500-700MB/sec

last

last1: what if you skip cat?

I don't think our cat is as optimised as GNU cat

even without cat, I get about the same speeds

zfs send dset@now | mbuffer -s 128k -m 1G | pv -rtab > /dev/null

110-120MB/sec

"gptzfsboot tries to find all ZFS pools that are composed of BIOS-visible hard disks or partitions on them." man GPTZFSBOOT(8)

does anyone know if a way to boot a ZFS pool form a non BIOS-visible disk?

meena: Not sure if it's an issue on my end, but FreeBSD-clibs-dev had an issue installing due to not being able to rename some temp files (or dirs) in /usr/include/c++/v1.

meena: Can't remember off the top of my head, but it looked like existing files in /usr/include/c++/v1 weren't being dealt with before installing the new ones. Though now that I think about, if it's using /usr/bin/install, then that should happened automatically.

Usecase: use USB to boot NVME on a motherboard that doesn't support booting from NVME. (I've done this on Linux, so I would assume freeBSD could also do this as well)

_xor: i usually blame whoever committed last

Any idea how to resolve this so that Arch Linux is satisfied: bugs.freebsd.org/bugzilla/show_bug.cgi?id=69 ?

Title: 69 – "Erase pencil mark!" does not leave enough clues

qtc`: depends what exactly you mean by "boot"

qtc`: on a non-UEFI system, neither boot nor loader can access anything that the bios can't access, so all of /boot would need to be on the USB. but from that point on, anything that the kernel can access is available

is 14.0 suppose to be stable ? if so - where is the download for it --- stable/14 branch --- 12 May 2023 -stable/14 branch created; release engineering continues on this branch

Title: FreeBSD 14.0 Release Process | The FreeBSD Project

Title: Get FreeBSD | The FreeBSD Project

Title: Index of /snapshots/amd64/amd64/ISO-IMAGES/14.0/

acu: No, the code freeze was delayed. The core team is still pushing things to that step first.

coreystephanphd, thanks - anyhow - once in stable, whatever it is built on that will end in 14 Release I assume

Yes. There will not be binary upgrades available until (at least) -ALPHA, otherwise -BETA or -RC. So for an ordinary end user not doing production testing etc., 13.2-RELEASE (which just came out a month or 2 ago) is the place to be.

if using synth, do i just use "make config" if i want to tweak a port's config options, or is there a way to do that in synth? i'm not seeing one in the docs.

RhodiumToad > anything that the kernel can access is available.

thats the method I used with Linux. but I don't know how to accomplish this with freeBSD

maybe I'm just looking at the wrong portion docs?

what you need to do is to split off /boot from the rest of the root filesystem, put it on a bootable USB, and put appropriate definitions into /boot/loader.conf (and in /etc/fstab to mount /boot)

I don't know if it's documented as such

is this a UEFI system or legacy boot? and does it support GPT?

No, right now I'm working on a MBR/BIOS system

But I plan to move one of the installs over toa GPT system when its setup/configured correctly

ok. so the USB needs to be partitioned for bootable MBR, and you need to install /boot/boot on it as bootcode

give it an "a" slice big enough to hold /boot with some spare space

then put vfs.root.mountfrom="zfs:zroot/ROOT/default" or whatever in the loader.conf on the usb

gpart bootcode -b /boot/pmbr -p /boot/boot -i 2 da0

look correct?

it's /boot/mbr for non-GPT

actually no

gpart bootcode -b /boot/mbr da0 and gpart bootcode -b /boot/boot da0s1 (or whatever the active partition is)

-p is only used for GPT where you have a freebsd-boot partition, which isn't what you're doing here

I think /boot/boot expects a BSD-style partition table, too

so gpart create -s MBR da0; gpart add -t freebsd da0; gpart create -s BSD da0s1; etc.

14 kernel boots fine waiting for buildworld if i may keep my iPhone such long.

but most important: azure uses tux as logo for a freebsd vm in the app.

qtc`: are you getting the idea or do I need to go into more detail?

I think I get the idea, will need to reformat the usb and copy data again before i know if i got it

Is there a non-polling way to be notified when a jail stops/dies? Like is there a file descriptor or something created somewhere that I can select()?

Also, what are prison_* functions?

Oh, nevermind, just saw the comment. "Kernel support functions for jail()"

I'm definitely doing something wrong pad.bsd.to/p/usb-boot

Title: FreeBSD Etherpad

I'm getting "Boot error"

RhodiumToad> does what i'm doing look correct?

The "etherpad" -- which widget produces the raw text without any controls, formatting, etc?

"Print" produces the browser print dialog.

Etherpad is for group work on documents. Did you want the pastebin (bsd.to) instead?

Title: dpaste

qtc` posted on etherpad; so was trying to see if could get that in plainer text. V_PauAmma_V, thanks for the reminder about "bsd.to"

here is the pastebin bsd.to/HNpP

Title: dpaste/HNpP (Bash)

Does the order of "newfs" & "gpart bootcode" matter? Or, my question is would "newfs" not erase bootcode?

ahh.. I run bhyve guests with a stdio and just stuff them into the background with a tmux session. I accidentally killed the tmux window that a single bhyve guest was using. bhyve is still running in the background. Is there some way of re-attaching to what I'm assuming is now a dangling stdio handle?

I *could* just restart the bhyve in a fresh tmux window but.. ehh.

parv> Does the order of "newfs" & "gpart bootcode" matter?

I would think so, so when it didnt work I rebooted into the live installer and ran the gpart bootcode for da0 again

so it doesn't look like that is the issue

Ok

any good ios freebsd ssh client that can be recommended?

Don't know about "ios freebsd ssh client"; For iOS, ty mosh & La Terminal

I haven't used any much

ty, one of those works with screen off?

Can't say

trying la terminal when dropping out again

la terminal looks promising

woops, reptyr will instakill a bhyve session. restarting the bhyve guest it is then.

midnight: what? how?

meena: I was running bhyve using a stdio com1 in a tmux window. I wanted to kill that session, but not the whole server, so I c-b,: kill-window by accident. The bhyve guest was functioning fine in the background. I wanted to open a new shell in that tmux, then reptyr to recapture the stdio for that guest. I installed reptyr, then ran: reptyr [bhyve pid]. That failed with "Unable to attach to pid 61149:

Capabilities insufficient". I then observed that the bhyve process was gone, and the guest was not responding to network ping. I then completed the kill with bhyvectl --destroy, and restarted. It's possible I missed something obvious I guess.

if you can reproduce this, especially with another type of console attached to it, so you may be able to observe what's going on, it might very well be worth a bug report

it doesn't matter what reptyr is doing, bhyve should be more resilient than that

Doesn't reptyr do some process injection stuff with ptrace?

I don't care

00:25 <meena> it doesn't matter what reptyr is doing, bhyve should be more resilient than that

But, probably I agree with you. It's okay in my case, it was more a "ooh opportunity to try"

that's how i discover a lot of bugs

indeed :-D

"this is probably going to work out just fine!" followed by, "there's no reason why this shouldn't have worked out just fine! wtf?"

hah, heard that