-
Notifications
You must be signed in to change notification settings - Fork 8
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Runs on bare metal? #50
Comments
Hi @subnut thanks for asking! Sorry for the late reply. Technically, yes it is able to run on bare metal, I have a personal system that is currently using it. However, I haven't yet done much to generalize the kernel for other systems. You would likely have to build your own custom kernel at this point. After a bit of a hiatus, I'm looking at providing some updates as well as making this more generally usable. Stay tuned for more updates, I'll try to have a game plan mapped out soon. |
Yes, I prefer static binaries where possible/reasonable. And I prefer avoiding GNU where reasonable as well. It's difficult to completely remove GNU utils, and there's no doubt lots of cases where doing so would be extremely uncomfortable. The base system uses busybox by default for now (toybox was incomplete when I began) and so far I haven't seen too many cases where busybox isn't usable. |
I think Glaucus linux is using toybox http://glaucuslinux.org/ |
Nice. I've been watching the progress of toybox for a long time. We could take another look at it, but the reason I chose busybox and have stuck with it up to now is that it had more features that allowed me skip several external packages while maintaining a small, simple size. As just a few examples: awk, gzip, sh, a dhcp client (udhcpc) I'd be interested in hearing other's thoughts about it, though. |
@subnut do you know what modules your Thinkpad uses? |
Umm, no..... How to find that out? |
If you are running another linux system on it already (or you can launch linux from an iso or usb) you should be able to run |
|
Looks like you have the r8169 network interface and the amdgpu, those are probably the most significant ones. I have those built as modules now, but am still missing some of the others. For example, I haven't started looking at wifi yet. As it stands right now, the machine will probably boot correctly with mere's linux package in the testing repo, but some pieces, like wifi wouldn't work. Network over your ethernet port should work fine though. |
I have been experimenting some with an arch-based no-systemd system, Obarun in specific, to see how life would be without udev. I have employed smdev, nldev, and libudev-zero. The first two have been idling around for years, the later is ongoing development as we write/read. My window manager has 100% functionality with it, very few applications threw out an error. So, if you can leave some udev setup/hooks to be easily substituted. illiliti/libudev-zero#4 The only source of headache for some arch sw is the reliance to libudev providing version information, and the key to this disfunctionality revolves around lvm2/device-mapper. Substituting nldev for udev in mkinitcpio was much easier than I had thought, booted fine first try. Taking the advice from the thread above I was able to build lvm2/device mapper udev free, I really thought I would be dealing with days if not hours of debugging and patching. It is hard to test everything against it since it is crawling everywhere, but it seems functional. The next phase would be substituting smdev/nldev for mdevd from skarnet, which is a little tougher to do, but the two projects libudev-zero/mdevd are in communication collaboration it seems. I am watching silently your explosion of work, I am waiting for the dust to settle a bit before giving it a try again since a year ago, but it is very inspiring. This is heading for true freedom, unlike fedora, debian, arch,.. etc heading for being standardized IBM-RH forks. |
I don't get this, your PKGBUILD for pacman appears to be making makepkg which you rename pacman-build, for unknown reasons, yet the pacman you have in the repository doesn't include this package. What do we do? Somehow copy the config from you PKGBUILD and attempt I was under the very poor assumption that the pacman upgrade you did incorporated pacman in its entirety. This is useless. |
The pacman PKGBUILD creates two packages, or split packages, one called I'm happy to consider alternative suggestions. The main objective in splitting them that way was to keep the base system footprint small for systems and use cases that don't plan on building packages. |
More details about the package splitting feature: https://archlinux.org/pacman/PKGBUILD.5.html#_package_splitting |
I came back to edit my venting frustration, I figured it out a little later. I see makepkg.conf is quite different from what arch is using. I get an errror (after many others trying to figure out what install flags work and don't with busybox: ==> ERROR: Missing dependencies: But the pkg is really all there and correct in ./pkg/nano/.. but doesn't get transfered to a tar ball Also, before even checking, I assumed the system needed a user to build packages, as it is common in pacman based distros, that ONLY user can build, only root can install. It seems you canged this configuration. Then while working on chroot /tmp is not a tmpfs and user couldn't write to it, and it seems as makepkg is trying to send the tarball to /tmp/staging but using root to build didn't produce anything either. Same error. Luckily just copying /usr/bin/nano and /etc/nanorc worked fine, so I am happy to have my favorite editor going. If I can get the ball rolling escaping those errors I can add a repository here and share my successful pkgbuilds What is the correct and complete PATH for a sh in Mere ... I can help with documentation but I need to find my way through it first. |
I didn't realize the splits before, I am in favor of it, and I was used to it in void, they sometimes split in 3 having the documentation also optionally installed. |
Thanks for not giving up! 😄 Yes, there is quite a bit that is different from Arch, and I started documenting what needs to be done to for developmet, but it really needs a lot more details. A few things to keep in mind:
There's more, but I don't have a lot of time right now. I'll try to make some more decent walkthroughs of a typical workflow when I have a moment, perhaps later this evening. The oddity about /tmp is funny, it should be set to 1777 so that every user can write to it, even if it isn't a tmpfs. But am also happy to consider turning it into a tmpfs as well. |
I tried a couple more pkgs and I get the same error about missing dependency I did manually change /tmp to 777 so both user and root can write to it |
The missing dependency error is just the To be able to package successfully, you just need to add 'ld-musl-x86_64.so.1' or, maybe better, "ld-musl-$(arch).so.1" to a depends variable in the PKGBUILD file. See this one for an example: https://github.com/jhuntwork/merelinux/blob/main/packages/sudo/PKGBUILD#L49-L51 I added that feature in because I kept getting caught by hidden library dependencies that were hard to track manually. |
Thank you, I've certainly made some progress with this fix, I was under the impression that musl alone would take care of this but it needs the specific library link to be happy. On another note some pkgs I am trying to build fail when they involve a test/check at the end of the building https://termbin.com/vpxm The behavior is similar, no output indicating specific problem, no process other than makepkg hanging on, but it stays there like this and does not proceed, even after I have forgotten what I was doing :) Disabling checks/tests wouldn't be a good idea. In the particular example I've been trying to build zsh basing the attempt on arch's zsh pkgbuild, which requires libcap and pam, gdbm (I've built that one), and pam needs pambase and a ton of other things that don't exist yet. So I tried building with disabling pam and cap at the configuration. But then this happened and reminded me of a couple of other pkgs that hang in the same part of the building. Any clues on what to do would be greatly appreciated. |
Do you mind uploading the full PKGBUILD files somewhere, maybe gdbm and zsh? I think libcap should be ok to add too, but pam might be a challenge. At least, the last I looked at it, it was a little hairy. |
I sent an email too Whatever I work on, will go here, if it is not working I will indicate it on the README of each pkg, gdbm and nano work, libcap zsh aren't. |
Looks like unsetting CFLAGS will keep it from hanging. It's either the difference between |
This is really surprising, but I've narrowed it down to having |
Some of the folks in the #musl channel on LiberaChat helped track it down to autoconf settings. If zsh's configure system doesn't include the right headers in their checks, some of configure's tests will fail resulting in a misconfigured build. It looks like there's an upstream fix for it here: zsh-users/zsh@bd647c1 although it's unreleased. That doesn't apply cleanly to the 5.8 package though. Separately, in their README, there's this note that will probably be helpful:
|
I'm going to close this issue now as the main question should be answered through the INSTALLING document now. Of course there are still more features to add to make the answer to this question really nice, including more hardware support and a desktop environment, but we'll work on those in separate issues. @fungilife feel free to update here if you like, or maybe add a new issue or discussion around the packages you're working on. |
Is it possible to run this on bare metal?
More specifically, a Thinkpad E495.
Thank god I found this... I was just going to make this EXACT SAME THING myself!
standards of musl + reliability of s6 + familiarity of pacman, a heavenly choice!
The text was updated successfully, but these errors were encountered: