08:03:14 <jonadab> rrq: Yeah, but dhclient should only run if something in /etc/networking/interfaces says to use DHCP. Which it doesn't.
08:04:09 <jonadab> But that doesn't seem to matter any more; on modern Linux systems, you're not allowed to specify your own network config, you have to let the software screw it up for you automatically.
08:05:58 <rrq> yes, the "desktop environments" usuallly include some gui software for network fiddling, and those typically include "helful" daemons
08:08:45 <rrq> mostly they are via "recommends" though so can (at least) be removed
08:15:56 <jonadab> Yes, once you track down which thing is causing the problem.
08:17:51 <rrq> true.. though in any case, all of them use dhclient, and that has its own config, where it's told whether or not to take notice of the DHCP provided gateway
08:24:49 <rrq> .. kind of same "problem" still; that the default setting isn't fully correct for your use case
08:27:06 <rrq> for me it's totally wrong :) because I have multiple "cables" set up via dhcp, but only one of them should be default gateway
14:29:06 <unixbsd> it works now, ps2 emu. it works only with archlinux at best, because of the rolling feature of it. it has newer xorg and newer kernel
15:47:10 <brocashelm> unixbsd: i use devuan ceres (current kernel is 220.127.116.11). what was your issue from earlier? not being able to run games on pcsx2?
15:47:54 <brocashelm> unixbsd: pcsx2 is installed and i can run final fantasy x just fine on i7-3770 cpu with radeon rx 560 gpu
16:07:35 <unixbsd> brocashelm: good to know, thank you, I will get a try ceres with the same kernel soo or later. thx for info
16:08:10 <unixbsd> brocashelm: here cheap gpu... Graphics card type, Vega 8. Motherboard, Gigabyte B450M S2H. CPU series, AMD Ryzen™ 3. Processor/type, 3200G. Pc kit from renkforce
16:43:08 <brocashelm> unixbsd: cool, i'm actually in between an upgrade as i try to get this motherboard for the amd ryzen 5 3600 build to be functional (i think i plugged in wrong components; first time building a pc ever). it will be my daily driver and refracta will run even smoother on it for sure. i have other intel systems that i'm keeping because they work just fine, but a luxury upgrade so i can get things done quicker (such as compiling and encoding)
16:44:23 <brocashelm> unixbsd: the moment i switched to ceres last july, i never went back to beowulf or ascii. it's stable enough for me and it helps to have hands-on experience troubleshooting gnu/linux systems. the learning curve is totally worth it IMO
19:33:40 <ShorTie> ceres still valid ??
19:33:54 <ShorTie> thought it twas chimaera now
19:35:10 <brocashelm> ceres = unstable
19:35:30 <brocashelm> so it will never transfer to another version
19:35:59 <brocashelm> chimaera was/is testing, whereas daedalus is next in line for that
19:36:37 <ShorTie> oh, Ok
19:46:05 <unixbsd> brocashelm: can you handle the enp8s0 insanity?
19:46:52 <unixbsd> brocashelm: If it differs too much to slack, I cannot gettin' used to it. enp..* and systemd is no way, just for gaming only.
19:49:35 <unixbsd> ShorTie: could we have a page on HOME devuan.org to list the codenames: i cannot follow up. ceres chimaera bulleye sid?? is there sid in devuan, ascii if it was debian... modded..
19:50:29 <unixbsd> sudo - for fdisk is a really systemd thing. you can suppress it.
20:35:28 <brocashelm> unixbsd: i think i always get eth0 by default
21:11:53 <fsmithred> eudev uses the old interface names by default. If you're getting the new names, something is wrong. Did you do an incomplete migration from debian?
21:13:18 <fsmithred> unixbsd, on the front page of devuan.org, right under where it says "Devuan Releases" click on the link that says Devuan Releases and you'll get to this page: https://www.devuan.org/os/releases
21:14:56 <brocashelm> i installed refracta directly
21:15:03 <brocashelm> so no problems here
21:15:21 <fsmithred> same here :)
21:15:29 <brocashelm> excellent
21:15:39 <fsmithred> actually, that's not true
21:16:05 <fsmithred> I installed beowulf before it was released
21:16:19 <fsmithred> and made most of the changes that get made for refracta
---------- 2021-06-06 ----------
00:44:19 <ShorTie> how long should update-initramfs: Generating /boot/initrd.img-5.10.0-7-amd64 take ??
00:44:31 <ShorTie> mine seems hung .. :/~
00:54:24 <rm> ShorTie, if you check in "top", does it use CPU?
00:54:37 <rm> load from mkinitramfs or gzip
01:30:55 <huria4> I heard some drama online that this project is bankrupt trying to keep catch-up with debian. Is there any truth to that statement?
02:34:39 <gnarface> ShorTie: if they changed the default to xz compression it could take much longer than before, especially on older machines
02:34:56 <gnarface> there should be a way to change it back to gzip or bz2 though
02:35:40 <jonadab> Yes, they all it a "default" because it's what happens if you default on your option, i.e., if you don't tell the software what setting you actually want.
02:40:54 <gnarface> well, the issue at hand i think is that debian chnaged it for existing installs without any care as to your previous setting and whether it's actually sane to ask a 1-core 32-bit machine to xz decompress a 25MB file at boot time
02:59:07 <ShorTie> this is a fresh debootstrap, so there reall is no initrd.img-5.10.0-7-amd64
02:59:14 <ShorTie> to undo
03:08:39 <gnarface> well, yea, if it was a fresh debootstrap it wouldn't even have a kernel package installed by default
03:08:45 <gnarface> you'd have to have installed it separately
03:26:08 <ShorTie> how we do that if i can ask ??
03:26:30 <ShorTie> install linux-base, but it is there already
03:26:53 <gnarface> run these commands:
03:26:57 <gnarface> apt-cache search ^linux-image
03:27:03 <gnarface> apt-cache search ^linux-headers
03:27:11 <gnarface> you need to pick some out of the list
03:27:36 <gnarface> well, you might not need the headers, but you do if you're using nvidia official binary drivers or anything else that relies on dkms
03:28:26 <gnarface> if you're updated, this might work: apt-get install linux-image-`uname -r`
03:29:02 <gnarface> but if you run the search commands it shouldn't be too hard to pick the right one
03:29:04 <gnarface> ask me if you're not sure
03:29:39 <gnarface> (kernels with "-rt" in the name are "realtime" kernels and contrary to popular belief, those are for audio studio production, not gaming)
03:30:19 <gnarface> (if you want a gaming kernel, just rebuild the stock default one with CONFIG_HZ=1000
03:33:19 <gnarface> i assume if you're installing a kernel in a debootstrapped chroot to turn it into a bootable system, you'll also need to know to run update-grub after installing the kernel
03:45:03 <ShorTie> ya, update-grub is always a problem for me, can't find device or sumfin like that
03:46:12 <gnarface> sometimes you have to tell it
03:46:26 <gnarface> sometimes you have to use grub-install instead
03:46:56 <gnarface> and sometimes if you've got a previous grub install on another physical disk it still trips and faceplants on reboot if you don't manually fix it up
03:47:23 <gnarface> shit happens
03:47:43 <ShorTie> oh i know that for sure
03:48:08 <gnarface> the thing that saves the day for me when all hope is lost: try lilo instead :)
03:48:39 <gnarface> i started with lilo so the behavior is much more familiar to me, but also it is a lot smaller and the config syntax is much simpler
03:48:40 <ShorTie> So, So, Sorry, No lilo here
03:50:20 <onefang> rEFInd is good.
03:51:42 <Walex2> gnarface: onefang: the current typical GNU/Linux boot sequence is: EFI->GRUB->initramfs->"root" fs
03:52:42 <Walex2> where EFI is an OS with a shell, GRUB is an OS with a shell, 'initramfs' is an OS (image) with a shell, "root" is an OS (image) with a shell.
03:53:07 <onefang> I know that. rEFInd replaces GRUB. Obviously it's an EFI thing.
03:59:38 <Walex2> onefang: I was pointing out that it is a crazy situation, if anything rEFInd improved it a bit as it is not a full OS like GRUB, but an application for the EFI OS.
04:01:05 * Walex2 uses JFS for the '/boot/'/"root" filesystem so cannot use rEFInd
04:01:15 <onefang> The major improvement from my point of view is no need to update / reinstall it after updating your kernel.
04:02:25 <gnarface> well the kernel packages are supposed to take care of that when it is relevant...
04:02:35 <Walex2> onefang: that is a side effect of it using the EFI OS to probe all disks on the system, doing at boot time what 'update-grub2' does statically
04:03:51 <Walex2> onefang: that is good but if one has many disks, but then eEFInd seems targeted at laptops and desktops which usually have few storage devices and partitions.
04:04:37 <plasma41> Walex2: Why JFS?
04:04:41 <Walex2> a rarely used option is to use the EFI partition itself as '/boot'
04:05:42 <Walex2> plasma41: because JFS is the "best" traditional filesystem, more stable, simple and with better or equal performance (not merely speed) as others.
04:07:04 <Walex2> plasma41: http://www.sabi.co.uk/blog/21-one.html?210123#210123
04:08:07 <Walex2> plasma41: http://www.sabi.co.uk/blog/17-one.html?170302#170302
04:09:31 <Walex2> plasma41: http://www.sabi.co.uk/blog/16-two.html?161217#161217
04:11:08 * Walex2 thinks that if only JFS had been adopted twenty years ago as the default Linux filesystem instead of 'ext3' by now there would be world peace, no COVID, faster GDP growth and better scifi movies
04:14:16 <plasma41> I see
04:15:06 <ShorTie> top says cpio is doiing sumfin
04:38:44 <Xenguy> onefang, First time I've heard tell of 'rEFInd', looks interesting
04:51:18 <Walex2> Xenguy: it is indeed pretty nice. But again, for laptops/desktops
04:52:11 <Walex2> eventually I will explore the option of just using the EFI partition as '/boot', and boot the Linux kernel directly from EFI.
04:53:06 <Xenguy> Walex2, Laptops are pretty much my use case nowadays...
04:53:44 <Xenguy> True to form I have simply avoided all contact with EFI thus far, disabling it in the BIOS, which seems to have worked thus far
04:57:52 <Walex2> Xenguy: I have also disabled EFI boot for a long time, because early implementations were buggy and so was WEFI setup in Linux. But I see the writing on the wall, in particular as many recent laptops can only do EFI boots from internal devices (most can still do MBR boots from external ones).
04:58:38 * Walex2 is reminded that he really needs to post his recent discovery of 'grub.cfg' in the EFI partition...
07:03:29 <xrogaan> So I noticed on Chimaera, with xfce and elogind, xscreensaver isn't responsive when resuming from hibernation. I have to wait some 20 seconds before it prompts me with the unlock screen.
07:17:19 <Walex2> xrogaan: that looks like some DNS timeout...
07:18:43 <xrogaan> why would it make requests?
07:19:57 <Walex2> xrogaan: is that system internet connected?
07:20:57 <Walex2> xrogaan: it can make requests for a million reasons, e.g. to resolver the system name and or to connect to a Kerberos server etc. etc. depending on what else is configured.
07:21:16 <xrogaan> alright, but what does?
07:21:37 <Walex2> xrogaan: a first check would be 'grep $(uname -n) /etc/hosts'
07:22:05 <xrogaan> that's my local hosts
07:22:55 <Walex2> xrogaan: it is just just a guess. You can get quite y bit of info with 'xscreensaver -verbose'
07:23:08 <Walex2> xrogaan: what does that command say?
07:24:42 <xrogaan> that I have to kill the one already running?
07:24:48 <Walex2> xrogaan: 'elogind --verbose'
07:25:19 <Walex2> xrogaan: what does the 'grep' say? Does it return a plausible line?
07:25:49 <xrogaan> there is no elogind
07:25:50 <Walex2> xrogaan: for 'xscreensaver' yes you have to kill the one already running, or start a new X session on another console
07:26:15 <xrogaan> there are just loopbacks addresses in my hosts files
07:26:17 <Walex2> xrogaan: you wrote above " with xfce and elogind, xscreensaver"
07:26:33 <xrogaan> yes, 'elogind' doesn't exists as a software
07:26:53 <xrogaan> there is 'loginctl'
07:27:03 <xrogaan> and elogind-inhibit
07:27:11 <Walex2> xrogaan: also hibernation is know to cause issues, and in particular to networking.
07:32:33 <xrogaan> xscreensaver-systemd: 01:31:11: uninhibited by "My SDL application" with cookie 40CD9813
07:32:38 <xrogaan> that's kind of weird
07:33:37 <xrogaan> I'd assume the xscreensaver-systemd is forcing xscreensaver to not "restore" after resume.
07:34:14 <xrogaan> It has 1 minutes intervals between the xscreensaver-systemd: 01:32:12: exec: xscreensaver-command -verbose -deactivate
07:41:08 <xrogaan> I believe that comes from the steam client though
07:57:03 <xrogaan> I disabled xfce's "lock screen when hibernate".
07:57:19 <xrogaan> It might be xfce that's badly configured and doesn't know how to unlock.