| [-_-] | hello there | 14:44 |
|---|---|---|
| [-_-] | when I open htop, I see multiple instances of the same app, like many xorg entries | 14:44 |
| [-_-] | do those take separate resources ? | 14:44 |
| [-_-] | or do they share the same ram and cpu chunk? | 14:45 |
| djph | yes. | 14:45 |
| [-_-] | yes ? | 14:45 |
| djph | Child processes may share (some or all of) the parent's resources, or they get their own chunks. | 14:46 |
| [-_-] | how can I list process that only the separate chunks are represented? | 14:47 |
| djph | dunno, it's never bothered me. Maybe the manual for (h)top will be helpful there | 14:47 |
| [-_-] | it is bothering me, I saw lxle gui by default takes only ~200 MB | 14:48 |
| [-_-] | yet mine takes ~600 MB | 14:48 |
| [-_-] | but I use dwm !!!! | 14:48 |
| [-_-] | this is unacceptable | 14:49 |
| [-_-] | what did they do that I did not? | 14:49 |
| [-_-] | also I am not using systemdos | 14:49 |
| nemo | hmmm machine did not come back after following debian → devuan instructions for a Debian 12 → dædalus VM on OVH. Maybe I should try Debian 10/11 → chimæra? | 15:18 |
| nemo | it's a brand new VM so I can try whatever | 15:18 |
| fsmithred | or maybe debian 11 to daedalus? | 15:20 |
| fsmithred | do you have access to any error messages? | 15:21 |
| gnarface | [-_-]: i dunno htop but regular top doesn't show individual threads by default (though it can be enabled there too) | 15:31 |
| gnarface | it would not be ridiculous to assume htop can disable them | 15:31 |
| gnarface | check the docs | 15:31 |
| nemo | fsmithred: doesn't seem to have anything like that in the web console | 15:34 |
| nemo | fsmithred: nor any visual VM | 15:34 |
| nemo | like a VT | 15:34 |
| nemo | fsmithred: I was following this btw https://www.devuan.org/os/documentation/install-guides/daedalus/bookworm-to-daedalus | 15:36 |
| nemo | fsmithred: and didn't come back at the reboot just before dist-upgrade | 15:36 |
| nemo | ovh debian 12. but I'll try 11 | 15:36 |
| nemo | I have another ovh vm that's working fine on dædalus, but I upgraded it from chimæra... and maybe beowulf. can't remember... | 15:37 |
| nemo | it was a pretty painless switch at the time. I don't even think I filed a guide | 15:37 |
| nemo | only thing I did differently was switch the default username to nemo ☺ but that should not have changed anything | 15:39 |
| nemo | hm. actually, another thing I didn't do, was use their sources.list exactly | 15:48 |
| nemo | I'd copied and pasted from one of my existing dædalus machines.. | 15:48 |
| nemo | maybe that's the problem. | 15:48 |
| nemo | the main difference is they enabled backports | 15:48 |
| nemo | I guess I can try 12 one more time but following more exactly | 15:49 |
| nemo | .. eh. unless anyone here thinks it matters, since I already did the 11 reset will do that first. kinda don't have a ton of time to play around with variations. | 15:51 |
| fsmithred | I think upgrade/migration from 11 to daedalus might be easier. And yes, disable backports just in case. | 15:55 |
| fsmithred | check 'apt policy backports' to make sure priority is low | 15:55 |
| fsmithred | $backports | 15:56 |
| fsmithred | whatever the right name is | 15:56 |
| nemo | oh they had backports commented out in their example anyway | 15:56 |
| nemo | so that can't be it | 15:56 |
| nemo | just hadn't noticed until I copied it | 15:56 |
| nemo | hm. I also had all the extra enabled like non-free and firmware, and while I feel that shouldn't matter... following theirs exactly on that too | 15:57 |
| fsmithred | maybe try or take a look at tito's migration script. | 16:02 |
| fsmithred | https://git.devuan.org/farmatito/migration | 16:08 |
| lyubov | i'm having issues with xdg-mime and xdg-open. xdg-mime query filetype does not return the filetype name and xdg-open fails to identify the filetype so cannot chose the default program and reverts to opening with the browser. is this a bug? | 16:11 |
| gnarface | probably, what's the file type? | 16:12 |
| gnarface | does "file" recognize it? | 16:12 |
| gnarface | so far i've managed to get by without xdg-mime and xdg-open. maybe you can too. | 16:13 |
| fsmithred | I think part of the problem is that whatever gets installed last becomes the program to open all files that possibly can. | 16:13 |
| fsmithred | I had to manually set file associations in the desktop-live isos to avoid that. | 16:14 |
| lyubov | what package installs file? | 16:16 |
| gnarface | package of the same name | 16:16 |
| lyubov | thanks, file works | 16:17 |
| lyubov | now xdg-mime works as well | 16:17 |
| gnarface | interesting | 16:17 |
| lyubov | thank you gnarface fsmithred | 16:17 |
| gnarface | no problem | 16:17 |
| lyubov | nevertheless, file obviously isn't a dependency of xdg-utils, but i guess this problem only emerges in minimal/server installs | 16:18 |
| gnarface | possibly the xdg stuff wasn't tested with "recommends" off | 16:19 |
| gnarface | or something like that | 16:19 |
| gnarface | my guess is they have a shared dependency but the package for file knows about it and whatever package xdg-mime is in doesn't | 16:21 |
| nemo | fsmithred: ok. back on the install of eudev. I got a "fatal" from insserv saying that service mountkernfs has to exist for eudev and service urandom has to exist for service networking | 16:23 |
| nemo | but going to continue w/ the instructions | 16:23 |
| nemo | the apt-get -f install did nothing.. | 16:24 |
| nemo | bit concerned about a "fatal" in something called "mountkernfs" | 16:24 |
| nemo | so not feeling good about the reboot | 16:24 |
| gnarface | how does urandom not exist? | 16:24 |
| gnarface | sounds like a VM problem | 16:24 |
| nemo | urandom exists | 16:25 |
| nemo | just not "service urandom" I guess | 16:25 |
| nemo | whatever that is | 16:25 |
| gnarface | are the permissions right on /dev/urandom ? | 16:25 |
| nemo | nemo@familybox:/etc$ ls init.d/*rand* | 16:25 |
| nemo | init.d/urandom | 16:25 |
| nemo | gnarface: crw rw rw | 16:25 |
| nemo | hmm /etc/init.d/urandom definitely exists. weird | 16:26 |
| nemo | maybe I can try reinstalling eudev and networking | 16:26 |
| nemo | /etc/init.d/mountkernfs.sh also exists | 16:27 |
| nemo | and they both provide urandom and mountkernfs. so initserv should not be erroring | 16:27 |
| nemo | er. insserv | 16:27 |
| nemo | gnarface: I'm trying to follow that debian to devuan guide on devuan.org for context if you missed that part ☺ debian 12 failed, so attempting 11 | 16:28 |
| nemo | gnarface: I'm at the "install eudev" stage and the apt install seems to be freaking out for inexplicable reasons | 16:28 |
| fsmithred | https://www.devuan.org/os/documentation/install-guides/daedalus/bookworm-to-daedalus | 16:28 |
| nemo | fsmithred: yep that one | 16:29 |
| nemo | hmm eudev exists in rc 0 6 S.. but nothing else. that alone could explain why the VM died on reboot | 16:30 |
| nemo | going to attempt reinstall | 16:30 |
| nemo | no errors on reinstall, but it's still only in those runlevels | 16:30 |
| gnarface | that looks normal | 16:31 |
| nemo | ah. yeah. just checked mine at home | 16:31 |
| nemo | ok | 16:31 |
| nemo | fingers crossed! | 16:31 |
| nemo | trying the reboot :) | 16:31 |
| gnarface | i think something is still wrong, and i read that guide and i'm not super sure the advice to reboot at that point is sound | 16:31 |
| gnarface | that said, this seems like a VM issue | 16:31 |
| nemo | gnarface: oh. is there anything I should try before reboot? | 16:32 |
| gnarface | maybe something that can be avoided by changing the VM config, i could only speculate | 16:32 |
| gnarface | what type of a VM is it? maybe it's a known issue in their community | 16:32 |
| nemo | OVH default Debian 10/11/12 | 16:33 |
| nemo | don't think there's anything that special about it | 16:33 |
| nemo | their sources list seems standard | 16:33 |
| gnarface | hmm | 16:33 |
| gnarface | is it real virtualization? does your guest run its own kernel? | 16:34 |
| fsmithred | Here's the link to tito's script: https://git.devuan.org/farmatito/migration/src/branch/master/migration.sh | 16:34 |
| nemo | gnarface: yes | 16:34 |
| fsmithred | The comment for the list of devuan packages that includes eudev says "order matters" | 16:34 |
| gnarface | so i'm wondering if the VM system has some sort of clamp down on changing disk mounts on the fly as a security issue | 16:34 |
| nemo | fsmithred: oh. does it not match the guide? | 16:34 |
| fsmithred | I haven't compared it in detail, but it is definitely different from the guide. | 16:35 |
| fsmithred | line 575 | 16:35 |
| nemo | oops should have fetched the raw | 16:38 |
| nemo | fsmithred: hm. I guess I'll try the script's list, but a bit late now since "order matters" :( | 17:04 |
| nemo | I might be starting over using that script | 17:04 |
| nemo | if it's successful... maybe guide should recommend it | 17:05 |
| nemo | preferentially | 17:05 |
| nemo | oh. that script is clearly desktop oriented | 17:06 |
| nemo | it's pulling in x11 stuff which I definitely don't want | 17:06 |
| nemo | reviewing the list | 17:06 |
| nemo | probably elogind | 17:06 |
| nemo | ok. after stripping elogind, everything else was already setup | 17:07 |
| nemo | going to attempt reboot then | 17:07 |
| nemo | it's back \o/ | 17:08 |
| nemo | wooo | 17:08 |
| fsmithred | cool! Script worked ok? | 17:08 |
| nemo | fsmithred: nope | 17:08 |
| nemo | fsmithred: I think Debian 11 was the key change | 17:08 |
| nemo | which is sad | 17:08 |
| nemo | fsmithred: I copied that one line from the script, but everything in it was already installed from the guide, except the desktop pieces I didn't want | 17:08 |
| nemo | fsmithred: the only other key deviation this time was copying the guide's source list exactly. but I really don't see why that would matter. mine had " main non-free non-free-firmware contrib" vs "main" in the guide.. but that's all | 17:09 |
| nemo | ok. going to continue w/ the guide. fingers crossed | 17:09 |
| fsmithred | yeah, I don't think the non-free stuff would cause a problem. | 17:10 |
| nemo | fsmithred: if debian 12 is an issue, might need to warn people :( | 17:10 |
| fsmithred | I would think excluding it might cause problems. | 17:10 |
| nemo | and. hope it's not a sign of a long-term trend | 17:10 |
| fsmithred | what, that debian is getting more and more fucked up? | 17:11 |
| fsmithred | newsflash... | 17:11 |
| fsmithred | old news | 17:11 |
| fsmithred | upgrades within devuan seem to be getting easier | 17:12 |
| nemo | heh | 17:12 |
| nemo | fsmithred: sadness for me at work - I wanted to setup vmware view's agent. it failed on devuan... because the install script only supported chkconfig, upstart and systemd | 17:15 |
| nemo | sooo I get to update their installer to add sysv or more likely update-rc.d | 17:16 |
| nemo | but yeah... trends | 17:16 |
| nemo | hoping whatever chkconfig does it probably ends up with something in init.d I can copy | 17:17 |
| blizzow | I would like to install ceres on an encrypted btrfs partition on a GPT partitioned drive to boot off UEFI using an efistub instead of grub or some other bootloader. | 19:55 |
| blizzow | I think this kind of forces me to do an install using debootstrap. | 19:55 |
| blizzow | I've downloaded the large installer image and booted off it. | 19:56 |
| blizzow | When I run the debootstrap command, it fails during unpacking base system. | 19:57 |
| blizzow | It says it's failing on trying to install cron-daemon or adduser. | 19:58 |
| blizzow | When I was perusing the log of debootstrap I feel like I saw something about a systemd requirement which really blew my mind. | 19:59 |
| fsmithred | maybe libsystemd0 | 19:59 |
| blizzow | Anyone know what I might be doing wrong or encountering here? | 19:59 |
| blizzow | I thought devuan was systemd free and would expect the debootstrap script/requirements to not contain anything that required systemd. | 20:00 |
| fsmithred | did it fail more than once? Sometimes it's just a problem connecting to the repo. | 20:00 |
| fsmithred | systemd init system is not installable in devuan. Some libraries are because lots of things depend on them, even if they do nothing. | 20:01 |
| blizzow | fsmithred: I think I've done this about 5 times now. | 20:02 |
| fsmithred | it's been a few months since I've done a debootstrap, and it always has worked for me. | 20:02 |
| fsmithred | What command did you use? | 20:02 |
| blizzow | I used debootstrap --arch amd64 ceres /mnt/target http://deb.devuan.org/merged/ ceres | 20:05 |
| fsmithred | that looks the same as what I use (except you don't need the 'ceres' at the end.) | 20:05 |
| fsmithred | I'm trying it now, but it could take a long time with my slow internet. | 20:07 |
| onefang | Ceres being "unstable" means it might be broken at any given time. | 20:09 |
| fsmithred | good point | 20:09 |
| fsmithred | OK, in five minutes I only have four lines of output. Still waiting at "Retrieving Packages" | 20:11 |
| onefang | Also it is currently in the middle of package mirrors update'o'clock. | 20:12 |
| onefang | And one of the DNS-RR mirrors is currently foiling the update. | 20:13 |
| onefang | 141.84.43.19 2001:4ca0:4300::1:19 | 20:13 |
| onefang | Er s/foiling/failing/ | 20:14 |
| fsmithred | I gave up. It did nothing after checking the key. | 20:17 |
| onefang | Try with a more stable release? | 20:18 |
| blizzow | I'd expect the base system packages that debootstrap requires is very static. | 20:19 |
| fsmithred | I'm running daedalus - it should at least download packages. | 20:19 |
| onefang | Try one of the package mirrors directly, instead of deb.devuan.org? | 20:20 |
| onefang | And I meant try installing a more stable release than ceres. | 20:20 |
| fsmithred | I get the same result with daedalus. It hangs after checking the key. I'm blaming it on the clouds overhead. (not kidding) | 20:22 |
| onefang | Insert "old man yells at clouds" meme here. | 20:23 |
| fsmithred | lol | 20:24 |
| fsmithred | Download: 0.07 Mbit/s | 20:24 |
| onefang | Ouch. | 20:24 |
| fsmithred | upload is 1.62 | 20:24 |
| blizzow | Tried with daedalus. That worked. | 20:24 |
| blizzow | I guess my workaround is to debootstrap daedalus, change apt.sources.list to ceres, chroot and apt upgrade? | 20:35 |
| fsmithred | technically you should go to excalibur first, but it might not matter. | 20:36 |
| golinux | Why are you wanting to run Ceres? | 20:36 |
| golinux | It will always be unstable and never become an official release | 20:38 |
| blizzow | I like new features sometimes? | 20:51 |
| rwp | The most reliable way to install Unstable is to install Stable first and then upgrade. | 20:54 |
| rwp | And that should not be any hardship since if one is running unstable then one will always be upgrading so that's just a normal day. | 20:54 |
| rwp | blizzow, When you debootstrap'd to boot a UEFI system the most confusing part is getting the partitioning suitable. I definitely recommend using the netinst installer from Stable at least once to have it set up suitable partitioning. Use that as a reference. | 20:59 |
| rwp | There are at least three different partition layouts depending. Legacy BIOS (which is simplest). UEFI. UEFI with Legacy CSM. All three are different. And then there are other variations too. | 21:01 |
| brocashelm | blizzow: depending on your use cases, try daedalus-backports versions of packages and see if that suits you fancy | 21:38 |
| brocashelm | i used ceres for the past 2.5 years and only had a few problems that weren't my own doing -- that were remedied rather quickly by applying specific fixes or apt-pinning a buggy version for the next build | 21:39 |
| brocashelm | the thing is it is a lot of updating, which becomes a chore easily | 21:40 |
| brocashelm | you'd be better off using a rolling release like artix or void than devuan ceres | 21:41 |
| n4dir | i tend to disagree | 21:41 |
| n4dir | but that probably is a question of taste or use case or such | 21:41 |
| brocashelm | if you know what you're doing and don't mind helping out, ceres and installing from experimental would definitely be a plus for both parties | 21:42 |
| n4dir | experimental: rather not | 21:42 |
| n4dir | also i really never ran in anyone really using it, besides for the lulz | 21:43 |
| brocashelm | experimental is for helping out the devs, like if they asked to test a build of dbus before pushing to ceres | 21:43 |
| brocashelm | but yeah, it isn't a merged repo, unlike debian's experimental (something to keep in mind) | 21:43 |
| n4dir | what exactly is he looking for, regarding ceres? I don't know artix, but i ran Void for a while. | 21:44 |
| brocashelm | he said he likes "new features", so ceres would be it if using devuan | 21:44 |
| n4dir | i too would rather use ceres then. | 21:45 |
| rwp | experimental is not a general purpose suite. experimental is a dropbox for specific packages which need a test before upload to unstable. | 21:45 |
| brocashelm | just be sure to install apt-listbugs and apt-listchanges, and always read the change logs/bug reports BEFORE confirming | 21:45 |
| n4dir | and backups | 21:45 |
| brocashelm | agreed, hence why i said unstable + experimental (for helping out with unstable faster) | 21:46 |
| n4dir | you could also install ceres in an emulator, and before you do the upgrade, you do it there | 21:46 |
| n4dir | depending how safe you want to be | 21:46 |
| n4dir | my whole point was: i ran debian sid for quite some years, and it was pretty stable | 21:46 |
| brocashelm | there are some packages that are on ceres that didn't get backported to daedalus, so i specifically install those packages | 21:47 |
| brocashelm | stable as in "doesn't crash" | 21:47 |
| n4dir | yeah, like that | 21:47 |
| brocashelm | but unstable technically means it changes. all the time | 21:47 |
| rwp | I run unstable along with having testing in sources.list so that when something is really broken I can more easily reach into the previous version which is hopefully still in testing. | 21:47 |
| brocashelm | testing IMO is a bit more of a gamble compared to unstable, since a bug fix might not make it in time | 21:48 |
| n4dir | brocashelm: that is why i don't run it anymore. I often don't start the PC for weeks or even months. | 21:48 |
| rwp | Crashing is usually a Linux kernel area. Right now I cannot run Linux 6.5 due to bugs there and must run the previous 6.4 instead. That's active right now in Unstable Ceres. | 21:48 |
| n4dir | brocashelm: many recommended to use a mixed testing unstable for the reason you just said | 21:48 |
| brocashelm | n4dir: same, i actually just wanted to go back to stable without a reinstall ;) | 21:48 |
| brocashelm | rwp: i run 6.4 kernel from backports; noticing the kernel module isn't picking up my firewall on lynis audits, and no swap usage at all | 21:48 |
| n4dir | at the end of the day it is his choice anyway. You know what you might run into. Then you have to decide | 21:49 |
| brocashelm | i think 6.3 is functional in that department | 21:49 |
| brocashelm | rwp: i tried to install 6.5 to see if that would fix the above issues, but it had issues updating, so i removed it and sorted things out | 21:49 |
| rwp | A smooth sea never made a skilled sailor. Running Unstable is a way to guarantee rough seas. Learning to navigate those seas is a teaching experience. | 21:51 |
| rwp | The problem is not intrinsically in running Unstable. The problem is that many people then complain about the problems instead of working to fix them. | 21:52 |
| n4dir | i am not sure if i learned much running debian-sid. | 21:52 |
| brocashelm | i definitely learned from it, but i would understand a gentoo/slackware/arch user learning even more | 21:52 |
| brocashelm | debian patches a lot of stuff and splits packages up more so you can pick and choose what components to use/avoid | 21:53 |
| blizzow | Just throwing this out herein case any devuan devs are interested. I'm getting the same difficulty debootstrapping excalibur that I am with ceres. Daedalus works fine. | 23:11 |
| rrq | good morning. which "same difficulty" is that? | 23:16 |
| rrq | ... and which platform are you debootstrapping on? | 23:17 |
| blizzow | rrq, I'm debootstrapping an amd64 system. I'm doing this because I want to use an encrypted root partition (btrfs+luks or zfs) and EFIstub as the bootloader. | 23:19 |
| rrq | fine. which platform are you debootstrapping on? | 23:20 |
| blizzow | I'm also on an amd64 system. The difficulty is debootstrapping ceres or excalibur dies out while unpacking the base-system. The output says (possibly the package cron-daemon-common is at fault) | 23:22 |
| blizzow | Looking at the logs, there are complaints about systemd in there. | 23:22 |
| rrq | ok. which OS are you using to run debootstrap; and which debootstrap? | 23:23 |
| blizzow | I'm using poop-OS 22.04. I uninstalled the OS deboostrap package and installed the most recent I could find from devuan. | 23:26 |
| blizzow | I also tried booting the 4GB devuan 5.0.1 image and running the same process and got the same issue. | 23:26 |
| blizzow | I'm going to be right back because I accidentally did an rm -rf /* in my chroot while proc/sys/dev were mounted. | 23:27 |
| rrq | thanks... I have a memory of some issues with the coming cron-daemon-common package but haven't followed it | 23:27 |
| rrq | did you check at bug.debian.org? | 23:27 |
| rrq | bugs.debian.org | 23:28 |
| rrq | btw I guess you are aware that excalibur and ceres are package collections for testing; ceres is for testing package groups individually rt function, and excalibur for testing them in relation to each other... not actual "distributions" normally | 23:30 |
| rrq | rt="with respect to" | 23:31 |
| blizzow | rrq: yeah, I'm aware that they're for testing. | 23:31 |
| rrq | so discovering that, say, cron-daemon-common has gained (spurious?) dependencies on systemd is a good thing and something to make a bug report for | 23:32 |
| rrq | that package is (has been) from debian, i.e. not forked, so any bug report about it should go there. | 23:34 |
| rrq | (you can see that from it's version tag not containing "devuan") | 23:35 |
| rrq | if the issue leads to a new need of forking, then that's less good of course | 23:41 |
| rrq | it then will take someone to raise their hand as fork maintainer, and that one doing the work | 23:42 |
| rrq | (i.e. identify the cause and work around it... or at worst, blacklist the package) | 23:43 |
| rrq | your personal workaround might be to exclude that package from debootstrap, whatever ramifications that might have | 23:45 |
| blizzow | I submitted a bug report. Given debian's choice to embrace systemd, I wouldn't imagine they care if yet another item depends on systemd. I did try a --exclude directive to debootstrap and it failed similarly, I may have had a typo or improper syntax I guess. | 23:46 |
| rrq | did you try --variant=minbase ? ... (given that cron-daemon-common is merely "important" and not "required") | 23:50 |
| blizzow | I did not realize that was an option. | 23:51 |
| rrq | (btw, I think of "debian" as an amorphous group of people where many (or most, even) are sensible) | 23:52 |
| rrq | fair enough. the RTFM advice is: use "man debootstrap" :) | 23:53 |
| blizzow | I guess that brings up - how is cron being installed in ceres or excalibur if this dependency exists? I think of cron as a 'low level' package and would think most installs would trigger the need for it early. | 23:55 |
| rrq | again: excalibur and ceres are not "releases" ... they are "package collections"; I guess anyone using such package collection as if a release would find their way of running cron if they need it. | 23:58 |
Generated by irclog2html.py 2.17.0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!