| onefang | On ASCII AMD64 I don't have that directory. | 00:11 |
|---|---|---|
| onefang | So it'll be some software that you have running on your x86, that isn't on your ARM and on my desktop. | 00:11 |
| onefang | Nor on my server. | 00:12 |
| ErRandir_ | maybe I still have something left over from Devuan Jessie on the x86 machine, it seems systemd created that directory. My arm machine is a fresh install. | 00:31 |
| fsmithred | I've got /run/user/1000 on my ascii (I think this one was upgraded from devuan jessie) | 00:36 |
| onefang | Mine where both debootstrapped to ASCII, so there wont be any Jessie cruft left over. | 00:37 |
| fsmithred | the date on that user dir is Dec 2, last time I rebooted. | 00:37 |
| onefang | Or could be some software you two have that I don't. | 00:38 |
| fsmithred | apt-file doesn't know it | 00:38 |
| onefang | /run is often a tmp device. | 00:38 |
| fsmithred | yeah, everything is Dec 2 except for utmp which has today's date | 00:39 |
| fsmithred | oh, and udev | 00:39 |
| rrq | don't those /run/user/* belong to some "login manager", eg elogind ? | 00:43 |
| ErRandir_ | timestamp on mine is also from the last reboot. Indeed it looks like elogind creates it via pam_elogind.so. Thanks! | 00:57 |
| DocScrutinizer05 | gosh, debian has another vote about init system policy? | 14:10 |
| DocScrutinizer05 | what should devuan users vote for? | 14:11 |
| mason | DocScrutinizer05: Only Debian developers and maintainers can vote. | 14:17 |
| mason | DocScrutinizer05: And the overlap of Devuan users who can vote are probably fairly clear on what they want. :) | 14:18 |
| debdog | MAOAM | 14:21 |
| yeti | MINT | 14:24 |
| DocScrutinizer05 | mason: thanks | 15:01 |
| GyrosGeier | yup | 15:06 |
| * GyrosGeier voted already | 15:06 | |
| APic | ☺ | 15:08 |
| GyrosGeier | and most of the options are so bad that "focus on systemd" made it into the first half | 15:09 |
| GyrosGeier | for me | 15:09 |
| GyrosGeier | because that is still a better outcome than "we leave it up to individual maintainers" | 15:09 |
| fsmithred | It would be really helpful (understatement) if maintainers who don't want to support other inits would accept patches that do provide the support. | 15:46 |
| DocScrutinizer05 | yes, a cursory read across the proposal (headlines) already made me cringe, seems they are poorly chosen and don't really cover a reasonable spectrum of choices/options | 15:48 |
| nemo | hm. | 15:49 |
| nemo | link to the vote? and would it help to canvas debian package maintainers I know? | 15:50 |
| DocScrutinizer05 | sombeody provide https://www.debian.org/vote/2019/vote_002 | 15:50 |
| nemo | I guess 3A is the best option for devuan at present? | 15:51 |
| DocScrutinizer05 | e.g. >>Choice 2: B: Systemd but we support exploring alternatives<< WTH "we support exploring"?? | 15:51 |
| nemo | hm or 6E | 15:51 |
| nemo | ugh. that's a lot of similar choices | 15:52 |
| nemo | how is the vote counted. will all the "support multiple inits" get diluted? | 15:52 |
| GyrosGeier | no | 15:52 |
| GyrosGeier | Debian has a sensible voting system | 15:52 |
| nemo | GyrosGeier: need 51% in multiple rounds? | 15:52 |
| nemo | IRV? | 15:53 |
| GyrosGeier | better | 15:53 |
| GyrosGeier | https://en.wikipedia.org/wiki/Schulze_method | 15:53 |
| DocScrutinizer05 | >><nemo> ugh. that's a lot of similar choices<< that's why I also cringed | 15:54 |
| GyrosGeier | the general agreement is that systemd remains default init, so the differences are in the level of support for people who don't want that | 15:55 |
| nemo | GyrosGeier: yeah, wouldn't expect that to change unfortunately. the backlash against systemd is still a minority | 15:56 |
| GyrosGeier | i.e. is lack of sysvinit support release-critical or not; is it allowed to create NMUs if maintainers don't apply patches, etc | 15:56 |
| GyrosGeier | systemd is also the most sensible choice for a desktop operating system on single-user computers who do not want to look into the innards | 15:56 |
| DocScrutinizer05 | and I see the whole focus is on init system aka PID1, not targeting the massive dependency hell that got introduced by systemd-related takeover | 15:57 |
| GyrosGeier | yes | 15:57 |
| nemo | GyrosGeier: hm. dunno... I have devuan on a 6 machines where no one seems to look at the innards | 15:57 |
| nemo | GyrosGeier: I mean, it's not like properly configured packages really *need* you to play with the init system | 15:57 |
| nemo | in theory the systemd is faster I guess, even with the clever simultaneous launch of multiple scripts, but it's not by an amount that really matters that much to most | 15:58 |
| nemo | GyrosGeier: the living room devuan machine the kids use boots in a few seconds | 15:58 |
| nemo | that one gets the most reboot 'cause they keep unplugging it | 15:58 |
| nemo | I've never touched the init system | 15:58 |
| GyrosGeier | nemo, problems like "if I connect my bluetooth headphone to it, what communications channel does the bluetooth widget on my desktop use to tell the bluetooth daemon, running as root, to pair with a device, and to save the link key in my user-local keyring so when I log in again I can access my headphones, but no one else can" | 15:59 |
| GyrosGeier | these are what systemd solves | 15:59 |
| GyrosGeier | boot speed is largely irrelevant | 16:00 |
| yeti | /!\ | 16:00 |
| GyrosGeier | but being able to pair headphones without knowing the admin password, that is useful | 16:00 |
| DocScrutinizer05 | clearly middleware considerations | 16:01 |
| GyrosGeier | yes | 16:01 |
| nemo | don't know nearly enough about that problem space to comment. I do know that typically home user is a member of sudoers... I guess it'd be nice to have more limited accounts. you'd think there'd be a way to design that that doesn't require the ground up rework of systemd | 16:01 |
| GyrosGeier | this could be done without systemd, but it was kind of shit | 16:01 |
| DocScrutinizer05 | that's systemd's problem, it started as "init system" but actually always targeted at middleware | 16:01 |
| nemo | DocScrutinizer05: is it possible to separate those considerations? | 16:02 |
| GyrosGeier | I'd think it was the other way round: middleware that needs to be pid 1 because that is where orphaned processes exiting are reported to | 16:02 |
| nemo | DocScrutinizer05: or are the modules too integrated? | 16:02 |
| GyrosGeier | they are pretty much integrated | 16:03 |
| nemo | GyrosGeier: and the binary logs and removal of init scripts just grew out of the need for this reporting how? | 16:03 |
| GyrosGeier | binary logs are because service instances now have IDs -- so if a service is restarted, it gets a new ID | 16:04 |
| DocScrutinizer05 | there should be a resolution that generally mandates generic backwards compatible APIs for each package (at very least implemented by compatibility wrappers) that reduce inter-package dependencies to a minimum. Applicable to all packages, not only systemd | 16:04 |
| GyrosGeier | there is a lot more data attached to log messages now | 16:04 |
| GyrosGeier | so these would be unreadable as text | 16:04 |
| GyrosGeier | removal of init scripts is because the dependency system is more elaborate, and specifically supports dependency injection (i.e. I can make a unit that says "this unit becomes a dependency of another, even though they don't know me") | 16:05 |
| nemo | GyrosGeier: you could always have a sidecar log if it was really necessary, which I guess depends on the data logged. As for unreadability. Eh, you can, and many apps do, fit a hell of a lot of data on a single separated line | 16:05 |
| nemo | GyrosGeier: being able to process with text processing tools is not really about 80 chars per line | 16:06 |
| GyrosGeier | but my expectation is that the complexity of the dependency tree is the limiting factor in the future | 16:06 |
| nemo | GyrosGeier: hm. I thought the existing init system in debian allowed exactly that kind of injection | 16:06 |
| GyrosGeier | basically, service init works because the services are Unix daemons that handle failures well | 16:06 |
| nemo | but perhaps I'm misunderstanding a subtle point | 16:06 |
| DocScrutinizer05 | if a log gets unreadable as text, it's gibberish per definition, as all logs need to be read by huumans in the end. Actually I don't see a single datatype (well maybe except multimedia rypes like pics, audio, video tjhat don't belong into logs) that can't be represented in ASCII plaintext as well | 16:06 |
| GyrosGeier | nemo, that worked to a certain extent, yes | 16:07 |
| nemo | DocScrutinizer05: another nice thing about text logs is they are much more corruption resistent. | 16:07 |
| DocScrutinizer05 | ack | 16:07 |
| nemo | DocScrutinizer05: binary formats are more sensitive to location of magic bytes | 16:07 |
| DocScrutinizer05 | which is the foundation idea in the end | 16:07 |
| nemo | and I've certainly encountered log corruption before | 16:07 |
| GyrosGeier | but expressing things like "start this before the network" didn't work | 16:07 |
| nemo | Gyprocps:# X-Start-Before: $network | 16:08 |
| nemo | oups | 16:08 |
| nemo | GyrosGeier: procps:# X-Start-Before: $network | 16:08 |
| GyrosGeier | I mean, I run sysvinit everywhere, and I agree on text logs | 16:08 |
| nemo | quick grep of my devuan | 16:08 |
| GyrosGeier | yes | 16:08 |
| GyrosGeier | that is insserv | 16:08 |
| GyrosGeier | which is optional | 16:09 |
| nemo | well yes | 16:09 |
| nemo | but that's your problem | 16:09 |
| GyrosGeier | without it, you need priorities in update-rc.d, but these have been removed | 16:09 |
| nemo | I mean the fact that it's optional sounds like a good thing to me, not a bad thing. | 16:09 |
| nemo | and if you want that capability, add it? | 16:09 |
| DocScrutinizer05 | I consider logs I can't print realtime to a lineprinter as absolutely worthless and missing their purpose | 16:10 |
| nemo | DocScrutinizer05: heh. we did that on our sun systems for critical logs. It made it a lot harder to hide an attack | 16:10 |
| DocScrutinizer05 | (modulo printspeed that needs to get handled by the serial baudrate and buffer size or whatever) | 16:10 |
| GyrosGeier | mmh | 16:10 |
| GyrosGeier | I used to use BSD securelevels | 16:11 |
| GyrosGeier | but support for that in Linux is spotty, and I'm not sure modern sysvinit still supports that | 16:11 |
| GyrosGeier | (that needs to be an actual thing in pid 1) | 16:11 |
| nemo | DocScrutinizer05: I imagine that even systemd is capable of outputting text logs as *well* but it bothers me text is a second class citizen | 16:11 |
| nemo | DocScrutinizer05: I don't see a good reason for *all* logging to be in text files with varying levels of detail | 16:11 |
| GyrosGeier | we had logging to postgres years ago | 16:12 |
| nemo | DocScrutinizer05: if you want binary size savings, gzip rotation. better indexing? well add an index file | 16:12 |
| GyrosGeier | it wasn't popular | 16:12 |
| nemo | GyrosGeier: good | 16:12 |
| nemo | even sqlite would piss me off | 16:12 |
| GyrosGeier | it absolutely makes sense in a datacenter context | 16:12 |
| nemo | and I actually am decentish at using it as a commandline tool | 16:12 |
| nemo | GyrosGeier: fine. then have the *binary* files as second class citizens in the data centre | 16:13 |
| GyrosGeier | no, postgres makes sense | 16:13 |
| nemo | that is the accumulation | 16:13 |
| GyrosGeier | writing to postgres is still through text | 16:13 |
| nemo | ok. I guess accumulation is variable and the postgres can be local or cluster whatever | 16:13 |
| nemo | just so long as it's stage two | 16:13 |
| GyrosGeier | indeed | 16:13 |
| GyrosGeier | separation of concerns | 16:14 |
| DocScrutinizer05 | by system design, adding complexity to the common case (writing log events to a database) to optimize (redce complexity) for the rare infrequent and not time critical case (readout of logs) is a "test failed" in CS-exam | 16:14 |
| nemo | GyrosGeier: anyway of all the stuff above, your bluetooth one sounded most sensible. perhaps 'cause I understand that portion of userspace devices the very least, and have no familiarity with how it might be shimmed into an existing init system | 16:15 |
| nemo | GyrosGeier: so that would be the one I'd have to learn more about if I wanted to defend my personal traditional init preferences | 16:15 |
| nemo | which are for bias for simple modular systems, lightweight init, and text everywhere | 16:15 |
| nemo | and it sounds like I might have to defend my preferences if I start contacting debian maintainers I know | 16:15 |
| GyrosGeier | my reason for preferring sysvinit is that it is simple | 16:17 |
| DocScrutinizer05 | ^^^ THAT | 16:17 |
| GyrosGeier | it will allow people to learn slowly, and have successes | 16:17 |
| GyrosGeier | I have been working with Debian since 1998, so >20 years now | 16:17 |
| nemo | hm. ahead of me. I stayed on redhat and variants until about 2000 | 16:18 |
| nemo | then gentoo and debian | 16:18 |
| GyrosGeier | I find systemd to be incomprehensible because it expects me to grasp all these concepts at the same time | 16:18 |
| GyrosGeier | same for Docker | 16:18 |
| nemo | GyrosGeier: interesting. yeah. that's my opposition to a ton of modern tool | 16:18 |
| nemo | *ing | 16:18 |
| DocScrutinizer05 | GyrosGeier: full ack | 16:18 |
| nemo | GyrosGeier: I'm currently maintaining about 3 dozen web apps for the company I'm working for that I banged out with help of a couple of others over the past decade to automate paper processes and such | 16:19 |
| GyrosGeier | and a lot of people just learn magic incantations instead of the underlying concepts | 16:19 |
| nemo | GyrosGeier: we know every single piece of those apps and have trivially moved them to different infrastructures. mostly 'cause they had few dependencies | 16:19 |
| GyrosGeier | the Ubuntu forums were a step in the wrong direction already | 16:19 |
| GyrosGeier | "doesn't work? add sudo." | 16:19 |
| nemo | GyrosGeier: no external libs, no massive APIs. injection opportunities closed down at lowest level possible.. | 16:20 |
| nemo | progressive enhancement... | 16:20 |
| nemo | ok. not *no* external libs. pragmatism. sometimes they are needed. but at least you know when you pull 'em in. and what they are for ☺ | 16:20 |
| GyrosGeier | my expectation is that there will be a new class of users, I usually call them Linux Consultant and Systemd Expert, that know the names of services and how they are connected, but not what they do | 16:21 |
| nemo | GyrosGeier: do you have more info on how the bluetooth device situation you mentioned would work for a home user who was not in sudoers in a non-systemd situation? if that came up. what are the existing options? | 16:21 |
| nemo | GyrosGeier: https://www.vitavonni.de/blog/201503/2015031201-the-sad-state-of-sysadmin-in-the-age-of-containers.html this was on HN today (again) it seemed apropos to above | 16:22 |
| GyrosGeier | nemo, separate daemon running as root that knows that it is acting on behalf of users | 16:22 |
| DocScrutinizer05 | this all fails with Mr P explicitly despising "portability", by statements like "who cares about BSD, Linux is mature enough to go its own unique way" OWTTE | 16:22 |
| nemo | GyrosGeier: what about the reporting to process 1? was there a spec for init to relay to the separate dæmon? | 16:22 |
| GyrosGeier | that can be avoided for services you have under control | 16:23 |
| GyrosGeier | basically, reporting to pid 1 happens when a process forks itself into the background, then terminates | 16:23 |
| GyrosGeier | which is default for daemons | 16:23 |
| DocScrutinizer05 | is linux a unix that tries to stay as universally unix compatible as possible, or is linux outside the unix family | 16:23 |
| GyrosGeier | if a process terminates while it has child processes, all the children get reparented to pid 1 | 16:24 |
| GyrosGeier | DocScrutinizer05, both | 16:24 |
| nemo | GyrosGeier: yeah. that part I'm familiar with. it's the whole unprivileged device systems I'm not familiar with ☺ | 16:24 |
| nemo | GyrosGeier: is the problem if the master dæmon dies unexpectedly? | 16:24 |
| GyrosGeier | nemo, the kernel doesn't provide access control methods that are fine-grained enough | 16:24 |
| GyrosGeier | so what people do is write a service that runs as root, implements the access control, and provides an interface that the user process can access | 16:25 |
| nemo | GyrosGeier: ok... but why can't that access control be implemented in the master... yeah. that's what I still don't get. why does this need to be in init | 16:25 |
| nemo | GyrosGeier: the whole why are these problems systemd is supposedly solving not modular | 16:25 |
| GyrosGeier | the access control isn't inside init | 16:25 |
| nemo | why can't you choose if you want to ditch init scripts or use binary logs or have a master dæmon for access control to devices | 16:26 |
| GyrosGeier | it's basically a reimplementation of the Windows95 service manager | 16:26 |
| nemo | I really don't understand the need for it to be completely intermeshed *and* in pid 1 | 16:26 |
| GyrosGeier | because it's a lot more work to implement it in a modular way | 16:26 |
| nemo | ok. well that would be understandable if it was a project being banged out by 1 guy | 16:27 |
| GyrosGeier | and they aren't getting paid for that, nor is there enough time | 16:27 |
| nemo | hm. they aren't being paid for that? I really thought this was one area where corp money was being thrown at the problem | 16:27 |
| nemo | but I guess there's no incentive to split it up | 16:27 |
| GyrosGeier | exactly | 16:27 |
| nemo | you'd think there'd be security wins to separation of concerns though | 16:27 |
| nemo | and that might matter to corp money. but maybe not | 16:27 |
| GyrosGeier | they want to build a platform, where you can ship software that knows it can expect certain services | 16:28 |
| GyrosGeier | making that modular makes the platform weaker | 16:28 |
| nemo | I mean, windows famously put XML/XHTML parsing, rendering of window widgets, and TTF parsing in the "kernel" sooo | 16:28 |
| nemo | guess we're headed down that road | 16:28 |
| GyrosGeier | no, Linus used a few choice expletives when that was suggested | 16:29 |
| nemo | Linus is being sidelined | 16:29 |
| nemo | he won't be the gatekeeper forever | 16:29 |
| GyrosGeier | but in general the kernel interfaces are "make things work", missing access control and revocation of interfaces | 16:30 |
| GyrosGeier | the access control mechanisms that exist are historic | 16:30 |
| GyrosGeier | e.g. there is no way for the kernel to force a process to give up an ALSA device handle | 16:31 |
| GyrosGeier | so a user could leave an audio player running and log out | 16:31 |
| GyrosGeier | X11 implements access control and revocation for graphics hardware | 16:31 |
| GyrosGeier | when you log out, clients are told to go away | 16:31 |
| GyrosGeier | but that's not a kernel interface | 16:31 |
| GyrosGeier | a process that has a framebuffer handle open cannot be told to go away | 16:32 |
| GyrosGeier | which is why only root can open the framebuffer | 16:32 |
| nemo | yeah. I get that part. what I didn't get was the desire to cram everything and the kitchen sink in proc 1, but seems answer to that is simply "'cause it's easier that way and we don't care about alternatives/modularity" | 16:32 |
| nemo | even if it might have security implications | 16:32 |
| GyrosGeier | pid 1 needs to understand the dependency structure | 16:33 |
| nemo | GyrosGeier: so... maintaining alternate inits might be for Debian's own good if this whole thing ends up biting linux | 16:33 |
| GyrosGeier | indeed | 16:33 |
| GyrosGeier | as said, it's a shite reimplementation of Windows 95/98 services | 16:33 |
| GyrosGeier | the bluetooth widget in Windows works exactly the same as in GNOME | 16:34 |
| GyrosGeier | program running in session context with user permissions asks the OS to activate a "bluetooth configuration" component for them | 16:34 |
| GyrosGeier | receives an IPC interface | 16:34 |
| GyrosGeier | then uses that to set up things | 16:34 |
| GyrosGeier | the policy layer for that lives on the other side of the interface, and most likely consists of multiple layers as well | 16:35 |
| GyrosGeier | if one of these layers fails, anything on top needs to be torn down | 16:35 |
| nemo | is this similarity due to similar constraints, or are you implying the old "embrace extend..." due to MS loss of the server market? | 16:35 |
| GyrosGeier | that is what systemd does as pid 1 | 16:35 |
| GyrosGeier | it's a sensible implementation | 16:36 |
| nemo | hm "shite reimplementation" and "sensible implementation" do not sound the same | 16:36 |
| GyrosGeier | you can either define a network interface, or use an existing IPC standard and wrap the network interface within it | 16:36 |
| nemo | but I guess Ⓑ is the windows one ? | 16:36 |
| GyrosGeier | systemd doesn't go far enough in many cases | 16:36 |
| GyrosGeier | they just make it work somehow, but they don't incorporate the things we've learned from 25 years of Windows history | 16:37 |
| GyrosGeier | systems like these have very specific failure modes | 16:37 |
| GyrosGeier | e.g. all dependencies are now runtime only, so you can't scan an executable to find out what packages need to be installed as well | 16:38 |
| nemo | my knowledge of bluetooth is limited to friend cursing the code quality of BlueZ to the point where he implemented his own driver for the device he was working on | 16:39 |
| GyrosGeier | MS solved that with embedded manifests | 16:39 |
| nemo | but I get the general principles above | 16:39 |
| mcr | GyrosGeier, what I hear you saying is that the systemd people are not re-inventing new init thinking, but rather are just replicating the failures of 25 years of Windows monolithic kernel errors. | 16:39 |
| nemo | still don't see the need for touching my precious pid 1 but I guess I understand enough to argue for saving alternate inits in a vote | 16:39 |
| GyrosGeier | pretty much | 16:39 |
| GyrosGeier | I mean, there is lots of cross-pollination between Windows and Linux | 16:40 |
| GyrosGeier | e.g. Windows basically boots with an initrd | 16:40 |
| GyrosGeier | and they have a mechanism for enumerating which drivers are included on the initrd | 16:40 |
| mcr | GyrosGeier, on the topic of forcing processes to give up access. We solved this for ttys back in the SRV3 / BSD4.2 days with revoke(2). I wish we could do the same thing for NFS file opens, and it seems like the same thing ought to work for X11, ALSA device handles, etc. | 16:41 |
| GyrosGeier | yes | 16:41 |
| GyrosGeier | ttys are special | 16:41 |
| GyrosGeier | there has always been an interface for revocation | 16:41 |
| GyrosGeier | (SIGHUP) | 16:41 |
| mcr | (well, I'm old enough to remember before revoke(2)) | 16:42 |
| mcr | SIGHUP wasn't enough, because processes could ignore it. | 16:42 |
| GyrosGeier | true, but their file handles went unusable as well | 16:42 |
| GyrosGeier | if you ignore SIGHUP, you need to really know what you're doing | 16:43 |
| mcr | no, they didn't. That took a call to revoke(). UUCP modem dialers needed to survive SIGHUP, when DCD actually did change :-) | 16:43 |
| GyrosGeier | ah | 16:45 |
| mcr | The GNOME file dialog still fails when NFS mounts are slow, and I'm still surprised given a wide variety of fuse-fs that we haven't invented better ways for the file dialogue to scan things without locking up. | 16:45 |
| mcr | Or to make df not hang on slow mounts. | 16:45 |
| GyrosGeier | there is a better way | 16:46 |
| GyrosGeier | but it's complex | 16:46 |
| GyrosGeier | and will mean more systemd integration :P | 16:46 |
| mcr | I have a few ubuntu VMs with systemd (because... docker and crap) and I continue to be amazed how hard it is to get a static /etc/resolv.conf configuration. Yet, the systemd resolver stuff doesn't really help for captive portals on a laptop. | 16:47 |
| GyrosGeier | it also turns off return path filtering | 16:53 |
| DocScrutinizer05 | >>GyrosGeier> and they aren't getting paid for that, nor is there enough time<< not an excuse for delivering shit - while I actually doubt that claim is correct to start with | 18:40 |
| GyrosGeier | DocScrutinizer05, RH is not paying the systemd developers to build a modular system, because they are not interested in shipping a modular system | 18:42 |
| GyrosGeier | they are interested in shipping, as someone on Twitter called it so aptly, "a monolith with a string-based calling convention" | 18:42 |
| GyrosGeier | monoliths are manageable | 18:42 |
| GyrosGeier | as long as you have full-time programmers, that is | 18:43 |
| DocScrutinizer05 | that sounds more like it, yesa | 18:44 |
| DocScrutinizer05 | I thought "paid for that" was systemd at alrge, sorry | 18:44 |
| Wonka | GyrosGeier: well, I work in a company paying over a hundred full-time programmers to improve the monolith they're selling. one of the longer-term goals is to make that monolith more modular. | 18:45 |
| GyrosGeier | systemd is also "modular", but you can't easily exchange parts | 18:46 |
| GyrosGeier | because the API pretty much defines the implementation | 18:47 |
| GyrosGeier | protocol design is a forgotten art form :/ | 18:47 |
| DocScrutinizer05 | actually I think a monolith is preferable for RH as it allows more easily to be poorly documented, intricate, obscure and without alternatives so RH (and Suse) may offer more expert service by those few who actually master that shit | 18:48 |
| DocScrutinizer05 | and don't get me started about (the recent lack of) protocol design and system design skills in groups like systemd cabal and freedesktop.org | 18:50 |
| Burek | systemDesktop enviroment | 18:51 |
| errandir1 | Talking about RH, today the OOM killer decided to kill systemd PID 1 on one of our RH systems. I just thought: good job OOM :) | 18:52 |
| onefang | lol | 18:53 |
| Wonka | I would have thought there'd be protections against OOM-killing PID 1 | 18:56 |
| errandir1 | OOM kills all bloat-ware | 18:56 |
| DocScrutinizer05 | errandir1: LOL | 19:17 |
| DocScrutinizer05 | errandir1: please provide syslog except ;-D | 19:18 |
| DocScrutinizer05 | excerpt even | 19:19 |
| overflyer | Hi guys just a general question for openrc based systems. Is it possible that chrooting into an aarch64 rootfs from an x86 based openrc linux is somehow different than from a x86 systemd based system? | 20:17 |
| overflyer | I am on artix linux but no one over there answers at the moment. I am just asking because I read tens of tutorials know and I actually know what packages I need and what to do to chroot into an arm rootfs, but I always get /bin/bash: FIle or directory not found. | 20:19 |
| overflyer | My kernel has binfmt support and I have all binfmt and qemu packages installed and I always copy /usr/bin/qemu-aarch64-static into usr/bin of the mounted arm rootfs image as every tutorial tells me to, but chrooting never works. | 20:20 |
| specing | overflyer: did you enable the aarch handler in binfmtmisc? | 20:22 |
| overflyer | I can only tell you that my kernel has binfmt support enabled and a u"pdate-binfmts --enable qemu-aarch64. " gives me "update-binfmts: warning: qemu-aarch64 already enabled in kernel." I do not exactly know what you mean by your question. Could you explain? | 20:25 |
| specing | overflyer: maybe the qemu executable should be called 'qemu-aarch64'? | 20:30 |
| overflyer | specing: I have a /usr/lib/binfmt.d directory where I have qemu.conf and a qemu-static.conf that both have a line starting like this (and many others): :qemu-aarch64:M::\x7fELF\x02\x01\x01\x00\x00\x00\x00\x ............ so that is the elf magic I guess | 20:32 |
| overflyer | what did you mean by aarch handler and binfmtmisc then I will check that and you explain to me what to look for and what to add?! | 20:32 |
| specing | yes, it is | 20:32 |
| specing | what is the path to qemu in that magic line? | 20:33 |
| overflyer | /usr/bin/qemu-aarch64-static and /usr/bin/qemu-aarch64 in qemu-static.conf and qemu.conf respectively | 20:34 |
| specing | But what gets passed to the kernel? | 20:34 |
| overflyer | if you tell me which file shows me that I will check | 20:35 |
| specing | I don't know which file does that on your system | 20:36 |
| DocScrutinizer05 | no fist hand knowledge here but I seem to recall systemd with its mandatory cgroups-hogging interferes with at least VMs | 20:37 |
| DocScrutinizer05 | a chroot won'T ahndle cgroups afaik | 20:38 |
| overflyer | is it possible that you want the content of /proc/sys/fs/binfmt_misc/qemu-aarch64 ? | 20:38 |
| specing | overflyer: not me, you want it | 20:39 |
| specing | DocScrutinizer05: I remember it was quite a pain to run systemd containers in LXC on gentoo, precisely because of it hogging everything | 20:39 |
| overflyer | Whenever you think you learned Linux pretty well you just hit a category which requires new knowledge and you feel like you are at right at the beginning. Frustrating. :D | 20:41 |
| onefang | That goes for any complex systems. Some of us enjoy learning new stuff all the time. B-) | 20:43 |
| overflyer | specing: the file /proc/sys/fs/binfmt_misc/qemu-aarch64vhas this content right here. enabled | 20:43 |
| overflyer | interpreter /usr/bin/qemu-aarch64 | 20:43 |
| overflyer | flags: OCF | 20:43 |
| overflyer | offset 0 | 20:43 |
| overflyer | magic 7f454c460201010000000000000000000200b7 | 20:43 |
| overflyer | mask ffffffffffffff00fffffffffffffffffeffff | 20:43 |
| specing | overflyer: yes, see | 20:43 |
| overflyer | anyways I kindof assume that it is not good that there is no qemu-aarch64-static version of this | 20:44 |
| overflyer | just the non-static one | 20:44 |
| overflyer | but I am very certain for chrooting I need the static one | 20:44 |
| overflyer | So how would I add this to the binfmt configuration so that next time I restart binfmt service it gets mount to /proc/sys/fs/binfmt_misc ? | 20:45 |
| overflyer | I basically want a /proc/sys/fs/binfmt_misc/qemu-aarch64-static file | 20:46 |
| specing | I think you need to go a few steps back and solve the initial PEBKAC caused by mindless copying of code from multiple incompatible tutorials | 20:47 |
| overflyer | It was not like full-retard zombie mode mindless like maybe a BIT mindless, but since I think I understood what the tutorials told me about qemu and binfmt I understood enough to make sure not to spam my system with unneccessary packages or configurations or such. Anyways ... I will purge all the packages and configs and so on and try to start anew | 20:50 |
| overflyer | And all because I wanted to start öearning kernel module programming with my new espressobin v5 by a book from Rodolfo Giometti... sigh | 20:50 |
| specing | overflyer: you'd have a nicer time doing that in Xen/KVM on x86 | 20:53 |
| specing | s/nicer/happier/ | 20:53 |
| overflyer | that was one of my next thoughts yes. I just really anted to work through the book step by step because it is brand new from 2019 and well written (well until the part he just chroots into the image and explains nothing although before that he explained everything in detail :D) | 20:55 |
| overflyer | and those books are hard to come by | 20:55 |
| overflyer | but I guess I need to follow your advice | 20:55 |
| onefang | See? Some of us love learning new complex things, like kernel module programming. B-) | 21:02 |
| overflyer | ;) | 21:07 |
| overflyer | I just hope all this is not because I am to stubborn to use systemd based systems | 21:08 |
| overflyer | because over the last few years I encounter more and more problems ue to that fact | 21:08 |
Generated by irclog2html.py 2.17.0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!