| yanmaani | I have high RAM usage, and sluggish performance, despite nearly nothing using RAM. Is it possible that zram might have created a "loop"? | 01:51 |
|---|---|---|
| tuxd3v | many thanks for the Devuan beowulf netinstall image :) | 01:59 |
| tuxd3v | I decided to purge packages and files.. and that should ring a bell automatically on our heads, but since I was doing several things at same time... it went south | 01:59 |
| tuxd3v | I left 1 kernel only | 01:59 |
| tuxd3v | and forgot to create a new initramfs.. | 02:00 |
| tuxd3v | later inside a shell I issued a 'reboot' thinking that I was in a guest machine... game over! | 02:00 |
| tuxd3v | thanks to the fact that I had a net install for beowulf around, I was able to start in rescue mode, chroot to the device I wanted, check what was wrong and finally create a new initramfs for the only existing kernel.. | 02:01 |
| tuxd3v | So long story short, Many thanks to the devuan community for the netinstall that I had in my pendrive :) | 02:02 |
| aloo_shu | (most) any live linux with root and chroot would do | 02:03 |
| tuxd3v | the system is up and kicking! | 02:03 |
| tuxd3v | aloo_shu, yes, many will, but I use devuan, and also later I discovered that the devuan version doesn't even need the chroot requirement, and you can simply choose what disk to drop in.. | 02:05 |
| tuxd3v | very helpful! | 02:05 |
| tuxd3v | it will do the chroot for you.. its nice | 02:06 |
| aloo_shu | knowing to use chroot is imo at least as or more useful as knowing vm's, docker | 02:07 |
| aloo_shu | but if you're stuck, and a tool helps you, that's also nice | 02:08 |
| tuxd3v | the concept is almost the same , the things is, containers also bring you network isolation and stuff, things that a shroot doesn't | 02:08 |
| tuxd3v | At least is the idea I have | 02:08 |
| tuxd3v | yeah, first time I went with a chroot, not knowing the simplicity that the menu provides.. | 02:09 |
| aloo_shu | there's quite some control in what you do, and do not bind-mount over into the chroot | 02:09 |
| tuxd3v | it went south because I created garbage.. | 02:09 |
| tuxd3v | I created a intiramfs for the kernel the live image was running :/ | 02:09 |
| djph | containers are niceish (AIUI) for spin up something super small and fast but ... not ... production (obviously, I could be wrong; given the prevalence of k8s, docker, etc) | 02:10 |
| tuxd3v | second time I went in discovery mode , and found that it provides you with the option to drop in any disk availlable | 02:10 |
| djph | I can't google today apparently -- chimaera is the next release on the roadmap, right? | 02:10 |
| tuxd3v | djph, yes I believe so :) | 02:11 |
| Tenkawa | djph: k8s,, docker, etc "are" containers.. just a different type | 02:12 |
| tuxd3v | ho ofcouse second time I created a initramfs for the single kernel availlable on the system :) | 02:12 |
| Tenkawa | they are still running under a single running kernel | 02:12 |
| Tenkawa | unlike virtualization | 02:12 |
| djph | Tenkawa: yeh; the little I know I equate them to different implementations of the same idea, ala vmware/vbox/kvm (probably wrong, but I'm bad with it in general) | 02:13 |
| Tenkawa | ie vmware, hyperv, etc | 02:13 |
| djph | err vbox/vmware/kvm all being implementations of "Virtual Machines" | 02:13 |
| Tenkawa | yeah thats kernel virtualization | 02:13 |
| tuxd3v | Tenkawa, indeed some sort of chroot, but with better isolation..the downside is that you need to have inside of it all tools that the programs need, replicating a lot of libraries | 02:14 |
| tuxd3v | but with chroot is the same regarding the replication of libraries | 02:14 |
| Tenkawa | tuxd3v: yeah containers can be super fast,, but they do need a lot of infrastructure and setup | 02:14 |
| tuxd3v | I understand that containers are the future for a lot of applications, for for a big amount of core aplications, containers are not the solution.. | 02:15 |
| tuxd3v | Tenkawa, agree | 02:15 |
| Tenkawa | chroot suffers from memory address limitations though.. thats what brought about part of this originally I think | 02:15 |
| aloo_shu | bind | 02:15 |
| aloo_shu | mount | 02:15 |
| Tenkawa | bind mounts have severe limitations | 02:16 |
| tuxd3v | network is not isolated with chroot | 02:16 |
| djph | Tenkawa: good news, 64-bits can address a hilariously large address space | 02:16 |
| Tenkawa | and are restrictive on the outer layers of the bind | 02:16 |
| aloo_shu | yeah that was not in response to memory | 02:16 |
| djph | (I know, there are other concerns ... ) | 02:17 |
| Tenkawa | aloo_shu: yeah the memory comment was for tuxd3v | 02:17 |
| aloo_shu | but, what to learn first? I'd give chroot preference over more managed forms of containerizations, just like learning written math before using a pocket calculator; you'll later understand the 'why' of things much better | 02:19 |
| tuxd3v | aloo_shu, agree | 02:31 |
| Centurion_Dan | Hi | 03:03 |
| Centurion_Dan | I turned on my other laptop the other day and found nm-applet was broken. It turns out the issue is that no elogind session is being started at login.... running slim... any thoughts on what I might have broken? It was working fine a few weeks ago... | 03:05 |
| Centurion_Dan | fsmithred? | 03:05 |
| Xenguy | Beowulf, or ...? | 03:06 |
| fsmithred | Centurion_Dan, how long has it been since the laptop was updated? | 03:06 |
| Centurion_Dan | running beowulf... | 03:07 |
| fsmithred | what version of eudev? | 03:07 |
| fsmithred | no | 03:07 |
| fsmithred | elogind | 03:07 |
| fsmithred | I'm using n-m in beowulf and chimaera and it's working fine. | 03:08 |
| Centurion_Dan | looks like I tried to install smbclient March 15 | 03:08 |
| Centurion_Dan | eudev v3.2.7-6 | 03:09 |
| fsmithred | 3.2.9-8~beowulf1 | 03:09 |
| fsmithred | that shouldn't be the problem | 03:09 |
| fsmithred | unless... | 03:10 |
| fsmithred | are all your modules getting loaded? | 03:10 |
| Centurion_Dan | fsmithred: I have no reason to think they're not.... | 03:12 |
| Centurion_Dan | if I go 'logincti' I get no login session... | 03:12 |
| fsmithred | did you get one before? | 03:13 |
| fsmithred | I think I'm using lightdm. Definitely not slim. | 03:15 |
| Centurion_Dan | I assume so... everything worked previously... | 03:17 |
| gnarface | yanmaani: i dunno but i think it is more likely you have a memory leak in your video drivers | 03:17 |
| Centurion_Dan | fsmithred: I'm still using slim but looks like slim is trying to use console kit instead of elogind... | 03:28 |
| fsmithred | you have all the right libs for elogind? | 03:34 |
| fsmithred | and not for consolekit | 03:34 |
| fsmithred | pam-auth-update | 03:35 |
| fsmithred | Unix and elogind should be checked | 03:36 |
| Centurion_Dan | fsmithred that is what I have.. | 04:03 |
| Centurion_Dan | I do see an error in the logs: "Failed to create cgroup 1: No such file or directory" | 04:07 |
| Centurion_Dan | fsmithred | 04:26 |
| Centurion_Dan | was that an irc wide kick?? | 04:27 |
| fsmithred | no, I'm still connected | 04:27 |
| fsmithred | I don't know what to make of the error message | 04:27 |
| Centurion_Dan | also in auth log I'm getting "dbus-update-activiation-environment: systemd --user not found, ignoring --systemd argument. | 04:29 |
| Centurion_Dan | " | 04:29 |
| fsmithred | you're sure you have all the right packages? libpolkit stuff for elogind and libpam-elogind | 04:34 |
| fsmithred | ? | 04:34 |
| fsmithred | that's all I can think of | 04:35 |
| Centurion_Dan | yes, I checked that.... | 04:36 |
| crashoverride | fsmithred: sorry for the commotion on #devuan-offtopic | 04:49 |
| Xenguy | crashoverride, I should say so ; -) | 04:55 |
| crashoverride | Xenguy: to be fair, I'm sorry it had to be on a #devuan related chan, not for what I said | 04:55 |
| Xenguy | It'll probably be just fine | 04:56 |
| Xenguy | There may be better places to have PM conversations | 04:56 |
| Xenguy | I mean if you guys want to duke it out, go private and blast away : -) | 04:56 |
| crashoverride | Xenguy: answered on #devuan-offtopic to minimize the noise here. | 04:57 |
| Xenguy | Oh right, wrong channel, oopsies | 04:57 |
| crashoverride | no wuckers. | 04:57 |
| golinux | I have no interest in duking anything out. I just don't want to waste my time. | 04:58 |
| aloo_shu | qed | 05:37 |
| fling | What package for ast xorg driver? | 10:23 |
| fling | The one for aspeed cards | 10:23 |
| xinomilo | probably : xserver-xorg-video-ast | 10:30 |
| ham5urg | I just tried unstable and wanted to install openssh-server. But it invokes a lot of dependencies like x11-common, libavahi..., etc. Is this common? | 15:35 |
| xinomilo | apt install openssh-server --no-install-recommends | 15:35 |
| ham5urg | ahh thank you xinomilo | 15:36 |
| ham5urg | In chimaera I have done "apt autoremove --purge libsystemd0" which also removed rsyslogd. Is this behavior due to the unfinished status of chimaera? | 15:49 |
| ham5urg | Is libsystemd0 some kind of dummy package? | 15:50 |
| fsmithred | no, libsystemd0 is a real package. You can replace it with libelogind0 | 15:50 |
| fsmithred | lsd0 even gets pulled in with a debootstrap install. I don't recall what depends on it at that level. | 15:51 |
| ham5urg | I removed libsystemd0 and with it, it removed rsyslog, but "apt install rsyslogd" brought it back without lsd0 | 15:53 |
| xinomilo | migrating from debian probably, so that's normal | 15:56 |
| xinomilo | rsyslog in debian depends on libsystemd0, rsyslog from devuan doesn't | 15:57 |
| ham5urg | yes | 16:00 |
| rwp | The presence of libsystemd0 is expected in Devuan and is not the same as running systemd as pid 1. Please don't freak out just because it is present. | 17:44 |
| DHE | yes it's necessary to allow unmodified debian packages to run on devuan. it's technically a good thing | 18:33 |
| DHE | (though I plan to try fixing it a bit on my system) | 18:33 |
| mason | amesser's built libsystemd0-free apt. Not sure if it's publically available. Might be worth poking around the repositories. | 18:35 |
| GyrosGeier | libsystemd0 is a piece of code that tells apps that init is not systemd | 19:14 |
| GyrosGeier | for applications that switch behaviour at runtime this means we can get by without patching packages | 19:16 |
| GyrosGeier | I mean, when I write stuff, I also make explicit systemd integration these days | 19:16 |
| brocashelm | yeah, i have rsyslog and libelogind0 instead of libsystemd0 | 19:17 |
| GyrosGeier | I mean, I have handling code to maintain multiple sockets in a select() loop, I don't care where the sockets come from | 19:17 |
| GyrosGeier | the boilerplate code I need for systemd socket activation with IPv6 support is 90% the same that I need for a standalone daemon with IPv6 support | 19:18 |
| GyrosGeier | so explicit systemd support is ten extra lines of code, not a bad price for having the same binary everywhere | 19:19 |
| DHE | my argument is that systemd seems to be trying to make itself into a dependency of other applications. that you have to ask "is this systemd?" in the first place is already a bad sign. | 19:20 |
| walex | DHE: 'libsystemd0' is not a "bad" dependency | 19:33 |
| walex | DHE: D-Bus is a bad dependency. | 19:33 |
| walex | I have just written a few days ago two short but not too short explanations of the rationale behind 'systemd' and why it is a bad solution to a real problem: | 19:35 |
| walex | http://www.sabi.co.uk/blog/21-one.html?210415#210415 | 19:35 |
| walex | http://www.sabi.co.uk/blog/21-one.html?210416#210416 | 19:35 |
| DHE | walex: "I need to behave differently if systemd is running" is bad. that's what I'm getting at. code quality of individual projects is a different problem | 19:43 |
| walex | DHE: but what's the problem with that? If the impact is small, and it is small, fine. As long as there is no dependency on D-Bus and 'systemd' itself. it is sort of like "I need to choose a different code path if IPv6 is available". | 19:44 |
| * walex remembers the "all the world has a VAX" story, not quite the same though | 19:45 | |
| walex | DHE: the story behind Devuan as I have seen it is not so much a rejection of 'systemd', but a rejection of making everything depend *just* on 'systemd'. | 19:46 |
| djph | walex: it's kind of both, as i understand it | 19:47 |
| walex | Now 'systemd' solves (badly) a very real problem, so I don't feel that projects should reject the extra functionality that 'systemd' offers, but also that for people who do not need it, there should be the option to do without. Again, a bit like IPv4/IPv6. That requires a bit of code to handle the extra functionality. | 19:48 |
| mason | walex: We shouldn't require an additional libc for everything, which is effectively what libsystemd0 wants to be. | 19:48 |
| walex | djph: ssssssh :-) The official rationale is "init freedom", not "systemd is also evil :-)" | 19:49 |
| DHE | but they do. systemd decided that it's going to kill programs when a user logs out, and now screen/tmux/others need to register themselves with systemd-specific code. normally restarting libvirt would destroy all your virtual machines so libvirt needs to register all your VMs with systemd | 19:49 |
| walex | mason: DHE: the really big problem is that 'systemd' realls does solve a big issue, and the even bigger problem is that it does so quite badly, but not so badly that even people who want that functionality would reject it. | 19:50 |
| djph | walex: got called away -- no I more meant that it's a bit of "there's possibly a need to replace sysvinit ... but this one's looking like it's not the answer" | 19:51 |
| walex | DHE: 'systemd' is indeed tentacular, kind like the "vampire squid" of framework (to paraphrase Matt Taibbi) | 19:52 |
| onefang | Take it to #devuan-offtopic, leave this channel for support. | 19:53 |
| walex | right | 19:55 |
| walex | if anybody wants to continue I will look at #devuan-offtopic but the two links above try to explain my view... | 19:56 |
| brocashelm | https://blog.desdelinux.net/en/list-free-systemd-distributions - this article lists some non-systemd distros of gnu/linux; the author personally recommends devuan to anyone who isn't very skilled with gnu/linux usage | 21:09 |
| brocashelm | i think devuan being "easy" to install/use for a novice is a good thing | 21:09 |
| brocashelm | what i think: isn't that part of what was so special about debian for the longest time? to take all that baggage from compiling packages by installing them and just getting straight to work? you can't easily say that about gentoo, arch, slackware, red hat/fedora, etc. | 21:11 |
| Walex | brocashelm: most of them do allow "just install the package" thing, the Debian/Devuan thing is that releases are stable for years and the package selection is particularly huge and well curated. | 21:22 |
| Walex | among the "well curated" aspect is good metadata dependencies, which tend to be more reliable for Debian than most other distros. | 21:23 |
| Walex | (e.g. Slackware does not really do dependencies) | 21:23 |
| rwp | In a pristine install of Beowulf the ethernet device is eth0. /proc/cmdline shows no net.ifnames setting. /etc/udev/rules.d/ is empty. | 21:46 |
| rwp | What is the Devuan strategy for ethernet device names? Is there a document? | 21:46 |
| mason | rwp: I think the strategy is traditional naming. | 21:49 |
| rwp | But traditionally there is a udev generator that would drop a file /etc/udev/rules.d/70-persistent-net.rules to cause persistent naming. | 21:49 |
| rwp | The /lib/udev/write_net_rules script is used to generate that file. It's present. But 70-persistent-net.rules is not. | 21:50 |
| rwp | And so I am confused about how multiple devices will be assigned. | 21:50 |
| Tenkawa | rwp: persistent naming came about with systemd-udev didnt it? | 21:52 |
| Tenkawa | if so.. devuan isnt going to have it | 21:52 |
| rwp | Well... The name "persistent" has been used by multiple conflicting things. 70-persistent-net.rules is pre-systemd by years for example. | 21:54 |
| Tenkawa | hmm doesnt seem to have any link to systemd | 21:54 |
| Tenkawa | yeah | 21:54 |
| rwp | Right. It doesn't. Not really. (However don't look too closely at the original authorship.) | 21:55 |
| Tenkawa | but its been changed like 5 times | 21:55 |
| Tenkawa | I'm reading the implementation history… quite messy | 21:55 |
| rwp | People keeping thinking they have the final solution. Again and again they have the final solution. | 21:55 |
| fsmithred | "predictable" names | 21:55 |
| fsmithred | that's what they call it | 21:55 |
| rwp | Oh, yes, that's right. Predictable (which no one can predict) and persistent. I remember now. | 21:56 |
| fsmithred | you can predict what it will be named if you open the box to see what slot it's in | 21:56 |
| fsmithred | if you want that in devuan, boot with net.ifnames=1 | 21:56 |
| rwp | On-board ethernet device. Not a PCIe NIC. | 21:56 |
| Tenkawa | yeah predictable.. not persistant duh | 21:56 |
| Tenkawa | I'm even reading it and still typing it wrong | 21:56 |
| rwp | I am happy with the traditional names. And my test kit right now has only one device. But the production unit has two ethernet devices. So I am needing to know how it decides. | 21:57 |
| fsmithred | one place the new names are nice is with a live-usb that has persistence. You get the same name no matter what computer you boot with. | 21:57 |
| Tenkawa | yeah I always just turn it off and go back to old style no matter what I use | 21:57 |
| fsmithred | some devices get the mac address in the name, even in devuan. e.g. usb wifi dongle | 21:58 |
| tuxd3v | fsmithred, last eudev was a nice update when using net.ifnames=0, a joy to use :) | 22:00 |
| fsmithred | why did you need to use that? Old names are the default. | 22:01 |
| rwp | I have two cases I am interested on. The one in my hand at this moment is going to be use USB dongle. | 22:01 |
| rwp | By another has two on-board ethernet devices. I'll deal with it on another day. | 22:01 |
| tuxd3v | indeed, just to remember that it exists and to emphasise that :) | 22:02 |
| rwp | I plug in the USB just now and yes I get the new name for the USB device. So that will always be that name and I understand the strategy to deal with. | 22:02 |
| rwp | And since the on-board is the only one I can ignore as there is no possibility for an eth1 device. | 22:02 |
| rwp | I am good to go for the rest of the afternoon. And then can push figuring out the dual-nic motherboard case to another day. :-) | 22:03 |
| Walex | rwp: there is simply no good and universal way to name hot-pluggable/autodiscoverable devices, and in way of principle nearly all PCIe/USB/SATA/... devices are like that, so choose your poison. | 22:04 |
| rwp | Walex, I was simply trying to understand the Devuan strategy. No complaints in any of my statements. Other than perhaps asking where the strategy was documented. | 22:04 |
| rwp | That's where I am looking forward to a wiki. Get these corner case things written down somewhere. | 22:05 |
| Walex | there are three common schemes: by sequence of discovery (eth0, eth1, sda, sdb, ...) by bus position (enp2s0, ...), by unique id (/dev/dsk/by-label/, ...). The Devuan default is usually by sequence of discovery for statically plugged devices, but as "fsmithred" says hotpluggables of some times do "by unique id". | 22:07 |
| Walex | storage as most people here knows actually get *all three* in various flavors under '/dev/disk/'. | 22:08 |
| Walex | Greg Kroah Hartman is the perpetrator of the 'systemd' of devices, 'udev' (now of course integrated with 'systemd' :-/) | 22:10 |
| rwp | Just noting that if Devuan is going with order of discovery then that is not the same as has been the traditional Debian strategy. | 22:15 |
| rwp | But there may not be much choice since the udev rule generator though present is deprecated upstream. | 22:15 |
| tuxd3v | University of Minesota USA prohibited from doing commits to the Linux kernel over very well fundamented suspects that they were introducing vulnerabilities in the kernel, to be expoited later.. | 22:27 |
| tuxd3v | https://github.com/QiushiWu/QiushiWu.github.io/blob/main/papers/OpenSourceInsecurity.pdf | 22:27 |
| DashiePie | tuxd3v: I'm not even surprised anymore, honestly | 22:37 |
| tuxd3v | DashiePie, me neither.. unfortunately | 22:38 |
| rwp | It's why we can't have nice things. :-( | 22:41 |
| tuxd3v | seems that they were introducing code that aparently does nothing but could be exploited in the future.. its bad.. | 22:44 |
| Walex | I would estimate that around 5-10% of all sw developers at "major" corps are paid by various "services" to introduce cleverly disguised bugs in their code. | 23:00 |
| Walex | that is a wild guess, but given how cheap and easy it is, I would think it is extremely common. | 23:01 |
Generated by irclog2html.py 2.17.0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!