Page MenuHomeFreeBSD

Linux Emulation Lair

trasz created this room.

Okay, let's test this thing.

You put up a very good point, but there's another related problem.

Which boils down to pkg upgrade failing on linux_base-c7 when you don't have the Linux kld modules loaded.

Given that the linux rc script runs ldconfig already - could we perhaps just make the linux_base ignore error return from ldconfig?

This way you could do steps mentioned in linux(4) in any order, and it would also fix pkg upgrade.

What do you think?

trasz changed the visibility from "Room Participants" to "Public (No Login Required)".

It may be unfortunate but packages have to run commands on installation sometimes and for Linux packages these may be Linux commands requiring Linux compatibility. These are taken from the RPM that we repackage. Usually these commands generate some sort of cache, like the cache or the fontconfig cache, etc. In general we cannot guarantee that packages work correctly if these caches aren't there. So I prefer that we require or at least suggest that Linux compatibility be enabled before installing Linux packages. Now for the specific case of linux_base. It runs ldconfig and gio-querymodules. If ldconfig fails that's ok, because the run-time linker can still find libraries by searching the library path. If gio-querymodules fails that's fine at the moment, because we don't have any ports that install GIO modules, but it's not unthinkable that we might one day. Having a port of gvfs for instance would make it possible to access remote locations in GTK file dialogs. So for now it's fine if the commands fail, but we can't promise users it will stay that way.

Nov 14th, 2019

What if linux_base installed an rc script, eg /usr/local/etc/rc.d/linux_base, which contains the commands above, conditional on linux_enable being set, and with DEPENDS: linux? You could also have a file created on installation and upgrade time somewhere under /compat/linux/var, that would be removed on the first run of that script.

This way one could always do 'pkg upgrade', even without linux kernel modules loaded; the commands would simply get deferred.

If the commands fail on package installation then they should run when the user runs service linux start. That doesn't happen with a linux_base rc.d script does it? I guess it would work if linux_base (and other Linux packages) installed a script in a location that is then sourced by /etc/rc.d/linux.

True, that’s even better.

Dec 29th, 2019

Would it be possible for Linux_base to provide libaio and libnuma? Some of the LTP tests want those; even if we don’t provide the SysCare yet, this would be an useful first step.

Dec 30th, 2019

I've just tested them and it works, thanks!

(Works, as in, they don't fail with linking errors, which mostly moves them from 'fail' to 'skipped', which is a good thing by itself.)

I've just found one more missing library:

FWIW, libnuma affects 64 tests, libaio - 12, libtirpc - 215.

although the libtirpc ones are not being run atm.

There's a version problem. Still, those tests are not run by default; libaio and libnuma are more important atm, I think.

Jan 7th, 2020

Hi. So, given the libaio and libnuma ports seem to work, is theee anything left to do before committing them?

Do you use, or know someone who uses, an application that needs them? I always ask this question when adding new ports because if nobody uses a port all the time spent on maintaining it is a waste.

Jan 8th, 2020

Well, yes - LTP. Those libraries are a prerequisite to making several tests pass.

Jan 9th, 2020

Thanks! Does look ok? I'm not sure that's the proper way to register dependencies.

Are there plans for linux c8? In ports, I mean.

Jan 10th, 2020

No, I haven't looked into yet.

Jun 7th, 2020

Do you know of anyone working on improving the "userspace bootstrap", so to speak?

For example packaging yum - so that the minimal linux thingy can be easily extended and upgraded from upstream distro?

No. The question comes up sometimes but I always thought yum and pkg would interfere with each other too much, overwriting each other's files on upgrades. It just looks like it could easily become a support nightmare. For me the linuxulator is meant to run binary-only commercial Linux software. Most of these are almost fully self-contained requiring only a minimal set of dependencies. If any such dependencies are missing we can add them to the ports tree. They also require only a minimal set of kernel features. If people want a full Linux distribution a virtual machine with a real Linux kernel seems better suited. Anyway, this is just my personal opinion. I've been getting less involved with FreeBSD lately so I don't want to make decisions about what direction to take. If the community wants yum then go and add yum. I would just first ask them what application they are trying to run that makes them think they need yum and then see if I could get the application running without it. Limiting the scope of the linuxulator is what keeps it manageable.

Jun 13th, 2020

Okay, I think I agree. How about adding a port for eg debootstrap, so that the full linux distro could be bootstrapped into eg /compat/ubuntu? The reason is, first, it makes experimenting with Linux stuff much easier, and second, it makes it easy to create Linux jails.

I'll try to compile a list of dependencies neccessary for debootstrap.

Sep 20th, 2020
May 30th, 2021 joined the room.
Dec 30th, 2022