| chozorho | Hey... is anyone online who can help solve a chimaera-update-related error? | 04:02 |
|---|---|---|
| Hydragyrum | don't ask to ask, just ask | 04:03 |
| chozorho | well... I may have done something stupid. Originally, back in January 2021, I installed Devuan on my laptop -- so far, so good. But then in September, for some reason -- I guess out of curiosity and because I used to experiment with my Linux machines -- I added the "chimaera" to my apt-sources, tried doing apt update / upgrade, but then... | 04:13 |
| chozorho | it ended up upgrading a huge number of packages, including GCC 10 and probably glibc and others... and when I rebooted, I went to enter the passphrase for my LUKS encrypted drive, but it kept aborting, and I amunable to log in. I've had to use a livecd ever since then... | 04:15 |
| chozorho | the error message says "libgcc_s.so.1 must be installed for pthread_cancel to work", which is really weird, because... | 04:15 |
| chozorho | it seems awfully similar to *this* bug right here: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=950254 | 04:15 |
| fluffywolf | I have no idea how to fix things when they're on an encrypted drive you can't access. | 04:17 |
| chozorho | but the problem is, that bug's "solution" still isn't clear to me. It's talking about keeping that shared library, libgcc_s.so.1, in the right directory. But even if I keep it in both /lib and in /lib/x86_64-linux-gnu, the error isn't resolved.... | 04:17 |
| Hydragyrum | can you open the luks encrypted volume from the livecd fine? | 04:17 |
| chozorho | ah, but I *can* access them, if I use a clever cryptsetup command that I launch from the livecd :P | 04:17 |
| chozorho | yep :D | 04:18 |
| Hydragyrum | I'd suggest updating the initramfs and making sure that it includes the right things | 04:18 |
| Hydragyrum | also, while the libgcc_s.so.1 may be in the right dir *on your normal root*, it's almost certainly *not* there on the initramfs | 04:19 |
| fluffywolf | if you chroot to the encrypted drive, do you get a working system? if so, try apt-get update, upgrade, etc, and make sure initramfs-tools 0.140 gets installed and the initramfs rebuilt. | 04:19 |
| Hydragyrum | and if it's not opening your encrypted volume, I assure you that it's not looking at the files on your normal root | 04:20 |
| golinux | Did you do a dist-upgrade? Or just an upgrade? | 04:20 |
| golinux | There is a sequence to upgrading and maybe you didn't do a full upgrade. | 04:20 |
| fluffywolf | from the bug report they pasted, it sounds like a bug that's been fixed in a newer version of initramfs-tools. | 04:21 |
| fluffywolf | so the question is how to install that newer version and have it rebuilt the initramfs when you can't boot the drive. | 04:21 |
| fluffywolf | and hope that fixes it. :) | 04:22 |
| Hydragyrum | importantly, you need to make sure your /boot (and other filesystems) are mounted when you do that upgrade chrooted into that install) | 04:24 |
| fluffywolf | hrmm, yeah, if you have them as separate partitions. I usually don't.... | 04:24 |
| Hydragyrum | with an encrypted drive, you normally need to | 04:25 |
| Hydragyrum | or at least it's a real pain with /boot encrypted | 04:25 |
| chozorho | hmmm ty for the feedback. I am slowly checking these one by one (I can chroot into it, and I just regenerated the initrd in /boot) | 04:53 |
| cws7788 | can not run " pkexec pcmanfm ",Is it lack of dependence? | 05:22 |
| cws7788 | pokit-agent-helper-1:error response to polickit deamon : gdbus.error:org.freedesktop.polickit1.error..failed: no session for cookie | 05:22 |
| cws7788 | Which program creates sessions? | 05:23 |
| rwp | cws7788, In Devuan elogind creates user sessions. And that's about the extent of my knowledge of it. I don't use it myself. | 05:49 |
| rwp | With encrypted drives I always have /boot as a separate plain not encrypted 512MB partition. | 05:53 |
| rwp | Similarly to the others I think /boot needs to be mounted in the chroot and the initramfs rebuilt after having upgraded the system. | 05:54 |
| systemdlete | Again, this might be a question I should have asked back in *nix sysadmin 101: Is there a command analogous to uptime that gives analogous statistics for I/O in the last 1,5,and 15 minutes? | 05:55 |
| Hydragyrum | iostat | 05:56 |
| systemdlete | thank you! | 05:56 |
| Hydragyrum | actually, I don't know if iostat can do the "last n" that well | 05:57 |
| Hydragyrum | /proc/diskstats and /sys/block/*/stat may also be useful | 05:59 |
| systemdlete | what I am looking for, actually, is something I can use to monitor i/o used for each file system, so actually, iostat looks promising | 06:00 |
| Hydragyrum | iotop may also be useful | 06:00 |
| systemdlete | iotop is more of a curses program I thought. At least that is how I used it | 06:01 |
| Hydragyrum | yeah it is | 06:01 |
| systemdlete | ah, -b | 06:01 |
| systemdlete | (batch mode) | 06:01 |
| Hydragyrum | sysstat may also be helpful for keeping long-term data on io | 06:02 |
| systemdlete | Hydragyrum: I think iotop may be more what I am looking for. This *might* tell me who the "offenders" are... | 06:02 |
| Hydragyrum | yeah | 06:02 |
| systemdlete | (I'm noticing high i/o lately) | 06:02 |
| Hydragyrum | (sysstat's the package iostat comes from, and has options to collect/store stats) | 06:03 |
| systemdlete | gosh. thank you | 06:03 |
| systemdlete | it has been so long since I've looked at this kind of thing | 06:03 |
| Hydragyrum | np | 06:04 |
| systemdlete | Maybe i can think of a way to yank just the highest io user over the past n minutes | 06:04 |
| systemdlete | I think that is mostly what I am after | 06:04 |
| systemdlete | not to say that that one is "the pig" -- it could be that no one is being a pig. Someone is always the highest user | 06:05 |
| systemdlete | but if I am noticing slow response times, that might help me target the problem. idk | 06:05 |
| Hydragyrum | https://github.com/sysstat/sysstat#introduction might help | 06:05 |
| systemdlete | thanks once more. pidstat looks like a candidate, based on its name.. | 06:06 |
| systemdlete | pidstat -d maybe... | 06:11 |
| jla | Heya devuanitas ... fresh Chimaera install, '$ ping sirio | 11:09 |
| jla | ping: socket: Operation not permitted' , uh ? | 11:09 |
| jla | what am i missing ? | 11:09 |
| hagbard | setcap cap_net_raw+ep /bin/ping | 11:16 |
| hagbard | maybe | 11:16 |
| jla | ah...just like this, on bash ? Let's see... | 11:16 |
| hagbard | as root | 11:16 |
| jla | yeah... dunno why but it works , thX | 11:17 |
| jla | is it expected beahviour ? | 11:17 |
| * jla Just wondering... | 11:18 | |
| hagbard | Theres something in the manpage of ping about this | 11:23 |
| hagbard | "ping requires CAP_NET_RAW capability to..." at the bottom of it | 11:25 |
| jla | weird ... feels like | 11:34 |
| jla | in terms of 'user experience', i mean | 11:35 |
| cws7788 | Today, my problem has been solved, and I am very happy. | 12:13 |
| cws7788 | edit synaptic , "Exec=pkexec synaptic" →→ | 12:16 |
| cws7788 | edit synaptic , "Exec=pkexec synaptic" →→ " | 12:16 |
| cws7788 | edit synaptic.desktop , "Exec=pkexec synaptic" →→ "Exec=sudo -b synaptic" | 12:18 |
| cws7788 | edit synaptic.desktop , "Terminal=false" →→ "Terminal=true" | 12:23 |
| ShorTie | stick it in your notes .. :/~ | 13:41 |
| luser978 | re: ping: ping uses raw datagrams and socket 0, needs permissions for this due to tighter security. on other *nixes user ping is rate limited and has some features disabled, root ping has full power. | 16:37 |
| luser978 | ping is a DoS tool when not limited. | 16:38 |
| xrogaan | so is any human behavior. | 17:20 |
| systemdlete | am I missing glibc? I search in apt but do not see it. Is it in a different repo? | 19:44 |
| systemdlete | luser978: How can you prevent someone from using a different version of ping (maybe by compiling it themselves) that does not prevent using it as a DoS tool? | 19:46 |
| debdog | systemdlete: Package libc6 | 19:49 |
| systemdlete | ah, ty | 19:50 |
| systemdlete | hmmm. Seems that in glibc 2.31, some floating point functions (like lchmod?) are no longer there. | 19:51 |
| systemdlete | It is breaking a build. | 19:52 |
| onefang | Might be in the math library? | 19:52 |
| onefang | Are you sure it's lchmod? Doesn't seem like a floating point function to me. | 19:57 |
| systemdlete | fegetenv is another one | 19:58 |
| bb|hcb | definitely not math related, lchmod is bsd stuff | 19:59 |
| systemdlete | https://www.cygwin.com/bugzilla/show_bug.cgi?id=26932 is an example of what I'm talking about | 19:59 |
| rwp | systemdlete, It feels to me that you are building a project but missing the build dependencies? | 19:59 |
| rwp | Start by installing the build dependencies of the packaged version of it: apt-get build-dep foothinghere | 20:00 |
| rwp | That will install the build libraries that were needed for the packaged version of it. | 20:00 |
| rwp | With those installed then building the self-compiled thing will probably Just Work. | 20:00 |
| systemdlete | I'm building from a tarball | 20:01 |
| systemdlete | not a deb package, sorry | 20:02 |
| rwp | That's what I thought from reading the above. | 20:02 |
| rwp | Don't be sorry. But I think you are simply missing the build dependencies of that tarball. | 20:02 |
| systemdlete | the config is complaining that some externs are not defined. The 2.31 glibc defined those as stubs | 20:03 |
| systemdlete | I'm surprised that the configure step does not indicate what to install | 20:03 |
| rwp | If the program is not packaged then try installing the build-dep of the most similar thing. Start with something like grep if nothing else: apt-get build-dep grep | 20:03 |
| systemdlete | (sometimes it suggests) | 20:03 |
| systemdlete | ok, will try that | 20:04 |
| rwp | ./configure is build by autoconf from what the programmer wrote in configure.ac and is often pretty sparse. | 20:04 |
| rwp | Basically if the programmer didn't write something specific in there to suggest something, then there will be no suggestions. | 20:04 |
| systemdlete | isn't there a way for me to run autoconf myself to obtain a new configure that might include what I need? | 20:04 |
| rwp | Also the *other* function of ./configure is to adapt to different systems where one might be one way and the other might be the other way. | 20:04 |
| rwp | You won't need to do that. | 20:05 |
| rwp | If the build dependencies are installed then ./configure will find them okay. | 20:05 |
| rwp | If the build dependences are not installed then rebuilding the ./configure won't make things better. | 20:05 |
| rwp | What program are you trying to build from a tar distribution bundle? | 20:05 |
| onefang | That bug report basically says these things where stubbed out from glibc, then added back again in a later version. Specifically mentions Debian, which Devuan is based on, having the older version with the functions stubbed out. | 20:07 |
| rkta | I just did a 'aptitude update; aptitude safe-upgrade', 'needrestart' asked to restart some programs, I said ok. X crashed, I got weird messages on the terminal, Alt+F2, log in as root, logged in, was switched back to tty1 at the prompt, couldn't enter anything. Used Ctrl-Alt-SysReq+B to reboot. Any chance to get some logs of this to report it? | 20:08 |
| rwp | rkta, Was one of the programs being restarted the xdm equiv such as lightdm or slim? That would restart X when those restart. | 20:09 |
| rwp | The aptitude commands you posted look okay and reasonable things to do to me. | 20:09 |
| rkta | rwp: I don't remember. I use i3wm. | 20:09 |
| rwp | I use i3 here too. When your system boots does it boot to a text console and you start X manually with either startx or xinit or other? Or does it boot to a graphical login manager? | 20:10 |
| rkta | I boot to console and use startx. | 20:10 |
| rwp | Okay. (Me too.) But then I don't know what service needrestart would have prompted for that would have crashed X. | 20:11 |
| rkta | That's why I'm asking to get some logs. ;) | 20:11 |
| rwp | There are only four places where this is logged as far as I know. | 20:12 |
| rwp | 1) ~/.xsession-errors logs information from running X programs. The stdout and stderr from all X programs are redirected there. Filled with lots of noise. | 20:12 |
| rwp | 2) /var/log/Xlog.0.log is where the X server itself logs information. | 20:12 |
| rwp | 3) /var/log/syslog is where all system related logs are put. | 20:13 |
| rwp | 4) /var/log/boot is where boot time logs are put if bootlogd is active at boot time. | 20:13 |
| rwp | That's off the top of my head. Check for typos. | 20:13 |
| rwp | It seems odd to me that you were able to Alt-F2 to get to vt2, log in there, but then switching back to vt1 then was stuck not able to enter anything and needed the MagicSq key to reboot. | 20:14 |
| rwp | Because if able to log in on vt2 and able to switch vts then the system didn't seem to be locked up at that time. So then locking up after that point is... odd. | 20:15 |
| rkta | Yep, that was strange. On vt1 were some message which looked like being from i3status. When I logged in and was put back to vt1 the messages had stop appearing. | 20:16 |
| rwp | Whichever vt you are in actively should become the active /dev/console and any program that logs to the system console will have messages follow you around as you switch vts. | 20:17 |
| rwp | That's rather a feature that can be pretty annoying when the system is spewing messages to the system console and you can't escape away from them because they follow you! :-} | 20:17 |
| rkta | This was not what was happening. | 20:17 |
| rwp | I was just remarking on that because you said messages that looked like i3status messages were showing up there. And i3status is an X thing. So if any messages are showing up on the text console then they are likely to be system console error messages. | 20:18 |
| rwp | I'll just close my previous comment by saying that "dmesg -n5" can usually make the system console usable by stopping the flow of informational messages there. Use -n3 if -n5 isn't enough. | 20:19 |
| rwp | Good luck! It's becoming lunch time here. | 20:20 |
| rkta | In i3status I have a 'field' to show the system temperatue which is not supported on this old device. It just shows "can't read temp", on vt1 there were messages telling me about not being able to show the temperature - not sure about the exact wording. | 20:20 |
| rkta | And I don't have ~/.xsession-errors nor /var/log/Xlog.0.log | 20:21 |
| rkta | And nothing interesting in /var/log/boot or /var/log/syslog | 20:25 |
| systemdlete | onefang: What do you make of the resolution to that bug? | 20:33 |
| onefang | It's 4:30 AM here, and I don't want to think that hard before bed. lol | 20:39 |
| Afdal | Is there some particular reason checkinstall isn't in the main Devuan repository? | 20:51 |
| rwp | Afdal, I see checkinstall in chimaera/main and beowulf-backports/main suites. | 20:54 |
| Afdal | Backports isn't enabled by default right | 20:54 |
| rwp | Correct. | 20:54 |
| Afdal | I'm new to Devuan, what should I know about backports before enabling it? | 20:54 |
| rwp | But basically as soon as chimaera releases then it will be in Devuan Stable as a released package. | 20:55 |
| golinux | https://www.devuan.org/os/packages | 20:55 |
| Afdal | checkinstall has been around forever, why's it being held back though? | 20:55 |
| golinux | Just don't install everything from backports. | 20:56 |
| golinux | Just dl what you need. | 20:56 |
| rwp | Generally useful backports use information https://backports.debian.org/ | 20:56 |
| Afdal | Yeah I already had an irritating scenario happen on *buntu before where they pushed a broken wireless library | 20:56 |
| Afdal | How do I enable a repository for only one thing? | 20:57 |
| rwp | Afdal, It was removed due to segfaulting: https://bugs.debian.org/878487 | 20:57 |
| Afdal | oh dear | 20:58 |
| rwp | https://tracker.debian.org/news/886126/checkinstall-removed-from-testing/ | 20:58 |
| rwp | It is possible to use "pinning" to specify specific packages for special handling. But honestly I am not more than passing familiar with pinning details. | 20:59 |
| Afdal | How do I add backports but not allow it to update all the software I already have | 21:00 |
| rwp | See the "man apt_preferences" page for the documentation on it. | 21:00 |
| rwp | By default backports won't upgrade anything on your system just by being enabled due to a global pinning of backports at -1 or something like that. | 21:00 |
| Afdal | oh good | 21:01 |
| rwp | Which says that if your currently installed package is the same or older than the release then you upgrade to the release. | 21:01 |
| rwp | But if you have a newer installed package from backports then it prefers the version from backports. | 21:01 |
| rwp | Which has the effect of manual actions being "sticky" if I can use that term. | 21:01 |
| Afdal | interesting that it keeps track of what comes from backports and what doesn't | 21:01 |
| rwp | If you manually install a backport then that package, and dependencies which are also pulled forward, then track backports. | 21:01 |
| systemdlete | is there no way to break out of an install after realizing I didn't really want to install the package? | 21:02 |
| rwp | But everything else doesn't. | 21:02 |
| rwp | systemdlete, Control-C? That might leave things in an inconsistent state. Which you can recover from. | 21:02 |
| systemdlete | been there done that | 21:02 |
| systemdlete | it still insists on completing the install | 21:02 |
| Afdal | Neat, so I don't need to do any special package pinning or anything then? Just add the repo and grab checkinstall from it? | 21:02 |
| rwp | It depends upon what stage of the install is happening when the interruption occurs. | 21:02 |
| rwp | Afdal, Yes. Please browse through the https://backports.debian.org/ on how to use backports though. | 21:03 |
| systemdlete | unpacking | 21:03 |
| rwp | systemdlete, Then it is really too late to stop it. Because to fix it later you would need to continue from there anyway. | 21:03 |
| rwp | If you have packages in an inconsistent state then "dpkg --configure -a" is usually the first step at resuming things so they can get consistent. | 21:04 |
| systemdlete | ^^ it still insists on completing it, yeah, I know | 21:04 |
| systemdlete | ok | 21:04 |
| rwp | Then "apt-install -f" after that. | 21:04 |
| systemdlete | well, apt seems to kind of get "stuck" in unpacking sometimes with some packages | 21:04 |
| rwp | If you are simply installing things that you don't want then you can purge them afterward and return (mostly) to where you were before. | 21:04 |
| systemdlete | when I did an strace in one such instance I found out that it was doing a ton of renames | 21:05 |
| rwp | If you were doing an upgrade and changing package versions then that is a little more difficult and I will say it all depends on what is happening and what you want. | 21:05 |
| systemdlete | purging them is not the problem. Breaking out of a mistake is the problem. Sounds like you can't, that's all. | 21:05 |
| systemdlete | so the answer to my question is "NO" | 21:06 |
| rwp | Downgrades can be done but it is involved and tedious and "if you have to ask..." then probably not a good plan to attempt. (Okay to attempt if you are confident of skills to do it.) | 21:06 |
| systemdlete | no, there is no way to break out of a mistaken install | 21:06 |
| rwp | Are you upgrading? | 21:06 |
| rwp | From one OS release to another? | 21:06 |
| systemdlete | no, just entered the wrong package name | 21:06 |
| systemdlete | meant to install something else | 21:06 |
| rwp | Then just let it finish. It's not the end of the world. Then purge the package off afterward. That's almost virtually the same result. apt-get purge --autoremove unwantedpkgfoo | 21:07 |
| systemdlete | no of course it is not the end of the world! | 21:07 |
| systemdlete | but when it hangs there unpacking forever and ever, it wastes a lot of time | 21:07 |
| systemdlete | since all I am going to do is remove/purge it anyway | 21:07 |
| systemdlete | that was my point. | 21:07 |
| rwp | Yes. Wastes a lot of time. Time to take a break and walk around and make a sandwich. But not really any way to avoid it. | 21:08 |
| systemdlete | ty for repeating the same thing 3 times. I get it now. | 21:08 |
| Afdal | btw, coming off of a *buntu, I kind of like that adding repositories is as simple as editing /etc/apt/sources.list | 21:09 |
| systemdlete | sorry, rwp. It's just that this sort of thing really makes me miss rpm. But those days are gone since I have no plans of switching to any distro that uses systemd | 21:09 |
| Afdal | It probably was always that simple but there's so much extra programs to obscure what's going on | 21:10 |
| Afdal | on *buntu | 21:10 |
| systemdlete | and all the rpm distros use systemd nowadays | 21:10 |
| rwp | It is mostly the same in Ubuntu at the deep technical detail. Except that Ubuntu has like a godzillian different suites, and they sometimes conflict, making it much more problematic. | 21:10 |
| rwp | Backports by contrast are design to be a middle thing that is as safe as possible and that get washed away when eventually upgrading to the next release. | 21:10 |
| rwp | Since Devuan Chimaera is very close to release this makes using backports right now particularly a good time. | 21:11 |
| Afdal | Messing with repositories was always such a headache for me because it never seemed like I quite understood the "right" way to do things | 21:11 |
| rwp | Because in some couple of weeks maybe (it's happening soon) one can upgrade to Chimaera and any installed backport is replaced by the newly released Stable version. | 21:11 |
| Afdal | oh really, that close huh? | 21:11 |
| Afdal | Do you recommend full reinstallation when upgrading on Devuan? | 21:12 |
| Afdal | I just installed this a couple weeks ago | 21:12 |
| rwp | *I* am an upgrade advocate. I have a few systems that trace back to Woody days. Upgrades traditionally have always worked in Debian. | 21:13 |
| rwp | Unfortunately of late that value has been lost and there have been some breaking problems. | 21:13 |
| rwp | So... I can't say it isn't in people's best interest to wash things clean with a fresh installation. | 21:13 |
| Afdal | By the way I'd like to note that it was a surprise to me when I realized openrc was my init, because... I was lead to believe that the installer would ask me what init I wanted to use, but it never did :'( | 21:13 |
| rwp | Often that is an easy way to get everything upgraded with the least amount of muss and no fuss. | 21:13 |
| Afdal | I prefer runit just because I've used it more but I fear messing with init replacement after installation is going to be too much a hassle | 21:14 |
| rwp | Afdal, What? There is a dialog question about what init you would like to use at install time. The default is sysvinit and OpenRC is an optional selection. | 21:14 |
| Afdal | There was no such dialogue for me >.> | 21:14 |
| rwp | I am confident that if you have openrc that it was because it was selected at installation time. Or that it was subsequently installed later. | 21:14 |
| Afdal | Maybe I'm not even using openrc... | 21:15 |
| rwp | There are multiple installers. Perhaps the one you used pre-selected it for you. | 21:15 |
| Afdal | How do I check if it's openrc or sysvinit? | 21:15 |
| rwp | Hmm.... Off the top of my head, try this: dpkg -S /sbin/init | 21:15 |
| Afdal | oof, guess it's sysvinit | 21:16 |
| Afdal | lol | 21:16 |
| Afdal | Luckily openrc and sysvinit seem to use a similar service management system | 21:16 |
| Afdal | I've been looking up openrc instructions | 21:17 |
| rwp | Maybe... I am not sure my test there is perfect. Let me dig a little. Not a question I have thought about for a while. | 21:17 |
| Afdal | What's the name of Duvuan's installer again | 21:17 |
| rwp | https://files.devuan.org/devuan_beowulf/installer-iso/ | 21:18 |
| rwp | But there are also Refracta installers and others that do things differently and make pre-selected choices. | 21:18 |
| rwp | A lot of people really like the Refracta installer and the resulting system choices for example. | 21:18 |
| rwp | https://refracta.org/ | 21:18 |
| Afdal | I used the terminal-based refracta without any GUI helper scripts because I needed to install this remotely | 21:19 |
| Afdal | perhaps that's why I missed the init choice prompt? | 21:19 |
| rwp | Yes. That makes everything make perfect sense. | 21:19 |
| rwp | Here is the link I was looking for: https://www.devuan.org/os/devuan-distros | 21:20 |
| Afdal | uh wait | 21:21 |
| Afdal | do I have the name wrong | 21:21 |
| Afdal | Refracta is a distribution name | 21:21 |
| Afdal | what's the name of the installer though... | 21:22 |
| Afdal | oh refractainstaller | 21:22 |
| Afdal | okay | 21:22 |
| Afdal | hmm, so hard hard is it to change your init in a running system anyway | 21:22 |
| Afdal | how hard* | 21:22 |
| Hydragyrum | >in a running system | 21:24 |
| Hydragyrum | so you mean replacing PID1? yeah probably not going to happen | 21:24 |
| Afdal | ;_;7 | 21:24 |
| Afdal | So this is gonna require chroot shenanigans isn't it | 21:25 |
| Hydragyrum | now, if you want to replace the init system to take place on next boot, that's doable | 21:25 |
| Afdal | oh okay | 21:26 |
| Hydragyrum | i.e. replace init but you're still running the old one until you reboot | 21:26 |
| Afdal | Well how hard is that | 21:26 |
| rwp | Afdal, Switching inits usually means installing the other init, then rebooting to it, then removing the old init, then rebooting again and it is done. | 21:26 |
| Afdal | sudo apt purge sysvinit; sudo apt install runit? | 21:26 |
| Afdal | oh | 21:27 |
| Hydragyrum | artix migration from systemd arch does it with possibly the hardest one to do it with | 21:27 |
| Afdal | So somehow I need to tell it to boot with the other init | 21:27 |
| rwp | The old adage "make before break" applies. Install the new. Reboot to the new. Remove the old. Reboot to the final configuration. | 21:27 |
| Afdal | Is this some instruction I need to give to initramfs or the kernel | 21:27 |
| Afdal | to pick the right init | 21:27 |
| rwp | Generally speaking installing something will configure it to be the thing that is active. | 21:28 |
| rwp | Follow the release instructions is always a safe thing. | 21:28 |
| Afdal | where's that >.> | 21:28 |
| rwp | https://www.devuan.org/os/init-freedom | 21:28 |
| rwp | That last was general information and not a specific answer to where documentation is located. Just a race condition of messages. | 21:29 |
| rwp | Beowulf release notes: https://files.devuan.org/devuan_beowulf/Release_notes.txt | 21:30 |
| rwp | I think those are a little sparse for the newbie though. Those are really pretty bare minimum. | 21:30 |
| Afdal | Yeah I don't see anything in there about changing inits | 21:31 |
| rwp | Looking at the older migration documentation could be useful to get the feel of the situation. https://www.devuan.org/os/documentation/dev1fanboy/en/stretch-to-beowulf | 21:34 |
| rwp | But know that that documentation was for migrating from older releases. So things will be mostly the same. But different in some details. | 21:34 |
| rwp | But it should get you the feel for the way things are done. And then please feel free to ask questions. | 21:35 |
| Afdal | uhhh | 21:35 |
| rwp | However personally I haven't been *switching* very often. I have stuck to my preferred. So maybe not such a good resource. | 21:35 |
| Afdal | So I guess there's typically a transition package you install that tells your kernel to switch to a different init on the next boot? | 21:35 |
| Afdal | wait I think I've read this wrong, nevermind | 21:36 |
| rwp | The kernel's command line will boot /sbin/init and whatever that is will be the init. | 21:37 |
| Afdal | Yeah I'm not really spotting the step here for how you manage to alter /sbin/init when you have multiple init packages installed, so that the kernel loads the right one up | 21:37 |
| rwp | The default is /sbin/init but that can also be overridden on the command line by telling the kernel init=/bin/bash (a time honored debug thing) or whatever. | 21:37 |
| rwp | The answer is package specific due to the actions written by the package author in the package postinst script. Making it hard for me to give one answer. | 21:38 |
| rwp | But most of the time the last one installed wins. | 21:38 |
| Afdal | lol | 21:38 |
| Afdal | maybe I should just install runit, reboot, and then see what's running | 21:39 |
| rwp | Note that if things get into a screwed up state the installer makes a very good rescue tool. | 21:40 |
| rwp | Boot the installer, look under Advanced, Rescue, boot the Rescue image, and then can make tweaks and changes to the system as needed. | 21:40 |
| Afdal | how's the rescue image different from the regular live image | 21:40 |
| rwp | The Rescue image is very similar, uses the same core, but will say "Rescue" in the corner so you can tell them apart. | 21:41 |
| rwp | After initial questions for setup that are identical to the installer then it will offer to chroot into the target system. | 21:42 |
| Afdal | oh so it has some helper scripts | 21:42 |
| rwp | That's basically it. It boots. It chroots you into the target system. Which then you can run commands and modify things. | 21:42 |
| Afdal | I just spent six months debugging a GRUB problem so I've become a chrooting pro now... | 21:42 |
| rwp | It will automatically activate LVM and start up RAID and so forth. But mostly it boots when your installed system does not boot. | 21:43 |
| Afdal | thanks for the tips, think I'll give that a try later | 21:46 |
| Afdal | So I take it when you install another init through apt, it sets the init with all the services you already have running on your current init? | 21:47 |
| Afdal | sets up the new init | 21:47 |
| rwp | The answer to your question is complicated because really the core is simply /sbin/init and whatever is there is started by the kernel as PID 1. Full stop. | 21:48 |
| rwp | Then all of the init systems try to read various init things to run from there. All in their own unique ways. But the good ones read the others in a compatibility layer. Mostly. | 21:49 |
| Afdal | I guess what I'm asking is does your service configuration with your current init get "translated" to the other init's configuration | 21:49 |
| Afdal | hmm | 21:49 |
| rwp | So for example runit will read /etc/init.d/* scripts and run them at the appropriate times. Even if there is not a native runit script. | 21:49 |
| Afdal | interesting | 21:50 |
| Afdal | I'd probably want to move those to the canon runit directory though | 21:50 |
| rwp | But if there is a native runit configuration then it supersedes the /etc/init.d/* sysv init script. | 21:50 |
| rwp | "move"? Not move. You could do nothing and things should work through the compatibility layer implemented by runit. | 21:51 |
| rwp | Or you could write native runit configuration for it. | 21:51 |
| Afdal | yeah but... that doesn't seem comfy I:} | 21:51 |
| rwp | Okay. Be comfy! :-) | 21:52 |
| Afdal | actually the issue for me is really | 21:52 |
| Afdal | runit has a simple system for adding and removing services | 21:52 |
| Afdal | and I want it to be consistent | 21:52 |
| Afdal | you just add or remove symlinks to /var/service/ | 21:53 |
| Afdal | but that won't work if it's interpreting everything from the previously existing sysvinit way | 21:53 |
| Afdal | Actually, that's Void Linux's way of doing it, anyway. Maybe runit works different on Devuan, I dunno. | 21:54 |
| rwp | Go for it! But remember the rules. See one. Do one. Teach one. After you dig though these things you must then teach one. :-) | 21:54 |
| golinux | Afdal: Poke the dev1galaxy.org forum for runit | 21:55 |
| golinux | I'm not adventurous enough to try and alternate init but i think you still may need the sysvinit scripts | 21:56 |
| golinux | Same with openrc. | 21:56 |
| rwp | It is not impossible to go through and write all of your own for everything. But it would be a lot of tedious work to do so. | 21:58 |
| rwp | Also I think runit on Devuan operates the same as runit on Void. Basically runit is runit the same everywhere. It's the package specific configurations which vary. | 21:58 |
| Afdal | Got another question as I'm thinking about how to free my life from IBMware | 21:59 |
| Afdal | How well does pipewire work on Devuan? | 21:59 |
| Afdal | is it still kind of a work in progress or | 21:59 |
| Afdal | does it make a good pulseaudio alternative now? | 22:00 |
| Afdal | Presuming someone has tried it in here | 22:00 |
| Afdal | actually that's a silly question to ask on a distro channel, nevermind | 22:01 |
| rwp | People have tried PipeWire here. I have not. I am looking forward to it replacing the pesky and problematic PulseAudio as soon as practical. | 22:01 |
| rwp | AFAIK PipeWire has not been packaged for any distro but perhaps one has picked it up. AFAICT people who are using it have installed it themselves. | 22:02 |
| Afdal | I see a pipewire package in the repo | 22:02 |
| rwp | Then there you go. You can tell that I am out of the loop and not a good resource for it. :-) | 22:06 |
| bb|hcb | yes, pipewire is in the repos; I have tried that but had to start it manually after each login (one daemon as root and a session manager as your user) ftr i use mate | 22:06 |
| golinux | https://dev1galaxy.org/viewtopic.php?id=4447 | 22:06 |
| Afdal | "And the main developer is the same who invented the pulseaudio crap." <- Uhh, what? | 22:07 |
| Afdal | damnit is pipewire also IBM >:I | 22:07 |
| Afdal | My god, it is... | 22:08 |
| Afdal | How didn't I realize this already | 22:08 |
| Afdal | I'm so confused about why this even exists | 22:09 |
| Afdal | I guess it was attempting to pulseaudio-ify video... and ended up doing audio? | 22:10 |
| fluffywolf | are people seriously trying to force yet another redhat blob onto linux again? | 22:17 |
| Afdal | it never ends -____- | 22:18 |
| systemdlete | My laptop is pretty much "quiesced" -- I have shut down most programs. The only thing "running" per se is the desktop itself. I have the charger plugged in and the laptop battery monitor acknowledges it is charging. ipmi confirms this. Yet the power level keeps dropping? | 22:21 |
| systemdlete | yeah | 22:21 |
| systemdlete | so tell me, my battery problems are related to systemd removal surgery? | 22:26 |
| systemdlete | that is, when devuan releases get their systemdectomy | 22:34 |
| rwp | systemdlete, I doubt it. I don't see how. But what do I know? Less and less each day. | 22:34 |
| rwp | Sounds more like a failing battery to me. I would power off and charge it without the system running and then see if the battery charges. | 22:35 |
| systemdlete | oh, it will. In fact, even if I just let it run out completely, it will recharge. | 22:35 |
| systemdlete | but that isn't how it should work. | 22:35 |
| systemdlete | When a laptop or other device is on charger, it should be charging (and sometimes it does) | 22:35 |
| systemdlete | this machine has ALWAYS worked this way, since day 1. | 22:35 |
| rwp | I have never had a laptop that could not charge while under maximum power stress usage. | 22:35 |
| rwp | So looking at what is running and using power seems the wrong thing to look at. | 22:36 |
| systemdlete | I didn't pay a lot for the thing. I just wanted, badsically, a tablet that I could use occasionally | 22:36 |
| Afdal | There's two things that might be the cause of your trouble, systemdlete | 22:37 |
| Afdal | Sometimes batteries misreport their charge level to operating systems | 22:37 |
| systemdlete | My gut feeling is that linux does not understand how the battery works on this machine (it's based on Intel cherry trail) | 22:37 |
| Afdal | I have a machine that does that | 22:37 |
| Afdal | well, the battery | 22:37 |
| systemdlete | Afdal: Nah. When this thing reaches 0 it will shut itself off | 22:37 |
| Afdal | the other issue may be a problem with your power port on the machine | 22:37 |
| systemdlete | so it is reporting the real level | 22:37 |
| systemdlete | yeah, that could be | 22:38 |
| systemdlete | a marginal power port. great. | 22:38 |
| Afdal | I've heard that's a common problem on laptops | 22:38 |
| systemdlete | and smart phones | 22:38 |
| Afdal | you can fix it with a soldering iron without a ton of trouble I think | 22:38 |
| Afdal | oh it's a phone | 22:38 |
| Afdal | -_- | 22:38 |
| systemdlete | no | 22:38 |
| systemdlete | its a laptop | 22:38 |
| Afdal | http://www.laptoprepair101.com/dc-power-jack-repair-guide/ | 22:38 |
| Afdal | this might help you | 22:38 |
| gnarface | is it a recent laptop your'e trying to charge over usb? | 22:38 |
| gnarface | or with a 3rd party charger or something? | 22:39 |
| gnarface | on some devices it is possible to outrun the charger if it is expecting usb3 max charging speed availability and you're charging it over usb2 | 22:40 |
| golinux | Can you please take the hardware stuff to #devuan-offtopic? | 22:40 |
| systemdlete | and this machine is sealed tighter than Fort Knox. | 22:41 |
| systemdlete | god forbid anyone can fix anything themselves anymore. It's the Apple way these days, and that's with everything. | 22:41 |
| systemdlete | I can plug and unplug is a dozen times and makes no difference. When it decides it isn't listening to the power port, its judgment is final. | 22:41 |
| systemdlete | it seems | 22:41 |
| systemdlete | And I am using the charger block and cable that came with the laptop | 22:41 |
| systemdlete | sorry | 22:41 |
| systemdlete | This started as an honest software question. | 22:41 |
| systemdlete | (see above) | 22:44 |
| golinux | systemdlete: Everything has a beginning . . . and an end. | 22:49 |
| systemdlete | and a middle too! | 22:49 |
| systemdlete | (which is where it changed) | 22:49 |
| systemdlete | It was 100% unintentional | 22:50 |
| golinux | I know that. That is what mindfullness is for. :) | 22:54 |
| _ds_ | Re. apt preferences: https://paste.debian.net/hidden/c6aea67b/ may help | 23:09 |
| _ds_ | Afdal, rwp ↑ | 23:11 |
Generated by irclog2html.py 2.17.0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!