| gnarface | NICAD: the motherboard bios setup panels should have an option to set the expansion card as your default display adapter instead of the motherboard one. if you don't see it right away, try checking for something like "advanced options" | 02:31 |
|---|---|---|
| gnarface | if you do that, xorg will most likely pick it up automatically then, however a custom xorg.conf can do the same thing (and more!) let me know if you need help fabricating one... | 02:32 |
| gnarface | ...well, it won't actually do quite the same thing in this case, your system boot-up and any console output before Xorg comes up will probably still go out the motherboard port, and maybe both or maybe only the motherboard port, so the BIOS setting is the preferred first step anyway, if furnished | 02:34 |
| gnarface | NICAD: *but with a custom xorg.conf, you could even use both at once for different displays | 03:27 |
| gnarface | some window managers may have built-in controls to set that up too, but not all of them | 03:27 |
| gnarface | (and if you want to try changing the setup by command-line after Xorg is started but your window manager doesn't have that feature, check out the xrandr binary) | 03:28 |
| freemangordon | gnarface: any idea how to avoid this https://pastebin.com/n08q2LKT | 08:30 |
| gnarface | freemangordon: hey man, sorry but i've got real mental issues, i'm way too paranoid for pastebin, but if you put it at paste.debian.net or just /msg it to me, i'll take a look | 09:10 |
| freemangordon | oh, sorry, will know for the future :) | 09:10 |
| gnarface | (anti-flooding bot in this room i think triggers at either 3 or 4 lines) | 09:10 |
| gnarface | i will take a look though if you deliver it in one of those two ways | 09:11 |
| freemangordon | https://paste.debian.net/1347828/ | 09:11 |
| gnarface | thanks | 09:11 |
| gnarface | freemangordon: interesting, this error "cycle found while processing triggers" is not one i've seen before, but it seems to be referring to the pre/postinst scripts in these packages causing the package installation equivalent analog of a http redirect loop | 09:13 |
| gnarface | usually in the stable distro, this type of thing is caused by packages from out of distro, or from another release | 09:14 |
| gnarface | (like backports) | 09:14 |
| freemangordon | this is caused by gconf, for sure | 09:14 |
| gnarface | but it might just be a simple glitch | 09:14 |
| gnarface | to figure it out in more specifics, i'd have to actually see the pre/postinst scripts ... they're capable of quite a lot of havoc, but they're usually fine unless you are pulling from unstable | 09:14 |
| freemangordon | I need a minute to confirm, but installing gconf2-common_3.2.6-8_all.deb before the upgrade seems to fix it | 09:15 |
| freemangordon | so maybe gconf2 shall pre-depend on gconf2-common | 09:15 |
| freemangordon | gconf2 has triggers on files that are distributed by gconf2-common | 09:16 |
| gnarface | yea, it might be something like that. unfortunately packaging isn't really my area of expertise, i've only dabbled with it a bit, but it seems like it's saying that gconf2 and sgml-base have triggers that both retrigger each other in a easily detectable but neverending loop | 09:16 |
| freemangordon | yeah | 09:17 |
| gnarface | like they each say to preconfigure the other first, and neithers' scripts can ever exit | 09:17 |
| gnarface | it's not something i can recall seeing myself or hearing anyone else complain about in daedalus around here, but stick around and maybe someone else has | 09:18 |
| freemangordon | right, but this prevents dist-upgrade from chimaera to daedalus | 09:18 |
| gnarface | yea, that part is weird, i've done a lot of dist-upgrades from chimaera to daedalus | 09:18 |
| gnarface | so it might be something you guys added | 09:19 |
| freemangordon | I don;t think so | 09:19 |
| gnarface | but it might be something super innocuous seeming like a change of location of some file it's checking | 09:19 |
| gnarface | although... hmm | 09:19 |
| gnarface | somewhere a long time ago in the debian release notes for some pre-devuan debian release, i do recall seeing the advice to "apt-get upgrade" then "apt-get dist-upgrade" as a second step, when doing upgrades - after changing the sources.list to the target release, to avoid... something | 09:20 |
| gnarface | maybe something like this | 09:20 |
| freemangordon | ok, confirmed https://paste.debian.net/1347829/ | 09:21 |
| freemangordon | lemme check if dist-upgrade will work | 09:21 |
| gnarface | i'd only ever had to actually do that once before myself, and i don't think it was on daedalus, but it could be different on arm/arm64... most my dist-upgrades have been on x86 architectures | 09:21 |
| freemangordon | this is amd64 VM | 09:21 |
| gnarface | oh, hmm | 09:21 |
| freemangordon | yeah, it will take ages on devices :) | 09:22 |
| gnarface | only other thing i can think of as a quick fix without actually debugging the hooked scripts line-by-line would be to simply remove one or both of the problematic packages before the upgrade, then re-install that package afterwards | 09:22 |
| freemangordon | removing gconf2 will remove all the leste, basically :) | 09:23 |
| gnarface | how about the sgml-base? | 09:23 |
| gnarface | does gconf2 depend on that? | 09:23 |
| freemangordon | there is no issue with it | 09:23 |
| freemangordon | thats a red herring | 09:23 |
| gnarface | hmm | 09:23 |
| gnarface | do stick around, there's smarter people than me around here, but usually they're asleep around now | 09:24 |
| freemangordon | yeah, ok, thanks | 09:24 |
| gnarface | systemdlete: by the way, in case nobody notified you of this already: <plasma41> If systemdlete returns, please let them know that '[ -d /run/systemd/system ]' is, as far as I'm aware, a reliable check for a running systemd. | 10:25 |
| gnarface | <plasma41> As an example, I used this exact check this week in my patchset submission to the snapper package: https://bugs.debian.org/cgi-bin/bugreport.cgi?att=7;bug=976888;filename=v2-1007-Make-cronjobs-defer-to-systemd-timers.patch;msg=22 | 10:25 |
| freemangordon | gnarface: in case anyone you know might be interested https://github.com/maemo-leste-upstream-forks/gconf/commit/779bdb1e11038462dc4c33a1064f0ffc3de926a0 | 12:39 |
| systemdlete | gnarface, thanks. That sounds ideal. | 14:58 |
| Alverstone | Is there a conventional method so saving the bootlog? I need to save the shutdown log. Inject a script into shutdown sequence and dump /dev/vcs*? | 19:05 |
| nemo | Alverstone: /var/log/boot.log ? | 19:18 |
| nemo | huh. that's weird... I thought devuan had a /var/log/boot or something whaaat | 19:20 |
| nemo | I guess there's /var/log/dmesg but.. | 19:21 |
| nemo | guessing that's not what you want | 19:21 |
| nemo | hm... is there anything in the shutdown that would not be in dmesg... | 19:23 |
| Alverstone | yes. the messages it prints on the screen | 19:24 |
| nemo | Alverstone: those aren't echoed to dmesg too? | 19:24 |
| Alverstone | though I decided to abandon all pride and record it on video | 19:24 |
| Alverstone | nemo, why should they? | 19:24 |
| nemo | dunno. don't know how the kernel logs things, but looks awfully similar to what I see at boot and shutdown | 19:25 |
| Alverstone | sysvinit scripts don't do anything special, just echo | 19:25 |
| nemo | ohhhh the script output | 19:25 |
| nemo | duh | 19:25 |
| nemo | :D | 19:25 |
| nemo | sorry was focused on kernel shutdown | 19:25 |
| Alverstone | /lib/lsb/init-functions is pretty simple | 19:25 |
| nemo | Alverstone: ok. I get it now. that's definitely interesting and useful, and yeah, AFAIK unless the script is written to do logging... | 19:26 |
| Alverstone | I guess I could make a script that would execute as the last in shutdown sequence, mount / back to readwrite, dump /dev/vcs and shutdown, but duh | 19:26 |
| nemo | Alverstone: hm. quite a few of the devuan scripts do use syslog | 19:27 |
| nemo | which ones don't | 19:27 |
| nemo | oh wow. most of them don't | 19:27 |
| nemo | ah. I see. what you pointed out. they are using the generic functions. | 19:28 |
| nemo | ok. that improves the % in my grep a lot ☺ | 19:28 |
| nemo | and yeah. since they are using the generic one, adding a hook in there besides echo is probably pretty easy. cool | 19:29 |
| nemo | I wonder why that isn't default | 19:30 |
| Alverstone | actually I tried redirecting all output into a file by altering the init, but for some reason the system didn't boot at all, just hang | 19:30 |
| Alverstone | weird | 19:31 |
| Alverstone | you'd think magic should be simpler | 19:31 |
| nemo | redirecting all output of... | 19:31 |
| Alverstone | init=/usr/local/bin/dumpinit.sh: exec /sbin/init > /var/tmp/lol 2>&1 | 19:32 |
| Alverstone | dumpinit.sh* | 19:32 |
| Alverstone | dumpb | 19:32 |
| Alverstone | dumb | 19:32 |
| * Alverstone is angry | 19:32 | |
| nemo | ummmm | 19:32 |
| nemo | I don't have dumpinit.sh and I don't know what the original is, but I can see messing with something like that possibly screwing up backgrounding if you aren't careful with quoting | 19:33 |
| nemo | which would hang things | 19:33 |
| nemo | oh. I see. | 19:34 |
| nemo | you were trying to replace init with your custom wrapper | 19:34 |
| nemo | one that captures stdin/stderr, with the logic that all subs would echo to the same stdin/stderr | 19:34 |
| nemo | I don't know if that part is true but... | 19:34 |
| nemo | you would think init would have a way to do that.. | 19:35 |
| nemo | hm | 19:36 |
| nemo | I guess another issue with your wrapper | 19:36 |
| nemo | it doesn't handle arguments | 19:36 |
| nemo | reading the man page for init, init definitely takes args | 19:37 |
| nemo | so you should pass them in to the wrapper call as well | 19:37 |
| nemo | runlevel being the one most likely to cause hangs I guess | 19:37 |
| nemo | since it wouldn't do anything at all otherwise? | 19:37 |
| nemo | otherwise the idea seems cool and I'm surprised init doesn't have logging functionality already | 19:38 |
| nemo | Alverstone: IMO adding the logging to the initfunctions wuold be less fragile | 19:47 |
| nemo | .. welp. curious if you come up with something that works well (or exists already) sounds useful | 19:50 |
| Alverstone | and how will it work, exactly? syslog requires a daemon, which is not available during boot and is stopped during shutdown. and what will you do after all filesystems are unmounted and root remounted readonly | 19:52 |
| fsmithred | Alverstone, there's a package called bootlogd | 19:57 |
| Alverstone | >bootlogd logs all messages printed to the system console during system boot | 19:58 |
| fsmithred | The first line in my /var/log/boot says "Activatinjg swap" | 19:58 |
| Alverstone | any luck with shutdown? | 19:58 |
| fsmithred | syslog notes when you shut down, but I don't know what it keeps. | 19:59 |
| fsmithred | nothing about shudown in boot | 19:59 |
| fsmithred | hey if you decide that the way to get it all is to switch to initramfs to shut down, please tell me how you did it. | 20:01 |
| fsmithred | I have a dream of someday eliminating my cryptsetup error messages. | 20:01 |
| Alverstone | I am not sure you can jump back to initramfs after you booted, though | 20:02 |
| Alverstone | plus pivot_root removes the previous root recursively | 20:02 |
| Alverstone | which is a funny gotcha | 20:02 |
| fsmithred | oops | 20:03 |
| fsmithred | I didn't know that | 20:03 |
| Alverstone | I don't have experience using custom initramfs hooks though, but dumping /dev/vcs is the only thing I can come up with, if you mean you have cryptsetup errors during boot | 20:04 |
| Alverstone | By the way why exactly you can't see them? I though it'd pause to prompt password | 20:04 |
| fsmithred | when I boot I see cryptsetup messages about bad shutdown | 20:11 |
| fsmithred | I'll see if I can find one | 20:12 |
| mason | fsmithred: What cryptsetup error messages? Timeouts when you shut down? | 20:13 |
| fsmithred | nothing in var/log | 20:14 |
| fsmithred | I think I will reboot and take a picture | 20:14 |
| mason | fsmithred: Those have existed for a few years now at least. I reported the issue but the general consensus was that it didn't exist, "doesn't affect me", so my fix is my own. | 20:14 |
| fsmithred | no timeouts | 20:14 |
| mason | ah | 20:14 |
| fsmithred | not that it doesn't exist, but that it doesn't matter | 20:14 |
| fsmithred | everything still works | 20:14 |
| mason | Well, an extra minute waiting for shutdown matters. | 20:14 |
| fsmithred | but cryptsetup close whatever does not happen at shutdown | 20:15 |
| fsmithred | no extra waiting | 20:15 |
| mason | Interesting. | 20:15 |
| fsmithred | this is known issue for years | 20:15 |
| mason | Alright, yeah, that would generally need a shutdown-ramfs because as noted you want to pivot to free up the root mount, so you can unmount it. Even systemd as I understand it just eats the error quietly. | 20:16 |
| mason | For me, if I don't say "skip=y" in cryptdisks-functions there's a minute or so of fumbling as it tries to deactivate the storage backing root and fails. | 20:17 |
| Alverstone | something very ugly I once did is deliberately break initramfs so it doesn't boot. then chroot into real root and init the system manually using scripts. maybe, just maybe, think could be used to do what you want | 20:20 |
| mason | Alverstone: You can always just modify the init script in the initramfs so it gives you a shell all the time. Or not modify it, and tell it you want a shell. | 20:21 |
| Alverstone | later I remembered you can do init=/bin/sh | 20:22 |
| fsmithred | mason, cryptsetup-modified-functions might eliminate the delay. (it's a package) | 20:22 |
| Alverstone | was enough for my purposes | 20:22 |
| mason | Alverstone: Oh yeah, that too! | 20:23 |
| fsmithred | actually, I think youknow that pakcage well. | 20:23 |
| mason | fsmithred: Ah, hadn't seen that. I bet it does more or less what I'm poking in with Ansible. | 20:23 |
| fsmithred | pretty sure you worked on that one with me at one time. (dpkg-divert) | 20:23 |
| mason | fsmithred: If I do it's slipped away from me. | 20:23 |
| mason | Oh, maybe. | 20:23 |
| fsmithred | fwiw, I thought it was no longer needed, but the author said it is needed in some cases (his) so I updated it. | 20:24 |
| mason | The need for a patch shows up for me mostly because of ZFS root. | 20:25 |
| fsmithred | take a look at it and see if it helps. | 20:26 |
| fsmithred | or feel free to improve it | 20:26 |
| mason | Interesting, this is very different from what I do: https://git.devuan.org/devuan/cryptsetup-modified-functions/src/branch/master/cryptdisks-functions | 20:30 |
| mason | So, they've removed the whole geometric backoff thing. | 20:33 |
| mason | The same thing can be achieved in the upstream script by saying "skip=y" at the top of _do_stop_callback() | 20:34 |
| mason | cryptsetup-modified-functions is also specific to LVM, which I don't actually use. | 20:35 |
| mason | But still, thank you for showing it to me, or reminding me of it anyway. | 20:35 |
| mason | Both approaches are just a way to say "how do we handle the situation where we'll quite literally never be able to release the underlying crypto device?" But it ends up not being a huge deal as long as your filesystem that's sitting on it is relatively coherent at shutdown. | 20:37 |
| Alverstone | when i used systemd it introduced some stupid bug that prevented /home from being unmounted. I didn't care to fix it for a month maybe and everything worked fine. I don't remember what was the issue though | 20:44 |
| Alverstone | One of the things that upsets me about runit is that sometimes it silently spams my pid table. I just started to wonder how the heck my PID got > 150000, appears polkitd fails to start because systemd devs enjoy breaking compatibility (some symbols missing or whatever). It does not even output any messages anywhere, I'd never notice otherwise | 22:17 |
| Alverstone | You'd think runsvdir would notify you, no? | 22:18 |
| Alverstone | what I end up doing is `sv status /etc/service/* | grep 'want up'` | 22:19 |
| schillingklaus | one reason more to boycott polit and everthing depending on it | 22:20 |
| Alverstone | fucking stupid piece of shit, not even a way to install from daedalus (I use excalibur) | 22:25 |
| Alverstone | I don't give a fuck | 22:25 |
| Alverstone | I removed it | 22:25 |
| Alverstone | and let it burn | 22:25 |
| Alverstone | if something will break | 22:26 |
| Alverstone | I don't give a damn | 22:26 |
| Alverstone | It's not my problem they're retarded | 22:26 |
| * Alverstone is very angry | 22:26 | |
| * Alverstone is sorry too | 22:26 | |
| Alverstone | Is there a daemon that will shutdown my system when power gets too low? I use laptop | 22:27 |
Generated by irclog2html.py 2.17.0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!