| al1r4d | Sunday ☕ | 02:08 |
|---|---|---|
| debdog | Funday | 02:08 |
| al1r4d | 🙆 | 02:09 |
| phogg | Happy-Days 😃🌅 | 05:12 |
| n4dir | Beckett always works: https://www.youtube.com/watch?v=L5vhQ4d_KMI | 05:16 |
| helios21 | Hi! upgrade to runit 2.1.2-54+usrmerge tells me: "warning: unmerged systems will fail to boot very soon". So for now a reboot without merging is still safe? I sure hope so. But of course will do the merge before in case its necessary to have my Devuan Ceres continue to boot fine. | 11:58 |
| helios21 | Well I will see in a moment. | 12:00 |
| helios21 | Well for now it does still boot. I also asked it on dng-ml. So let's see what the answer will be. But I expect I will need to usr-merge my Devuan Ceres systems. | 12:05 |
| gnarface | helios21: stick around, someone might know eventually | 12:30 |
| gnarface | since it's ceres i recommend making a backup | 12:30 |
| helios21 | I do regular backups. Yeah, I will wait for someone to reply either here or on the list. Thanks. | 12:31 |
| joerg | aiui usr-merge has impacts when a) /usr/ is a separate partition, mounted late, so early bootup has no access to executables in /usr/(s)bin/*, and B)[!!!] on installing/updating new packages that expect usrmerge and mess up systems that don't have it | 13:48 |
| joerg | https://subdivi.de/~helmut/dep17.html | 13:56 |
| joerg | ^^^ highly qualified summary of the usrmerge situation, thanks to helmut | 13:59 |
| joerg | to me usr-merge is another "move fast and break things" problem somebody picked "because we can". Basically no real benefit at all and initially the proponents had no idea which trouble they will see | 14:13 |
| rrq | usr-merge or not only makes a difference when a program is referred to by a full path but different from its installation path. | 14:16 |
| rrq | doing so has traditionally been identified as "A Bug" and been corrected. | 14:18 |
| joerg | rrq: helmut has an in-depth analysis in https://subdivi.de/~helmut/dep17.html | 14:18 |
| rrq | I've seen that. not too interesting. | 14:19 |
| rrq | if programs are referenced by the paths they are installed by, then usr-merge or not is irrelevant. | 14:20 |
| rrq | some people also use short program names and a PATH variable for resolution | 14:21 |
| joerg | aiui, the problem with dpgk / $PKGMNGR is when packages change their files' paths | 14:27 |
| joerg | i.e. during update, nit during normal operation | 14:28 |
| joerg | or put simply: a fresh install is supposed to work, an update/upgrade may break the system | 14:30 |
| joerg | my uneducated 2ct on it | 14:31 |
| rrq | obviously if a program on update is removed from one pathname and installed under another, then all full-path references to the old pathname become "invalid" | 14:31 |
| joerg | or, in some situations it even may remove the file it just updated | 14:32 |
| joerg | "P1: File loss during canonicalized file move" in https://subdivi.de/~helmut/dep17.html | 14:34 |
| rrq | yes for such a scenario usr-merge or not does have relevance | 14:35 |
| rrq | (with "not" being favoured) | 14:35 |
| rrq | that notion of his of "canonicalized" filename is rather peculiar | 14:36 |
| rrq | it really just emphasize a desire of referring to a program via a full pathname different from where it gets installed | 14:37 |
| joerg | my point basically was just about it's a dpkg problem that hits package maintainers. It probably isn't anything you will be able to take care about as user | 14:51 |
| joerg | in a reply to >>Hi! upgrade to runit 2.1.2-54+usrmerge tells me: "warning: unmerged systems will fail to boot very soon". So for now a reboot without merging is still safe?<< | 14:53 |
| rrq | ok. that message sounds like nonsense; why should they fail to boot? | 14:55 |
| rrq | maybe suddenly changing the kernel so that it only looks for /usr/sbin/init ? | 14:58 |
| rrq | while not changing various init packages to install at that path | 14:59 |
| joerg | my comment above >>usr-merge has impacts when a) /usr/ is a separate partition, mounted late, so early bootup has no access to executables in /usr/(s)bin/*, ...<< | 14:59 |
| rrq | yes a usr-merge system will puke on that; it boots but initrd scripts referring to /usr/.. programs of course fail ... | 15:02 |
| rrq | well any system, usr-merge or not, will puke on that; the bugs are in those scripts... | 15:03 |
| joerg | yep | 15:04 |
| joerg | just usr-merge encourages initscipt developers to ignore this, so it's not "a bug" anymore | 15:06 |
| joerg | which is just :-S | 15:06 |
| rrq | I wonder which "problem" usr-merge solves? ... taken us some 50 years of computing to run into that problem, which apparently has to be solved by bastardizing the filesystem. | 15:12 |
| joerg | >>I wonder which "problem" usr-merge solves?<< the problem is systemd promising "simple init scripts every monkey can write" and a separate /usr partition been prohibitive to that promise | 15:16 |
| rrq | :) | 15:17 |
| rrq | I just realized that this is not the off-topic channel | 15:18 |
| rrq | ... and that it's well past midnight here | 15:18 |
| joerg | oh, sorry | 15:19 |
| systemdlete | Does anyone recognize this file? It is named "log.sh" and suddenly appeared in the home directory of a brand-new user I created just a day ago. I am certain that I did not create it. https://pastebin.com/DTAHQq8N | 19:01 |
| systemdlete | (wondering if it comes from skel or the like, but have not noticed it until just now) | 19:02 |
| systemdlete | this is in a VM running Star Linux (Kirk) | 19:03 |
| systemdlete | The file's timestamp is from 2021 | 19:03 |
| systemdlete | It might be nothing to worry about, but it is very spooky | 19:03 |
| systemdlete | oh | 19:05 |
| systemdlete | nvm | 19:05 |
| systemdlete | I see: It is in /etc/skel | 19:05 |
| systemdlete | (on that Star Linux; I don't see that on normal devuan) | 19:05 |
| * systemdlete has had a few bad days here with bareos going south--had to create a whole new backup system using restic, which is working out nicely | 19:07 | |
| fsmithred | no, I've never seen that before, and it looks like someone's custom script to scrape a few logs. | 19:07 |
| systemdlete | fsmithred, yeah, looks like the Star maintainers did that | 19:07 |
| systemdlete | I'm just very jumpy since Friday when my backups went POOF. | 19:08 |
| systemdlete | The bareos devs have been going nuts for months now, putting out upgrades about 3-4x a week sometimes | 19:08 |
| systemdlete | this last one was a doozy | 19:08 |
| fsmithred | rsync FTW | 19:09 |
| systemdlete | I had to modify config files for bareos, and then it complained that the database version was behind | 19:09 |
| systemdlete | rsysnc maybe, but restic really kills it | 19:09 |
| systemdlete | so I tried to "fix" the problem by running dpkg reconfigure, but that just totally verbludgeoned the whole thing | 19:10 |
| systemdlete | just as well; I've been looking to replace bareos for a couple of years now | 19:10 |
| systemdlete | but too busy to really look into it. | 19:10 |
| systemdlete | nothing like a disaster to make one change their priorities! | 19:10 |
| systemdlete | Anyway, I've been a bit edgy for a couple of days, so my tentacles were up. Sorry for the interruption. | 19:12 |
| systemdlete | everyone go back to enjoying your Sunday | 19:12 |
| onefang | But it's Monday already! | 19:20 |
| systemdlete | onefang, you must be in NZ or thereabouts? | 19:23 |
| onefang | Australia. | 19:25 |
| systemdlete | That was my next guess | 19:26 |
| Nrml | Getting this error when trying to upgrade a Chimaera VM to Ceres: | 19:38 |
| Nrml | E: Failed to fetch http://deb.devuan.org/merged/pool/DEBIAN/main/b/bash/bash_5.2.21-2_amd64.deb 404 Not Found [IP: 131.188.12.211 80] E: Unable to fetch some archives, maybe run apt-get update or try with --fix-missing? | 19:38 |
| Nrml | Complete paste of the commands I used and their results here: https://paste.lcomrade.su/o2rn2P34 | 19:39 |
| Nrml | Of course running `apt-get update` again fixed nothing. | 19:40 |
| Nrml | So, is the Ceres repo b0rked (returning 404 errors for some files)? Is there a way to try and fix that besides running `apt-get dist-upgrade` with the `--fix-missing` flag (which I understand will leave the old, Chimaera bash installed)? | 19:41 |
| onefang | 131.188.12.211 is currently passing all apt-panopticon checks. Wait 30 minutes and try again after it's updated. | 19:42 |
| Nrml | OK! Thanks onefang! | 19:50 |
| Nrml | Is this a regular occurrence? | 19:50 |
| Nrml | OK, half an hour passed, and I just ran `apt-get update && apt-get dist-upgrade`. Same error. Any ideas? | 20:07 |
| Nrml | ^onefang | 20:08 |
| Nrml | OK, fixed it myself, changed to specific mirror which was (fortunately) not broken. | 20:15 |
| Nrml | Thanks again onefang for the assist | 20:15 |
| onefang | Well things like Ceres are not checked thoroughly by apt-panopticon, it's testing, it's nature is to break sometimes. shrug | 20:23 |
| onefang | You are welcome. | 20:23 |
| golinux | Nrml: Why would you try to upgrade from Chimaera (old-stable) to Ceres (unstable)? | 20:40 |
| golinux | Daedalus is our current stable release and Excalibur is testing. Skipping releases is NOT recommended. | 20:41 |
| golinux | Info is here: https://beta.devuan.org/os/releases | 20:42 |
| golinux | Ha! Or better here: https://devuan.org/os/releases | 20:43 |
| Nrml | golinux> Nrml: Why would you try to upgrade from Chimaera (old-stable) to Ceres (unstable)? -> Sorry, I meant from Daedalus (not Chimaera) to Ceres. | 20:49 |
| buZz | typically people adopt ceres because they want unstable software | 20:50 |
| buZz | by thinking 'higher number is better' | 20:50 |
| onefang | And before I meant "ceres is unstable", thanks for reminding me golinux, It's nature is to be unstable. | 20:50 |
| golinux | Or bragging rights | 20:50 |
| Nrml | golinux: and yes, I know Ceres is unstable and not recommended as a daily driver. I mean this as a test. | 20:50 |
| onefang | Or they want to help test things. | 20:50 |
| buZz | Nrml: did you pastebin the actual sources.list and errors? | 20:51 |
| golinux | Seems like we all finally got on the same page. :) | 20:51 |
| Nrml | I've been reading that Ceres breaks much less frequently nowadays than a few years ago and I'm installing it in a VM to see for myself | 20:51 |
| n4dir | i wanted to see how long it takes me to break debian-sid. After more than 5 years, it was still not broken, but i gave up on debian due to systemd | 20:51 |
| onefang | Like in my Daehalus install I'm using syslinux from ceres, so I can help rrq test his changes. | 20:51 |
| n4dir | thing about unstable is: it *can* break all the time, not it breaks all the time | 20:51 |
| buZz | btw http://deb.devuan.org/merged/pool/DEBIAN/main/b/bash/bash_5.2.21-2_amd64.deb works fine | 20:51 |
| buZz | also , http:// ??? | 20:51 |
| brocashelm | any release can break | 20:51 |
| Nrml | BuZz: I did. And already fixed it by switching to a different mirror. | 20:51 |
| brocashelm | unstable just means "changes all the time" | 20:52 |
| buZz | Nrml: from deb.devuan.org, the one you're -ment- to use? | 20:52 |
| buZz | i bet its just 'i'm still using http://' for packages :D | 20:52 |
| Nrml | buZz: yep, to mirrors.ocf.berkeley.edu/devuan, it's what fixed it. | 20:53 |
| Nrml | buZz> btw http://deb.devuan.org/merged/pool/DEBIAN/main/b/bash/bash_5.2.21-2_amd64.deb works fine -> Maybe now? Wasn't when I first posted, ditto 30 mins later. | 20:54 |
| buZz | Nrml: why not just fix it to function like intended? | 20:54 |
| brocashelm | just pay close attention to what apt tells you when you use ceres; apt-listbugs and apt-listchanges are just some of your friends | 20:54 |
| onefang | mirrors.ocf.berkeley.edu is hella out of date. | 20:54 |
| buZz | Nrml: it likely works in my browser because its switching to https:// | 20:54 |
| buZz | quite sure many devuan mirrors are https only since ages | 20:55 |
| onefang | I keep emailing them, they keep telling me someone else is fixing it. 8.43% weekly update stat. | 20:55 |
| Nrml | Re: http/https, It doesn't matter much as packages are signed, no? | 20:55 |
| onefang | https://sledjhamr.org/apt-panopticon/results/Report-web.html | 20:55 |
| buZz | it matters if the -webhost- doesnt respond to http:// :D lol | 20:55 |
| buZz | leading to your 404s ;) | 20:56 |
| onefang | deb.devuan.org isn't HTTPS, though the servers behind it are when used directly. | 20:56 |
| Nrml | buZz: but then it wouldn't respond with 404, there would be a connection reset or similar error | 20:56 |
| Nrml | Anyway | 20:56 |
| Nrml | this is fixed now, but thanks for the info | 20:56 |
| buZz | Nrml: highly recommended to not use mirrors.ocf.berkeley.edu ;) | 20:57 |
| onefang | It's not fixed if you are using mirrors.ocf.berkeley.edu. | 20:57 |
| Nrml | Having other issues now, fixed a few of them, this is the latest: | 20:57 |
| buZz | especially if you want the latest bugs from ceres | 20:57 |
| joerg | maybe related: I tried `ping 131.188.12.211` to times, first failed, second worked | 20:57 |
| onefang | Especially if you want anything, they just don't actually update. | 20:57 |
| joerg | two* times | 20:58 |
| onefang | "last updated @ 2021-11-09 02:48:53" | 20:58 |
| * brocashelm uses dev.beard.ly | 20:59 | |
| joerg | 131.188.12.211 is one of roundrobbin deb.devuan.org CNAME deb.rr.devuan.org | 20:59 |
| onefang | Correct joerg. | 20:59 |
| Nrml | https://paste.lcomrade.su/6eUZFE6Y | 20:59 |
| Nrml | This is the latest error. | 20:59 |
| Nrml | Any ideas? | 21:00 |
| Nrml | onefang: OK, changing back to deb.devuan.org | 21:01 |
| Nrml | Will retry, maybe something bad on mirrors.ocf.berkeley.edu | 21:01 |
| onefang | Let me spell it out to you once again, mirrors.ocf.berkeley.edu has not updated anything on it's mirror for TWO YEARS! | 21:01 |
| Nrml | Well, OK. | 21:01 |
| Nrml | I have switched back to deb.devuan.org and I'm re-running the upgrade. | 21:01 |
| onefang | Good luck. | 21:01 |
| Nrml | onefang> Let me spell it out to you once again, mirrors.ocf.berkeley.edu has not updated anything on it's mirror for TWO YEARS! -> perhaps it should be removed from https://pkgmaster.devuan.org/mirror_list.txt ? | 21:02 |
| buZz | the -update- i hope | 21:02 |
| Nrml | Ok | 21:02 |
| joerg | https://termbin.com/750m | 21:03 |
| buZz | if you change apt sources, do apt update first | 21:03 |
| buZz | joerg: what ip is '80' | 21:03 |
| Nrml | yep, I meant `apt-get update && apt-get dist-upgrade` | 21:03 |
| joerg | oooh right, sorry :-) | 21:03 |
| buZz | Nrml: plz, upgrade | 21:03 |
| buZz | dont do dist-upgrade instead of upgrade | 21:03 |
| buZz | -first- upgrade, -then- dist-upgrade | 21:03 |
| joerg | damn! should have noticed >>PING 80 (0.0.0.80) 56(124) bytes of data.<< | 21:04 |
| Nrml | OK Buzz, first time I hear that, but will do | 21:04 |
| buZz | Nrml: its in the debian docs since debian has docs :/ | 21:04 |
| onefang | Note that for mirrors.ocf.berkeley.ed https://pkgmaster.devuan.org/mirror_list.txt says "Active: New mirror, some day, maybe." I should pester them once more and threaten them with removal. | 21:04 |
| Nrml | apt-get update && apt-get upgrade && apt-get dist-upgrade | 21:04 |
| Nrml | onefang: OK, I did not notice that line. | 21:05 |
| buZz | i typically do a reboot between upgrade and dist-upgrade, but might not be needed persé | 21:05 |
| Nrml | It's on a VM and I have a snapshot just before changing /etc/apt/sources.list and all the fuckaroo that followed, I will rollback to that snapshot and then redo as indicated | 21:06 |
| Nrml | BRB | 21:06 |
| * golinux drumroll | 21:07 | |
| Nrml | For the record, here's what happens when I replaced `http://` with `https://`: https://paste.lcomrade.su/JW9NRZjH | 21:11 |
| Nrml | Changed back to `http://` and it's now proceeding normally | 21:11 |
| Nrml | This time I got no 404 error re: the bash package | 21:28 |
| Nrml | Some crap further on, but related to the zfs-utils package, I can fix it. | 21:29 |
| n4dir | Nrml: which version was it, you said? | 21:29 |
| n4dir | anyway: earlier i went to the web, with your full URL, and there sure it was | 21:29 |
| Nrml | n4dir: must have been a temporary error. But it stuck for a bit over the half-hour onefang told me to wait before retrying | 21:32 |
| onefang | I at least made a more prominent warning on https://pkgmaster.devuan.org/mirror_list.txt until I get around to bother them once more and not get any decent reply this time again. | 21:39 |
| rwp | Can you get https://www.devuan.org/get-devuan updated? | 21:41 |
| Nrml | OK everyone, `apt-get update` finished mostly OK. | 21:45 |
| Nrml | buZz: reboot before `apt-get dist-upgrade`? | 21:46 |
| buZz | its what i do, i'm not fully convinced its needed | 21:46 |
| Nrml | humrmrmrm | 21:46 |
| buZz | but 'apt upgrade' could have updated the kernel | 21:46 |
| Nrml | it did not | 21:46 |
| buZz | i like to do 'dist-upgrade' 'from the green' | 21:46 |
| Nrml | I checked the messages, it's still the old daedalus kernel. | 21:47 |
| buZz | so, 'everything' working, after upgrading all the updates i grabbed prior | 21:47 |
| rwp | Between apt-get upgrade and apt-get dis-upgrade I recommend doing apt-get upgrade --with-new-pkgs | 21:47 |
| n4dir | you sure use the old kernel until you reboot, wether it is installed or not | 21:47 |
| buZz | rwp: oh fancy | 21:47 |
| Nrml | I will save another snapshot and try without reboot, if it fails I will rollback and retry rebooting first | 21:47 |
| n4dir | the new one is installed or not | 21:47 |
| Nrml | rwp: why? | 21:47 |
| rwp | The dist-upgrade is the action that can remove things. I want to get as much new installed as possible to make the package dependency topography as simple as possible. | 21:48 |
| rwp | The upgrade and upgrade --with-new-pkgs are actions I consider safe actions because they don't really change anything. But the last is allowed to pull in new dependencies as names change. | 21:48 |
| rwp | Some things like bind9 always spin their library names so they do not upgrade without --with-new-pkgs. Also linux-image-amd64 can't upgrade without pulling in a new kernel name. | 21:49 |
| Nrml | OK, makes sense. | 21:49 |
| Nrml | I just saved an snapshot of the VM right after `apt-get update && apt-get upgrade` so if hell breaks loose, I can rollback and retry | 21:50 |
| Nrml | 1 min | 21:50 |
| rwp | Sometimes apt when given a completely major release difference will get confused by the huge number of possibilities in changing from one package depends topography to another. I have seen dist-upgrade get confused and choose the wrong solution. Or at least an unfortunate solution. Reducing dist-upgrades problem space makes things go much easier. Almost always correct when it is small. | 21:50 |
| rwp | When I say dist-upgrade get confused I mean when people (unfortunately) choose to run dist-upgrade as the first action. NOOO! And then it has zippered some systems of friends of mine. | 21:51 |
| joerg | >><Nrml> OK everyone, `apt-get ***update****` finished mostly OK. … reboot before `apt-get dist-upgrade`? << seems there's missing the upgrade in between? | 21:51 |
| rwp | I suggest running "apt-get upgrade --with-new-pkgs" and then running "apt-get dist-upgrade" reviewing what it wants to do at that step closely. | 21:52 |
| Nrml | joerg: sorry, I meant `upgrade` and not `update`. the latter has been run before | 21:52 |
| Nrml | rwp: OK, will do | 21:53 |
| rwp | It's forever going to be a point of confusion between "update" and "upgrade". Just the naming we have though. | 21:53 |
| Nrml | yep | 21:54 |
| rwp | I will run "upgrade" and "upgrade --with-new-pkgs" almost without thinking much here because it is never a problem. But if 3rd party repositories are configured then one must be careful because sometimes those Frankensteins will stir things up. | 21:54 |
| Nrml | the distinction for me is clear, but sometimes the fingers go their own way | 21:55 |
| Nrml | No 3rd party repos here, at least for now | 21:55 |
| rwp | Sometimes when there are deep problems with 3rd party repositories I must remove them, and some of their packages, then upgrade, then re-install the required 3rd party repositories and apps. | 21:55 |
| onefang | apt-show-versions | grep -v /daedalus | grep -v " not installed" # good for figuring out if your FrankenDevuan is tangled. | 21:56 |
| rwp | There are 3rd party communities like winehq, jenkins, jitsi, and so on that are always bolted onto the side and must be used when they must be used. But sometimes they still get in the way of upgrades. In those cases if they cause problems then I must neuter them such that the base OS can be upgraded, then re-install them as needed. | 21:56 |
| Nrml | OK, `apt-get upgrade --with-new-pkgs` is installing a new kernel. Should I reboot before proceeding with `apt-get dist-upgrade` ? | 21:57 |
| rwp | +1 for apt-show-versions. Good for detangling. | 21:57 |
| rwp | I don't. I proceed to dist-upgrade and then reboot afterward. | 21:58 |
| onefang | Though I'm still wondering why the "not installed" thing turns up for things that clearly ARE installed. shrugs | 21:58 |
| rwp | If you are bored you can read an article I wrote. Bob's Guide to System Upgrades https://www.proulx.com/~bob/doc/bobs-guide-to-system-upgrades-with-debian/bobs-guide-to-system-upgrades-with-debian.html | 21:59 |
| onefang | I don't have time to be bored. lol | 21:59 |
| Nrml | rwp> I don't. I proceed to dist-upgrade and then reboot afterward. -> Wilco | 22:02 |
| onefang | I use a script I'm working on updating now, to install rather than update to new releases, using mmdebstrap. One thing I notice with both chimaera and daedalus is that if my script installs the backports kernel, it can't find it's boot disk when the kernel fires up, but if I upgrade to the backports kernel AFTER booting it, works fine. | 22:02 |
| onefang | Then I need to remove the non backports kernel at the end. | 22:03 |
| rwp | Feels like a problem building the initramfs image. Hmm... | 22:03 |
| onefang | Another odd thing, initramfs gets built several times, including by desktop-base. lol | 22:04 |
| rwp | I have also seen the extra initramfs builds happening serially through the process. Grumph. | 22:04 |
| rwp | Nrml, I don't think anyone has mentioned cleaning things up before and after an upgrade. Please do read the article I posted above and look at the cleaning steps. | 22:06 |
| Nrml | rwp: thanks, will do. | 22:08 |
| Nrml | Upgrades from a version to the next are really complicated. This is one of my motivations for testing Ceres. If it works reasonably well, IIUC no `apt-get dist-upgrade` will ever be necessary again as it becomes a rolling release. | 22:11 |
| Nrml | And if/when stuff breaks after `apt-get upgrade`, I can rolback to a snapshot right before it and all will be well. | 22:11 |
| rwp | Nrml, Actually it's the other way around. With Unstable Ceres every daily upgrade is a daily dist-upgrade just like when doing a major release upgrade. | 22:12 |
| rwp | And all of the cleaning steps I mention are needed on a routine basis too. | 22:12 |
| Nrml | Weird. That is not what I heard. | 22:13 |
| Nrml | But OK, makes sense. | 22:13 |
| rwp | It's one of the reasons people argue that Unstable is not a rolling release in the same way that other systems produce true rolling releases. | 22:13 |
| Nrml | As Ceres will upgrade packages between major versions (eg, `bind8` -> `bind9`) right? | 22:14 |
| rwp | Right. | 22:14 |
| Nrml | and same with kernel, etc | 22:14 |
| Nrml | OK | 22:14 |
| Nrml | But if I run `apt-get upgrade` on Ceres it will not do that, right? | 22:15 |
| rwp | With Unstable I have most of this scripted. All of the up front "safe" operations I run daily by cron and then the "unsafe" dist-upgrade action I use -s simulate and it emails me the output. I then perform whatever action I think is needed manually. | 22:15 |
| rwp | Often there will be a large transition and that day things will blow up and I don't do anything waiting for the migration to proceed. Which might take some days or even weeks when there are problems with the migration. | 22:16 |
| onefang | I have my upgrades scripted to. Sends me an email when updates are needed. It includes taking care of my various file integrity things when files get updated. | 22:16 |
| rwp | Nrml, The "upgrade" action will not change the list of installed package names. Only the versions of individual packages can change. Forward. | 22:16 |
| rwp | So if linux-image-amd64 appears with a new Depends to a different new Linux kernel then "upgrade" can't touch it. It will say "held back". Because to install it would require installing a new package, a new packaged linux-image-6.5.4.3.2-blah-blah kernel and upgrade can't do that. | 22:17 |
| rwp | Then "upgrade --with-new-pkgs" can install it though. Because that does not delete anything. It just installs a new package and upgrades existing packages. So that can proceed. | 22:18 |
| rwp | Some packages always require dist-upgrade due to adding things and removing things both of which need to happen at the same time. This is a frequent occurrence in Unstable. | 22:19 |
| rwp | And sometimes things in Unstable are just broken. When running Unstable one usually has Testing repositories configured too. So that after an upgrade happens that breaks things then one can easily install the prior version pulling it out of Testing while it is still there and before it is overwritten by the Unstable version. | 22:20 |
| rwp | Unless the problem wasn't noticed until late enough that the Testing version is already gone. In which case I must dig through snapshot.debian.org and find the prior version. | 22:20 |
| rwp | Right now procmail in Unstable has a bug which is a showstopper for a feature I use. I have to use the version from Testing and then mark it "apt-mark hold procmail" so that it does not upgrade. (Which reminds me I need to find some time to try to debug it, since I use it and it affects me.) | 22:22 |
| Nrml | OK, two issues during `apt-get update --with-new-packages`: https://paste.lcomrade.su/g2m8aUNv | 22:24 |
| Nrml | My observations/questions are inline, beginning with '-> ' | 22:24 |
| Nrml | Comments, tips, cluebats? | 22:24 |
| rwp | DKMS failed to rebuild the external 3rd party ZFS module. | 22:25 |
| rwp | This is outside my experience since I have so far avoided using DKMS to build 3rd party kernel modules. | 22:26 |
| rwp | I am thinking that the new linux-6.5.0 kernel needs a newer OpenZFS module to match it. | 22:27 |
| rwp | I am actually stuck on linux 6.4 because of a bug in 6.5 which grows committed memory forever until resources fail it. | 22:28 |
| Nrml | It doesn't look that way, here it is: https://paste.lcomrade.su/jS0XkeG0 | 22:28 |
| Nrml | ZFS module building seems to have succeeded, no errors and even a 'success' message | 22:29 |
| rwp | The Daedalus kernel is 6.1.0-13-amd64. I would probably install it, then hold it, and then upgrade everything around it. | 22:29 |
| Nrml | rwp: bug in 6.5 which grows committed memory forever until resources fail it. -> OK, generic bug or something specific to your setup/use case? | 22:30 |
| rwp | It's an in between bug. I am not the only one who sees it. But probably you won't see it. | 22:30 |
| Nrml | OK | 22:31 |
| Nrml | rwp> The Daedalus kernel is 6.1.0-13-amd64. I would probably install it, then hold it, and then upgrade everything around it. -> this sounds like the best policy right now. | 22:31 |
| onefang | With 256 GB of memory, I might not see it for some time. | 22:31 |
| Nrml | onefang: my machine with the most RAM has just 64GB | 22:31 |
| Nrml | rwp: kernel 6.4 not an option? | 22:32 |
| Xenguy | rwp, re: "https://www.devuan.org/get-devuan": After a quick glance, the mirror seems properly up-to-date | 22:32 |
| rwp | I am wondering if the upgrade to the zfs version 2.1.13 (I assume it is an upgrade from a previous version) requires grub to be upgraded in order to identify the new zfs features it provides? Perhaps grub-install is needed? | 22:32 |
| Nrml | rwp: I can try and install it manually | 22:32 |
| rwp | Xenguy, See the discussion of mirrors.ocf.berkeley.edu in the scrolllback above. | 22:32 |
| Xenguy | rwp, I was replying to just that | 22:33 |
| Xenguy | The package mirrors may be an issue, but the ISO mirror looks okay, at first glance | 22:33 |
| Nrml | rwp: hummrmrmrmr | 22:33 |
| Nrml | # apt-cache policy grub-install | 22:33 |
| Nrml | N: Unable to locate package grub-install | 22:33 |
| rwp | grub-install is in the grub-common package. | 22:34 |
| Nrml | OK | 22:34 |
| rwp | Sorry. grub2-common. | 22:34 |
| rwp | Xenguy, Ah, yes, (hand slaps forhead) I forgot the difference between ISO mirrors and package mirrors. | 22:35 |
| onefang | Some do both, but that's entirely up to the mirror admins. | 22:35 |
| Xenguy | rwp, Yeah, I finally figured that out, after some years of reminding myself : -) | 22:35 |
| Nrml | grub-common is installed and is the newest available version: https://paste.lcomrade.su/nWZz0N9c | 22:35 |
| Nrml | checking grub2-common nopw | 22:36 |
| Nrml | *now | 22:36 |
| Nrml | Ditto grub2-common: https://paste.lcomrade.su/HztyfWmo | 22:37 |
| rwp | Those grub-common and grub2-common package installs all look normal to me. | 22:38 |
| Nrml | yeo | 22:38 |
| Nrml | but still there's an error with grub-install during `apt-get upgrade --with-new-pkgs`: | 22:38 |
| Nrml | version_find_latest | 22:39 |
| rwp | The earliest error mentions cryptsetup. Do you have cryptsetup-initramfs installed? That's critical. | 22:39 |
| Nrml | is that some kind of grub internal module/file? | 22:39 |
| rwp | At some point cryptsetup-initramfs because split off from cryptsetup and there is no Depends to pull it in on an upgrade. I have been burned by that twice so far. By the second time I should have known but got snagged a second time anyway. | 22:40 |
| Nrml | lemme check cryptsetup-initramfs | 22:40 |
| Nrml | yep, cryptsetup-initramfs installed and latest version: https://paste.lcomrade.su/3VPCkyjq | 22:41 |
| Nrml | Please let me point to this error line specifically: | 22:42 |
| Nrml | /etc/grub.d/10_linux: 1: version_find_latest: not found | 22:42 |
| rwp | Can you post "dpkg -l | grep grub" to see what else might be involved there? | 22:42 |
| rwp | There is no mention of version_find_latest in my /etc/grub.d/10_linux script from grub-common version 2.12~rc1-12 | 22:43 |
| Nrml | rwp: here it is: https://paste.lcomrade.su/raw/VhZZS2vt | 22:44 |
| rwp | I don't have a UEFI booting Unstable system to share back. :-( | 22:45 |
| rwp | grub-pc is in the "rc" state. It has config files installed but is otherwise marked as removed. I would "purge" it. "apt-get purge grub-pc" (or dpkg --purge grub-pc) | 22:46 |
| rwp | Here is my copy of /etc/grub.d/10_linux and it seems important that yours is different https://paste.debian.net/plain/1299320 | 22:48 |
| rwp | Is there a /etc/grub.d/10_linux.dpkg-* file? Like if the local one was modified by something and the new version did not get installed? | 22:49 |
| Nrml | OK, purging grub-pc | 22:54 |
| Nrml | Humrmrmrmr... | 22:55 |
| Nrml | https://i.imgur.com/SmLwNm2.png | 22:56 |
| Nrml | Doesn't look good | 22:56 |
| rwp | Hmm... That does not make sense. I would definitely not do that until that is understood. | 22:56 |
| Nrml | Peraps it would be best to fully install grub-pc instead? | 22:57 |
| Nrml | *Perhaps | 22:57 |
| rwp | Maybe. I don't know. This is the only UEFI system I have available to look at here: https://paste.debian.net/plain/1299321 | 22:58 |
| Nrml | Tried and it installed OK, now doing a `dpkg-reconfigure linux-image-6.5.0-4-amd64` | 23:01 |
| Nrml | Looks good! | 23:01 |
| Nrml | No errors | 23:01 |
| rwp | https://bbs.archlinux.org/viewtopic.php?id=279415 mentions that version_find_latest is part of a grub-customizer package and that removing it solved that person's problem. | 23:01 |
| Nrml | Here's a paste: https://paste.lcomrade.su/E2JkeXEB | 23:02 |
| Nrml | cryptsetup WARNING/ERROR persist, but I' | 23:02 |
| Nrml | *but I'm pretty sure they can be ignored. | 23:03 |
| Nrml | So, `apt-get dist-upgrade` now? | 23:03 |
| rwp | Has that completed successfully yet? If not then yes. | 23:03 |
| rwp | I hate to say this Nrml but I must. Welcome to Unstable! These problems are sometimes what happens in Unstable. | 23:03 |
| Nrml | rwp: no problem. | 23:04 |
| rwp | And also with UEFI too. Working with UEFI is like trying to pet a feral cat. | 23:04 |
| Nrml | rwp> Has that completed successfully yet? -> What is "that"? `apt-get upgrade --with-new-pkgs` ? | 23:05 |
| rwp | Either. Both! | 23:05 |
| rwp | if apt-get upgrade --with-new-pkgs is now clean then proceed on to apt-get dist-upgrade. | 23:05 |
| Nrml | I think it's now clean as the only error was the one I just fixed with `apt-get install grub-pc && dpkg-reconfigure linux-image-6.5.0-4-amd64` | 23:08 |
| Nrml | But I will run it again, brb | 23:09 |
| Nrml | Looks reasonably clean to me: https://paste.lcomrade.su/Om8L7BUU | 23:11 |
| Nrml | Just a handful of 'no longer required' packages, which I plan on ignoring for now. | 23:11 |
| Nrml | so, `apt-get dist-upgrade` and then reboot? | 23:12 |
| rwp | Looks good so far! Yes. Keep going. | 23:13 |
| rwp | Review the action list for dist-upgrade carefully focusing specifically on the remove section. | 23:13 |
| rwp | Before rebooting run this and review if you need something special: find /etc \( -name '*.dpkg-*' -o -name '*.ucf-*' \) -print | 23:14 |
| Nrml | OK, from your article. Wilco! | 23:14 |
| onefang | Maybe I should read that article after all, so far I have added two of your suggestions to my install scripts. lol | 23:20 |
| ddl | ty too. | 23:24 |
| Nrml | rwp: reading your article. just got here: "All of the above has been the preparation". This has been about 90% of the article, and this is BEFORE the upgrade per se | 23:35 |
| Nrml | Ouch | 23:35 |
| Nrml | I did nothing / almost nothing of that prep | 23:36 |
| ddl | 99.43% and 0.57% | 23:36 |
| rwp | Yup! As I said, preparation is the most important part. | 23:36 |
| ddl | nobody gets root here silly | 23:36 |
| ddl | it's in Crisco | 23:36 |
| Nrml | should I just rollback to a snapshot before I started trying to do all that (ie, where Daedalus was installed and working) and then redo it all, but with your prep steps before the upgrade per se? | 23:37 |
| rwp | I need to update the section talking about the handling of obsolete conffiles. Because I only just edit the status file manually now. I should create a script to automate the handling of it. | 23:38 |
| rwp | Nrml, Are things working for you now or not? Are things working or broken? If working then well you have just muddled through like most people do. Keep going. | 23:38 |
| rwp | Nrml, I am anxious to hear how your upgrade turns out! But I am go afk for a while. BBIAB! Until then Good Luck! | 23:59 |
Generated by irclog2html.py 2.17.0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!
