Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > comp.os.linux.misc > #89524 > unrolled thread

Uh Oh - HOSED Upgrade - Deb - HOW to Recover ?

Started byc186282 <c186282@nnada.net>
First post2026-08-03 23:05 -0400
Last post2026-08-05 03:10 +0000
Articles 5 — 4 participants

Back to article view | Back to comp.os.linux.misc


Contents

  Uh Oh - HOSED Upgrade - Deb - HOW to Recover ? c186282 <c186282@nnada.net> - 2026-08-03 23:05 -0400
    Re: Uh Oh - HOSED Upgrade - Deb - HOW to Recover ? rbowman <bowman@montana.com> - 2026-08-04 06:29 +0000
    Re: Uh Oh - HOSED Upgrade - Deb - HOW to Recover ? Charlie Gibbs <cgibbs@kltpzyxm.invalid> - 2026-08-04 18:18 +0000
      Re: Uh Oh - Hosed Upgrade - Deb - How to Recover ? Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-08-05 00:19 +0000
      Re: Uh Oh - HOSED Upgrade - Deb - HOW to Recover ? rbowman <bowman@montana.com> - 2026-08-05 03:10 +0000

#89524 — Uh Oh - HOSED Upgrade - Deb - HOW to Recover ?

Fromc186282 <c186282@nnada.net>
Date2026-08-03 23:05 -0400
SubjectUh Oh - HOSED Upgrade - Deb - HOW to Recover ?
Message-ID<LtednTo-66N9y-z3nZ2dnZfqnPcAAAAA@giganews.com>
Just the latest upgrade for my Deb-derived distro (MX) and
suddenly getting evil evil messages about how the latest
kernel is missing dependencies and WON'T upgrade.

"
dpkg: error processing package linux-image-liquorix-amd64 (--configure):
  dependency problems - leaving unconfigured
dpkg: dependency problems prevent configuration of 
linux-headers-liquorix-amd64:
  linux-headers-liquorix-amd64 depends on 
linux-headers-7.1.5-2-liquorix-amd64 (= 7.1-7~mx23ahs); however:
   Package linux-headers-7.1.5-2-liquorix-amd64 is not configured yet.
dpkg: error processing package linux-headers-liquorix-amd64 (--configure):
  dependency problems - leaving unconfigured
"

Never seen this with MX before. Waited a couple of
days to see if a fix was simply "late" - but no.
MX usually "Just Works".

Tried the usual junk-removal stuff. No good.
"--fix-missing", no good.

Now, fortunately, MX has a good 'custom ISO creator'
utility and I'd done a full image just maybe three
weeks ago. If I *must* I can make a thumb containing
that ... which WILL install. But that's kinda MAJOR.
Can copy my desktop and a few other things somewhere
and copy them back later. Then re-try the updates.

But that SUCKS SUCKS SUCKS !

"Dependency problems" ? Why not NAME it ???
Guess you're just "supposed to know" ...

Any advice here before I have to do The Nasty ???

Had a similar intractable update issue with Manjaro
a year ago - broken and would not be fixed. Had to
just HOSE it. Updates, esp "security" updates, are
very important these days - too many out to Get Us.

Plus, my MX is still WORKING. However the FUTURE
is unclear. NEED a 'future'.

[toc] | [next] | [standalone]


#89534

Fromrbowman <bowman@montana.com>
Date2026-08-04 06:29 +0000
Message-ID<nddf5dF4198U28@mid.individual.net>
In reply to#89524
On Mon, 3 Aug 2026 23:05:35 -0400, c186282 wrote:

> Just the latest upgrade for my Deb-derived distro (MX) and suddenly
> getting evil evil messages about how the latest kernel is missing
> dependencies and WON'T upgrade.

How's that ahs going for you? I uodated today and 6.12.100 is doing fine.

[toc] | [prev] | [next] | [standalone]


#89561

FromCharlie Gibbs <cgibbs@kltpzyxm.invalid>
Date2026-08-04 18:18 +0000
Message-ID<P1qcS.5178$bZ8b.4024@fx01.iad>
In reply to#89524
On 2026-08-04, c186282 <c186282@nnada.net> wrote:

