Solved No working /usr/bin/cc after upgrade

astyle

astyle

Discussion:

I downloaded 14.1-RELEASE-amd64-disk1.iso (no patches), installed it inside a VirtualBox VM, and ran freebsd-update fetch and freebsd-update install, as per Handbook.

During the upgrade, the original VM crashed when I ran freebsd-update fetch for the first time - it happened at "Inspecting System" step. Well, the very reason for updating is that original 14.1-RELEASE was very unstable for me inside VBox.

I rebooted the VM, re-ran freebsd-update fetch, it finished without complaints this time. Then I ran freebsd-update install, rebooted a couple times, and then freebsd-version showed me that I'm at p2.

Great. I fetched a snapshot of ports from cgit.freebsd.org/ports, went to editors/nano as the very first thing I want to compile on a clean system. But just typing make config ended in failure. I was able to capture the entire output, which is attached as typescript.txt.

Reading through typescript.txt, it looks like my problem is that
Code: 
elf_load_section: truncated ELF file
No working C compiler found. Tried cc and gcc.
Click to expand...

I suspect this is related to what I saw during my second attempt at freebsd-update: I was told that CC and Clang got patched. I just blindly said OK to that.

I don't want to resort to pkg, I want to compile my ports!

It does look like the upgrade corrupted my /usr/bin/cc 😭

Is there anything that can be done short of ripping out a working copy of cc from another FreeBSD installation? I'm open to ideas.
 

Attachments

  • typescript.txt
    4.9 KB · Views: 40
Tried to SSH into my VM, and re-run freebsd-update fetch... Yep, something's up with the p2 files...
Code: 
root@kde6:/home/astyle # freebsd-update -F fetch
Looking up update.FreeBSD.org mirrors... 3 mirrors found.
Fetching metadata signature for 14.1-RELEASE from update1.freebsd.org... done.
Fetching metadata index... done.
Inspecting system... done.
Preparing to download files... done.
The following files will be updated as part of updating to
14.1-RELEASE-p2:
/usr/bin/c++
/usr/bin/cc
/usr/bin/clang
/usr/bin/clang++
/usr/bin/clang-cpp
/usr/bin/cpp
root@kde6:/home/astyle # freebsd-update install
Creating snapshot of existing boot environment... done.
Installing updates...gunzip: (stdin): unexpected end of file

The files all weigh in at 49MB. And if gunizip sees an unexpected EOF, then of course those compilers are corrupted and won't work. This has me thinking that maybe it's the files on FreeBSD's update servers are the ones having a problem.

Edit: After following Alain De Vos ' suggestion, I discovered that the files are supposed to weigh in at 92.6 MB... which is frankly in line with what one can expect when the compilers work.
 
Update: Just ripping out files from the original 14.1-RELEASE didn't work:
Code: 
root@kde6:/home/astyle # cd /usr/ports/editors/nano
root@kde6:/usr/ports/editors/nano # cc -version
su: cc: Exec format error
( make config failed when checking the compilers).

Patching the compilers with freebsd-update didn't work, either - I ended up reproducing the problem I'm having in the first place.

Well, the p2 patches did make my VM stable, so I'm happy I got that, if nothing else. :/

BUT after ripping out older (known working) compilers from the metal that's hosting my kde6 VM:
Code: 
root@kde6:/usr/ports/editors/nano # cc --version
FreeBSD clang version 14.0.5 (https://github.com/llvm/llvm-project.git llvmorg-14.0.5
-0-gc12386ae247c)
Target: x86_64-unknown-freebsd13.2
Thread model: posix
InstalledDir: /usr/bin
root@kde6:/usr/ports/editors/nano #

Bingo.
1720464796773.png


(Well, the fact that 13.2, rather than 14.1 is the compilers' default target - that is a little worrisome. But this is a 14.1-RELEASE VM, so let's see how far I can take this. Because of the targeting mismatch, I'm not marking this solved yet).

Edit: Well, 14.1-RELEASE VM is back to crashing during compilations. I didn't even get very far in trying to compile editors/nano 😩
 
Caught myself on yet another detail I completely missed - post #2 pointed me to arm64's base.txz, and I needed amd64... so not all is lost, I can make corrections and probably continue... Pheeww.

Well, no go, it looks like I should just use a fresh ports snapshot with the VM running 13.3-RELEASE, because VM with 14.1-RELEASE keeps crashing when the base compilers work properly. I'd rather chase kde6 than figure out why the VM crashes when it shouldn't.
 
astyle said:
This has me thinking that maybe it's the files on FreeBSD's update servers are the ones having a problem.
Click to expand...
No problems here.
Code: 
root@fbsd-test:~ # freebsd-version -urk
14.1-RELEASE
14.1-RELEASE
14.1-RELEASE
root@fbsd-test:~ # freebsd-update fetch
src component not installed, skipped
Looking up update.FreeBSD.org mirrors... 3 mirrors found.
Fetching metadata signature for 14.1-RELEASE from update2.freebsd.org... done.
Fetching metadata index... done.
Fetching 2 metadata patches.. done.
Applying metadata patches... done.
Fetching 1 metadata files... done.
Inspecting system... done.
Preparing to download files... done.
Fetching 59 patches.....10....20....30....40....50.... done.
Applying patches... done.
The following files will be updated as part of updating to
14.1-RELEASE-p2:
/bin/freebsd-version
/boot/kernel/zfs.ko
/lib/libc++.so.1
/lib/libzpool.so.2
/rescue/[
/rescue/bectl
/rescue/bsdlabel
/rescue/bunzip2
/rescue/bzcat
/rescue/bzip2
/rescue/camcontrol
/rescue/cat
/rescue/ccdconfig
/rescue/chflags
/rescue/chgrp
/rescue/chio
/rescue/chmod
/rescue/chown
/rescue/chroot
/rescue/clri
/rescue/cp
/rescue/csh
/rescue/date
/rescue/dd
/rescue/devfs
/rescue/df
/rescue/dhclient
/rescue/disklabel
/rescue/dmesg
/rescue/dump
/rescue/dumpfs
/rescue/dumpon
/rescue/echo
/rescue/ed
/rescue/ex
/rescue/expr
/rescue/fastboot
/rescue/fasthalt
/rescue/fdisk
/rescue/fetch
/rescue/fsck
/rescue/fsck_4.2bsd
/rescue/fsck_ffs
/rescue/fsck_msdosfs
/rescue/fsck_ufs
/rescue/fsdb
/rescue/fsirand
/rescue/gbde
/rescue/geom
/rescue/getfacl
/rescue/glabel
/rescue/gpart
/rescue/groups
/rescue/gunzip
/rescue/gzcat
/rescue/gzip
/rescue/halt
/rescue/head
/rescue/hostname
/rescue/id
/rescue/ifconfig
/rescue/init
/rescue/ipf
/rescue/iscsictl
/rescue/iscsid
/rescue/kenv
/rescue/kill
/rescue/kldconfig
/rescue/kldload
/rescue/kldstat
/rescue/kldunload
/rescue/ldconfig
/rescue/less
/rescue/link
/rescue/ln
/rescue/ls
/rescue/lzcat
/rescue/lzma
/rescue/md5
/rescue/mdconfig
/rescue/mdmfs
/rescue/mkdir
/rescue/mknod
/rescue/more
/rescue/mount
/rescue/mount_cd9660
/rescue/mount_msdosfs
/rescue/mount_nfs
/rescue/mount_nullfs
/rescue/mount_udf
/rescue/mount_unionfs
/rescue/mt
/rescue/mv
/rescue/nc
/rescue/newfs
/rescue/newfs_msdos
/rescue/nos-tun
/rescue/pgrep
/rescue/ping
/rescue/ping6
/rescue/pkill
/rescue/poweroff
/rescue/ps
/rescue/pwd
/rescue/rcorder
/rescue/rdump
/rescue/realpath
/rescue/reboot
/rescue/red
/rescue/rescue
/rescue/restore
/rescue/rm
/rescue/rmdir
/rescue/route
/rescue/routed
/rescue/rrestore
/rescue/rtquery
/rescue/rtsol
/rescue/savecore
/rescue/sed
/rescue/setfacl
/rescue/sh
/rescue/shutdown
/rescue/sleep
/rescue/stty
/rescue/swapon
/rescue/sync
/rescue/sysctl
/rescue/tail
/rescue/tar
/rescue/tcsh
/rescue/tee
/rescue/test
/rescue/tunefs
/rescue/umount
/rescue/unlink
/rescue/unlzma
/rescue/unxz
/rescue/unzstd
/rescue/vi
/rescue/whoami
/rescue/xz
/rescue/xzcat
/rescue/zcat
/rescue/zdb
/rescue/zfs
/rescue/zpool
/rescue/zstd
/rescue/zstdcat
/rescue/zstdmt
/sbin/devd
/usr/bin/c++
/usr/bin/c++filt
/usr/bin/cc
/usr/bin/clang
/usr/bin/clang++
/usr/bin/clang-cpp
/usr/bin/cpp
/usr/bin/dtc
/usr/bin/gcov
/usr/bin/kyua
/usr/bin/ld.lld
/usr/bin/lldb
/usr/bin/lldb-server
/usr/bin/llvm-addr2line
/usr/bin/llvm-ar
/usr/bin/llvm-cov
/usr/bin/llvm-cxxfilt
/usr/bin/llvm-nm
/usr/bin/llvm-objcopy
/usr/bin/llvm-objdump
/usr/bin/llvm-profdata
/usr/bin/llvm-ranlib
/usr/bin/llvm-readelf
/usr/bin/llvm-readobj
/usr/bin/llvm-size
/usr/bin/llvm-strings
/usr/bin/llvm-strip
/usr/bin/llvm-symbolizer
/usr/bin/objdump
/usr/bin/users
/usr/include/c++/v1/string
/usr/lib/clang/18/lib/freebsd/libclang_rt.fuzzer-x86_64.a
/usr/lib/clang/18/lib/freebsd/libclang_rt.fuzzer_no_main-x86_64.a
/usr/lib/libc++.a
/usr/lib/libpmc.a
/usr/lib/libpmc.so.5
/usr/lib/libprivateatf-c++.a
/usr/lib/libprivateatf-c++.so.2
/usr/lib/libprivatedevdctl.a
/usr/lib/libprivatedevdctl.so.0
/usr/lib/libprivategmock.a
/usr/lib/libprivategmock.so.0
/usr/lib/libprivategmock_main.a
/usr/lib/libprivategmock_main.so.0
/usr/lib/libprivategtest.a
/usr/lib/libprivategtest.so.0
/usr/lib/libprivatessh.a
/usr/lib/libprivatessh.so.5
/usr/lib/libzpool.a
/usr/lib32/libc++.a
/usr/lib32/libc++.so.1
/usr/lib32/libpmc.a
/usr/lib32/libpmc.so.5
/usr/lib32/libprivatedevdctl.a
/usr/lib32/libprivatedevdctl.so.0
/usr/lib32/libprivatessh.a
/usr/lib32/libprivatessh.so.5
/usr/lib32/libzpool.a
/usr/lib32/libzpool.so.2
/usr/libexec/atf-check
/usr/libexec/atf-sh
/usr/libexec/atf_pytest_wrapper
/usr/sbin/config
/usr/sbin/sshd
/usr/sbin/zfsd
root@fbsd-test:~ # freebsd-update install
src component not installed, skipped
Creating snapshot of existing boot environment... done.
Installing updates...
Restarting sshd after upgrade
Performing sanity check on sshd configuration.
Stopping sshd.
Waiting for PIDS: 988.
Performing sanity check on sshd configuration.
Starting sshd.
Scanning /usr/share/certs/untrusted for certificates...
Scanning /usr/share/certs/trusted for certificates...
 done.
root@fbsd-test:~ # cc --version
FreeBSD clang version 18.1.5 (https://github.com/llvm/llvm-project.git llvmorg-18.1.5-0-g617a15a9eac9)
Target: x86_64-unknown-freebsd14.1
Thread model: posix
InstalledDir: /usr/bin
root@fbsd-test:~ #
root@fbsd-test:~ # freebsd-version -urk
14.1-RELEASE
14.1-RELEASE
14.1-RELEASE-p2
 
SirDice said:
No problems here.
Code: 
root@fbsd-test:~ # freebsd-version -urk
14.1-RELEASE
14.1-RELEASE
14.1-RELEASE
root@fbsd-test:~ # freebsd-update fetch
src component not installed, skipped
Looking up update.FreeBSD.org mirrors... 3 mirrors found.
Fetching metadata signature for 14.1-RELEASE from update2.freebsd.org... done.
Fetching metadata index... done.
Fetching 2 metadata patches.. done.
Applying metadata patches... done.
Fetching 1 metadata files... done.
Inspecting system... done.
Preparing to download files... done.
Fetching 59 patches.....10....20....30....40....50.... done.
Applying patches... done.
The following files will be updated as part of updating to
14.1-RELEASE-p2:
/bin/freebsd-version
/boot/kernel/zfs.ko
/lib/libc++.so.1
/lib/libzpool.so.2
/rescue/[
/rescue/bectl
/rescue/bsdlabel
/rescue/bunzip2
/rescue/bzcat
/rescue/bzip2
/rescue/camcontrol
/rescue/cat
/rescue/ccdconfig
/rescue/chflags
/rescue/chgrp
/rescue/chio
/rescue/chmod
/rescue/chown
/rescue/chroot
/rescue/clri
/rescue/cp
/rescue/csh
/rescue/date
/rescue/dd
/rescue/devfs
/rescue/df
/rescue/dhclient
/rescue/disklabel
/rescue/dmesg
/rescue/dump
/rescue/dumpfs
/rescue/dumpon
/rescue/echo
/rescue/ed
/rescue/ex
/rescue/expr
/rescue/fastboot
/rescue/fasthalt
/rescue/fdisk
/rescue/fetch
/rescue/fsck
/rescue/fsck_4.2bsd
/rescue/fsck_ffs
/rescue/fsck_msdosfs
/rescue/fsck_ufs
/rescue/fsdb
/rescue/fsirand
/rescue/gbde
/rescue/geom
/rescue/getfacl
/rescue/glabel
/rescue/gpart
/rescue/groups
/rescue/gunzip
/rescue/gzcat
/rescue/gzip
/rescue/halt
/rescue/head
/rescue/hostname
/rescue/id
/rescue/ifconfig
/rescue/init
/rescue/ipf
/rescue/iscsictl
/rescue/iscsid
/rescue/kenv
/rescue/kill
/rescue/kldconfig
/rescue/kldload
/rescue/kldstat
/rescue/kldunload
/rescue/ldconfig
/rescue/less
/rescue/link
/rescue/ln
/rescue/ls
/rescue/lzcat
/rescue/lzma
/rescue/md5
/rescue/mdconfig
/rescue/mdmfs
/rescue/mkdir
/rescue/mknod
/rescue/more
/rescue/mount
/rescue/mount_cd9660
/rescue/mount_msdosfs
/rescue/mount_nfs
/rescue/mount_nullfs
/rescue/mount_udf
/rescue/mount_unionfs
/rescue/mt
/rescue/mv
/rescue/nc
/rescue/newfs
/rescue/newfs_msdos
/rescue/nos-tun
/rescue/pgrep
/rescue/ping
/rescue/ping6
/rescue/pkill
/rescue/poweroff
/rescue/ps
/rescue/pwd
/rescue/rcorder
/rescue/rdump
/rescue/realpath
/rescue/reboot
/rescue/red
/rescue/rescue
/rescue/restore
/rescue/rm
/rescue/rmdir
/rescue/route
/rescue/routed
/rescue/rrestore
/rescue/rtquery
/rescue/rtsol
/rescue/savecore
/rescue/sed
/rescue/setfacl
/rescue/sh
/rescue/shutdown
/rescue/sleep
/rescue/stty
/rescue/swapon
/rescue/sync
/rescue/sysctl
/rescue/tail
/rescue/tar
/rescue/tcsh
/rescue/tee
/rescue/test
/rescue/tunefs
/rescue/umount
/rescue/unlink
/rescue/unlzma
/rescue/unxz
/rescue/unzstd
/rescue/vi
/rescue/whoami
/rescue/xz
/rescue/xzcat
/rescue/zcat
/rescue/zdb
/rescue/zfs
/rescue/zpool
/rescue/zstd
/rescue/zstdcat
/rescue/zstdmt
/sbin/devd
/usr/bin/c++
/usr/bin/c++filt
/usr/bin/cc
/usr/bin/clang
/usr/bin/clang++
/usr/bin/clang-cpp
/usr/bin/cpp
/usr/bin/dtc
/usr/bin/gcov
/usr/bin/kyua
/usr/bin/ld.lld
/usr/bin/lldb
/usr/bin/lldb-server
/usr/bin/llvm-addr2line
/usr/bin/llvm-ar
/usr/bin/llvm-cov
/usr/bin/llvm-cxxfilt
/usr/bin/llvm-nm
/usr/bin/llvm-objcopy
/usr/bin/llvm-objdump
/usr/bin/llvm-profdata
/usr/bin/llvm-ranlib
/usr/bin/llvm-readelf
/usr/bin/llvm-readobj
/usr/bin/llvm-size
/usr/bin/llvm-strings
/usr/bin/llvm-strip
/usr/bin/llvm-symbolizer
/usr/bin/objdump
/usr/bin/users
/usr/include/c++/v1/string
/usr/lib/clang/18/lib/freebsd/libclang_rt.fuzzer-x86_64.a
/usr/lib/clang/18/lib/freebsd/libclang_rt.fuzzer_no_main-x86_64.a
/usr/lib/libc++.a
/usr/lib/libpmc.a
/usr/lib/libpmc.so.5
/usr/lib/libprivateatf-c++.a
/usr/lib/libprivateatf-c++.so.2
/usr/lib/libprivatedevdctl.a
/usr/lib/libprivatedevdctl.so.0
/usr/lib/libprivategmock.a
/usr/lib/libprivategmock.so.0
/usr/lib/libprivategmock_main.a
/usr/lib/libprivategmock_main.so.0
/usr/lib/libprivategtest.a
/usr/lib/libprivategtest.so.0
/usr/lib/libprivatessh.a
/usr/lib/libprivatessh.so.5
/usr/lib/libzpool.a
/usr/lib32/libc++.a
/usr/lib32/libc++.so.1
/usr/lib32/libpmc.a
/usr/lib32/libpmc.so.5
/usr/lib32/libprivatedevdctl.a
/usr/lib32/libprivatedevdctl.so.0
/usr/lib32/libprivatessh.a
/usr/lib32/libprivatessh.so.5
/usr/lib32/libzpool.a
/usr/lib32/libzpool.so.2
/usr/libexec/atf-check
/usr/libexec/atf-sh
/usr/libexec/atf_pytest_wrapper
/usr/sbin/config
/usr/sbin/sshd
/usr/sbin/zfsd
root@fbsd-test:~ # freebsd-update install
src component not installed, skipped
Creating snapshot of existing boot environment... done.
Installing updates...
Restarting sshd after upgrade
Performing sanity check on sshd configuration.
Stopping sshd.
Waiting for PIDS: 988.
Performing sanity check on sshd configuration.
Starting sshd.
Scanning /usr/share/certs/untrusted for certificates...
Scanning /usr/share/certs/trusted for certificates...
 done.
root@fbsd-test:~ # cc --version
FreeBSD clang version 18.1.5 (https://github.com/llvm/llvm-project.git llvmorg-18.1.5-0-g617a15a9eac9)
Target: x86_64-unknown-freebsd14.1
Thread model: posix
InstalledDir: /usr/bin
root@fbsd-test:~ #
root@fbsd-test:~ # freebsd-version -urk
14.1-RELEASE
14.1-RELEASE
14.1-RELEASE-p2
Click to expand...
Interesting... esp. the results of cc --version... 😲

Maybe I should just try again, and install 14.1-RELEASE in another VM...
 
Yes, something bad happened to your VM - I get the same as SirDice:
Code: 
# cc --version
FreeBSD clang version 18.1.5 (https://github.com/llvm/llvm-project.git llvmorg-18.1.5-0-g617a15a9eac9)
Target: x86_64-unknown-freebsd14.1
Thread model: posix
InstalledDir: /usr/bin
# freebsd-version -ruk
14.1-RELEASE
14.1-RELEASE
14.1-RELEASE-p2
 
Tried again, my VM crashed again when applying the patches and spitting out the list of what got applied:
Code: 
root@kde6_1:/home/astyle # freebsd-version
14.1-RELEASE
root@kde6_1:/home/astyle # freebsd-update fetch
Looking up update.FreeBSD.org mirrors... 3 mirrors found.
Fetching public key from update1.freebsd.org... done.
Fetching metadata signature for 14.1-RELEASE from update1.freebsd.org... done.
Fetching metadata index... done.
Fetching 2 metadata files... done.
Inspecting system... done.
Preparing to download files... done.
Fetching 53 patches.....10....20....30....40....50. done.
Applying patches... done.
The following files will be updated as part of updating to
14.1-RELEASE-p2:
/bin/freebsd-version
/boot/kernel/zfs.ko
/lib/libc++.so.1
/lib/libzpool.so.2
/rescue/[
/rescue/bectl
/rescue/bsdlabel
/rescue/bunzip2
/rescue/bzcat
/rescue/bzip2
/rescue/camcontrol
/rescue/cat
/rescue/ccdconfig
/rescue/chflags
/rescue/chgrp
/rescue/chio
/rescue/chmod
/rescue/chown
/rescue/chroot
/rescue/clri

The only reason I even got that many lines of output was because I ssh'ed into the VM with help of Konsole on the metal...

Anything I should be doing differently at this point, or just boot up and run freebsd-update install ?
 
Looks like you've tried it twice - install 14.1-RELEASE on VirtualBox, then the first freebsd-update "crashes" - so something with VirtualBox (what's the host?) and a FreeBSD 14.1 guest and freebsd-update causes an issue?
 
Well, ended up booting up, ran freebsd-update install - and VM crashed again
Code: 
# freebsd-update install
Creating snapshot of existing boot environment... done.
Installing updates...gunzip: (stdin): unexpected end of file

Restarting sshd after upgrade
Performing sanity check on sshd configuration.
Stopping sshd.
Waiting for PIDS: 831.
Performing sanity check on sshd configuration.
Starting sshd.
Scanning /usr/share/certs/untrusted for certificates...
Scanning /usr/share/certs/trusted for certificates...
 done.

It seems like in this case, just being stubborn and running freebsd-update -F fetch after every crash (the -F option is supposed to force a re-fetch of the patches) should do the job:
Code: 
root@kde6_1:/home/astyle # cc --version
FreeBSD clang version 18.1.5 (https://github.com/llvm/llvm-project.git llvmorg-18.1.5
-0-g617a15a9eac9)
Target: x86_64-unknown-freebsd14.1
Thread model: posix
InstalledDir: /usr/bin
root@kde6_1:/home/astyle # freebsd-version
14.1-RELEASE-p2

Metal/Hostname:
$ uname -a
FreeBSD thinkpad 13.2-RELEASE FreeBSD 13.2-RELEASE releng/13.2-n254617-525ecfdad597 GENERIC amd64
 
It looks like one of the patch files it downloaded got corrupted, causing the error when trying to extract it. You could delete everything in /var/db/freebsd-update/ before doing freebsd-update fetch maybe it cached a corrupted file.

Usually before I do a release upgrade freebsd-update -r <version> upgrade I clear that /var/db/freebsd-update/ directory, just to make sure everything is pristine.
 
Thanks.

astyle said:
original VM crashed
Click to expand...

astyle said:
VM is back to crashing
Click to expand...

astyle said:
keeps crashing
Click to expand...

astyle said:
I ssh'ed into the VM
Click to expand...

astyle said:
VM crashed again
Click to expand...

In any of those cases, did the host window to the guest virtual machine disappear?

Was there any guest kernel panic (system crash)?

Was it a single virtual machine with multiple installations (one after the other), or separate VMs?

How much memory was given to the guest?
 
Cath O'Deray said:
1. In any of those cases, did the host window to the guest virtual machine disappear?

2. Was there any guest kernel panic (system crash)?

3. Was it a single virtual machine with multiple installations (one after the other), or separate VMs?

4. How much memory was given to the guest?
Click to expand...
3. Multiple installations (one after another) into same VM.

1. Yep, when VM crashes, host window to guest VM disappeared. The VirtualBox management console showed the VM as 'Aborted'.

2. No idea if any of them experienced a kernel panic. I suspect swap paging issues. Screenshot shows a running VM that got updated to -p2 patchlevel. Prior to the updating, those same errors did cause the VM to crash:
1720583796500.png



4. VM had 16 GB of RAM (metal host has 40 GB).
 
Thanks,

astyle said:
when VM crashes, host window to guest VM disappeared. The VirtualBox management console showed the VM as 'Aborted'.
Click to expand...

I should assume that the case that allowed ssh was different. (I can't imagine an aborted, non-windowed machine allowing ssh connections.)

ZFS also at the host, for the volume that stores the virtual drive?

Which version of FreeBSD, exactly, on the host?
 
It might that freebsd-update is tickling an area of FreeBSD 14.1 that causes an issue with VirtualBox - e.g. I had this issue:

forums.freebsd.org

Solved - Dell R430, R640, H730, freebsd-update and CAM error

Hi, Taken a while to get this far, but wondering if anyone has seen anything like this and/or has some answers. I've gone through a lot of machines, but the simple reproducible case is: 1) Dell R430 (or R640) 2) Dell H730 RAID controller 3) mrsas driver 4) old firmware or latest makes no...
forums.freebsd.org forums.freebsd.org

It started off being very easy to trigger with freebsd-update but was actually a driver issue.

EDIT: just to clarify my story NOTHING to do with VirtualBox, just an illustration of how freebsd-update triggered a hard-to-find issue involving a few journeys down rabbit-holes!
 
Cath O'Deray said:
ZFS also at the host, for the volume that stores the virtual drive?

Which version of FreeBSD, exactly, on the host?
Click to expand...

astyle said:
Metal/Hostname:
$ uname -a
FreeBSD thinkpad 13.2-RELEASE FreeBSD 13.2-RELEASE releng/13.2-n254617-525ecfdad597 GENERIC amd64
Click to expand...
richardtoohey2 said:
It might that freebsd-update is tickling an area of FreeBSD 14.1 that causes an issue with VirtualBox - e.g. I had this issue:

forums.freebsd.org

Solved - Dell R430, R640, H730, freebsd-update and CAM error

Hi, Taken a while to get this far, but wondering if anyone has seen anything like this and/or has some answers. I've gone through a lot of machines, but the simple reproducible case is: 1) Dell R430 (or R640) 2) Dell H730 RAID controller 3) mrsas driver 4) old firmware or latest makes no...
forums.freebsd.org forums.freebsd.org

It started off being very easy to trigger with freebsd-update but was actually a driver issue.
Click to expand...
richardtoohey2 : That's astonishing, but might be a nudge that is needed to encourage getting the emulators/virtualbox-ose port to be up-to-date with upstream.
 
Thanks. Scrub the host, if you haven't already done so, and if it's HDD or hybrid: a more thorough check.

You could also scrub at the guest level, although I doubt that it will uncover anything.

astyle said:
… The VirtualBox management console showed the VM as 'Aborted'. …
Click to expand...

15.0-CURRENT here. I haven't encountered that symptom in a very long time, I doubt that the issue is with VirtualBox.

In my case I looked less at VirtualBox (as a cause), more at:
  • physical storage
  • how it was connected
  • host activities at the times of failures.
 
My experience with this is several years old now, but on multiple occasions I ran into mystifying filesystem corruption issues with VirtualBox on a FreeBSD host when "Use Host I/O Cache" was turned off for virtual SATA controllers (which was the default, at least at that time). I put an entry in my notes, warning myself to never do that again.

Make of this what you will.
 
You must log in or register to reply here.
Back
Top