On Tue, 3 Aug 2021 16:08:52 +0800, Brad wrote in message 
<d67d6970-65d8-8a5f-5edd-05657e0ed...@fnarfbargle.com>:
> On 3/8/21 1:32 pm, Brad Campbell via Dng wrote:
> > Just got stung again by this one, this time upgrading an ascii 64
> > bit rpi3 image to beowulf while using a 5.10 kernel provided by the
> > rpi foundation.
> > 
> > This time I just unpacked the deb, commented out the "exit 1" and

..my occational workaround, is cheat out apt (or dpkg), adding 
an "exit 0" line below any line acting up in any of the relevant
control-the-package script in /var/lib/dpkg/info/$PACKAGENAME.*, 
for e.g. zsh, those are: root@d44:~# ll /var/lib/dpkg/info/zsh.*
-rw-r--r-- 1 root root 2569 Apr 27  2020 /var/lib/dpkg/info/zsh.list
-rw-r--r-- 1 root root 3483 Feb  5  2019 /var/lib/dpkg/info/zsh.md5sums
-rwxr-xr-x 1 root root  949 Feb  5  2019 /var/lib/dpkg/info/zsh.postinst
-rwxr-xr-x 1 root root  356 Feb  5  2019 /var/lib/dpkg/info/zsh.postrm
-rwxr-xr-x 1 root root  178 Feb  5  2019 /var/lib/dpkg/info/zsh.preinst
-rwxr-xr-x 1 root root  178 Feb  5  2019 /var/lib/dpkg/info/zsh.prerm

..easier, and disappears on the next upgrade. ;o)

> > repacked the deb, then a bit of manual installation to get the
> > dependencies updated. 
> 
> 
> After another re-install ascii and upgrade to beowulf to verify I can
> confirm that if you remove or rename /run/udev prior to the
> dist-upgrade the check gets disabled. It's pretty obvious in the
> pre-inst file, but as it only ever caught me in the middle of an
> upgrade when I was more interested in getting things running rather
> than finessing a work-around I never really looked too hard.
> 
> In my case I ran the dist-upgrade until it bombed out, rm
> -r /run/udev and then ran the upgrade again and this time it ran to
> completion. A manual /etc/init.d/eudev restart afterwards re-created
> the directory and we are off to the races.
> 
> I can't see why I wouldn't just zap /run/udev before the upgrade.

..last year's Knoppix-8.6.1 has a similar problem, it boots with 
2 udev processes, each eating 100% cpu of each core, I simply kill 
all udev processes and restart the udev service. 
Uptime now 51 days 18:30, I haven't gotten around to test the other 
isos down my /boot/images. :o)

-- 
..med vennlig hilsen = with Kind Regards from Arnt Karlsen
...with a number of polar bear hunters in his ancestry...
  Scenarios always come in sets of three: 
  best case, worst case, and just in case.
_______________________________________________
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Reply via email to