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
Alpine Linux Template #7323
Comments
So far, all of the packages have been implemented as an APKBUILD. I'm currently working on initd scripts, with the following, as far as I can tell, mostly working:
My current roadblock is #!/sbin/openrc-run
name=$RC_SVCNAME
cfgfile="/etc/qubes/$RC_SVCNAME.conf"
command="/usr/bin/qubes-gui"
pidfile="/run/qubes/$RC_SVCNAME.pid"
command_background="yes"
error_log=/var/log/qubes/$RC_SVCNAME.log
depend() {
need qubes-db
}
start_pre() {
checkpath --directory --owner $command_user:$command_user --mode 0775 \
/run/qubes /var/log/qubes /var/run/console/user
# start console-kit-daemon
/usr/bin/ck-list-sessions > /dev/null 2>&1
# pretend tha user is at local console
touch /var/run/console/user
/bin/sh -c /usr/lib/qubes/qubes-gui-agent-pre.sh
. /var/run/qubes-service-environment
command_args="$command_args $GUI_OPTS"
export DISPLAY=:0
} |
Thank you for working on this. I can't help you with this issue, but maybe this link, how Void Linux done this, can help you. |
Thanks @moiselazarus! I threw an afternoon on it with no success, but that void has suceeded in packaging for Qubes before helps a lot! I havn't implemented the one-shot scripts adequately, so that's where I'm at. |
Back on trying to figure this out. Despite implementing the one-shot scripts, I still am facing the |
I've made more progress: hvm mode with qubes kernel works using additional kernelopts |
@Nexolight Would you have encountered the issue of |
Sounds like either Xorg not starting (or crashing on start?) or not loading qubes driver (generic config file instead of the one from qubes-gui-agent?). |
The |
Of note, |
Good news! Tracked down the issue - it isn't a problem with Xorg, but rather with pam. There needs to be an Alpine version of /etc/pam.d/qubes-gui-agent. I've been trying for the last hour to throw spaguetti at the wall, see if it stick, but alas I do not know anything about pam. I see that they are copies of |
Doesn't seem to have to do with pam anymore (edit: or maybe it does??) strace:
|
Can you push the openrc files to your repo. I would like to test, maybe some hints or steps to build the template. |
@moiselazarus Apologies for the delay, I was without my laptop for a little while. You will find the repo updated with latest openrc files. Following this guide to setting up an Alpine HVM proved useful: https://github.com/Nexolight/void-tainted-pkgs/tree/qubes/QubesOS. A few notes:
By memory, that should get your VM to a similar state as mine. Don't desitate in case of questions |
Current state of
That the issue still persists suggests that these error were non-fatal. @marmarek Having created |
Debugged the issue: the qubes-gui-runuser issue had to do with two things: one was an error of mine in misunderstanding the command syntax, and the other was that qubes-run-xorg was trying to start xorg with ash (via /bin/sh link) rather than with bash. Of course, it'd be too easy for it to just work, as Xorg runs now but then crashes shortly after. See log below:
Unfortunately, my debugging hits a new wall... |
Missing udev rules from https://github.com/QubesOS/qubes-linux-utils/blob/master/udev/udev-qubes-misc.rules ? Or maybe |
I don't think any of those require "fixing" - both are optional features and everything should work just fine without them (and indeed the process continues to run past those attempts). |
Adding Another issue is that while
Indeed, this was desperation. I was barking up the wrong tree. |
You can add |
initrd starts
|
It should remain running, with various children processes (mostly dependent on /etc/xdg/autostart content). The question is whether |
Fixed it, it was a permission issue in |
Memory ballooning doesn't work, any pointers that I could follow? Note that no initcpio hooks have been adapted to Alpine. I suspect it may have something to do with that. Also note, AppVM does announce succesful start, so connection to |
That's about |
Indeed, |
After converting to template,
dom0 error after
I can execute |
I got the template builder ported over. It is available here: It does not produce a working template yet. While I can build, install, and boot the template, something is still broken as qubes-db refuses to start (fails with I've also got the build infrastructure implemented here: https://lab.ilot.io/ayakael/qubes-aports The template builder pulls the packages from that infra and then sets up the image. All in all, good progress! I'm sure a full day of troubleshooting will be enough to iron out whatever's the problem. |
The qubesdb problem is evading me still. I'd appreciate some pointers, here is an strace:
|
Your
|
@lubellier Thanks! Yes, everything is there. The missing libraries is actually qubesdb going through every possible library location. It eventually finds the libraries, and then it continues. |
Did you compare your strace output with a fedora template workable qubesdb-daemon strace output ? |
I went down the comparison rabbit hole and ended up comparing the working manually built Alpine template with the broken one. Indeed, it had nothing to do with qubesdb, but rather some missing low-level services that needed to be added to a runlevel. There were also groups + user issues. I'm glad to say that the template builder now builds a functional template! Next up is getting the template builder to be able to generate multiple versions of Alpine (right now, it can only do the latest stable), after I'll get some Gitlab pipelines up to make prebuilt RPMs available via Releases. |
I finished up the basic components of the infra. RPM are now available here: https://lab.ilot.io/ayakael/qubes-builder-alpine/-/releases Feel free to test and come back to me on any issues. I only tested the ability to open xterm within the template. |
Issue: I was not able to connect to any services running on 127.0.0.1 while using AppVM based on this template, because lo interface was not automatically turned on (sudo ifconfig lo up) |
@ayakael wow, this is just awesome! Thank you for this great work |
Template RPMs for v3.19 are up for both r4.1 and r4.2 @TwinkleToes777 Thank you for noticing this. I added the necessary setup steps in the builder @LindaFerum With pleasure ^^ I have time to work on this more. Any idea on how I might want to improve accessibility of this project? @marmarek @andrewdavidwong What steps can I take to improve visibility so that it's comparable to Arch Linux? |
That's a good question. There are two separate aspects:
|
Today I installed the Antoine's 3.19 alpine template from the rpm release in Qubes-OS 4.1. And It works great, congratulation to Antoine ( @ayakael ) ! I tested:
Presently, for my usage, the main limitation (already in the the-yet-to-be-implemented-list)) is :
Lately I saw that I installed the wrong template ( 4.2 rpm template in QubesOS 4.1 ) but It works :-) I will fix my mistake later... |
@lubellier Many thanks for checking that! If you find a way to get apk proxying working, please feel free to share. I can then integrate it in the template builder. It's low on my list of things to tackle, so outside help would be welcomed. I'd like to tackle systems VMs next. As for your mistake, it should be as easy as changing the URL in @andrewdavidwong Awesome, thank you! I'll wait for @marmarek's perspective, and then get on that. My building infra (available here) has all of the APKBUILD files in the same repo. I assume getting it to match the archlinux infra would involve integrating those APKBUILD files in their relevant repos. |
@ayakael I found a solution, I don't own a gitlab account on lab.ilot.io and I never did an APKBUILD, so I share here.
Thanks to the 2 aliases, the usage is very basic:
|
@lubellier Many thanks for this! I've just pushed an update to I've also pushed a new image |
@ayakael Thanks for the package and repository update! |
@lubellier The new template RPM will have |
@ayakael i have |
do not modify the is this standalone qube instead of template by a chance? those should not use updates proxy by default (but it's still okay to enable it, if you configure policy for it too) |
@marmarek, R4.2
default settings in my policy
|
ah, so it isn't even standalone, just normal app qube; proxy shouldn't be enabled in that case, see https://github.com/QubesOS/qubes-core-agent-linux/blob/main/network/update-proxy-configs#L79 ( |
I see, we're missing |
I agree. Apk doesn't provide a setting file for the proxy settings. So we should find a way to inject the Ideas : a shell function, a shell script, |
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
Of note, I've rebuilt all r4.1 and r4.2 packages to support current edge that now uses python 3.12. With r4.1 EOL in mid-june, this is likely the last update for r4.1 packages. I will sunset the r4.1 building infra around that time, as well. EDIT Alpine 3.20, due for release in the beginning of may, will thus be the last release that will support r4.1, and that only till mid-june. |
description
QubeOS should have an Alpine Linux template. This has been requested in the past, and I've finally decided to tackle it, having packaging experience with this distro. This space is for tracking issues.
current state
steps
hurdles
The text was updated successfully, but these errors were encountered: