| nemo | "get result error" ? weird | 00:06 |
|---|---|---|
| onefang | That was copy pasted from the VM's serial console. | 00:09 |
| onefang | The rebuilt VM is behaving now. Probably just my RAM gremlim got stuck in the old RAM disk. | 00:10 |
| * onefang goes back to actual testing. | 00:10 | |
| onefang | If the kernel actually DID detect a floppy drive, it would turn up as /dev/fd0 correct? Been a very long time since I've even seen one. Maybe qemu provides a floppy by default? | 00:15 |
| gnarface | does it? i didn't think so, but virt-manager might | 00:16 |
| gnarface | i was gonna say, it should be easy to just not enable floppies in the first place | 00:17 |
| gnarface | there's no reason a VM would need one | 00:17 |
| gnarface | and yes, /dev/fd* | 00:17 |
| gnarface | at least, i thought | 00:17 |
| Errandir | my guess is on 386 it would provide a floppy but on x86_64 it wouldn't. | 00:18 |
| gnarface | been a while since i used one | 00:18 |
| onefang | I don't even install that virt stuff, I just script qemu directly, and yep I don't tell it to add a floppy drive. | 00:20 |
| gnarface | eh, see what happens if you explicitly say no floppy then | 00:22 |
| gnarface | there might be a way to disable it at the kernel command-line too i think... | 00:22 |
| onefang | Well the VM rebuild resulted in no floppy driver crash, so I'll just blame the RAM gremlin and move on. | 00:23 |
| onefang | No /dev/fd* turned up in the VM. | 00:23 |
| rrq | https://www.qemu.org/docs/master/system/i386/pc.html | 00:24 |
| onefang | My next test is to see if I can get qemu to allocate all the RAM at start up, then see if I can divide and conquer this RAM gremlin. 128 GB real RAM VM coming up! B-) | 00:24 |
| onefang | Odd. I tell qemu to create a temporary file in /media/RAM, which is a RAM disk, then to use that as a backing store for RAM, and to preallocate it. Seems to be the only way to preallocate RAM. But there's no file in /media/RAM, qemu actually allocates the requested RAM (doesn't otherwise), AND requests that amount of cache as well. So no 128 GB VM. lol | 01:13 |
| * onefang fiddles more. | 01:13 | |
| leitz | Should I be able to find mpstat, pidstat, iostat, and sar on my devuan box? | 01:15 |
| mason | leitz: apt-file search bin/sar | 01:18 |
| leitz | mason, oddly, my system didn't have apt-file. However, "apt search mpstat" returned sysstat, which has everything and is now installed. Thanks! | 01:21 |
| mason | leitz: It's not a core utility, but it's hugely useful. If you install it, make sure to "apt-file update" before using it. | 01:22 |
| gnarface | onefang: i always just specified a static amount of ram on the command-line, never had problems with it that required extra work to "preallocate" ... i avoid the balloon driver though | 01:22 |
| mason | In short, if you don't know what package includes something, you can search with apt-file and find the right package(s) without knowing anything beyond the binary name in advance. | 01:22 |
| onefang | Ah, the qemu man page lies. I can use the -mem-prealloc optian WITHOUT the -mem-path option, then it preallocates the memory and doesn't fill up cache as wel. | 01:23 |
| onefang | I'm preallocating half my memory to the VM so I can try to divide and conquer my RAM gremlin. See if I can get it to move to the VM and not screw with the host. | 01:24 |
| onefang | But yeah normally I just "-m 32G" or whatever and don't preallocate. Coz just like every other computer I have use with an enormous amount of RAM, if I give the VM 128 GB, it takes a long time before the BIOS even shows. | 01:25 |
| onefang | So right now I'm running a qemu VM with 128 GB of RAM preallocated. Let's give it some work to do. B-) | 01:27 |
| gnarface | quake server? | 01:28 |
| onefang | It's a test VM of my Devuan install script. I did recently start adding games to it, so I have something to do to actually test it. Writing your own Freeciz ruleset is very addictive. | 01:29 |
| onefang | So now I can leave it running, with half my RAM, test lots of stuff on it, play my current fave game on it while I'm not doing anything else, and try out all those other things I normally do that tend to trip the RAM gremlin. Try them on both host and guest, see if RAM gremlin hits one, or the other, or both. | 01:32 |
| leitz | onefang, is that "FreeCiv"? | 01:36 |
| rrq | onefang: are you able to define which particular memory regions to use for qemu? | 01:38 |
| onefang | Oops, yep, FreeciV not FreeciZ. Typo. | 01:39 |
| onefang | You can do some complicated NUMA memory stuff for qemu, that's over the top for my usage at the moment. | 01:40 |
| rrq | mmm apparently one can (possibly) direct tmpfs to specific regions... you could go that way and offer the tmpfs regions as disks to do write/read load tests in | 01:43 |
| onefang | For now I'm happy with "VM can use half the memory preallocated, leave it running and test it a lot with the various things I do normally" which is what I'm up to with my current major rewrite of this install script. | 01:46 |
| onefang | So if the gremlin moves to which ever half has been preallocated to this long running VM, then I can spend time trying to track it down better. If not, I can pre-allocate before doing anything else after rebooting the host. There is a method behind this prealocation in a long running VM madness. | 01:49 |
| leitz | onefang, I hate you! I'm supposed to be job searching, not finding out about a game... | 01:50 |
| onefang | Job search with a game company. B-) | 01:51 |
| AlexLikeRock | hi | 02:05 |
| AlexLikeRock | dudes | 02:05 |
| AlexLikeRock | how are you ? | 02:05 |
| golinux | Alex | 03:23 |
| golinux | oops . . . he's gone | 03:23 |
| systemdlete | I don't have a lot to report about the apt-cacher-ng issue, but I did notice someething rather interesting upon rebooting the server running the cacher just a few minutes ago. | 12:42 |
| systemdlete | Upon logging into the server,it ran slow, took several minutes to get a login prompt. | 12:42 |
| systemdlete | And I noticed that my network monitor was getting errors when trying to check for package updates on various systems. They were all complaining about the host and port, as usual. | 12:43 |
| systemdlete | So I decided to run lsof on the port apt-cacher-ng listens to | 12:44 |
| systemdlete | port 3142, and here was the output (using dpaste now): dpaste:557FBEFA | 12:45 |
| systemdlete | I restarted the cacher and voila! Everything was peaceful again and I could run apt update without trouble. | 12:46 |
| * systemdlete knows that gnarface prefers dpaste, and it is simple enough to use | 12:47 | |
| systemdlete | (and yes, that's all obfuscated, but just the names of the innocent) | 12:48 |
| CueXXIII | uh, i get free(): double free detected in tcache 2; Aborted from dpaste in unstable… | 12:59 |
| systemdlete | CueXXIII, do you mean when you use -g ? | 13:00 |
| systemdlete | I just did it here, to check, and it comes back safe and sound. | 13:00 |
| systemdlete | no errors or warnings | 13:00 |
| systemdlete | I'm on daedalus, using stable | 13:01 |
| CueXXIII | yes, but posting a test message fails with the same error | 13:01 |
| systemdlete | oh | 13:01 |
| systemdlete | must be a problem with unstable then? | 13:01 |
| systemdlete | I can post it to another pastebin, if you like | 13:02 |
| CueXXIII | quite probably… | 13:02 |
| systemdlete | try https://paste.debian.net/hidden/950fdb6c/ ? | 13:03 |
| CueXXIII | hm, the close_wait are normal when there have been some connections | 13:05 |
| CueXXIII | hm, but the file descriptors seem to not get cleaned up… | 13:06 |
| systemdlete | but that many? | 13:06 |
| CueXXIII | yeah, might be a leaking filedescriptor bug | 13:09 |
| systemdlete | leaky code, not a leaky file descriptor, but I think that's what you mean, right? | 13:10 |
| CueXXIII | i mean the code is leaking file descriptors, yes | 13:10 |
| systemdlete | ok | 13:11 |
| systemdlete | I should mention that I recently upgraded the cacher from 3.6.4-1 to 3.7.4-1 | 13:18 |
| systemdlete | not that it matters, necesarily, but perhaps I just introduced even more bugs, idk | 13:19 |
| systemdlete | it does seem, overall, to be a bit more stable. Fewer problems overall | 13:19 |
| systemdlete | the upgrade from backports was necessary because the server is still chimaera | 13:20 |
| systemdlete | I'm saying this so that anyone trying to figure this out wont get thrown due to mismatched versions | 13:20 |
| systemdlete | best place to file bug? It looks like the github for it is upstream/sid, but I'm not sure if that where I should file it. | 13:24 |
| systemdlete | or is it better to do it on debian's bug list? | 13:25 |
| CueXXIII | how did you upgrade the cacher? if thatcame fro upstream, it's not a matter for debian's bts | 13:27 |
| CueXXIII | great, i rebuilt dpaste on unstable and now the error is gone, but i still can't get your paste identifier | 13:32 |
| systemdlete | dpaste -g dpaste:557FBEFA | 13:32 |
| systemdlete | doesn't work for you? | 13:32 |
| CueXXIII | nope, sits there for 7 s and then just quits | 13:33 |
| systemdlete | I did the upgrade using apt and -t chimaera-backports | 13:33 |
| systemdlete | hmm | 13:33 |
| systemdlete | I'm not sure where the package was built from. I got it from the backports repo, that's all I know. | 13:34 |
| CueXXIII | backports still belongs to debian | 13:35 |
| systemdlete | so why wouldn't it be for debian's bts? Sorry I am not clear on this | 13:35 |
| CueXXIII | no, you can file it on debian's bts | 13:37 |
| systemdlete | ok | 13:37 |
| systemdlete | thanks | 13:37 |
| CueXXIII | ok, dpaste forgot my paste test after ~10 minutes | 13:54 |
| CueXXIII | systemdlete: cyn you still access dpaste:32564133 - or your paste? | 13:55 |
| systemdlete | I could not retrieve the original, but I just made another paste: dpaste:5D424A53 | 14:02 |
| systemdlete | and I am able to retrieve it | 14:03 |
| systemdlete | it spills to stdout | 14:03 |
| CueXXIII | got it, too | 14:06 |
| CueXXIII | https://github.com/sim590/dpaste/issues/19 | 14:07 |
| CueXXIII | so it is working as intended… | 14:08 |
| systemdlete | so then what was the "free(): double free detected in tcache 2; Aborted from dpaste in unstable…" commotion? | 14:09 |
| CueXXIII | i guess some abi change in one of dpaste's dependencies | 14:09 |
| systemdlete | I need to get some sleep. | 14:09 |
| systemdlete | Hopefully, gnarface or rrq or other will see this thread and maybe have a suggestion with this information provided in my paste. | 14:10 |
| CueXXIII | since the dpaste in unstable is the same binary as the one in stable, but rebuilding it fixed the error | 14:10 |
| systemdlete | oh, I see. | 14:10 |
| systemdlete | https://paste.debian.net/hidden/950fdb6c/ (to avoid the 10 minute timeout?) | 14:12 |
| get | hi all | 22:08 |
| debdog | oy! | 22:08 |
| get | any howto arround to get installed php5.6 and 7.0 on chimaera ? tried the debian11 way but the packages are depending on systemd.... | 22:09 |
| get | and dont want go back in evolution | 22:10 |
| gnarface | get: 2 versions of php installed concurrently without virtualization or heavy repackaging? you don't. php7 is already on chimaera though, that shouldn't have been any problem to install... | 22:13 |
| get | yes, it comes with 7.4 but i need 7.0 as far or 5.6 for a software im using. | 22:14 |
| get | will run it with php-fpm so i can run them in paralel | 22:14 |
| gnarface | OH i see... well, have you considered virtualization? you could run the php7 stuff in one guest and the php5.6 stuff in another guest... | 22:15 |
| get | my actual control panel doesnt support this yet. | 22:15 |
| get | what kind of virtualization you suggest? | 22:16 |
| gnarface | whatever | 22:16 |
| gnarface | kinda depends on what hardware you've got | 22:16 |
| gnarface | qemu is the best if you have hardware acceleration available for it and you're not subjecting it to load, just testing | 22:17 |
| get | years ago i managed xen hypervisor, qemu but we deployed a host for this. | 22:17 |
| gnarface | qemu is solid and well supported it's just complicated to setup right | 22:17 |
| gnarface | usually for production services i use linux-vservers actually, but that's not well supported anymore, so even though it's massively more efficient and secure and hardware-agnostic, i can't really advise it for someone who isn't comfortable with using super intrusive 3rd party kernel patches | 22:18 |
| get | i already have this box running with chimaera for over 6months as webhost. Xeon(R) CPU D-1521 2x480 ssd and 32gb ram. | 22:18 |
| gnarface | it can probably handle qemu fine | 22:19 |
| gnarface | other people around here might have some other advise... i think vbox is popular despite the bugs | 22:19 |
| gnarface | *advice | 22:19 |
| get | i think yes. but on other hosts, what are running debian i installed via apt the needed versions and conf'd it into my panel and done. | 22:20 |
| gnarface | maybe there's a way to actually install 2 php versions concurrently safely but that'd be news to me | 22:20 |
| get | https://tecadmin.net/how-to-install-php-on-debian-11/ | 22:21 |
| gnarface | the thing about using php7 because whatever you need isn't available for 7.4 though... eh, as a php developer of longer than there's been actual releases of php (since the early betas) that sounds like a really bad idea | 22:21 |
| gnarface | and actually, fcgi is just garbage too | 22:23 |
| gnarface | you should really reconstruct your solution around mod_php with apache or you're in for a lot of pain | 22:23 |
| gnarface | sorry if that's not what you want to hear | 22:23 |
| gnarface | i actually used to do this for a living, so i actually know | 22:24 |
| gnarface | stick around, i'm sure someone else here can give you other opinions | 22:25 |
| get | im basically trying to get other versions as the included into the main repo | 22:25 |
| get | and no, im using nginx and fpm | 22:25 |
| gnarface | https://pkginfo.devuan.org/cgi-bin/policy-query.html?c=package&q=%5Ephp%5B0-9%5D%5C.%3F%5B0-9%5D%3F%24&x=submit | 22:26 |
| gnarface | well, you can easily see all the php versions and what devuan release they correspond do | 22:26 |
| gnarface | correspond to* | 22:26 |
| gnarface | mixing releases is a very bad idea (debian would tell you the same) | 22:26 |
| get | ah | 22:26 |
| gnarface | i think here's the php-fpm versinos https://pkginfo.devuan.org/cgi-bin/policy-query.html?c=package&q=%5Ephp.*fpm%24&x=submit | 22:28 |
| gnarface | *versions | 22:28 |
| get | ah so basically i can use those mirrors to install via apt | 22:28 |
| gnarface | yes, but keep in mind you're strongly advised to only use them in installs of the actual release version they belong in, hence my suggestion to virtualize so you don't mix them and make a "frankendevuan" | 22:29 |
| gnarface | apt will definitely not stop you from mixing releases, though mundane package dependency version conflicts might... if you were to force your way around them though, in the long run that's worse because even if it seems to work initially it introduces unfixable and sometimes even untraceable gremlins | 22:30 |
| get | ah ok they are not prepared to be "modular" | 22:30 |
| get | they are depending on the host-version | 22:30 |
| gnarface | they're packaged so within the individual php versions they're modular, so you don't necessarily have to install all the optional php packages of that particular version... in that sense they're very modular, and quite a bit more so than other distros in fact | 22:31 |
| gnarface | but no, they absolutely never intended you to run 2 different php versions on the same install | 22:31 |
| gnarface | that's not part of the security model or the expected use cases | 22:32 |
| gnarface | and whatever white whale you're chasing that makes you think you require this... it's probably based on some fundamental error in judgement somewhere, sorry | 22:33 |
| gnarface | (maybe not yours, maybe your employers, i dunno, i pass no judgment) | 22:33 |
| gnarface | but you can easily just have two separate installs of two separate releases, one for each php version you need, that'll work with 2 physically separate computers or virtual machines... hell you could even pull it off with chroots | 22:34 |
| fsmithred | add xserver-xephyr and you can have a chroot with a desktop. | 22:35 |
| gnarface | good tip, fsmithred | 22:43 |
| dev01beginner | guide for minimal-install for devuan? | 22:52 |
| fsmithred | un-check everything except system utilities at the tasksel window | 22:52 |
| fsmithred | reboot into the new system and add whatever else you want | 22:52 |
| fsmithred | if you want more minimal, un-check the system utilitites, too. | 22:53 |
| fsmithred | I predict you'll add most of them anyway. | 22:53 |
| dev01beginner | i'm going to be using a minimal-live iso | 22:54 |
| dev01beginner | to install | 22:54 |
| gnarface | they're only a couple megabytes | 22:54 |
| gnarface | don't use minimal-live to install | 22:54 |
| gnarface | use the netinstall iso | 22:54 |
| fsmithred | https://www.devuan.org/os/documentation/install-guides/daedalus/install-devuan | 22:54 |
| gnarface | but keep a copy of minimal-live to fix stuff if you break it | 22:54 |
| dev01beginner | ok | 22:54 |
| fsmithred | ok, that link is not for minimal-live. Actually there is no install guide for the minimal-live | 22:55 |
| gnarface | yea, but the minimal live install is basically just like the other live disks; you boot it then run something that copies the contents over to your harddrive | 23:00 |
| gnarface | it's not a traditional "install" experience and may not give you the same results | 23:00 |
| gnarface | it's perfectly valid but if you're doing this for the first time you want to have results that most align with the expected setup various 3rd party tutorials you're following will assume | 23:01 |
| fsmithred | I agree | 23:02 |
| gnarface | but all the live isos are very useful as general purpose test/repair/recovery utilities | 23:02 |
| gnarface | it's definitely a good idea to keep a copy locally | 23:02 |
| fsmithred | also possible to debootstrap from the live isos | 23:02 |
Generated by irclog2html.py 2.17.0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!