Re: Building a Linuxulator userland from source
I never tried. But you have suggested a fun project to work with. On Fri, Aug 18, 2023 at 9:56 AM Aryeh Friedman wrote: > On Fri, Aug 18, 2023 at 3:45 AM Mario Marietto > wrote: > > > > Nice idea,but I think you will have no advantages changing userland. > Actually I ve been able to squeeze the maximum features from the > linuxulator. So im sure that you will not add any more feature to it. Im > running cuda with the nvidia drivers and maya 2023 inside the linuxulator. > What else could I want to do from it ? I even tried different cg tools but > they didnt work because some bugs. The same bugs that you will find using > another userland. Im also running successfully stable diffusion and my > Nvidia gpu is recognized like a real linux box. > > Still doesn't support tensorflow or pytorch in GPU mode > -- Mario.
Re: Building a Linuxulator userland from source
Hello.
For example some time ago I started an email exchange with a FreeBSD
developer because I'd found two bugs. You can see our full log here :
https://pastebin.ubuntu.com/p/HvVC9pkgVB/
I've removed the name of the developer. Anyway he said that he was
investigating,but at some point he stopped to reply. So I don't know if the
bugs are already there or not. Or if he has submitted them.
I'm not experienced,but I suspect that those kinds of bugs aren't caused by
the kind of userland,but at a level of abstraction layer. So,if you change
userland,you will not fix them.
On Sat, Aug 19, 2023 at 12:00 PM Felix Palmen wrote:
> * Mario Marietto [20230818 18:17]:
> > But if I have understood well,do you want to change the userland and you
> > are sure to reach a better linux compatibility? I don't think you will be
> > able to. The linuxulator is not perfect because it is bugged at a "low"
> > level. Changing the userland it will remain bugged.
>
> Ok, let's get this straight ...
>
> 1.) If you think "linuxulator is bugged at a 'low' level", whatever this
> should mean, then please be specific about it, but please do so where it
> is on topic, e.g. in a PR on bugzilla.
>
> 2.) A very frequent issue when trying to run some Linux binary on
> FreeBSD is that shared libs are either missing or too old (which is btw
> why many people resort to installing some other dist in some Linux jail
> instead of using the linux-c7 ports). So, *of course* a newer userland
> will fix this. The uncertainty here is just whether it can be a feasible
> approach to build this userland from source. Ongoing research.
>
> Cheers, Felix
>
> --
> Felix Palmen {private} fe...@palmen-it.de
> -- ports committer -- {web} http://palmen-it.de
> {pgp public key} http://palmen-it.de/pub.txt
> {pgp fingerprint} 6936 13D5 5BBF 4837 B212 3ACC 54AD E006 9879 F231
>
--
Mario.
Re: Building a Linuxulator userland from source
Would be nice to have a linux userland such as nixos instead of ubuntu / Centos. Can nixos be used ? On Sun, Aug 20, 2023 at 11:25 PM Tatsuki Makino wrote: > Hello. > > I only know enough about linuxulator that I can maintain > print/epson-inkjet-printer-escpr2... > However... > > I think /compat/linux is a very important path for linuxulator and/or > linux-binary, and I think it would be problematic to prevent it from being > used. > I don't know enough to write here why it is, as noted above 🤣 > If I can spend a little more time, I might write something. > > Regards. > > > -- Mario.
Re: Building a Linuxulator userland from source
-> Ideally the userland should be choosable for example if you got GPU passthrough to work on debian then odds are you could pass it through to FreeBSD I didn't understand well what you meant. Can you elaborate in a different way ? thanks. On Mon, Aug 21, 2023 at 1:11 AM Aryeh Friedman wrote: > On Sun, Aug 20, 2023 at 5:53 PM Mario Marietto > wrote: > > > > Would be nice to have a linux userland such as nixos instead of ubuntu / > Centos. Can nixos be used ? > > Ideally the userland should be choosable for example if you got GPU > passthrough to work on debian then odds are you could pass it through > to FreeBSD > > > > On Sun, Aug 20, 2023 at 11:25 PM Tatsuki Makino < > tatsuki_mak...@hotmail.com> wrote: > >> > >> Hello. > >> > >> I only know enough about linuxulator that I can maintain > print/epson-inkjet-printer-escpr2... > >> However... > >> > >> I think /compat/linux is a very important path for linuxulator and/or > linux-binary, and I think it would be problematic to prevent it from being > used. > >> I don't know enough to write here why it is, as noted above 🤣 > >> If I can spend a little more time, I might write something. > >> > >> Regards. > >> > >> > > > > > > -- > > Mario. > > > > -- > Aryeh M. Friedman, Lead Developer, http://www.PetiteCloud.org > -- Mario.
Re: Building a Linuxulator userland from source
CentOS has been replaced already successfully with Ubuntu and Devuan. On the FreeBSD forums there are a couple of nice tutorials. BTW if we can use even different user lands,we will be even happier. On Tue, Aug 22, 2023 at 1:04 PM Trenton Schulz wrote: > > Felix Palmen writes: > > > > > I assume/hope that's a minor risk. /usr/local is not in the > > standard > > search paths of the toolchain, so, must be added explicitly. A > > build > > system doing that without being requested to do so would be > > pretty much > > broken. Furthermore, the toolchain is built > > --with-sysroot=/compat/linux > > so prepends that to all the system search paths. > > > > Configure scripts finding *tools* in FreeBSD's /usr/local > > *might* be a > > risk. Not an issue building with poudriere (the build jail will > > only > > have what we want), but maybe an issue when someone builds the > > ports in > > a live system. > > > > Well, we will see :) At least, I already have the first ports > > building > > fine using shell and make from the Linux userland, e.g. here: > > > https://github.com/Zirias/zfbsd-ports/blob/linux/sysutils/linux-man-db/Makefile > > This is really fascinating work, and I see value in this even if > some other way of doing things eventually replaces the Centos-7 items. > > Some of this has a bit of overlap with Gentoo prefix > (https://wiki.gentoo.org/wiki/Project:Prefix), where one puts the > bare bones of a Gentoo distro under a "prefix" (for example, > /compat/linux), but then you can use Gentoo's portage > infrastructure to build the other parts of the system. > > I imagine, you are maybe thinking of your own set of linux-* in > the ports tree, but this might also be useful area to borrow from? > > Anyway, I'll lurk back into the shadows to see how this develops. > > Best regards, > > -- > Trenton > > -- Mario.
Re: Building a Linuxulator userland from source
---> you won't be able to use FreeBSD ports/packages of Linux software with
it...
I'm interested to understand what you mean better herecan you elaborate
using different words ? thanks.
On Tue, Aug 22, 2023 at 2:13 PM Felix Palmen wrote:
> * Mario Marietto [20230822 13:59]:
> > CentOS has been replaced already successfully with Ubuntu and Devuan.
>
> No. You can install whatever you like in some Linux jail, you could even
> use it as an alternate compat.linux.emul_path if you want, in both cases
> it will partially work.
>
> You *won't* get e.g. full unhindered access to the whole / filesystem
> tree, you won't be able to use FreeBSD ports/packages of Linux software
> with it, and so on.
>
> FreeBSD's official Linuxulator userland is -c7, nothing has been
> replaced. Please stop spreading such unfounded claims.
>
> Bye, Felix
>
> --
> Felix Palmen {private} fe...@palmen-it.de
> -- ports committer -- {web} http://palmen-it.de
> {pgp public key} http://palmen-it.de/pub.txt
> {pgp fingerprint} 6936 13D5 5BBF 4837 B212 3ACC 54AD E006 9879 F231
>
--
Mario.
Re: Building a Linuxulator userland from source
It would be nice to try that tool that can hack / convert ./ add another
layer (another linux distro inside the first one. I dont remember the name
now.
Il mer 23 ago 2023, 08:21 Felix Palmen ha scritto:
> * Cy Schubert [20230822 10:34]:
> > Basically this would become another Linux distro, albeit a virtual one
> > that runs under our Linuxulator.
>
> And also a pretty minimal one. Right now, I'm just building a truly
> minimal userland (the GNU toolchain, openssl, GNU make/grep/sed/awk, GNU
> coreutils and man-db) and working on putting together some sane USES for
> that.
>
> > Avoiding discussion about packaging -- we can package this any way we
> > wish -- how will this support software written for distro A, B, or C.
> > For example, Red Hat software doesn't neccesarily run on SuSE or
> > Ubuntu because shared library dependencies may be different.
> >
> > Building our own "distro" to run under the Linuxulator may require a
> > complete set of packages and end-user applications because existing
> > Linux software may require a Fedora, Debian or Red Hat library.
> > Wouldn't this negate the need for a Linuxulator because a person can
> > build most Linux software to run on native FreeBSD.
>
> Well first, when I ask why "Linuxulator" is needed, the answer in my
> head is: Mostly for closed-source Linux software. Because exactly as you
> say, anything else should better be ported and built to run natively on
> FreeBSD, if possible.
>
> Now, maybe I'm looking at the wrong software? In my experience with
> closed-source Linux Software, sure, it *might* offer
> distribution-specific packages, but almost always offers a plain binary
> tarball as well. The latter could easily be used to create a port (like
> was done in the past as well in our tree), and then it's just a question
> of adding ports for the (hopefully few) shared libraries needed by this
> software.
>
> > I think a better path might be to support multiple Linux userlands in
> > parallel. Thus a user could simply copy or install vendor software for
> > a Red Hat in one environment and a SuSE vendor software in another.
>
> This would be the consequence if you really want to support
> distribution-specific software packages. I don't think it's feasible in
> practice, at least it would make it very hard to still have ports of
> Linux software (like my makemkv port), these would need to build and run
> with any of these userlands.
>
> To challenge my source-based approach, I'm looking for "proof of
> concept" closed-source software to try get running with it, I'll
> probably start with makemkv because I already maintain that port. Open
> to suggestions what else to test there. In the end, getting to run e.g.
> Google Chrome would be perfect, but I imagine this requires creating a
> lot of ports for shared libs first.
>
> Cheers, Felix
>
> --
> Felix Palmen {private} fe...@palmen-it.de
> -- ports committer -- {web} http://palmen-it.de
> {pgp public key} http://palmen-it.de/pub.txt
> {pgp fingerprint} 6936 13D5 5BBF 4837 B212 3ACC 54AD E006 9879 F231
>
Should we boot the FreeBSD kernel in ELF format or in zImage format ? How?
Hello. we have just virtualized Debian 12 on our arm (32 bit) Chromebook. As host / dom0 we have chosen Devuan 5,and for guest / domU,Debian 12. It works great. But our goal is different. We want to virtualize FreeBSD as domU. Can we have a working Xen PV network driver for a FreeBSD arm guest ?. I found that Julien Grall has ported the Xen drivers to FreeBSD on arm. I would like to know if Julien's work was accepted upstream by FreeBSD, in which case FreeBSD as a Xen guest on arm should work if we enable the Xen PV drivers in the FreeBSD on arm kernel. If Julien's work was not accepted upstream by FreeBSD, we will have to find his patches and apply them ourselves to the FreeBSD on arm kernel. We found these slides : https://events.static.linuxfound.org/sites/events/files/slides/Porting%20FreeBSD%20on%20Xen%20on%20ARM%20.pdf Slide 13 refers to a XENHVM FreeBSD on arm kernel config - that is what we want to find. It looks like when that slide presentation was written, there were some limitations on FreeBSD Xen guests. For example, for our debian bookworm guest, I am using vcpus = '2' to match the number of real cpus on our Chromebook, but slide 13 mentions support for only 1 VCPU with a FreeBSD guest, so I will need to change that vcpus = '1' in the FreeBSD guest config unless support for 2 or more vcpus was added later, which is possible because that slide presentation is 9 years old. Here is where I would expect to find the XENHVM FreeBSD on arm kernel config file: https://cgit.freebsd.org/src/tree/sys/arm/conf But it is not there unless I am not understanding something correctly. For now, unfortunately conclude that the support for Xen on arm that Julien Grall mentioned in that slide presentation 9 years ago was never added to the official FreeBSD source code. I am searching the web now to see if the patches that Julien Grall wrote are still posted somewhere online. If we cannot find them, we can ask here and on the xen-users mailing list. Julien regularly reads that list and responds to question about Xen on arm, so I think he will tell us how to find the patches if we cannot find them online. According to this page from the FreeBSD wiki: https://wiki.freebsd.org/Xen I think FreeBSD only supports Xen on x86, not arm. So this is going to be a bit of a challenge to get a Xen FreeBSD guest on arm working. We know Julien Grall has some patches that made it work in the past ! I found a slightly newer slide presentation by Julien here: https://www.slideshare.net/xen_com_mgr/bsdcan-2015-how-to-port-your-bsd It is about the same, but it mentions the GENERIC FreeBSD kernel supports Xen on arm64, but still says we need the XENHVM FreeBSD config for Xen on arm 32 bit, which I haven't found online yet. Please,take a look at this output of the linux kernel that can boot on Xen, and the FreeBSD kernel that cannot : % file zImage-6.1.59-stb-xen-cbe+ zImage-6.1.59-stb-xen-cbe+: Linux kernel ARM boot executable zImage (little-endian) % file FREEBSD-XENVIRT FREEBSD-XENVIRT: ELF 32-bit LSB executable, ARM, EABI5 version 1 (SYSV), dynamically linked, interpreter /red/herring, for FreeBSD 11.0 (1100048), not stripped The FreeBSD kernel that won't boot is in ELF format but the Linux kernel that does boot is in zImage format. I spent time reading the docs on xenbits.xenproject.org, and according to those docs Xen on arm only knows how to boot a kernel in the zImage format, so the FreeBSD kernel is in a format that modern Xen incorrectly detects as an x86 kernel. I also watched Julien Grall's 30 minute video presentation of his work to boot FreeBSD/arm on Xen at FOSDEM 2014 here : https://archive.fosdem.org/2014/schedule/event/freebsd_xen_arm/ In that video, and in other places, Julien mentions that the boot ABI for FreeBSD/arm on Xen was not yet developed and he was getting occasional crashes and needed to investigate the problem. He mentioned the zImage ABI that Linux uses, but pointed out FreeBSD does not use that format, and back then it was an open question which format to use to boot FreeBSD/arm on Xen. Unfortunately, nine years later, the only supported format is still the zImage format that Linux uses. It looks like Julien's work back then was using an ELF binary to boot FreeBSD/arm on Xen instead of the supported zImage format that Linux uses and the modern Xen toolstack exits with an error when trying to boot the FreeBSD ELF formatted binary that Julien's patch creates. So the best solution would be to try to port the rules to build a FreeBSD kernel in the zImage format instead of the ELF format. I have been studying the Makefiles in Linux to see how Linux builds the Linux arm kernel in the zImage format, but it is not trivial to understand. -- Mario.
Porting HAXM to FreeBSD ?
Hello. What about porting HAXM to FreeBSD ? "HAXM was created to bring Intel Virtualization Technology to Windows and macOS users" keeping in consideration that MacOS has some code of FreeBSD inside : Is the source code of HAXM freely available ? Are you able to port it to FreeBSD ? The idea is to accelerate qemu with HAXM on FreeBSD. Someone that can and wants to do this ? Here : http://mail-index.netbsd.org/netbsd-users/2019/02/13/msg022207.html I can read that HAXM has been imported into pkgsrc/emulators/haxm ---> Wow. So,it exists for NetBSD but not for FreeBSD ? -- Mario.
