Autor: Arnt Karlsen Data: Para: dng Assunto: Re: [DNG] Ascii to Beowulf upgrade borked with eudev
On Tue, 3 Aug 2021 16:08:52 +0800, Brad wrote in message
<d67d6970-65d8-8a5f-5edd-05657e0edc80@???>: > 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.