search

sakaki- / gentoo-on-rpi-64bit

Bootable 64-bit Gentoo image for the Raspberry Pi4B, 3B & 3B+, with Linux 5.4, OpenRC, Xfce4, VC4/V3D, camera and h/w codec support, weekly-autobuild binhost
GNU General Public License v3.0
921 stars 126 forks source link

systemd init system #50

Closed maggu2810 closed 6 years ago

maggu2810 commented 6 years ago

Without starting a discussion about the good and bad things about systemd, please allow me to ask if you plan to add a systemd (non OpenRC) image, too?

sakaki- commented 6 years ago

Hi @maggu2810 -

Good question. Let me start by saying that, in case I've given the wrong impression somewhere, I don't have an issue with systemd per se - in my EFI install guide, for example, I cover both OpenRC and systemd installs (with the latter being the default in fact) and I have created images using systemd init in the past (such as e.g. archlinux-on-b3).

Rather, my main issue is simply one of bandwidth for release engineering - the two images (if I created a systemd variant in addition to the OpenRC one) would have significantly different package sets (and USE flags) so would have to be individually tested, and this is just a spare-time project for me.

If you would like to help move this forward, perhaps the best thing would be to PR systemd unit files for the various existing OpenRC startup services to my rpi3-overlay (this wouldn't be onerous, there aren't many of them); I could then try making a bootable systemd image for test purposes and (if you were willing to do so) you could then test it (ensure all apps open correctly, NetworkManager associates properly, no strange stuff in system logs, genup still runs properly, etc.) - in such a case at least a 'special edition' image could then be publicly released supporting systemd.

maggu2810 commented 6 years ago

Hi @sakaki-

in case I've given the wrong impression somewhere, I don't have an issue with systemd per se

No, there has been now impression -- or at least the only one has been that it is not used. :wink: I just wanted to avoid a discussion which init system is better etc.

I will try to have a deeper look at your image and setup a crossdev. I don't know currently how much time I am able to spend, but I will give it a try and share my experiences (some time).

Thank you for your fast reply.

necrose99 commented 6 years ago

i atm have just completed an arm64 drive image... , on scaleaway with 8 gigs.. native arm64 atm its a debian9 arm64 /dev/vdb : gentoo , i have a systemd built.. in repo , and have allocated a chroot. 150 gigs on chroot drive , hoping to swap to as main o/s ie systemd --buildkgonly...

ARM64-Generic, with exception of RPI3 bins for the moment till the upgrade out... generic so can be used on multiple systems RPI3 , server etc..

to do spin instance test gentoo image for boot , can then run chroots or builders.. ie catalyst molecule etc...

bit rustty with http configs by hand as webmin.... and ftp etc rsync and done... (willing to lend me a hand , I can expose binhost folders..)

to do layman is broken... :-( and overlays , however metasploit , puppet , ansible , salt ....DOCKER DOCKER SWARM, etc are nearly done on main... a few other dev-ops toys... zfs has built in the past , as for kernel and root.. rockpro64 can use sata so 10 TB nas drive and SSD make a good combo...

Other todo is forking to Pine64/Rockpro64/rock64 as for building on my desk 4 gigs vs 1 gig more Oomph... however RPI3 is quite Expendable , case and all by comparison to Teleasploit.com NUK box.. reserching iot for Sec testing and sec-def-testing...

necrose 99 @ pro ton mai l .com .... likewsie irc pentoo on freenode etc...

dev-util/molecule spec ::sabayon , feed a spec and bins makes chroot ... iso/tar out.. typically does not need much wrapping.. , or dev-util/catalyst ..(rel-eng has thiers quite scripted.. )

i have u-boot and grub also built.
VOLS: /boot/efi, /boot , / for RPI3 / PINE/ROCK64 image is 2016 , however having u-boot/grub for both makes for kernel testing...

been trying to get a Docker image of rpi3 etc to load mount : host:rpi3-packages to packages... in docker --privileged ...wala.. emerge foo ..... and done , just been a pest to get emu to run right.. , thus easy to fork systemd etc... as crossdev can be done but many users... however would make for faster simplicity.. as one could get qemu to finally work , resin.io has it working on every other docker os but gentoo...

RPI3 kernel ATM wont init and will die on last falls image, and per RPI3 systemd units for boot would need be made....