libera/#devuan/ Monday, 2024-08-12

freaxehi solved the problem earlier with devuan not booting on a ryzen 7 2700 system, turned out to be an nvidia graphics card holding up the boot process. i swapped that out with an ati rx580 card and it works fine now04:12
freaxehthe nvidia graphics card in question is a 103004:13
gnarfacecool04:13
gnarfaceweird that it would hang, but maybe it was hanging at launching the graphical login?04:13
gnarfacesome models might do that if you're using the nouveau drivers04:13
freaxehno i didn't install a graphical login, just ssh server and base packages04:13
freaxehthis is a file server not a workstation04:14
gnarfaceoh, weird that it would matter then04:14
freaxehyes04:14
gnarfacehmm, i wonder if putting "nomodeset" in the kernel command-line parameters would have worked04:14
freaxehprobably04:14
gnarfacemaybe it was booting successfully and only the console was going blank?04:14
gnarfacethat's also a possible issue with some driver/model combos04:15
gnarfacewell, worth trying if you want to be sure, but you're probably better off with the rx580 either way04:15
freaxehnot in a file server, lol, i'll buy another amd card to put in there.04:16
freaxehbetter than buying another motherboard that wont solve the issue04:16
gnarfaceindeed04:17
freaxehanyway just wanted to let you guys know, time to get to work on reassembling this system04:18
freaxehmy devuan box thinks its 201705:47
freaxehcan someone whos well versed with "date" spit out the correct command to set it05:48
freaxehmy bios doesn't have the option to set the date05:48
fluffywolfapt-get install ntpdate?  :)05:48
freaxehit thinks the repositories are out of date05:48
freaxehi tried apt update earlier05:48
freaxehE: Release file for http://deb.devuan.org/merged/dists/daedalus-updates/InRelease is not valid yet (invalid for another 2780d 2h 56min 6s). Updates for this repository will not be applied.05:49
fluffywolfdate -s "Sun Aug 11 08:49:05 PM PDT 2024"05:49
freaxehapt install ntpdate worked05:49
freaxehcheers05:49
freaxehall fixed :)05:50
drizzthello !08:20
drizztback with the devuan upgrade problem on aarch64 (arm64)08:21
gnarfacefyi there's also #devuan-arm, though it's even slower over there...08:22
drizztI strongly think that the problem comes from some programs segfaulting08:22
drizztbefore the critical part of the update I still can install other packages, but I already have libc updated, and some programs already segfault08:24
drizztxz, vim08:25
drizztI'll check #devuan-arm08:28
eyalrozbash completion is acting up on Excalibur...11:22
eyalrozhttps://unix.stackexchange.com/q/781758/3486811:22
freaxehis it ok if i idle in here? i'm eager to learn more about devuan12:04
rrqcertainly12:05
rrq(most of us do :)12:05
fsmithredYou'll be like most of the folks in here - silent.12:05
freaxehoh i doubt that fsmithred12:05
freaxehi'm a bit of a talker12:05
fsmithredFeel free to either ask or answer a question.12:05
freaxehand have plenty of questions about my devuan box12:06
drizztwe are here to help (and get some help too from time to time)12:42
adhocindeed.13:00
ibanjaI have a strange problem. There have been two instances where I’ve modified scripts in two different directories and the next day the have reverted back to the original script from several modifications earlier in the one case.13:37
ibanjaI am using inotifywait to monitor the directory, but is there a way to monitor what process is causing the changes?13:37
drizztmake the script read-only and check the logs for errors ?13:38
drizzt(or rootfs read-only if you fear that the modifications are made by a root process)13:39
ibanjagood idea.13:40
drizztor a combination of inotify + lsof, but I don't know if the lsof will comme in quickly enough to see who has the file openned13:41
ibanjaI just found a tool called auditctl (auditd package). Maybe that will tell me something.13:44
buZzcould also perhaps be some aggressive and incorrect caching?13:46
ibanjabuZz: how is that?14:10
ibanjaWhat might cause that? I am running smartctl on the drive to check for errors.14:10
ibanjasmartctl showed no errors.14:12
buZzi dont know what filesystem you're using or anything14:21
buZzbut i've seen overeager caching sometimes not write changes away, for instance14:21
drizztif you fear for a caching problem, you can run "sync" after your modifications14:25
drizztbut this should not happen as the kernel and VFS should grant you that you always access the latest version of the file14:26
buZzdrizzt: yeah but maybe its a write-back cache on a hw device that doesnt listen to 'sync'14:30
buZzwouldnt be the first time i see such misconfigged caches, anyway ;)14:30
ibanjaI'm using ext4, but I'm in the process of trying to get devuan installed on a zfs mirror.14:47
plasma41ibanja: Where are the scripts within the filesystem?16:25
ibanjaplasma41: they were in ~/dev/cpp/projects/fpa-black-scholes and ~/dev/scripts/bash/projects/fpa-general-scripts16:30
al1r4donefang, hi sir, do you get new server rental?16:33
plasma41ibanja: Hmm, both within your home directory. That pretty much rules out some weird interaction with the package manager.16:35
ibanjaplasma41: It's a mystery. I haven't changed anything config-wise that I can think of.16:40
ibanjaI found the issue of why my file keeps reverting to an old version. I automate packaging my scripts into deb packages and a typo in the build script overwrote my new source files with old ones. It was a matter of a missing semi-colon. OOPs19:24
djphibanja: it's alwasya a semicolon!19:43
ibanjadjph: Isn't it though. :)20:01
mathewHello. I want to set up syncthing on my homeserver. the program comes with an systemd file on install. but on my homeserver runs devuan chimaera. Now i need to write an init script to start the syncthing servie at boot. did someone here did it already?23:20
rrqmathew: you might know; the start point for diy init script is "man init-d-script"23:37
mathewthx! i will read this!23:38
mathewNow i did find a script on the internet. i will use it and change the necessary aspect with man init-d-script in mind. https://gist.githubusercontent.com/typomedia/3fe16c0e8214ce60b0b2/raw/23595ba29ce853da85e26e6b376ad52fb9f0b861/init.syncthing.sh23:40
rrqlooks fine to me; maybe something to submit to the orphan-sysvinit-scripts package; I'm not sure about their process for adding scripts, but maybe a bug report is good23:51
rwpI also gave it a quick look-over and it looks okay to me too.  Nothing of note jumped out at me.23:52
rrqmathew: i.e. an email to submit@bugs.devuan.org, where first line is "Package: orphan-sysvinit-scripts" and second is "Version: ceres", and then up to you for the rest23:53
rwpThe only thing I would have added would be the optional inclusion of /etc/default/$NAME which if present could override things like TIMEOUT and so on.  But that's really a minor thing.23:53
rrqmmm maybe it's to submit@bugs.debian.org rather, since its not a forked package23:55
mathewone problem is that one has to add an user "syncthing" which is not done at apt install. so the scirpt failes if no user "syncthing" is present.23:55
mathewbut if the user is present, the script runs fine so far.23:56
rwpUsers are normally added in the package postinst script.23:56
rrqthat's a bug for installing syncthing rather23:56
rrq(what rwp said)23:56
rwpA pet peeve of mine is when postinst scripts unconditionally add a user.  Which works great on a fresh install.  But on an upgrade then complains that the user already exists.23:56
rwppostinst scripts should test first and add user if the user does not already exist.  That also handles a case where the local admin customized things.23:57

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