| EHeM | Xenguy: With 1.0/2.0 there was a bit of flapping between the country codes and non-country code servers; the situation around pkgmaster has seemed unclear, security updates-only? main server? | 01:13 |
|---|---|---|
| fsmithred | pkgmaster is the main server. Please don't hit on it - it's slow and needs to serve all the mirrors. | 01:14 |
| EHeM | I'm presently guessing the country-codes have disappeared from some server configuration, as such us.deb.devuan.org is *broken* (404 Not Found). | 01:15 |
| fsmithred | yeah, the country codes never really worked. We've never had a US package mirror. | 01:16 |
| golinux | There hasn't been a US pkg mirror for a long time if ever. | 01:16 |
| golinux | I think that obeardly might have had one for jessie. | 01:17 |
| fsmithred | if you don't want to use deb.devuan.org, pick a fast one. | 01:17 |
| fsmithred | maybe this will help. Mirror Checker: https://sledjhamr.org/apt-panopticon/ | 01:18 |
| golinux | sledjhamr.org/devuan-cd/ breaks the sound barrier | 01:18 |
| golinux | Oops that the iso mirrors. | 01:18 |
| golinux | sledjhamr.org/devuan | 01:19 |
| EHeM | fsmithred: Having the country-code servers round-robin between the regular servers is fine as a fallback; my hope was it would round-robin while there weren't any US mirrors and then move between US mirrors if one or more came up. | 01:21 |
| fsmithred | yeah,, that's logical | 01:21 |
| fsmithred | I don't get to touch any of that | 01:22 |
| EHeM | Yet instead of falling back to round-robin, they've been getting broken. | 01:22 |
| EHeM | On the mirror list I note mirrors.ocf.berkeley.edu and dev.beard.ly. | 01:22 |
| rrq | us.deb.devuan.org is an alias for pkgmaster.devuan.org | 01:22 |
| EHeM | mishka.snork.ca would likely be pretty fast here too. | 01:25 |
| fsmithred | rrq, in web browser, us.deb.devuan shows fewer items than pkgmaster and no new file dates | 01:28 |
| Xenguy | Well maybe I'm doing it fucking wrong, but as I mentioned, using country codes is doing it fucking wrong | 01:29 |
| rrq | mmm so your browser/browsing does something odd, then | 01:29 |
| fsmithred | same in lynx | 01:30 |
| rrq | the aliasing is normal DNS | 01:30 |
| rrq | mine looks odd too | 01:32 |
| rwp | Something is definitely different between them: https://paste.debian.net/plain/1206396 | 01:33 |
| fsmithred | where are we??? | 01:33 |
| rwp | I am in Colorado, US. | 01:34 |
| fsmithred | lol, I mean on this page | 01:34 |
| fsmithred | that's supposed to be pkgmaster | 01:35 |
| fsmithred | looks like it went into isolation last year and never came out | 01:35 |
| rwp | I suspect that pkgmaster has a different configuration for the different hostnames being serviced. | 01:35 |
| rwp | Since it is Nginx (which I prefer btw) I suspect that there are different server config segments servicing the different "server_name"s. | 01:37 |
| * rrq afk | 01:39 | |
| rwp | fsmithred, But if you are asking about my paste then please run this command yourself: diff -u <(wget -O- -q http://us.deb.devuan.org/) <(wget -O- -q http://pkgmaster.devuan.org/) | 01:39 |
| fsmithred | no, I was just commenting on differences I see on a quick look. | 01:39 |
| fsmithred | different number of .txt files and only old dates on one site. | 01:40 |
| rwp | It definitely looks like us.deb.devuan.org is looking at a different, older, directory tree. Since files have older dates there. | 01:40 |
| rwp | Hmm... In my web browser my Firefox won't let me look at the http page but only the http page. Same result however. | 01:43 |
| onefang | sledjhamr.org is really fast on the sledjhamr.org copy of apt-panopticon for obvious reasons. That's why we have two other copies of apt-panopticon runinng, so my mirror doesn't get a home town advantage. https://sledjhamr.org/apt-panopticon/results/Report-web.html http://veritas.devuan.org/apt-panopticon/results/Report-web.html https://borta.devuan.dev/apt-panopticon/results/Report-web.html | 02:28 |
| onefang | Don't use the country codes. | 02:29 |
| EHeM | Using the country codes /should/ be advantageous to both sides; for people downloading, closer mirrors often get higher speeds; on the infrastructure side it uses cheaper bandwidth (packets don't travel as far), plus it does some to even out load among servers and keeps downloaders isolated from how the servers are distributed. | 02:33 |
| gnarface | EHeM: that's assuming they're configured correctly, which they currently are not, last i heard | 03:07 |
| gnarface | EHeM: what's worse, is there's stale dns entries floating around for them so they'll almost seem to work except often be pointing to a outdated, even potentially compromised server | 03:08 |
| EHeM | gnarface: The Packages file is signed and it contains cryptographic hashes of packages, a compromised server could provide out of date packages, but it wouldn't allow compromise of systems (this was fixed around 2005 or so). | 03:17 |
| gnarface | EHeM: theoretically, but regardless it'll still hose upgrades and cause support issues practically indistinguishable from a MITM attack to the bulk of people who trip on this issue | 03:18 |
| gnarface | at least to the bulk of the ones who get as far as asking for help in this channel... i must presume some larger percentage of people just give up and switch distros without asking | 03:19 |
| gnarface | while a better solution would be to just fix the DNS registry, the issue of the fact that we don't have enough mirrors distributed geographically to actually make doing so of any practical value whatsoever does enter into why it is still not fixed | 03:21 |
| rwp | We have certainly seen people here asking for help who have had very strange upgrade problems and now I wonder how much might have been related to this. | 03:22 |
| gnarface | if the server is outdated it rarely causes a super collossal faceplant of an upgrade on stable, but even causing minor, completely correctable dependency tangles is beyond most new users | 03:23 |
| gnarface | er, even fixing minor dependency tangles is beyond them, i mean | 03:23 |
| gnarface | and yea, if they decide at that moment to try getting the package from an ubuntu ppa "just in case that'll fix it, because it always fixes it for ubuntu!" then all bets are off | 03:24 |
| gnarface | people have been trained for decades not to read those types of error messages | 03:25 |
| EHeM | gnarface: Not having mirrors with appropriate geographical distribution means country-code servers are lowish value /now/; if they can be left pointing to a simple round-robin, that works well as a fallback, since when appropriate mirrors exist you simply adjust the DNS records and everyone is distributed appropriately. | 03:28 |
| rrq | note: the service is now reconfigured (corrected) to serve *.deb.devuan.org as if it was deb.devuan.org | 03:28 |
| gnarface | yea i think the issue is being exacerbated or at least prolonged by some malicious TTL usage | 03:29 |
| rrq | previously it served as if archive.devuan.org | 03:29 |
| gnarface | EHeM: i wasn't the one in charge, my services were declined | 03:30 |
| EHeM | rrq: Looks suspiciously like that is in place. | 03:31 |
| rrq | note tha now any jessie installation using CC will fail to update | 03:59 |
| * EHeM . o O ( Why is `smartd` so good at triggering the oom-killer? ) | 04:19 | |
| gnarface | are you running without any swap? | 04:20 |
| EHeM | Nope, plenty of swap, adaquate free memory. | 04:20 |
| gnarface | odd, i dunno | 04:20 |
| gnarface | would have to assume a memory leak then | 04:20 |
| gnarface | is it a multi-arch system? | 04:21 |
| EHeM | Nope. | 04:21 |
| gnarface | hmm, yea i'm out of ideas then | 04:21 |
| gnarface | sometimes on multi-arch systems a 64-bit binary will accidentally use a 32-bit version of a library and everything works fine except for the leaking | 04:21 |
| EHeM | My feeling is `smartd` uses some pattern of memory allocation which triggers $something in the VM system. | 04:22 |
| gnarface | custom kernel? | 04:22 |
| gnarface | maybe the CMA size is too small or something? | 04:22 |
| gnarface | that was plaguing me on my new arm systems in the early days | 04:23 |
| EHeM | Slightly, simply rebuild with some extra security options on. | 04:23 |
| gnarface | default ram slab allocator though? | 04:23 |
| EHeM | Thing is, it /appears/ to have plenty of memory for what it is doing, just `smartd` perfectly tickles the oom-killer. | 04:24 |
| gnarface | yea that's weird | 04:24 |
| gnarface | i'm no kernel dev though | 04:24 |
| EHeM | The system is run with a fairly low amount of memory, but not so low I would expect the oom-killer to be needed. | 04:26 |
| gnarface | smartd only looks at blocks, not filesystems or filesystem contents, right? | 04:28 |
| EHeM | Pretty sure it is using ioctl() to send commands directly to the hardware, no or minimal reading/writing. | 04:29 |
| gnarface | yea, i can't picture what would even cause it to use more memory | 04:30 |
| EHeM | Could be the commands are triggering $something, but I don't know what. | 04:31 |
| EHeM | Xenguy: x86-only? aarch64? | 04:47 |
| systemdlete | I just added a new disk to my ascii system (I know, I know... I keep trying to upgrade to beowulf, but I have different problems every time). Anyway, I force failed the partitions on the old disk that was failing from the mdadm raid1 arrays. But I can't seem to run grub-install on the new drive (/dev/sdc) -- I get errors about unknown partitions. | 05:28 |
| systemdlete | The web pages I've found say to reboot and then install grub, which is fine for little folks like me. But what about 24x7 data centers? | 05:28 |
| GoatAvenger | systemdlete, still on ascii >.< | 05:28 |
| systemdlete | (yeah yeah GoatAvenger. yeah yeah) | 05:29 |
| GoatAvenger | hehehe | 05:29 |
| GoatAvenger | systemdlete, so you're adding the new disk to a raid1 array and trying to get GRUB into it's MBR? | 05:30 |
| GoatAvenger | (you're probably more knowledgeable than I am..) | 05:30 |
| systemdlete | I know I'm a fool. But I've tried about 4 times now to install beowulf on this machine, but it seems to take issue somehow with my partitioning or something. This system has a UEFI mainboard, but I'm still using grub. Ascii boots fine (usually, anyway). But a fresh beowulf always has issues of one sort or another. | 05:30 |
| GoatAvenger | that's weird.. hmm | 05:31 |
| systemdlete | Well... not exactly. EFI partitioned disks are a bit different. I think they actually work off the EFI tables, but I've forgotten it's been so long since my last attempt. | 05:31 |
| GoatAvenger | yeah, i always just disable UEFI stuff on whatever board I'm working with | 05:32 |
| GoatAvenger | don't know much about it.. | 05:32 |
| EHeM | Things seem to be getting better with UEFI and GRUB, it is still somewhat dark magic to get everything together, but it isn't /that/ bad now. | 05:32 |
| systemdlete | EHeM, I am able to boot ascii off the same board! | 05:32 |
| systemdlete | I am not sure, though, if that was already on the disk when I upgraded to the new board. | 05:33 |
| EHeM | I'm uncertain whether UEFI /requires/ GPT, but I can state it seems to be /encouraged/ at a minimum. | 05:34 |
| systemdlete | So the 2 existing disks are /dev/sda and /dev/sdb. The new one is /dev/sdc | 05:34 |
| systemdlete | They are all gpt partitioned, identically. | 05:34 |
| EHeM | Alas, UEFI also wants you to allocate some space for a VFAT filesystem where the boot files get located and this then needs the appropriate magic markings. | 05:35 |
| systemdlete | the failing drive is /dev/sda. Both it and the new /dev/sdc drive are 2T WD EFRX drives. | 05:35 |
| systemdlete | EHeM, it already works for booting ascii. And I think I actually did finally get beowulf to boot, but it wouldn't play the desktop (graphical interface) | 05:36 |
| systemdlete | I forget which irritating issue that one was | 05:36 |
| systemdlete | It's the same video card before and after boot (ascii/beowulf) so I'd think it would work. | 05:37 |
| EHeM | Important packages to have installed for UEFI boot include "efibootmgr" and "grub-efi". | 05:39 |
| systemdlete | Ah. THis might be part of the issue. There is no on-board video. I have a "NVIDIA Corporation GK208B [GeForce GT 710] (rev a1)" (this is from lspci) | 05:39 |
| systemdlete | So I believe -- iirc now -- that the problem was getting video to work. I had asked gnarface about this because he usually has video knowledge. I think it came down to choosing a binary blob vs the open source driver. | 05:41 |
| systemdlete | I think I was so frustrated by that point I just returned to ascii and forgot about it. | 05:41 |
| EHeM | That may well need the nouveau driver with beowulf or else nvidia-legacy. | 05:42 |
| systemdlete | The first 2 times I tried install, the problem really was with grub. But I believe that the last try or two it was video issues. It was failing during the load (startx) | 05:42 |
| systemdlete | EHeM: Exactly. | 05:42 |
| systemdlete | Anyway, for now, it seems I will have to reboot to get my hard disk configuration settled out. | 05:43 |
| systemdlete | I will be moving the failing drive to another box where I can do some surface analysis -- I've found that, often, a seemingly failing drive will stop having errors after running badblocks on it for a few days. | 05:44 |
| EHeM | If the nouveau driver is in good enough shape for your card, it may be better to do *without* a xorg.conf file and simply let it probe the device during start. | 05:44 |
| EHeM | systemdlete: That suggests it is managing to remap the sectors, while such a drive may have some time remaining in service that is a strong hint it is approaching end of life (do NOT ignore this hint!). | 05:45 |
| systemdlete | or it could just be a whole scad of bad sectors that get remapped (internally, by the drive's own fw). | 05:46 |
| systemdlete | It's only a year old... | 05:46 |
| systemdlete | I'll try badblocks on the drive and see if I can chase away the bad sectors. Then I can use it as a spare. | 05:47 |
| systemdlete | What I meant (I see you said more or less the same thing, sorry) is that there might not be anything really wrong with the drive but for a few bad sectors. I mean, the fw and board might be OK along with much of the surface. | 05:48 |
| systemdlete | I've seen this happen with at least 4 disks now. Too bad they are 500GB only, but they no longer have problems. I can't use them for anything except some test machines here. | 05:49 |
| EHeM | The recommendation is once you see a single remapped sector, keep a *very* close eye on the drive since the remap count tends to increase and once it exhausts the available remapping sectors... | 05:50 |
| systemdlete | right. | 05:51 |
| systemdlete | That's why I won't actually use any of those born-again drives in the system I mostly depend on. But they might be fine for testing on a test box, e.g. | 05:52 |
| EHeM | I've got a drive here which I pulled when it had ~130 remapped sectors, it was on average remapping about 1 per day which was too high for my taste. | 05:53 |
| systemdlete | Also, I've got a script running in the background that tails the kern.log file looking for tell-tale hints of the bad sectors. It beeps when it finds bad sectors, which is exactly the time I notice looooong delays in response. | 05:53 |
| systemdlete | So I know the script works correctly. | 05:53 |
| systemdlete | smartctl doesn't seem to say there are unusually high bad sectors. The raw number is 0 (whatever that is) and the "value" is 200 (whatever that is). This is a WD drive. | 05:58 |
| ShorTie | there are extra sectors on a drive | 06:43 |
| ShorTie | wd has a tool to remap bad sectors | 06:44 |
| systemdlete | ShorTie: Does it only run on Windows? | 06:47 |
| systemdlete | (There are no Windows systems within a 300 ft perimeter of my home. I made sure of that.) | 06:48 |
| systemdlete | (and there are turrets about every 25 ft around the perimeter) | 06:48 |
| systemdlete | (I'm safe here. Verrrry safe.) | 06:49 |
| tns | hab keinen loginscreen, beowulf frisch auf old i686 fujitsu primergy aufgesetzt - ssh geht -aber eben nur einen black screen mit cursor; tasksel war: mate, sshd und server...kann mir Jemdand einen Hint geben? | 13:58 |
| debdog | tns: not familiar with this topic but maybe https://refracta.org/docs/readme.refracta2usb.txt helps. refracta is based on devuan. | 14:34 |
| debdog | oops, wrong channel | 14:35 |
| debdog | tns: schwarzer sceen mit cursor heißt, xorg läuft. musst nur herausfinden, warum der displaymanager nicht gestartet wird... | 14:36 |
| tns | Danke, ci schau mal was ich damit hinbekomme! | 14:37 |
| debdog | https://files.devuan.org/devuan_beowulf/Release_notes.txt "Lightdm is the default for the other desktops." | 14:38 |
| debdog | also schätze ich, daß lightdm das problem ist. vlt. gibt es ein log. | 14:38 |
| debdog | und wenn wir englisch schreiben, dann gibt es mehr leute, die dir helfen könnten... tns | 14:39 |
| debdog | könnte auch sein, daß die fehlermeldung im xorg log ist | 14:39 |
| tns | true, good idea - Xorg log... | 14:41 |
| tns | cat /var/log/Xorg.0.log | 14:46 |
| tns | [ 52.939] | 14:46 |
| tns | X.Org X Server 1.20.4 | 14:46 |
| tns | X Protocol Version 11, Revision 0 | 14:46 |
| tns | [ 52.939] Build Operating System: Linux 4.19.0-16-amd64 i686 Debian | 14:46 |
| tns | [ 52.939] Current Operating System: Linux devuan1 4.19.0-17-686 #1 SMP Debian 4.19.194-3 (2021-07-18) i686 | 14:46 |
| tns | [ 52.939] Kernel command line: BOOT_IMAGE=/vmlinuz-4.19.0-17-686 root=/dev/mapper/devuan1--vg-root ro quiet | 14:46 |
| tns | [ 52.940] Build Date: 19 April 2021 09:34:38AM | 14:46 |
| tns | [ 52.940] xorg-server 2:1.20.4-1+deb10u3 (https://www.debian.org/support) | 14:46 |
| tns | [ 52.940] Current version of pixman: 0.36.0 | 14:46 |
| tns | [ 52.940] Before reporting problems, check http://wiki.x.org | 14:46 |
| tns | to make sure that you have the latest version. | 14:46 |
| tns | [ 52.940] Markers: (--) probed, (**) from config file, (==) default setting, | 14:46 |
| tns | (++) from command line, (!!) notice, (II) informational, | 14:46 |
| tns | (WW) warning, (EE) error, (NI) not implemented, (??) unknown. | 14:46 |
| tns | [ 52.940] (==) Log file: "/var/log/Xorg.0.log", Time: Tue Aug 3 12:08:13 2021 | 14:46 |
| tns | [ 52.974] (==) Using system config directory "/usr/share/X11/xorg.conf.d" | 14:46 |
| tns | [ 53.002] (==) No Layout section. Using the first Screen section. | 14:46 |
| tns | If no devices become available, reconfigure udev or disable AutoAddDevices. | 14:46 |
| tns | [ 53.065] (II) Loader magic: 0x6fb740 | 14:46 |
| tns | [ 53.065] (II) Module ABI versions: | 14:46 |
| tns | [ 53.065] X.Org ANSI C Emulation: 0.4 | 14:46 |
| tns | [ 53.065] X.Org Video Driver: 24.0 | 14:46 |
| tns | [ 53.065] X.Org XInput driver : 24.1 | 14:46 |
| tns | [ 53.065] X.Org Server Extension : 10.0 | 14:46 |
| tns | [ 53.067] (++) using VT number 7 | 14:46 |
| tns | [ 53.067] (II) systemd-logind: logind integration requires -keeptty and -keeptty was not provided, disabling logind integration | 14:46 |
| tns | [ 53.072] (--) PCI:*(0@0:4:0) 1002:4752:1734:007a rev 39, Mem @ 0xfd000000/16777216, 0xfc010000/4096, I/O @ 0x00001000/256, BIOS @ 0x????????/131072 | 14:46 |
| tns | [ 53.075] (II) LoadModule: "glx" | 14:46 |
| tns | [ 53.081] (II) Loading /usr/lib/xorg/modules/extensions/libglx.so | 14:46 |
| tns | [ 53.167] (II) Module glx: vendor="X.Org Foundation" | 14:46 |
| tns | [ 53.167] compiled for 1.20.4, module version = 1.0.0 | 14:46 |
| tns | [ 53.167] ABI class: X.Org Server Extension, version 10.0 | 14:46 |
| tns | [ 53.167] (==) Matched ati as autoconfigured driver 0 | 14:46 |
| tns | [ 53.167] (==) Matched modesetting as autoconfigured driver 1 | 14:46 |
| tns | [ 53.167] (==) Matched fbdev as autoconfigured driver 2 | 14:46 |
| tns | [ 53.182] ABI class: X.Org Video Driver, version 24.0 | 14:47 |
| tns | [ 53.182] (II) LoadModule: "vesa" | 14:47 |
| tns | [ 53.183] (II) Loading /usr/lib/xorg/modules/drivers/vesa_drv.so | 14:47 |
| tns | [ 53.185] (II) Module vesa: vendor="X.Org Foundation" | 14:47 |
| tns | [ 53.186] compiled for 1.20.1, module version = 2.4.0 | 14:47 |
| tns | [ 53.186] Module class: X.Org Video Driver | 14:47 |
| tns | [ 53.186] ABI class: X.Org Video Driver, version 24.0 | 14:47 |
| tns | [ 53.186] (II) modesetting: Driver for Modesetting Kernel Drivers: kms | 14:47 |
| tns | [ 53.186] (II) FBDEV: driver for framebuffer: fbdev | 14:47 |
| tns | [ 53.186] (II) VESA: driver for VESA chipsets: vesa | 14:47 |
| tns | [ 53.192] (EE) open /dev/dri/card0: No such file or directory | 14:47 |
| tns | [ 53.192] (WW) Falling back to old probe method for modesetting | 14:47 |
| tns | [ 53.192] (EE) open /dev/dri/card0: No such file or directory | 14:47 |
| tns | [ 53.192] (II) Loading sub module "fbdevhw" | 14:47 |
| tns | [ 53.192] (II) LoadModule: "fbdevhw" | 14:47 |
| tns | [ 53.193] (II) Loading /usr/lib/xorg/modules/libfbdevhw.so | 14:47 |
| tns | [ 53.198] (II) Module fbdevhw: vendor="X.Org Foundation" | 14:47 |
| tns | [ 53.198] compiled for 1.20.4, module version = 0.0.2 | 14:47 |
| tns | [ 53.200] (II) LoadModule: "int10" | 14:47 |
| tns | [ 53.200] (II) Loading /usr/lib/xorg/modules/libint10.so | 14:47 |
| tns | [ 53.208] (II) Module int10: vendor="X.Org Foundation" | 14:47 |
| tns | [ 53.208] compiled for 1.20.4, module version = 1.0.0 | 14:47 |
| tns | [ 53.208] ABI class: X.Org Video Driver, version 24.0 | 14:47 |
| tns | [ 53.208] (II) VESA(0): initializing int10 | 14:47 |
| tns | [ 53.214] (II) VESA(0): Primary V_BIOS segment is: 0xc000 | 14:47 |
| tns | [ 53.214] (II) VESA(0): VESA BIOS detected | 14:47 |
| tns | [ 53.214] (II) VESA(0): VESA VBE Version 2.0 | 14:47 |
| tns | [ 53.214] (II) VESA(0): VESA VBE Total Mem: 8128 kB | 14:47 |
| tns | [ 53.214] (II) VESA(0): VESA VBE OEM: ATI MACH64 | 14:47 |
| tns | [ 53.214] (II) VESA(0): VESA VBE OEM Software Rev: 1.0 | 14:47 |
| tns | [ 53.214] (II) VESA(0): VESA VBE OEM Vendor: ATI Technologies Inc. | 14:47 |
| tns | [ 53.214] (II) VESA(0): VESA VBE OEM Product: MACH64GM | 14:47 |
| tns | [ 53.214] (II) VESA(0): VESA VBE OEM Product Rev: 01.00 | 14:47 |
| tns | [ 53.228] (EE) VESA(0): Specified fbbpp (24) is not a permitted value | 14:47 |
| tns | [ 53.228] (II) UnloadModule: "vesa" | 14:47 |
| tns | [ 53.228] (II) UnloadSubModule: "int10" | 14:47 |
| tns | seems to be it - but I cannot interpret it accordingly; what does it mean? | 14:47 |
| debdog | an IRC window is a horrible place to debug such files. pleas, use https://paste.debian.net/ | 14:48 |
| debdog | tns: is there an /var/log/lightdm/lightdm.log ? | 14:50 |
| debdog | is lightdm even installed? | 14:50 |
| debdog | or any other displaymanager for that matter. sorry, I am nor familiar with https://pkginfo.devuan.org/ and I have no system to find which packeages are installed by meta packages and their sub (meta) packages. | 14:52 |
| buZz | tns: please use pastebin.com or similar for such big pastes | 14:56 |
| gnarface | missing driver probably | 14:57 |
| tns | sorry, I want to use paste.debian.net - but somehow it's not taking it; @debdog: lightdm is installed;: Itried to paste the log here https://paste.debian.net/ - but as before, somehow it's not taking it... | 14:59 |
| buZz | try using a pastebin that works | 15:00 |
| buZz | and paste.debian gives you error msgs for why it failed | 15:00 |
| tns | http://zerobinftagjpeeebbvyzjcqyjpmjvynj5qlexwyxe7l3vqejxnqv5qd.onion | 15:04 |
| tns | der log von lightdm... | 15:11 |
| debdog | tns: "www.zerobinftagjpeeebbvyzjcqyjpmjvynj5qlexwyxe7l3vqejxnqv5qd.onion could not be found. Please check the name and try again." | 15:33 |
| tns | phhh...yeah...same here... | 15:35 |
| tns | does it help: Find us on Tor Onionspace: | 15:36 |
| tns | http://zerobinqmdqd236y.onion | 15:36 |
| tns | Onion V3: | 15:36 |
| tns | http://zerobinftagjpeeebbvyzjcqyjpmjvynj5qlexwyxe7l3vqejxnqv5qd.onion | 15:36 |
| debdog | da he keck is onion? | 15:37 |
| brocashelm | it does if you use tor ;) | 15:37 |
| debdog | haha | 15:37 |
| buZz | onion is for terrorists | 15:37 |
| debdog | tns: try https://dpaste.org/ | 15:37 |
| brocashelm | i like onions | 15:37 |
| debdog | yes, along with a steak | 15:38 |
| brocashelm | i also recommend using https://anonpaste.org | 15:39 |
| buZz | onion + carrot + celery | 15:40 |
| buZz | == mirepoix | 15:40 |
| tns | https://rentry.co/5gdk9 | 15:40 |
| tns | any better? | 15:40 |
| debdog | hmm, mayhap xorg is not working properly. can you describe the cursor of your black screen? is it X-shaped or a white rectangular? | 15:42 |
| tns | white rectangular | 15:42 |
| debdog | ohh, then xorg is the culprit | 15:43 |
| debdog | can you paste its log again, please? | 15:43 |
| debdog | afk for a bit... | 15:43 |
| buZz | i think for 'ati' driver you might need to enable non-free repos and install some firmware blobs | 15:44 |
| buZz | if i read that log correct | 15:44 |
| buZz | 14:47:35 < tns> [ 53.214] (II) VESA(0): VESA VBE OEM Vendor: ATI Technologies Inc. | 15:44 |
| buZz | 14:47:36 < tns> [ 53.214] (II) VESA(0): VESA VBE OEM Product: MACH64GM | 15:44 |
| buZz | wtf mach64 :) | 15:44 |
| buZz | is this the 90s? | 15:44 |
| tns | for sure it is before Millenium...so I bet 90's is correct... Tx100 something | 15:45 |
| buZz | there's quite some chance that the 'ati' driver no longer has support for that old gpu | 15:47 |
| tns | I`ll try the repos first - does devuan have own non-free? I don't find it , yet? | 15:55 |
| brocashelm | tns: you must add non-free to your repo | 15:59 |
| brocashelm | tns: devuan syncs updates from upstream (debian) except for forked packages (e.g. network-manager) and blacklisted packages (e.g. systemd) | 16:00 |
| brocashelm | tns: so something like this would work: deb http://deb.devuan.org/merged beowulf main non-free contrib | 16:01 |
| brocashelm | tns: also a good idea to add non-free and contrib to other devuan repos (e.g. beowulf-security, beowulf-updates) so that you have a stable system | 16:01 |
| tns | ok, thanks ! | 16:03 |
| psionic | when will chimera come out? | 19:54 |
| fsmithred | after debian bullseye goes stable | 19:55 |
| psionic | will it be based on 5.x kernel? | 19:55 |
| fsmithred | weeks after, not months after | 19:55 |
| fsmithred | already is. We use same kernel as debian. | 19:55 |
| fsmithred | 99% of devuan packages are unchanged from debian. | 19:56 |
| psionic | Im still at stretch with my custom compiled 5.x kernel, I tried to switch to beauwulf once but there were some issues with it, dont even remember what, maybe something related to vmware workstation, hope the new version will be working fine | 19:59 |
| buZz | i dont think vmware falls within the interest of devuan :P hehe | 20:23 |
| buZz | why not virtualbox? | 20:23 |
| buZz | or straight up libvirt stuff or something | 20:23 |
| onefang | QEMU + KVM works for me. | 21:37 |
| rwp | buZz, My understanding is that on MS-Windows that VirtualBox works well there. But under the Linux kernel that VB is awful, was at one time declared as such by Linus. | 21:40 |
| rwp | So under Devuan and a Linux kernel I suggest avoiding VB and using KVM which is a full native solution, very mature, very heavily used. | 21:41 |
| buZz | ah no clue, i use virtualbox every now and then for some win10 | 21:41 |
| rwp | If one is *on* Windows then VB is likely okay from what I hear. | 21:41 |
| rwp | If one wants to *run* Windows as a VM under Linux then it works very well using KVM. | 21:42 |
| rwp | Unfortunately the US government requires MS-Windows in many situations I interact with and there is no way for me to avoid it. | 21:43 |
Generated by irclog2html.py 2.17.0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!