libera/#devuan/ Friday, 2024-08-02

adhoc morning all02:59
golinuxEvening all. ;)03:02
* adhoc sips the first coffee of the morning.03:04
adhocWhat is news in terms of coming releases/changes?03:04
fsmithred423 packages can be upgraded. That's since 27July03:18
adhocI better go patch things, BBL03:40
onefangI need to reboot, also BBL.03:40
* adhoc needs to find a better way to WoL thirty ish machines, patch them and power most of them back down again...03:46
jmjloh testing04:24
jmjlI should've switched to daedalus, I was on chimaera04:25
gnarfacedaedalus is now current stable04:27
adhoc what is the current life expectancy of chimeara?04:36
braddHi. is there a way to make a 'persistant' network interface name, rather than the ethXX names.. devuan seems to be re-ordering my eth2 and eth3 interfaces04:45
gnarfaceyea, there's a way to do that... are they hotplug or something?05:05
gnarfaceusually it's not a problem for pci devices05:05
gnarfaceusually what's supposed to happen is udev should cache them in /etc/udev/rules.d/70-persistent-net.rules, keyed by MAC address05:06
gnarfaceoh, hmm... if you were using MAC address randomization maybe that could throw it off... not sure05:07
gnarfaceanyway, nothing will stop you from making a udev rule keyed by whatever you want that names them whatever you want. not sure if there's an easier way (maybe a module option or something? maybe a network-manager setting if you're using that...)05:08
Xenguyadhoc, Chimaera is good for a few years now05:09
gnarfacenormally it shouldn't be an issue unless they're usb devices05:09
gnarfaceusb devices just come up in the order they're plugged in, and behave notoriously unpredictably if plugged in at the same time or already plugged in from a previous boot05:10
rustyaxeusb ethernet devices are teh creation of the devil.. Mostly because they almost inevitably are realshrek chipsets inside :(05:17
braddok, no I've added a new nic to the system.. so maybe now (if I dont change anything), I can just use the ethXX device without fear of it changing on me?05:24
amarsh04On the /usrmerge front I tried to install base-files:amd64 13.3devuan1 -> 13.4devuan1 but it failed due to /bin -> /usr/bin and /sbin -> /usr/sbin symbolic links still present05:24
amarsh04removing those symbolic links caused booting to fail as the checking and mounting of root had the old paths hard-coded05:26
braddgnarface, I'm getting in dmesg -> "Error changing net interface name eth2 to eth1: File exists" (although everything seems to be working)05:31
adhocXenguy: thanks for the update.05:45
gnarfacebradd: find this file and just edit by hand then: ls -l /etc/udev/rules.d/*persistent-net*06:44
gnarfaceor, delete it and presumably it'll regenerate it correctly (probably a good idea to make a backup just in case)06:45
braddok, I'll give it a try06:48
braddgnarface: well it got rid of the warning, but it didnt regenerate that persistant file07:11
amarsh04updated the forum with my /usrmerge situation: https://dev1galaxy.org/viewtopic.php?pid=51466#p5146607:20
gnarfacebradd: that's weird... you sure you have udev or eudev actually installed? which release is this?07:35
gnarfaceif you've just recently upgraded it could have been removed accidentally07:38
braddhow do I tell? (uname -a gives debian 6.1.69-107:44
bradd(sources.list says its using daedalus)07:48
CueXXIIIamarsh04: how did it fail exactly? those symlinks should be there after usrmerge07:51
CueXXIIIamarsh04: or do you mean manually created symlinks from /bin/somefile -> /usr/bin/somefile? not sure if usrmerge can handle that situation07:55
gnarfacebradd: try "dpkg -l |grep udev"08:12
braddii  eudev                               3.2.12-4+deb12u1               amd64        /dev/ and hotplug management daemon08:12
braddii  libeudev1:amd64                     3.2.12-4+deb12u1               amd64        libeudev shared library08:12
gnarfaceno no, don't paste08:12
gnarfaceyea, looks installed though08:12
gnarfacehmm, weird that it's not working08:12
gnarfacehow about eth0? did it show up correctly at least?08:13
gnarfacemaybe that file doesn't actually get written right away, i'm not sure08:13
braddoh. well the networking has been working now, so maybe at some point I'll just generate the udev file manually08:14
braddi.e. with mac address mappings08:14
gnarfaceon mine it says it's generated by the /lib/udev/write_net_rules binary08:15
gnarfacewhich presumably is referenced by /lib/udev/rules.d/75-persistent-net-generator.rules (not sure the index numbers are static on those)08:15
gnarfacei've had problems before with those not getting updated right but not recently08:16
gnarface(the files in /lib/udev/ that is)08:16
braddodd, but after removing that perisitant file, there is nothing in that directory08:16
braddmaybe I should try a apt upgrade ?08:17
gnarfaceto be clear, do not remove the /lib/udev/rules.d/75-persistent-net-generator.rules file, just the /etc/udev/rules.d/70-persistent-net.rules file08:17
gnarfacei think you have the most recent udev, but if you're current and your /etc/apt/sources.list is correct, this shouldn't hurt anything: apt-get update && apt-get --no-install-recommends dist-upgrade08:18
braddthere was only the 70-* file.. no other rule files in that dir08:18
braddok, I'll give it a shot08:18
gnarfaceuh, well the only other auto-generated file that goes in there that i know of would be 70-persistent-cd.rules, which would only appear if you have an optical drive08:18
gnarfacebasically, the system's udev rules go in /lib/udev/rules.d, and /etc/udev/rules.d is for your own custom ones or auto-generated ones08:19
braddoh, i see08:19
gnarfacei don't recall any issues with it not getting created before... anything's possible though08:21
braddok. did the dist-upgrade. nothing in /etc/udev/rules.d08:23
gnarfacemake sure udev is running: ps aux |grep udev08:23
braddyep. /sbin/udevd --daemon08:23
gnarfacethen maybe uh... "/etc/init.d/eudev reload"08:24
gnarfacethough i can't imagine why that would work if it didn't work on startup... maybe if some other relevant log error turns up08:24
gnarfacethere is a newer kernel than that in the repo, but that one doesn't look very much older so i doubt it's the issue08:25
gnarfaceif some other error happened to be in the logs that might help though, at this point i'm out of ideas08:25
gnarfacejust by way of sanity check, what's the md5sum of your /lib/udev/rules.d/75-persistent-net-generator.rules file? i've got 6578220eeaa8e957de1464d46a34c3f7 here08:26
braddok. I'll run it like this for now.. maybe tomorrow I'll make the rules.d file08:26
gnarfacethis is a pure daedalus system? no other stuff mixed in? the only other thing i could really do is sanity check your /etc/apt/sources.list08:27
braddsame md508:27
gnarfaceif you paste it at paste.debian.net i'll look08:27
gnarfaceoh, hmm... just thought of one more thing but it's a long shot: df -h08:28
gnarfacemake sure the partition /etc is on isn't full08:28
gnarfacethough i'd expect udev to complain about that i don't actually know...08:28
bradd/dev/md0 (/) is at 80% used08:29
gnarfacehmm, that's probably not the issue then08:29
gnarfacesorry, out of ideas. let me know if you figure it out, and stick around in case someone else has an idea.08:30
braddok, thats for helping08:30
gnarfacethere must be something obvious that i'm forgetting, i'd think... usually the problem isn't with that file not generating, usually the complaint is about stopping it from changing08:31
AlexLikeRockadios gnarface o/08:40
amarsh04CUEXXIII "The base-files package cannot be installed because /bin is a symbolic link and not pointing at usr/bin exactly.10:54
CueXXIIIamarsh04: ls -ld /bin11:14
CueXXIIIit should point to "usr/bin", not "/usr/bin" nor "../usr/bin"11:14
amarsh04ah, thanks11:17
AlexLikeRocko/23:30

Generated by irclog2html.py 2.17.0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!