#linuxulator — Public Fediverse posts

Running Podman on FreeBSD? It’s a totally different beast than Linux. :freebsd:

I just published a follow-up to my previous Podman deep dive, going into the FreeBSD operational model for OCI containers. No systemd, no Quadlets, and no rootless mode, but you get native ZFS storage drivers, rc.d service integration, and the Linuxulator.

We also cover the big question: why Podman complements Jails instead of replacing them.

Read it here: https://blog.hofstede.it/podman-on-freebsd-oci-containers-without-systemd/

#FreeBSD #Podman #Linuxulator #ZFS #Homelab

Getting `KLD Linux.ko: depends on kernel - not available or version mismatch` on a machine that runs the #Linuxulator on #FreeBSD after upgrading a pkgbasified 14 to 15. Same for related file system modules. Is there anything I can do right now, or should I revert and wait for the modules to be re-compiled for 15? When would those versions hit -RELEASE?

🎩✨ Oh look, someone discovered the #Linuxulator on #FreeBSD and thinks it's magical because VS Code kinda works. 🎉🚀 It’s like finding out that water is wet—astoundingly groundbreaking! 🧙‍♂️🔍
https://hayzam.com/blog/02-linuxulator-is-awesome/ #VSCode #discovery #techmagic #groundbreaking #HackerNews #ngated

🎩✨ Oh look, someone discovered the #Linuxulator on #FreeBSD and thinks it's magical because VS Code kinda works. 🎉🚀 It’s like finding out that water is wet—astoundingly groundbreaking! 🧙‍♂️🔍
https://hayzam.com/blog/02-linuxulator-is-awesome/ #VSCode #discovery #techmagic #groundbreaking #HackerNews #ngated

🎩✨ Oh look, someone discovered the #Linuxulator on #FreeBSD and thinks it's magical because VS Code kinda works. 🎉🚀 It’s like finding out that water is wet—astoundingly groundbreaking! 🧙‍♂️🔍
https://hayzam.com/blog/02-linuxulator-is-awesome/ #VSCode #discovery #techmagic #groundbreaking #HackerNews #ngated

🎩✨ Oh look, someone discovered the #Linuxulator on #FreeBSD and thinks it's magical because VS Code kinda works. 🎉🚀 It’s like finding out that water is wet—astoundingly groundbreaking! 🧙‍♂️🔍
https://hayzam.com/blog/02-linuxulator-is-awesome/ #VSCode #discovery #techmagic #groundbreaking #HackerNews #ngated

Linuxulator on FreeBSD Feels Like Magic

https://hayzam.com/blog/02-linuxulator-is-awesome/

#HackerNews #Linuxulator #FreeBSD #Magic #Linux #FreeBSD #TechNews

@trashheap <https://www.reddit.com/r/freebsd/comments/1qyh3pe/comment/o43qttr/>

"… Maybe first runs of www/chromium are just a little fragile. …"

I made a messy screen recording that shows failure with a first run.

Cc @clf

#FreeBSD #DRM #Widevine #Chromium #Linuxulator

@mpts Thanks again for your tip! My #Jekyll build chain works - via a Git hook calling the #Linuxulator - on my existing #Forgejo #FreeBSD server now.

Quick writeup for anyone interested:

https://oxcrag.net/blog/2025/07/26/GitOps-website-deployment-with-Forgejo-and-Jekyll-on-FreeBSD.html

@mikael Hmm, I see. Wouldn't the bundler break on a Linux distro as well?

When it comes to the Linux-only SASS library, a solution might be to run it with #Linuxulator on #FreeBSD. I've done it in the past for various programs that are only released for Linux.

Good luck!

Ok, so check this out. I raved about how magical #FreeBSD #linuxulator is, but it gets even better! In my Ubuntu linux jail, I downloaded the source for the #mobian kernel, installed cross-compiling tools, compiled the kernel and modules, copied to an sdcard, and booted up the kernel on my #pinephonepro 🤯 So, on my amd64 FreeBSD, I used a translation layer to load up Ubuntu Linux, used it to cross-compile a Linux kernel for arm64, and booted that up on a device! How unbelievable is that?!?

