| adhoc | morning all | 02:13 |
|---|---|---|
| debdog | the early bit catches the word | 02:31 |
| systemdlete29 | I know that mucking with such things as /dev and /sys can lead to trouble, but don't worry, so far I am only trying things on a test box. What I observe is that I cannot--even as root--write to files on /sys. Is that a security feature, or does my system require a tweak to permit such writing? | 05:16 |
| systemdlete29 | I've tried chmod u+w /sys/.../file_i_want_to_write_to | 05:16 |
| systemdlete29 | but that doesn't work | 05:16 |
| systemdlete29 | I get "write error: Input/output error" | 05:17 |
| systemdlete29 | is it only via the rules.d files that /sys can be modified? | 05:18 |
| systemdlete29 | rrq: I did look at the docs on arch but I could not find what I was looking for. It's possible I need to keep digging over there. | 05:18 |
| rrq | well /sys is a virtual filesystem that present the kernel setup througha filesystem model | 05:19 |
| rrq | some things are writable eg as way of modifying module parameters | 05:20 |
| rrq | so it's not actually a directory tree | 05:20 |
| rrq | but /dev is a directory tree although some of its "memebrs" are "API points" (device nodes) for kernel thingies | 05:21 |
| rrq | it is "the old way" :) | 05:22 |
| rrq | udev is supposed to map /sys/... into /dev/... to make "the new way" accessible as "the old way", since in particular "the old way" is better documented | 05:25 |
| rrq | we are looking at the combined result of 40 or so years of a varying degree of brilliance in kernel development | 05:27 |
| systemdlete29 | lol. indeed... | 05:27 |
| systemdlete29 | what is the main distinction between /proc and /sys because I notice that /proc/sys seems to have similar substructure. I know that /proc has process info whereas /sys does not. But why is there a need to have 2 of these virtual file systems? Could 1 do as well had the design been otherwise? | 05:29 |
| gnarface | i thought /sys was just supposed to be for kernel info | 05:30 |
| systemdlete29 | ok, but /proc also has a /proc/sys | 05:30 |
| gnarface | yea, it may not be super sane | 05:30 |
| rrq | yes I think /proc/sys/.. was the original idea, and then it got spun out as a separate /sys .. but then already there were piles of software using /proc/sys ... | 05:30 |
| gnarface | volunteer devs really like green fields | 05:31 |
| systemdlete29 | yeah I get you | 05:31 |
| gnarface | but you're right systemdlete29, that some stuff in /sys just can't be changed without changing kernel code | 05:31 |
| gnarface | that's by design | 05:31 |
| systemdlete29 | I'm just trying to kind of map it all out so I can understand it a bit | 05:31 |
| systemdlete29 | ok, thanks for that info | 05:32 |
| gnarface | what's really confusing is some stuff can be changed in /sys, and is intended to be | 05:32 |
| gnarface | like for example cpu clockspeed and governor settings | 05:32 |
| systemdlete29 | right, I remember that part | 05:32 |
| systemdlete29 | so most of it seems to be immutable | 05:32 |
| rrq | "backward compatibility" used to be important, rather than the "planned obsolescence" of today | 05:41 |
| systemdlete29 | fast bytes | 05:42 |
| adhoc | rrq: obsolescence happens | 06:00 |
| adhoc | none of it is planned =( | 06:00 |
| adhoc | mostly because poor software engineering practice | 06:01 |
| systemdlete29 | adhoc: Does that mean there is a chance that systemd will go away? Systemd seems to tick the boxes... | 06:27 |
| rrq | (sorry, my noted thought might have pushed us into OT ) | 06:29 |
| golinux | systemdlete: Eventually everything "goes away". | 06:29 |
| * golinux slaps rrq with a soggy, wet noodle. :D | 06:30 | |
| adhoc | systemdlete29: I believe the features that systemd brings are to secure market domanance(sp?), not improve things | 06:31 |
| * systemdlete29 runs away... | 06:31 | |
| systemdlete29 | this might be usleful at some point: https://documentation.suse.com/sles/12-SP5/html/SLES-all/cha-udev.htm It is not totally complete, but it is pretty clear and even provides a few examples. | 06:34 |
| rrq | mmm that's pretty much "man dev" plus something about "tmpfile.d" that looks new | 06:45 |
| rrq | "man udev" | 06:45 |
| systemdlete29 | Similar, but not exactly the same. | 07:43 |
| systemdlete29 | I feel I may need both to decipher this cryptic work | 07:44 |
| systemdlete29 | A rosetta stone would be nice also | 07:44 |
| systemdlete29 | In particular, there doesn't seem to be any mention, one way or the other, of directly setting ATTRS; it doesn't seem to be supported at all. | 07:52 |
| systemdlete29 | (you can only set ATTR, not ATTRS, apparently) | 07:52 |
| rrq | yes "ATTRS" is a look-back into ATTR along the "parent node" chain | 07:54 |
| systemdlete29 | sure, but how does one modify one of those parent nodes? | 07:54 |
| rrq | no, only those of the "current node" | 07:55 |
| systemdlete29 | I've so far been able to confirm I am getting the correct "add" action for my rule, which is pretty simple. | 07:55 |
| systemdlete29 | As I said: (you can only set ATTR, not ATTRS, apparently) | 07:56 |
| systemdlete29 | ^^ | 07:56 |
| systemdlete29 | I agree we seem to be restricted from doing so, at least directly. | 07:56 |
| systemdlete29 | I wonder if there is a way to do this via the usb subsystem itself, rather than taxing my wits against this monstrosity. | 07:56 |
| rrq | what is/was the goal here? | 07:57 |
| brocashelm | is there a way to get xfce to run without dbus running? would putting dbus_enable="NO" in /etc/rc.conf suffice? | 07:58 |
| onefang | https://www.devuan.org/os/documentation/dev1fanboy/en/devuan-without-dbus.html might be useful. | 07:59 |
| systemdlete29 | rrq: I was trying to set the serial number of usb ethernet devices because, sadly, some mfrs don't seem to think they are necessary | 08:00 |
| brocashelm | yeah, i linked to that in ot earlier, but that doesn't apply to xfce or any other de | 08:00 |
| systemdlete29 | So if I have multiple of the same make/model of usb device, they are indistinguishable from an application's POV | 08:00 |
| brocashelm | just to have xfce running sans dbus (but not removed) | 08:00 |
| systemdlete29 | and unfortunately, the application does not have ANY way to uniquely identify usb devices by mac address--I have asked the devs and they have told me as much. | 08:01 |
| onefang | Just remember that /sys is a virtual file system controlled by the kernel, not a real file system. So it only lets you do things that the kernel thinks are sane, but most of it is purely for the kernel to show information and thus read only. | 08:01 |
| systemdlete29 | and, unfortunately, the application does not support references to /dev/... which would be a useful way to distinguish them also. | 08:02 |
| systemdlete29 | No, its not what the kernel thinks is sane. I think it is more what a certain dev thinks is sane. Not that this person is necessary himself sane. | 08:02 |
| systemdlete29 | If an admin would like to shoot their own foot off, unix traditionally allowed them to. | 08:03 |
| systemdlete29 | What I want to do would hardly damage the system, so I deem it "sane" | 08:03 |
| systemdlete29 | I think using the NAME= approach in the rules makes a lot of sense. But the devs do not have plans to support it or maybe any other decent idea. | 08:04 |
| systemdlete29 | so... I may be S.O.L | 08:04 |
| systemdlete29 | I have more usb-eth dongles coming. I will check them to make sure they have serial numbers (real ones, not silly "000000" ones). Otherwise, they go back to the clowns that sold them to me. | 08:05 |
| systemdlete29 | I mean, changing the serial number of something should be just as straightforward and accessible as changing a mac address, which you can do with nearly any ethernet device nowadays (or at least, I have not run into a problem doing so) | 08:06 |
| rrq | right; I don't think I've ever used the serial number of any device :) | 08:07 |
| systemdlete29 | but you have probably changed a mac once or twice? | 08:07 |
| rrq | yes though that number belongs to the function of the device, not device itself | 08:08 |
| systemdlete29 | what is the distinction? The kernel could easily permit an override, even if it means storing the info inside its own tables. | 08:08 |
| rrq | but I agree it *should* be easy :) | 08:09 |
| systemdlete29 | I think that is done in some places for certain things. | 08:09 |
| systemdlete29 | yes, that is the point. Straightforward. | 08:09 |
| systemdlete29 | And hopefully, documented a bit more thoroughly than the short shrift we are given. | 08:09 |
| * systemdlete29 sings "I'm a Volunteer and I'll do WTF I Like Even If It Pisses Off The Entire World." | 08:10 | |
| rrq | for USB it comes in the descriptor I guess, so any override would need to be a filter on the communication | 08:10 |
| systemdlete29 | Perhaps, idk exactly. All I do know if that tools like openwrt can do this quite comfortably for the MAC address. | 08:11 |
| systemdlete29 | But you are right that maybe it amounts to some overhead. | 08:12 |
| rrq | systemdlete29: pm | 08:22 |
| rrq | brocashelm: xfce4-session seems to require dbus (session), and so do several "core" programs (eg xfce4-panel), which makes it a "no" answer. | 11:48 |
| fsmithred | systemdlete29, try using file system labels on your usb devices. | 13:02 |
| fsmithred | brocashelm, I don't know if you can run xfce without dbus, but I did play with running it without policykit. This is old (jessie) so some things may have changed. https://dev1galaxy.org/viewtopic.php?pid=11341#p11341 | 13:05 |
| spacecadet001 | anyone using vpn ? | 14:35 |
| spacecadet001 | may i know if riseup works for anyone ? | 14:35 |
| fsmithred | spacecadet001, I have used riseup, and it works. | 14:45 |
| fsmithred | I don't recall any details about using it. | 14:46 |
| spacecadet001 | I meant the riseupvpn debian package ? They don't provide support for openvpn now. | 14:47 |
| spacecadet001 | snap package they provide is not compatible with devuan | 14:48 |
| fsmithred | I think I tried it in chimaera | 14:48 |
| fsmithred | was thinking about it this morning. I'll reinstall and try again. | 14:49 |
| spacecadet001 | if it's working for you , do not reinstall . | 14:49 |
| fsmithred | it's no longer installed | 14:50 |
| spacecadet001 | latest package has dependency on libappindicator3-1 . | 14:51 |
| fsmithred | I'm not seeing it in chimaera or beowulf now (riseup-vpn package) | 14:51 |
| spacecadet001 | ok , please let me know. | 14:51 |
| spacecadet001 | https://riseup.net/en/vpn/linux | 14:54 |
| spacecadet001 | ok. | 14:55 |
| spacecadet001 | I will try building , but will need to see if i can replace the lib modules | 14:55 |
| spacecadet001 | Thank you , fsmithred. | 14:56 |
| fsmithred | spacecadet001, I have 0.19.11 installed on this beowulf I'm running right now. | 15:01 |
| fsmithred | and I have the .deb package in my home dir, so I must have downloaded it from debian and installed it manually | 15:01 |
| spacecadet001 | ok will check that . | 15:02 |
| spacecadet001 | thank you | 15:03 |
| fsmithred | beowulf has libappindicator3-1 but chimaera has libappindicator3-0.1-cil | 15:03 |
| fsmithred | not sure if there's an easy way to get it to work in chimaera | 15:03 |
| spacecadet001 | yes that is the issue . | 15:03 |
| fsmithred | I added the leap archive and installed with apt. I see the command in apt history. | 15:06 |
| spacecadet001 | installed in Chimaera ? | 15:07 |
| fsmithred | no, in beowulf | 15:07 |
| fsmithred | I'm checking now to see if leap has packages for bullseye(chimaera) | 15:08 |
| fsmithred | nope. no bullseye in leap according to apt update. | 15:08 |
| spacecadet001 | they have not updated debian . | 15:09 |
| spacecadet001 | https://dl.bitmask.net/RiseupVPN/linux/ | 15:09 |
| spacecadet001 | https://0xacab.org/leap/bitmask-vpn | 15:10 |
| fsmithred | spacecadet001, you could try building it with their instructions. FWIW, I found it easier to use tor-browser instead of the vpn. | 15:20 |
| rrq | spacecadet001: you might also consider installing libayatana-appindicator3-1=0.5.91-1 from daedalus into your chimaera | 15:26 |
| noobaroo | Hi, i am trying to replace systemd with sinit on Debian | 22:14 |
| brocashelm | this channel is for devuan support | 22:16 |
| brocashelm | if you need help with devuan, just ask | 22:16 |
| brocashelm | current supported inits for devuan are sysvinit, openrc, and runit (partially implemented). you can try s6 and a few others if you like, but they are experimental and not yet officially supported by the devs | 22:20 |
| brocashelm | when you use the devuan installer iso, you can choose any of the three inits i mentioned | 22:20 |
| brocashelm | no need to worry about systemd as devuan's merged repository checks for that | 22:20 |
| brocashelm | https://www.devuan.org/os/documentation/install-guides/chimaera/install-devuan | 22:21 |
| noobaroo | is sinit part of the installer iso? | 22:32 |
| noobaroo | (suckless init) | 22:33 |
| brocashelm | no, it's sysvinit, openrc, and runit for now | 22:35 |
| brocashelm | although runit is not 100% implemented as its services still use sysv scripts | 22:36 |
| brocashelm | not sure about openrc, but that one should be stable at the very least | 22:36 |
| brocashelm | i use runit myself and haven't had any issues. it's fast when booting up | 22:36 |
| fsmithred | noobaroo, the migration guides might have some hints for you. https://www.devuan.org/os/install | 22:46 |
| fsmithred | openerc in debian/devuan uses the sysvinit scripts. | 22:49 |
| rrq | noobaroo: you can trial your (say) /bin/sinit by booting up with "init=/bin/sinit" as a kernel parameter; it'll boot up your initrd then pivot to the root filesystem and run sinit ... you'll then of course also need your /bin/rc.init properly prepared for a useful bootup | 23:02 |
| noobaroo | rrq, have you done this before? | 23:03 |
| rrq | used kernel parameter, yes, but not sinit.. just /bin/bash really | 23:04 |
| rrq | and I'm blissfully unaware with the debian+systemd initrd | 23:04 |
| noobaroo | http://ix.io/3VEu | 23:04 |
| rrq | with=of | 23:04 |
| noobaroo | if I put /bin/bash at bottom of rc.init I can get a working prompt. But I can't get getty to run, no login prompt or TTY switching | 23:06 |
| rrq | probably the initial mounts should be before starting udev (eudev) | 23:06 |
| noobaroo | You think that will make getty work? I can see all the /dev/tty#sin /dev, there are tons | 23:07 |
| noobaroo | /dev/tty0-dev/tty-some high number i dont remember | 23:08 |
| noobaroo | Thanks for your suggestions, super appreciated! | 23:08 |
| rrq | my getty start lines are like "/sbin/getty 115200 tty2" | 23:08 |
| rrq | the mount order would be primarily for /run and /tmp being set up before running udev | 23:09 |
| noobaroo | Alright, ill try to readjust order, and also revamp getty commands | 23:10 |
| noobaroo | in the meantime, I regressed a bit to get a working system. I had to reinstall systemd package, overwriting eudev. | 23:11 |
| noobaroo | When I tried launching Grub normally (no init= parameter) systemd failed to start udev and gave me a recovery prompt in which my keyboard did not work lol | 23:12 |
| noobaroo | I created a custom systemd service of eudev and masked udev, so i really am not sure what went wrong. With runlevel target being sysinit | 23:12 |
| alphalpha | Hi | 23:33 |
| fsmithred | hi | 23:36 |
Generated by irclog2html.py 2.17.0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!