> Just the latest upgrade for my Deb-derived distro (MX) and
> suddenly getting evil evil messages about how the latest
> kernel is missing dependencies and WON'T upgrade.

This is similar to another thread I started here.  IMHO
upgrades are the scariest part of Linux.  I always take
full backups of everything first with a script like this:

#!/bin/bash
# Back up cjglap2 - version 2025-08-27
# This script must be run as root!
if [ "$(id -u)" -ne 0 ];
then
  echo This script must be run as root!
  exit
fi
# Copy the root partition.
dd if=/dev/sda1 | gzip >/mnt/backup/cjglap2/sda1.img.gz
# Copy various directories.
rsync -av --delete /etc                                /mnt/backup/cjglap2
rsync -av --delete /usr                                /mnt/backup/cjglap2
rsync -av --exclude='/home/cjg/.cache/' --delete /home /mnt/backup/cjglap2
rsync -av --delete /var/spool/slrnpull                 /mnt/backup/cjglap2

Then, even if the worst happens, I can wipe the disk and start over.
Having /home in its own partition makes things a lot easier.

-- 
/~\  Charlie Gibbs                  |  In this world there are
\ /  <cgibbs@kltpzyxm.invalid>      |  two kinds of people:
 X   I'm really at ac.dekanfrus     |  1. Those who can extrapolate
/ \  if you read it the right way.  |  from incomplete data.

[toc] | [prev] | [next] | [standalone]


#89564

FromLawrence D’Oliveiro <ldo@nz.invalid>
Date2026-08-05 00:19 +0000
Message-ID<114tvid$2iv3s$1@dont-email.me>
In reply to#89561
On Tue, 04 Aug 2026 18:18:23 GMT, Charlie Gibbs wrote:

> # Copy the root partition.
> dd if=/dev/sda1 | gzip >/mnt/backup/cjglap2/sda1.img.gz

Doing a dd on a volume that is currently mounted may not give
completely reliable results.

> # Copy various directories.
> rsync -av --delete /etc                                /mnt/backup/cjglap2
> rsync -av --delete /usr                                /mnt/backup/cjglap2
> rsync -av --exclude='/home/cjg/.cache/' --delete /home /mnt/backup/cjglap2
> rsync -av --delete /var/spool/slrnpull                 /mnt/backup/cjglap2

“-a” does not include “-A” or “-X”, which I like to include these
days, just in case.

[toc] | [prev] | [next] | [standalone]


#89565

Fromrbowman <bowman@montana.com>
Date2026-08-05 03:10 +0000
Message-ID<ndfnt1F4198U38@mid.individual.net>
In reply to#89561
On Tue, 04 Aug 2026 18:18:23 GMT, Charlie Gibbs wrote:

> This is similar to another thread I started here.  IMHO upgrades are the
> scariest part of Linux.  I always take full backups of everything first
> with a script like this:

I hit that this morning. I'd been playing with CircuitPython on an old 
Playground Express board using VS Code and the CircuitPython v2 extension. 
All was good. I updated the Leap machine and got the latest Code, 1.131. 
The extension crashed and burned on takeoff. I reverted Code to 1.130, 
still no joy. I jumped a few but 1.127 works as expected. 

The other part is 1.127 uses Electron 42.2, 1.130 and 1.131 use 42.7. That 
makes me suspicious. Before the Trixie update Code started to crash on the 
Pi 5. It turned out the kernel optimizations for the Pi 5 were the problem 
and reverting to the Pi 4 kernel solved it.

Too damn many moving parts! At least it helped me to decide on MicroPython 
instead of CircuitPython. CP has some advantages but the extension author 
lost interest about 10 months ago so I'm not waiting for a VS Code fix. I 
assume it still works with Thonny, the default IDE in the Raspberry Pi OS. 
Adafruit used to recommend Mu but that's dead now too.

[toc] | [prev] | [standalone]


Back to top | Article view | comp.os.linux.misc


csiph-web