systemd megathread

changed title from (currently confidential) systemd demo images megathread to (currently confidential) systemd megathread

By Oliver Smith on 2024-03-05T17:16:54

changed the description

By Oliver Smith on 2024-03-05T17:16:54

changed the description

By Caleb Connolly on 2024-03-05T18:30:10

made the issue visible to everyone

By Caleb Connolly on 2024-03-05T19:21:46

changed title from (currently confidential) systemd megathread to systemd megathread

By Caleb Connolly on 2024-03-05T19:50:16

pmbootstrap (systemd branch): support pmb:systemd-never option in postmarketos-ui-* packages for UIs where maintainers don't support systemd (e.g. Sxmo)

If systemd is an explicit dependency of other packages that explicitly require it, you don't need special considerations for non-systemd images.

Re: https://gitlab.postmarketos.org/postmarketos/pmaports/-/blob/52f833c4/main/postmarketos-base-ui/APKBUILD#L122

You probably want to add `conflicts="systemd-logind" to package "elogind".

By WhyNotHugo on 2024-06-25T12:07:11

I suggest adding install_if="postmarketos-base systemd" to the systemd-services package instead of making it an explicit dependency of postmarketos-base too. This will facilitate minimal images without it (e.g.: for sxmo).

By WhyNotHugo on 2024-06-25T12:07:05

I followed the instructions but I get the below:

pmbootstrap repo_bootstrap systemd --arch=aarch64
[14:13:15] *** 0% [BOOTSTRAP=1] zapping ***
[sudo] password for justin:
[14:13:20] Unregister qemu binfmt (aarch64)
[14:13:20] % rm -rf /home/justin/.local/var/pmbootstrap/chroot_native
[14:13:20] % rm -rf /home/justin/.local/var/pmbootstrap/chroot_buildroot_aarch64
[14:13:20] Cleared up ~468 MB of space
[14:13:20] *** 3% [BOOTSTRAP=1] initializing native chroot (without merged /usr) ***
[14:13:21] (native) install alpine-base
[14:13:22] *** 7% [BOOTSTRAP=1] initializing buildroot_aarch64 chroot (without merged /usr) ***
[14:13:24] (native) install qemu-aarch64
[14:13:24] Register qemu binfmt (aarch64)
[14:13:24] (buildroot_aarch64) install alpine-base
[14:13:28] *** 10% [BOOTSTRAP=1] building apk-tools ***
[14:13:29] (buildroot_aarch64) install abuild
[14:13:32] (buildroot_aarch64) install abuild build-base ccache git
[14:13:39] (native) install ccache-cross-symlinks abuild gcc-aarch64 g++-aarch64 crossdirect
[14:13:43] NOTE: The failed command's output is above the ^^^ line in the log file: /home/justin/.local/var/pmbootstrap/log.txt
[14:13:43] ERROR: Command failed (exit code 1): % sudo ln -sf /native/bin/busybox /usr/local/bin/gzip
[14:13:43] See also: <https://postmarketos.org/troubleshooting>

Run 'pmbootstrap log' for details.

Before you report this error, ensure that pmbootstrap is up to date.
Find the latest version here: https://git.sr.ht/~postmarketos/pmbootstrap/refs
Your version: 2.2.1

By Justin Zobel on 2024-06-25T12:06:54

@calebccff @Justin_Zobel @amartinz @WhyNotHugo @craftyguy @kailueke @ollieparanoid @Arnavion @Minecrell : open letter from a freedom lover to PostmarketOS devs :

open letter

Me and my two friends, who got the Pinephone for privacy/security reasons, are all using PostmarketOS. Why? Because no SystemD. SystemD, being a 1.5 million lines of code begemoth, is written with little respect for security - as you could see by Pwnie "award" and plenty of CVEs. Therefore the security-minded people who choose a Pinephone despite its worse usability compared to the ordinary Android phones, also tend to avoid SystemD.

Currently, the primary distinguishing feature of PostmarketOS - is that, being based on Alpine, it doesn't have SystemD. However, by artificially switching this Alpine-based distro to SystemD, you are losing this competitive advantage and your priorly-outstanding distro won't be unique anymore.

One of my "Pinephone friends" (who btw uses Artix Linux on his desktop for the same no-SystemD reason) - really loves PostmarketOS (even contributed a couple of patches), and last week he told me that he is going to make a significant donation to PostmarketOS when he gets his next paycheck. But I have just made a phone call to him - and, after getting the news about that SystemD switch, he doesn't want his hard-earned money to fund the SystemD work

You really are shooting yourself in the foot with this SystemD madness, please stop before its too late and you become yet-another-soulless-non-unique-distro.

P.S. sorry for my emojis above, but lets see if you have a freedom of speech there...

By qma ster on 2024-03-11T08:34:03

mentioned in merge request !4894 (closed)

By Caleb Connolly on 2024-03-07T02:13:41

I'm following the steps to build a systemd image for my samsung-gt510.

The pmbootstrap repo_bootstrap systemd --arch=aarch64 step seems extraordinarily slow. I'm building on a machine with a 7950X3D.

Click to expand

[07:29:36] *** 0% [BOOTSTRAP=1] zapping ***
[07:29:36] Cleared up ~0 MB of space
[07:29:36] *** 4% [BOOTSTRAP=1] initializing native chroot (without merged /usr) ***
[07:29:36] Update package index for x86_64 (4 file(s))
[07:29:38] (native) install alpine-base
[07:29:39] *** 9% [BOOTSTRAP=1] initializing buildroot_aarch64 chroot (without merged /usr) ***
[07:29:40] (native) install qemu-aarch64
[07:29:41] Register qemu binfmt (aarch64)
[07:29:41] (buildroot_aarch64) install alpine-base
[07:29:43] *** 13% [BOOTSTRAP=1] building apk-tools ***
[07:29:44] (buildroot_aarch64) install abuild
[07:29:45] (buildroot_aarch64) install abuild build-base ccache git
[07:29:58] (native) install abuild
[07:29:59] (native) install abuild build-base ccache git
[07:30:00] (native) install linux-headers lua-dev lua5.3 lua5.3-lzlib musl>=1.2.3_git20230424 openssl-dev openssl-libs-static openssl>3 scdoc zlib-dev zlib-static
[07:30:02] (native) build x86_64/apk-tools-9992.14-r6.apk
[07:30:09] (native) install apk-tools>=2.0.7-r1 attr curl fakeroot libc-utils libcap-getcap lzip openssl-dev>3 openssl>3 patch pkgconf pkgconfig scanelf scdoc tar zlib-dev
[07:30:10] (native) build x86_64/abuild-99993.12.0-r1.apk
[07:30:12] (native) install ccache-cross-symlinks abuild gcc-aarch64 g++-aarch64 crossdirect
[07:30:13] (buildroot_aarch64) build aarch64/apk-tools-9992.14-r6.apk
[07:31:05] (buildroot_aarch64) uninstall build dependencies
[07:31:06] *** 18% [BOOTSTRAP=1] building abuild ***
[07:31:06] (native) install ccache-cross-symlinks abuild gcc-aarch64 g++-aarch64 crossdirect
[07:31:07] (buildroot_aarch64) build aarch64/abuild-99993.12.0-r1.apk
[07:31:22] (buildroot_aarch64) uninstall build dependencies
[07:31:23] *** 22% [BOOTSTRAP=1] building alpine-base ***
[07:31:23] (native) install ccache-cross-symlinks abuild gcc-aarch64 g++-aarch64 crossdirect
[07:31:24] (buildroot_aarch64) build aarch64/alpine-base-9999-r0.apk
[07:31:31] (buildroot_aarch64) uninstall build dependencies
[07:31:33] *** 27% [BOOTSTRAP=2] zapping ***
[07:31:33] Unregister qemu binfmt (aarch64)
[07:31:33] % rm -rf /home/sam/.local/var/pmbootstrap/chroot_native
[07:31:33] % rm -rf /home/sam/.local/var/pmbootstrap/chroot_buildroot_aarch64
[07:31:34] Cleared up ~715 MB of space
[07:31:34] *** 31% [BOOTSTRAP=2] initializing native chroot (with merged /usr) ***
[07:31:34] (native) install alpine-base
[07:31:35] (native) merge /usr
[07:31:35] *** 36% [BOOTSTRAP=2] initializing buildroot_aarch64 chroot (with merged /usr) ***
[07:31:36] (native) install qemu-aarch64
[07:31:36] Register qemu binfmt (aarch64)
[07:31:37] (buildroot_aarch64) install alpine-base
[07:31:38] (buildroot_aarch64) merge /usr
[07:31:39] *** 40% [BOOTSTRAP=2] building systemd ***
[07:31:39] (buildroot_aarch64) install abuild
[07:31:43] (buildroot_aarch64) install abuild build-base ccache git
[07:31:49] (native) install ccache-cross-symlinks abuild gcc-aarch64 g++-aarch64 clang crossdirect
[07:32:00] (buildroot_aarch64) build aarch64/systemd-255.2-r0.apk
[07:35:48] (buildroot_aarch64) uninstall build dependencies
[07:35:49] (native) install ccache-cross-symlinks abuild gcc-aarch64 g++-aarch64 clang crossdirect
[07:35:50] (buildroot_aarch64) build aarch64/systemd-255.2-r0.apk
[07:39:05] (buildroot_aarch64) uninstall build dependencies
[07:39:06] *** 45% [BOOTSTRAP=2] building dbus ***
[07:39:06] (native) install ccache-cross-symlinks abuild gcc-aarch64 g++-aarch64 crossdirect
[07:39:07] (buildroot_aarch64) build aarch64/dbus-9991.14.10-r1.apk
[07:42:15] (buildroot_aarch64) uninstall build dependencies
[07:42:16] *** 50% [BOOTSTRAP=2] building linux-pam ***
[07:42:16] (native) install ccache-cross-symlinks abuild gcc-aarch64 g++-aarch64 crossdirect
[07:42:17] (buildroot_aarch64) build aarch64/linux-pam-1.5.3-r8.apk
[07:46:06] (buildroot_aarch64) uninstall build dependencies
[07:46:07] *** 54% [BOOTSTRAP=3] zapping ***
[07:46:08] Unregister qemu binfmt (aarch64)
[07:46:08] % rm -rf /home/sam/.local/var/pmbootstrap/chroot_native
[07:46:08] % rm -rf /home/sam/.local/var/pmbootstrap/chroot_buildroot_aarch64
[07:46:08] Cleared up ~865 MB of space
[07:46:08] *** 59% [BOOTSTRAP=3] initializing native chroot (with merged /usr) ***
[07:46:09] (native) install alpine-base
[07:46:10] (native) merge /usr
[07:46:10] *** 63% [BOOTSTRAP=3] initializing buildroot_aarch64 chroot (with merged /usr) ***
[07:46:10] (native) install qemu-aarch64
[07:46:11] Register qemu binfmt (aarch64)
[07:46:11] (buildroot_aarch64) install alpine-base
[07:46:13] (buildroot_aarch64) merge /usr
[07:46:13] *** 68% [BOOTSTRAP=3] building systemd ***
[07:46:13] (buildroot_aarch64) install abuild
[07:46:17] (buildroot_aarch64) install abuild build-base ccache git
[07:46:23] (native) install ccache-cross-symlinks abuild gcc-aarch64 g++-aarch64 clang crossdirect
[07:46:26] (buildroot_aarch64) build aarch64/systemd-255.2-r0.apk
[07:49:40] (buildroot_aarch64) uninstall build dependencies
[07:49:42] *** 72% [BOOTSTRAP=3] building dbus ***
[07:49:42] (native) install ccache-cross-symlinks abuild gcc-aarch64 g++-aarch64 crossdirect
[07:49:43] (buildroot_aarch64) build aarch64/dbus-9991.14.10-r1.apk
[07:52:44] (buildroot_aarch64) uninstall build dependencies
[07:52:45] *** 77% [BOOTSTRAP=3] building linux-pam ***
[07:52:45] (native) install ccache-cross-symlinks abuild gcc-aarch64 g++-aarch64 crossdirect
[07:52:46] (buildroot_aarch64) build aarch64/linux-pam-1.5.3-r8.apk

I've heard the fans spin up once or twice to do some actual work, but otherwise my load avg has been sitting at around 3. Is this expected or am I missing some pmbootstrap config? Or perhaps some of the newly packaged stuff is missing a -j$(nproc) flag?

By Sam Day on 2024-03-10T14:19:41

Managed to build a systemd image for samsung-gt510 and flash it. It doesn't boot past bootsplash though.

Further, I can't SSH in to debug. The USB network is coming up, but the SSH server isn't listening.

I enabled initramfs telnet and poked around. I think the systemd-services package is missing from my install?

~ # apk list | grep systemd
postmarketos-base-systemd-1-r0 aarch64 {postmarketos-base-systemd} (GPL-3.0-or-later) [installed]
systemd-255.2-r0 aarch64 {systemd} (MIT AND GPL-2.0-only AND LGPL-2.1-or-later) [installed]
systemd-boot-255-r0 aarch64 {systemd-boot} (GPL-2.0-only)
systemd-journald-255.2-r0 aarch64 {systemd} (MIT AND GPL-2.0-only AND LGPL-2.1-or-later) [installed]
systemd-libs-255.2-r0 aarch64 {systemd} (MIT AND GPL-2.0-only AND LGPL-2.1-or-later) [installed]
systemd-logind-255.2-r0 aarch64 {systemd} (MIT AND GPL-2.0-only AND LGPL-2.1-or-later) [installed]
systemd-udevd-255.2-r0 aarch64 {systemd} (MIT AND GPL-2.0-only AND LGPL-2.1-or-later) [installed]
ukify-255-r0 aarch64 {systemd-boot} (GPL-2.0-only)

~ # find / | grep ssh
/usr/libexec/gcr-ssh-askpass
/usr/libexec/gcr-ssh-agent
/usr/lib/libssh.so.4
/usr/lib/ssh
/usr/lib/ssh/sftp-server
/usr/lib/ssh/ssh-pkcs11-helper
/usr/lib/libssh.so.4.9.6
/usr/lib/gnome-keyring/devel/gkm-ssh-store-standalone.so
/usr/bin/sshd
/usr/bin/ssh-agent
/usr/bin/ssh
/usr/bin/sshd.pam
/usr/bin/ssh-add
/usr/bin/ssh-keygen
/usr/bin/ssh-copy-id
/usr/bin/ssh-pkcs11-helper
/usr/bin/ssh-keyscan
/usr/share/icons/Adwaita/cursors/crosshair
/root/.ssh
/etc/xdg/autostart/gnome-keyring-ssh.desktop
/etc/nftables.d/50_ssh.nft
/etc/ssh
/etc/ssh/sshd_config.d
/etc/ssh/sshd_config.d/usepam.conf
/etc/ssh/ssh_config
/etc/ssh/sshd_config
/etc/ssh/moduli
/etc/ssh/ssh_config.d
/etc/pam.d/sshd
/home/sam/.ssh
/home/sam/.ssh/authorized_keys

I manually dropped /usr/lib/systemd/system-sshd.service + /usr/lib/systemd/system-sshdgenkeys.service in place and symlinked them to /usr/lib/systemd/system/multi-user.target.wants/ and now SSH is available again.

By Sam Day on 2024-03-10T14:34:42

I would like to test the new branch for oneplus-fajita, but i cant because i dont have the option to repo_bootstrap as mentioned above:

pmbootstrap repo_bootstrap systemd --arch=aarch64 usage: pmbootstrap [-h] [-V] [-c CONFIG] [--config-channels CONFIG_CHANNELS] [-mp URL] [-m URL] [-j JOBS] [-E EXTRA_SPACE] [-B BOOT_SIZE] [-p APORTS] [-t TIMEOUT] [-w WORK] [-y] [--as-root] [-o] [--no-ccache] [--no-cross] [-l LOG] [--details-to-stdout] [-v] [-q] {init,shutdown,index,work_migrate,repo_missing,kconfig,export,sideload,netboot,flasher,initfs,qemu,pkgrel_bump,aportupgrade,newapkbuild,lint,status,ci,log,zap,stats,update,build_init,chroot,install,checksum,aportgen,build,deviceinfo_parse,apkbuild_parse,apkindex_parse,config,bootimg_analyze,pull} ... pmbootstrap: error: argument action: invalid choice: 'repo_bootstrap' (choose from 'init', 'shutdown', 'index', 'work_migrate', 'repo_missing', 'kconfig', 'export', 'sideload', 'netboot', 'flasher', 'initfs', 'qemu', 'pkgrel_bump', 'aportupgrade', 'newapkbuild', 'lint', 'status', 'ci', 'log', 'zap', 'stats', 'update', 'build_init', 'chroot', 'install', 'checksum', 'aportgen', 'build', 'deviceinfo_parse', 'apkbuild_parse', 'apkindex_parse', 'config', 'bootimg_analyze', 'pull')

I did checkout the systemd-Branch for pmbootstrap/aports ... if that is correct. At least it seems like correct for me... Because it has the same contents as mentioned here: https://gitlab.postmarketos.org/postmarketos/pmaports . But still no "repo_bootstrap"-command for me :( . What do i do wrong?

By GeraltvonNVIDIA on 2024-03-07T11:41:43

Good day everyone! Although I haven't contributed for a long time, I am a passionate user of PostmarketOS and hopefully my opinion could matter something, so just my two cents:

Actually @qmastery16 has a good point: it will be beneficial to continue providing those "OpenRC ISOs", even if they will be 'less featured' (in this case, accompany with a note regarding the shortcomings). There is clearly a group of people (disclaimer: I am one of them) who prefers the alternative init systems for various reasons - and providing the OpenRC ISOs will certainly help the postmarketOS popularity
Is it possible to set up some crowdfunding (Patreon or whatever) - to reward those particular people like @funderscore who are doing the OpenRC-related work at postmarketOS - for the "OpenRC branch"?

By Mike Banon on 2024-06-25T12:16:16

I don't believe OpenRC images are going anywhere from the blog post. The only thing that's changing is they're adding an option to use systemd.

As for funding, postmarketOS already has https://opencollective.com/postmarketos for raising funds for the development of postmarketOS and support of its contributors.

By Justin Zobel on 2024-03-09T05:44:59

I don't believe OpenRC images are going anywhere from the blog post

@Justin_Zobel , this blog post implies that the OpenRC images will be gone and the people will have to build their own - if that's not the case, please update the blog post to clarify this

postmarketOS already has https://opencollective.com/postmarketos for raising funds

Yes, but it does not allow those who does not like systemd to avoid financially supporting it. Please add a new funding option there that will be called "OpenRC maintenance" or something, the funds of which will go to OpenRC maintainers specifically

By Mike Banon on 2024-06-25T12:16:31

his blog post implies that the OpenRC images will be gone and the people will have to build their own

The blog post specifically has a section about this, it's the first entry in the Q&A section:

So pre-built images of Sxmo will continue to be OpenRC based

I don't think the blog post can get any clearer than that.

If you're concerned that non-Sxmo OpenRC images will no longer be produced/published... Well, I think that's the whole point. The reason to introduce systemd is to make it the default experience for Gnome/KDE UI spins, because it's anticipated that this will result in a better experience and require less maintenance.

Yes, but it does not allow those who does not like systemd to avoid financially supporting it. Please add a new funding option there that will be called "OpenRC maintenance" or something, the funds of which will go to OpenRC maintainers specifically

I was hesitant to suggest this earlier since it might be interpreted as inflammatory and/or fracturing to the pmOS community, but given these kinds of ideas are popping up now, I think it might be worth saying: perhaps the people who feel strongly enough against systemd should consider forking pmOS. Artix Linux as a non-systemd fork of Arch has already been mentioned in this thread.

Of course it'd be a bummer to lose mindshare and maintainer energy from pmOS to arbitraryidealogyOS (there I've already named your fork for you, you're welcome!), but it might be better than dealing with constant noise from detractors that have nothing to contribute other than "systemd bad! because reasons that only barely made sense 10 years ago!"

By Sam Day on 2024-03-09T10:46:45

But also, just so I don't seem like I'm being completely negative and flame-baity, might I suggest that if you really care so much about OpenRC and don't want to throw any dollars to the filthy systemd heathens that are doing most of the work to make pmOS a reality, perhaps you could approach the people(s) maintaining Sxmo packaging for pmOS and ask them to start up their own OpenCollective/Patreon/Github sponsorship, if they don't have it available already?

By Sam Day on 2024-03-09T10:49:21

Yes, but it does not allow those who does not like systemd to avoid financially supporting it. Please add a new funding option there that will be called "OpenRC maintenance" or something, the funds of which will go to OpenRC maintainers specifically

Just to be clear, the money does currently not go to paying any full-time developers as it is not enough for that.

By Newbyte on 2024-03-09T10:53:30

this blog post implies that the OpenRC images will be gone and the people will have to build their own

No. Sxmo images will keep using OpenRC. That said, prebuilt images are only available for a handful of devices and even less UIs anyway..

it does not allow those who does not like systemd to avoid financially supporting it

Why? Don't we all share the love for free software? Why do you feel like this is needed?

And FYI: the money does not go to paying me to begin with. (which is fine)

By f_ on 2024-03-11T16:57:26

changed the description

By Oliver Smith on 2024-03-10T14:15:47

changed the description

By Oliver Smith on 2024-03-10T14:17:08

changed the description

By Oliver Smith on 2024-03-10T14:35:59

changed the description

By Oliver Smith on 2024-03-10T14:41:53

marked the checklist item pmbootstrap (systemd branch): support pmb:systemd-never option in postmarketos-ui-* packages for UIs where maintainers don't support systemd (e.g. Sxmo) as completed

By Oliver Smith on 2024-03-10T19:14:50

changed the description

By Oliver Smith on 2024-03-10T20:16:05

marked the checklist item pmbootstrap: make MR, get current patches from systemd branch reviewed and merged into master (pmbootstrap!2273 (merged)) as completed

By Oliver Smith on 2024-03-13T21:24:10

changed the description

By Oliver Smith on 2024-03-13T21:25:24

Is there already a task item somewhere to put something useful @ https://postmarketos.org/systemd (it's currently in the /etc/motd)

By Sam Day on 2024-03-14T19:48:00

changed the description

By Oliver Smith on 2024-03-14T19:46:23

changed the description

By Oliver Smith on 2024-03-17T16:31:46

changed the description

By Oliver Smith on 2024-03-17T16:42:17

changed the description

By Oliver Smith on 2024-03-17T16:44:50

Not sure if this issue can be used for discussions, but I just read the blog announcement at https://postmarketos.org/blog/2024/03/05/adding-systemd/ and have a few questions:

In the announcment it says one of the main blockers we found as we collaborate more closely with KDE and GNOME developers is that they have a hard time with our OpenRC-based stack, but isn't it Alpine's stack, ie their responsibility to keep KDE/GNOME up to date? (or is it that upstream maintainers are actually pmOS members? I don't know how close the project members work together, but I'm also a bit confused by the wording)
I'm assuming KDE/GNOME will at some point completely switch over to require systemd, what are the implications for the respective packages in Alpine/pmOS?
Will Alpine add systemd dependencies to their package repository, or will there be downstream versions in pmOS that include/use these changed dependencies? (at least I haven't seen any systemd related issues or merge requests on Alpine's Gitlab)
If there will be downstream versions, what happens to the upstream (ie Alpine) versions, will they still be maintained to work with OpenRC, or removed at some point?
Similarly, what will happen for devices that already have KDE/GNOME installed with OpenRC, will they be automatically switched to systemd when the new package versions are ready (via postmarketos-release-upgrade script)?
I don't really care much what init system gets used behind the scenes, but I am concerned about things breaking when upgrading, and I imagine switching out such a deeply integrated component might be difficult to do without issues

By Zapeth on 2024-04-03T17:17:58

In the announcment it says one of the main blockers we found as we collaborate more closely with KDE and GNOME developers is that they have a hard time with our OpenRC-based stack, but isn't it Alpine's stack, ie their responsibility to keep KDE/GNOME up to date? (or is it that upstream maintainers are actually pmOS members? I don't know how close the project members work together, but I'm also a bit confused by the wording)

There are two parts to this. For one thing, yes, the maintainers of GNOME and KDE upstream in Alpine are primarily pmOS contributors. But we will still have to maintain OpenRC support upstream in Alpine as Alpine isn't switching to systemd. But what this rather is about is that we want to make it easier for KDE and GNOME upstream developers to use pmOS as a test platform for running their software on phones. Both KDE and GNOME upstream developers have had issues testing things on pmOS due to the lack of systemd.

I'm assuming KDE/GNOME will at some point completely switch over to require systemd, what are the implications for the respective packages in Alpine/pmOS? Will Alpine add systemd dependencies to their package repository, or will there be downstream versions in pmOS that include/use these changed dependencies? (at least I haven't seen any systemd related issues or merge requests on Alpine's Gitlab)

Since Alpine is not switching to systemd, the answer is no.

If there will be downstream versions, what happens to the upstream (ie Alpine) versions, will they still be maintained to work with OpenRC, or removed at some point?

We still intend to maintain everything upstream in Alpine.

Similarly, what will happen for devices that already have KDE/GNOME installed with OpenRC, will they be automatically switched to systemd when the new package versions are ready (via postmarketos-release-upgrade script)? I don't really care much what init system gets used behind the scenes, but I am concerned about things breaking when upgrading, and I imagine switching out such a deeply integrated component might be difficult to do without issues

Someone else will have to answer this, I don't know exactly.

By Newbyte on 2024-04-03T17:18:39

Thanks for the responses

But what this rather is about is that we want to make it easier for KDE and GNOME upstream developers to use pmOS as a test platform for running their software on phones. Both KDE and GNOME upstream developers have had issues testing things on pmOS due to the lack of systemd.

Ok, I initally thought the intention of this change was to reduce maintenance work for pmOS developers, thats why I was confused how adding an additional stack of packages was supposed to help with that, but if its for KDE/GNOME devs and pmOS has no problem with the additional efforts then it makes sense for me.

We still intend to maintain everything upstream in Alpine.

Then I guess it should be no problem for users that already have the OpenRC-based packages installed to stay on those versions? That would be fine for me, assuming there are no conflicts down the road with systemd packages.

By Zapeth on 2024-04-03T17:17:24

Similarly, what will happen for devices that already have KDE/GNOME installed with OpenRC, will they be automatically switched to systemd when the new package versions are ready (via postmarketos-release-upgrade script)? I don't really care much what init system gets used behind the scenes, but I am concerned about things breaking when upgrading, and I imagine switching out such a deeply integrated component might be difficult to do without issues

I think postmarketos-release-upgrade should ask if you wish to stay with openrc or switch to systemd, depending on the UI package.

By f_ on 2024-04-02T10:40:25

changed the description

By Oliver Smith on 2024-04-03T21:27:29

changed the description

By Oliver Smith on 2024-04-03T21:39:37

master_staging_systemd was built successfully for x86_64! I've updated the instructions for building your own systemd based images to use the staging repo, and moved it to the wiki: https://wiki.postmarketos.org/wiki/Systemd

EDIT: master_staging_systemd is a rebased version of the systemd branch

By Oliver Smith on 2024-04-23T18:40:40

changed the description

By Oliver Smith on 2024-04-03T21:51:46

changed the description

By Oliver Smith on 2024-04-03T22:41:33

mentioned in issue pmbootstrap#2329 (closed)

By Oliver Smith on 2024-04-03T22:44:04

marked the checklist item build entire branch on bpo for aarch64 as completed

By Oliver Smith on 2024-04-07T13:02:40

marked the checklist item build entire branch on bpo for armv7 as completed

By Oliver Smith on 2024-04-07T14:56:01

I think we should pre-install systemd-timesyncd for ntp time/date updates.

By Justin Zobel on 2024-04-10T12:02:52

#2632 (comment 1854621903)

@Justin_Zobel, I agree. One of the most annoying aspects of Debian is that it doesn't by default configure NTP¹. For a primary smartphone-based OS, I consider this important, because a user generally doesn't want to spend any time in the terminal configuring the OS with a touch-screen keyboard.

By Mr. Beedell, Roke Julian Lockhart on 2024-04-10T12:12:30

https://unix.stackexchange.com/a/137269/386242

My postmarketos img doesnt boot just a blinking cursor on google trogdor

By FrostNovaHD on 2024-04-12T13:43:22

I did the steps from the wiki

By FrostNovaHD on 2024-04-12T13:43:22

Hi, thanks for testing this out. This issue has gotten pretty unwieldly so we're going to close it. Could you open a new issue with this and any additional details you have? It'd be good to debug this further so we'd really appreciate your help!

By Bryant Mairs on 2024-04-30T21:22:36

changed milestone to %initial systemd support

changed the description

By Oliver Smith on 2024-04-21T18:11:45

added status::confirmed label

removed status::confirmed label

marked the checklist item bpo: build the systemd binary repository as completed

By Caleb Connolly on 2024-04-30T19:05:52

marked the checklist item bpo: build the systemd binary repository as incomplete

By Bryant Mairs on 2024-04-30T19:05:56

changed the description

By clayton craft on 2024-04-30T19:06:02

marked the checklist item bpo: build the systemd binary repository as completed

By Caleb Connolly on 2024-04-30T19:09:12

closed

#2632 (closed)

@susurrus, I've read the thread and don't appear to have missed anything explaining the issue closure, so is this now complete - do new ISOs provided via pmbootstrap and https://flash.postmarketos.org use SystemD?

By Mr. Beedell, Roke Julian Lockhart on 2024-05-07T11:46:12

Sorry my previous comment above to FrostNova wasn't more clear. We've closed this issue as it's been replaced by the systemd milestone. See that for the overall tracking. Because things are happening so fast, please jump in the chatroom if you want to follow a more up to date status.

There will be a blogpost soon summarizing the state of things and how to help or even just follow along, so stay tuned for that also.

By Bryant Mairs on 2024-05-07T13:18:46

#2632 (comment 1896075813)

@susurrus, thank you.

By Mr. Beedell, Roke Julian Lockhart on 2024-05-07T13:17:54

systemd megathread

Demo images

How to build your own systemd-based postmarketOS images

Next steps for integrating systemd into postmarketOS

How to contribute

Child items 0

Activity