Oh wow, the #FreeBSD #Linuxulator is just magic! I setup an Ubuntu #LinuxJail as described in the linked wiki and was able to compile and flash #Arduino code to my Uno using #PlatformIO, which is absolutely mind blowing because the tools for compiling are not available for "freebsd_amd64", yet in this Linux environment (not emulated, not a VM, just a translation layer), the Linux binaries were able to compile and then flash to the USB device (using the FreeBSD kernel… https://tobykurien.com/post-1744211915

One of the main things that worried me regarding running #FreeBSD on this computer was the unavailability of #1Password for this operating system: With unique credentials everywhere and multiple devices, some sort of centralized secrets manager is a must. Fortunately the #Firefox plugin works here. Next step will be to dip my toes into the #linuxulator to see what can be done that way.

#Podman has been ported to #FreeBSD. And it can run Arch Linux for me.

Linux containers in FreeBSD can start through the old good #Linuxulator - which does not support complex features like cgroups or namespaces, which means I probably can't run a container inside a container. Yet.

But this Linux layer is actively supported in FreeBSD for almost 20 years and is rock-solid! It started in 2006 at Google, based on Linux kernel 2.6 and today it shows up as 5.15-compatible!

In case you did not know, you can easily watch #Netflix or other content that requires #WidevineDRM on #FreeBSD, thanks to #linuxulator compatibility layer.

Very easy to set up. And one more solid reason to use FreeBSD as your primary daily driver, without the need to switch to something else.

https://github.com/mrclksr/linux-browser-installer

@meka not really. In a jail, using Gentoo's "portage" to build packages probably would make sense. But the #Linuxulator userland should not run jailed but instead integrated (by means of the "overlay" that's by default in /compat/linux) with the #FreeBSD userland, so it can (mostly!) access the same files at the same paths. This comes with additional requirements and also additional challenges building the packages (so unmodified portage wouldn't work either). It makes more sense using #FreeBSD ports for that, as you probably want FreeBSD packages. Moreover, it's possible to "bootstrap" that without the need for any Linux binary, by first cross-compiling the #GNU toolchain, I got this part working somewhat well 😉

@meka Unfortunately, I hit a roadblock (needing #rust for #Linuxulator before getting to a point where I could actually test some closed-source #Linux software) and didn't find time to experiment building that on #FreeBSD. So, no conclusion yet, and to continue, I'd have to go through the whole branch again first and at least upgrade everything .... 😞

@stefano Ok, so you're exactly where I finally gave up, my instance is running in a #Devuan vm (no docker involved) after I failed to both run it inside #FreeBSD and #Linuxulator jails 😞

Update on my #FreeBSD #Linuxulator "userland from source" project: Fixing "interesting" issues 🙄

I meanwhile created a #ports #overlay, for easy testing in different environments, and trying it on my "productive" builder, there were suddenly lots of failures. The "weirdest" one now took me many days to fully understand: For some ports, "stage" seemed to install the files just fine, yet "package" didn't find any files. 🤯

Turns out installing using #Linux tools created the stagedir below /compat/linux instead. Trying to understand why, the answer was "because it could".

The indirect reason was #ccache, forcing #poudriere to do everything as root by default, and for root, /compat/linux is writable. There are still some other fails, maybe also ccache-related, but at least I just committed a workaround (including a warning) for *this* issue:
https://github.com/Zirias/freebsd-ports-overlay-linuxsrc/commit/e354a4d999e79f40d0f6aee1a40c897613ec7460

@thindil Haha, that was just a gentle hint 😉. But I think it's really important to understand the difference between #Linuxulator and #LinuxKPI, although you're certainly right, *both* were further improved/extended in #FreeBSD 14.

BTW, I'm pretty sure there is *no* GPL-licensed code in the kernel. There is some GPL-licensed code in base, yes, but you can build base without it; the goal is always to provide a full BSD-licensed OS.

In fact, if I'm not mistaken, remains of GPL-licensed files in LinuxKPI are the main reason we still have drm-kmod drivers as a port (and not integrated with the base kernel), where this port includes these small parts of LinuxKPI. The drm drivers themselves are not GPL-licensed.

@thindil Haha, that was just a gentle hint 😉. But I think it's really important to understand the difference between #Linuxulator and #LinuxKPI, although you're certainly right, *both* were further improved/extended in #FreeBSD 14.

BTW, I'm pretty sure there is *no* GPL-licensed code in the kernel. There is some GPL-licensed code in base, yes, but you can build base without it; the goal is always to provide a full BSD-licensed OS.

In fact, if I'm not mistaken, remains of GPL-licensed files in LinuxKPI are the main reason we still have drm-kmod drivers as a port (and not integrated with the base kernel), where this port includes these small parts of LinuxKPI. The drm drivers themselves are not GPL-licensed.

@thindil Haha, that was just a gentle hint 😉. But I think it's really important to understand the difference between #Linuxulator and #LinuxKPI, although you're certainly right, *both* were further improved/extended in #FreeBSD 14.

BTW, I'm pretty sure there is *no* GPL-licensed code in the kernel. There is some GPL-licensed code in base, yes, but you can build base without it; the goal is always to provide a full BSD-licensed OS.

In fact, if I'm not mistaken, remains of GPL-licensed files in LinuxKPI are the main reason we still have drm-kmod drivers as a port (and not integrated with the base kernel), where this port includes these small parts of LinuxKPI. The drm drivers themselves are not GPL-licensed.

@thindil Haha, that was just a gentle hint 😉. But I think it's really important to understand the difference between #Linuxulator and #LinuxKPI, although you're certainly right, *both* were further improved/extended in #FreeBSD 14.

BTW, I'm pretty sure there is *no* GPL-licensed code in the kernel. There is some GPL-licensed code in base, yes, but you can build base without it; the goal is always to provide a full BSD-licensed OS.

In fact, if I'm not mistaken, remains of GPL-licensed files in LinuxKPI are the main reason we still have drm-kmod drivers as a port (and not integrated with the base kernel), where this port includes these small parts of LinuxKPI. The drm drivers themselves are not GPL-licensed.

@thindil Haha, that was just a gentle hint 😉. But I think it's really important to understand the difference between #Linuxulator and #LinuxKPI, although you're certainly right, *both* were further improved/extended in #FreeBSD 14.

BTW, I'm pretty sure there is *no* GPL-licensed code in the kernel. There is some GPL-licensed code in base, yes, but you can build base without it; the goal is always to provide a full BSD-licensed OS.

In fact, if I'm not mistaken, remains of GPL-licensed files in LinuxKPI are the main reason we still have drm-kmod drivers as a port (and not integrated with the base kernel), where this port includes these small parts of LinuxKPI. The drm drivers themselves are not GPL-licensed.

@thindil @emaste Please understand that a #syscall is something completely different than some other, in-kernel, call. A syscall is the special way userspace can call something in the kernel, which needs a context switch. Some architectures have special CPU instructions for syscalls available, on other architectures, software-interrupts (that the kernel can handle) are used, etc.

Nothing of that is done for in-kernel calls, they're "just" function calls.

#FreeBSD #Linuxulator provides a set of #Linux-compatible syscalls. The #LinuxKPI project on the other hand aims to provide in-kernel Linux compatibility for use by certain drivers. They're completely unrelated.

BTW, you're missing a syllable, it's spelled LinuxULator 😉

@thindil @emaste Please understand that a #syscall is something completely different than some other, in-kernel, call. A syscall is the special way userspace can call something in the kernel, which needs a context switch. Some architectures have special CPU instructions for syscalls available, on other architectures, software-interrupts (that the kernel can handle) are used, etc.

Nothing of that is done for in-kernel calls, they're "just" function calls.

#FreeBSD #Linuxulator provides a set of #Linux-compatible syscalls. The #LinuxKPI project on the other hand aims to provide in-kernel Linux compatibility for use by certain drivers. They're completely unrelated.

BTW, you're missing a syllable, it's spelled LinuxULator 😉

@thindil @emaste Please understand that a #syscall is something completely different than some other, in-kernel, call. A syscall is the special way userspace can call something in the kernel, which needs a context switch. Some architectures have special CPU instructions for syscalls available, on other architectures, software-interrupts (that the kernel can handle) are used, etc.

Nothing of that is done for in-kernel calls, they're "just" function calls.

#FreeBSD #Linuxulator provides a set of #Linux-compatible syscalls. The #LinuxKPI project on the other hand aims to provide in-kernel Linux compatibility for use by certain drivers. They're completely unrelated.

BTW, you're missing a syllable, it's spelled LinuxULator 😉

@thindil @emaste Please understand that a #syscall is something completely different than some other, in-kernel, call. A syscall is the special way userspace can call something in the kernel, which needs a context switch. Some architectures have special CPU instructions for syscalls available, on other architectures, software-interrupts (that the kernel can handle) are used, etc.

Nothing of that is done for in-kernel calls, they're "just" function calls.

#FreeBSD #Linuxulator provides a set of #Linux-compatible syscalls. The #LinuxKPI project on the other hand aims to provide in-kernel Linux compatibility for use by certain drivers. They're completely unrelated.

BTW, you're missing a syllable, it's spelled LinuxULator 😉

@thindil @emaste Please understand that a #syscall is something completely different than some other, in-kernel, call. A syscall is the special way userspace can call something in the kernel, which needs a context switch. Some architectures have special CPU instructions for syscalls available, on other architectures, software-interrupts (that the kernel can handle) are used, etc.

Nothing of that is done for in-kernel calls, they're "just" function calls.

#FreeBSD #Linuxulator provides a set of #Linux-compatible syscalls. The #LinuxKPI project on the other hand aims to provide in-kernel Linux compatibility for use by certain drivers. They're completely unrelated.

BTW, you're missing a syllable, it's spelled LinuxULator 😉

Did all these tests, did some fixes, "#Linuxulator userland from source" branch builds fine on #FreeBSD 14-CURRENT/13.2-RELEASE, aarch64/amd64/i386 🥳

Now doing test builds with 15-CURRENT, which already has a fix for the #Linux #xattr issue. Unfortunately, it's still incomplete. Neverending story 😞

JFTR, not blaming dchagin at all. It seems Linux has some very weird design decisions, and semantics of the xattr syscall return codes -- EPERM is considered fatal by GNU/Linux tools, because Linux returns ENOATTR or ENOTSUP when access to e.g. the system namespace is restricted 🤯

Double-checking still in progress. So far, fixed an issues on 13.2/aarch64, another one on 14-CURRENT/amd64 (yep, didn't upgrade my #FreeBSD test builders to 15-CURRENT yet 🙈) and yet another one on 14-CURRENT/i386.

Now, test builds for 13.2/i386 are running. We will see. Once I'm sure the #Linuxulator version of #ffmpeg builds fine everywhere, I'll finally check #MakeMKV 😎

And now, the *real* dependency monster in my #FreeBSD #Linuxulator userland: #ffmpeg 🙈

That's #Linux port #151 I added, it has *almost* everything enabled that's in the default options of the FreeBSD port. I left out a few things that seemed (too) complex like vulkan ... 🙈

I guess now it's time to double-check the branch on other architectures and other FreeBSD versions first. And then, finally, check whether #MakeMKV will work fine with this!

@meka Well, if you can build them, you can (probably) port them to work natively on #FreeBSD. This is "just" about building the userland for #Linuxulator to support closed-source (or, otherwise "unportable") #Linux apps.

I'm still unsure whether it's a good idea. I was thinking about using #MakeMKV as a PoC, which requires #ffmpeg. Only half way (or less) through with the dependencies for a somewhat "full-featured" ffmpeg and I'm already at 135 commits to my branch 🤯 I certainly won't be able to maintain all the ports needed for this userland all by myself 😉

Minor news from my #FreeBSD #Linuxulator userland project: I now succeeded to build a first "dependency monster" (in order to have all features consumers might expect): #cairo. Among other things, required porting all the #Xorg libs first 😉

I'm about to force-push my #Linuxulator userland branch now, removing all hacks to disable xattr usage.

TL;DR is: If you want to test it on #FreeBSD 14 and newer right now, you'll have to apply this patch: https://people.freebsd.org/~dchagin/xattr.patch -- I hope it will be committed to main and stable/14 soon 😎

The (weird) background is: Support for #Linux xattr syscalls was added quite recently, and it correctly maps the Linux syscalls to the FreeBSD ones. So far, so good. BUT: Access to the "system" namespace for extended attributes is typically restricted to root (and, on FreeBSD, also restricted in #jails). Now, FreeBSD returns EPERM on rejected attempts, which IMHO makes perfect sense. But, Linux returns ENOTSUP in these cases instead. And: GNU tools and other Linux software using extended attributes consider EPERM a *fatal* error as a consequence. This means things like "install" from GNU coreutils are now broken in jails and as non-root. 🤯

The patch above fixes this.

@alexr Sorry, but it really doesn't make sense to me to compare anything just regarding #Linux vs #Linuxulator. The kernel(!) as a source of indeterminism is very unlikely, everything else (like #glibc where the allocator is implemented) is the same. I don't see what I would gain from that huge amount of work here.

@alexr Are you suggesting that the same GCC (native #Linux, not cross-target) would produce different code when the Kernel isn't "real" #Linux, but #FreeBSD's #Linuxulator?

I still see no sane way to check this, maybe short of installing this very same version on a Linux system and comparing assembler output... 🤔 but it doesn't seem like a likely thing to me 🤷‍♂️

Did some minor fixes and overall improvements in the new USES=linuxsrc today ... it already grew quite large 🤔
https://github.com/Zirias/zfbsd-ports/blob/linux/Mk/Uses/linuxsrc.mk

BTW, a while ago, I couldn't resist to add some #branding to the #FreeBSD #Linuxulator toolchain, currently in line 119.

I mean, the #vendor field in these target triplets is there for a reason, right? To be used by vendors? 😏

Today's progress on #FreeBSD #Linuxulator "userland from source" project: We have build systems! 🥳

Supported now (apart of plain #make): GNU #autotools (including #autoreconf), #cmake, #meson and #ninja!

They're all supported with their original #ports "USES", by some #bmake trickery in my new "USES=linuxsrc", fixing up just the parts that are different when building from/for the Linuxulator (like adjusting dependencies and commands to use the #Linux-native versions).

Ok, no #scons yet, didn't need it so far 🙈

Today's progress on #FreeBSD #Linuxulator "userland from source" project: We have build systems! 🥳

Supported now (apart of plain #make): GNU #autotools (including #autoreconf), #cmake, #meson and #ninja!

They're all supported with their original #ports "USES", by some #bmake trickery in my new "USES=linuxsrc", fixing up just the parts that are different when building from/for the Linuxulator (like adjusting dependencies and commands to use the #Linux-native versions).

Ok, no #scons yet, didn't need it so far 🙈

Today's progress on #FreeBSD #Linuxulator "userland from source" project: We have build systems! 🥳

Supported now (apart of plain #make): GNU #autotools (including #autoreconf), #cmake, #meson and #ninja!

They're all supported with their original #ports "USES", by some #bmake trickery in my new "USES=linuxsrc", fixing up just the parts that are different when building from/for the Linuxulator (like adjusting dependencies and commands to use the #Linux-native versions).

Ok, no #scons yet, didn't need it so far 🙈

Today's progress on #FreeBSD #Linuxulator "userland from source" project: We have build systems! 🥳

Supported now (apart of plain #make): GNU #autotools (including #autoreconf), #cmake, #meson and #ninja!

They're all supported with their original #ports "USES", by some #bmake trickery in my new "USES=linuxsrc", fixing up just the parts that are different when building from/for the Linuxulator (like adjusting dependencies and commands to use the #Linux-native versions).

Ok, no #scons yet, didn't need it so far 🙈

Today's progress on #FreeBSD #Linuxulator "userland from source" project: We have build systems! 🥳

Supported now (apart of plain #make): GNU #autotools (including #autoreconf), #cmake, #meson and #ninja!

They're all supported with their original #ports "USES", by some #bmake trickery in my new "USES=linuxsrc", fixing up just the parts that are different when building from/for the Linuxulator (like adjusting dependencies and commands to use the #Linux-native versions).

Ok, no #scons yet, didn't need it so far 🙈

Time for cleanup after identifying two "interesting" issues:

1.) #FreeBSD ports come with a Templates/config.site file which is normally used by #GNU #autoconf, containing quite a lot of "cache variables" so autoconf can avoid running the actual tests. Nice, but completely wrong when targeting #Linux. So, add an empty "CONFIG_SITE=" variable to every linux port, and suddenly I can also remove some explicit cache variables again 🙈

2.) I'm building the "native" toolchain for #Linuxulator --with-sysroot=/compat/linux, which makes sure the linker reliably finds startup files and system libs, without stuff from FreeBSD base interfering. BUT: This completely breaks when some explicit lib path to /usr/lib or /usr/lib64 is added (and many build systems will do that), because sysroot doesn't apply here. Therefore, add wrapper scripts around gcc and g++ filtering out any "-L/usr/lib" or "-L/usr/lib64" argument 🙈 with that, Linux #bash builds without any patches! 🥳

Now, waiting for builds.

@bdiederik No. #Debian's #kfreebsd is a #GNU userland configured to use the (native) #FreeBSD kernel. What I'm building here is a #GNU userland using a #Linux kernel (although "faked" by #FreeBSD's #Linuxulator -- the kernel can provide a Linux-compatible userspace-ABI, syscalls etc...)

The goal is to replace the ancient "linux-c7" userland currently offered in FreeBSD ports. I'm testing here whether building a userland from source would be a feasible way 😉

Indeed, sanity-checking the new #Linux-native #GCC for #FreeBSD's #Linuxulator shows it works perfectly fine at least for C, and using static #libgcc (because I removed the libgcc_s.so file, should really be packaged separately) 🥳

So, to complete the toolchain, next steps will be separate ports for libgcc and libstdc++, should be possible to build these with this native gcc, we will see!

Indeed, sanity-checking the new #Linux-native #GCC for #FreeBSD's #Linuxulator shows it works perfectly fine at least for C, and using static #libgcc (because I removed the libgcc_s.so file, should really be packaged separately) 🥳

So, to complete the toolchain, next steps will be separate ports for libgcc and libstdc++, should be possible to build these with this native gcc, we will see!

Indeed, sanity-checking the new #Linux-native #GCC for #FreeBSD's #Linuxulator shows it works perfectly fine at least for C, and using static #libgcc (because I removed the libgcc_s.so file, should really be packaged separately) 🥳

So, to complete the toolchain, next steps will be separate ports for libgcc and libstdc++, should be possible to build these with this native gcc, we will see!

Indeed, sanity-checking the new #Linux-native #GCC for #FreeBSD's #Linuxulator shows it works perfectly fine at least for C, and using static #libgcc (because I removed the libgcc_s.so file, should really be packaged separately) 🥳

So, to complete the toolchain, next steps will be separate ports for libgcc and libstdc++, should be possible to build these with this native gcc, we will see!

Indeed, sanity-checking the new #Linux-native #GCC for #FreeBSD's #Linuxulator shows it works perfectly fine at least for C, and using static #libgcc (because I removed the libgcc_s.so file, should really be packaged separately) 🥳

So, to complete the toolchain, next steps will be separate ports for libgcc and libstdc++, should be possible to build these with this native gcc, we will see!