| joerg | I see this very behavior every now and then, I came to the conclusion that it's the graca driver locking up and freezing the complete X11 | 02:13 |
|---|---|---|
| joerg | mouse still works, mousecursor moves. switching to another VT works. But I never managed to unfreeze the X11 session | 02:14 |
| joerg | I can terminate it by ctrl+alt+BS (*2) | 02:15 |
| gry | Regarding the «The devuan guest says it's Friday the 18th of March. Running 'hwclock' as root says "hwclock: select() to /dev/rtc0 to wait for clock tick timed out".» issue, I've tried hwclock with various parameters, the error is still the same. Any tips would be appreciated. | 03:45 |
| gnarface | gry: there's only so much that could possibly be wrong with an error like that... kernel or hardware, most likely | 04:49 |
| gnarface | if it's a stock kernel it's probably bug report time | 04:49 |
| gnarface | if it used to work, you might have fried it | 04:49 |
| gnarface | but you should do some searches about that particular motherboard, maybe it is a known issue with a workaround | 04:50 |
| gnarface | if it's a custom kernel you probably just forgot something important | 04:50 |
| gnarface | bios settings might be relevant too | 04:51 |
| gnarface | this isn't in a virtual machine, right? if it's a VM this is probably expected behavior | 04:51 |
| gnarface | and in that case the time needs to be corrected on the host | 04:51 |
| gnarface | and if it is right on the host, it could be a bug in the VM software, or maybe just a misconfiguration | 04:52 |
| gnarface | note that the x86 kernels are the same exact kernel packages that debian uses, so you can also check their bug tracker for relevant notes | 04:52 |
| gnarface | if it's a ARM system the kernels are custom and you should ask in #devuan-arm | 04:53 |
| gnarface | gry: oh, and one other thing i just thought of; if it's newer hardware you could try the backports kernel | 04:59 |
| gry | gnarface it's a virtual guest; the host's time is fine | 05:00 |
| gnarface | gry: all fingers point to the virtualization software itself then | 14:36 |
| gnarface | it could be doing this purposefully or on accident | 14:36 |
| gnarface | it would be most likely mentioned somewhere in their info as a known bug if it is the latter | 14:37 |
| gnarface | gry: you're running ntp on the host not in the guest, right? | 14:50 |
| joerg | gry: what gnarface said. See https://startpage.com/do/metasearch.pl?query=virtualization%20software%20cmos%20clock | 14:51 |
| joerg | gry: depending on which virtualization system you are using and what are the config options of the VM, you may not have any normal CMOS clock in the VM environment, since that clock is a virtual device that might get synced to the host and then applied some further processing (timezone and whatnot) but for sure doesn't play nicely with the standard NTP stuff. So in the VM it's not possibe to just the clock, and probably in your VM solution the syncing of clock | 15:02 |
| joerg | to host time fails as well | 15:03 |
| gnarface | there should be a way to turn if off, so the guests just can't drift the clock | 15:05 |
| gnarface | then you run ntpd on the host and everything is fine | 15:05 |
| gnarface | setting different timezones with tzdata in the guests should still work i think | 15:05 |
| gnarface | not sure if that's true if the VM software is buggy though | 15:06 |
| joerg | gnarface: AIUI gry said that the time in host is correct. So I guess that what is broken is the virtualization service that should do the sync from host down to guest CMOS clock | 15:11 |
| joerg | actually I looked into exactly such feature to keep the time at a certain date for a VM in which a test version of software was running "for 7 days" ;-) | 15:12 |
| joerg | there's quite a number of config options for the VM when setting it up, where you can tweak the way the clock is working | 15:14 |
| joerg | generally I'd not expect a guest to have the permissions to mess with the host's cmos (or system) clock | 15:15 |
| gnarface | yea it doesn't seem safe to me to begin with | 15:15 |
| joerg | prolly a first pragmatic approach would be to simply delete the localhost cmos clock stratum(?) from NTP's config | 15:19 |
| joerg | in VM obviously | 15:20 |
| joerg | let it start up brute force from NTP via internet | 15:20 |
| joerg | or LAN, whatever you have | 15:20 |
| joerg | most routers nowadays offer a NTP service for LAN | 15:21 |
| joerg | saturn:/run/user # ntpdate 192.168.7.1 | 15:25 |
| joerg | 22 Mar 15:25:29 ntpdate[13106]: adjust time server 192.168.7.1 offset -0.000737 sec | 15:25 |
| nemo | https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1007249 | 15:53 |
| nemo | So, high urgency apache2 bug fixed in 2.4.53 | 15:53 |
| nemo | trying to figure out if this is not in chimæra due to debian or devuan | 15:53 |
| nemo | hmmm loosks like https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1007254 is blocking | 15:54 |
| nemo | *looks | 15:54 |
Generated by irclog2html.py 2.17.0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!