[TriLUG] Ubuntu 18.04 upgrade problem
Pete Soper via TriLUG
trilug at trilug.org
Tue Apr 16 10:28:36 EDT 2019
Thanks, Aaron. Yes, it was ineffective as you predicted. So this
suggests libc6-dev-armhf-cross_2.27-3ubuntu1cross1.1_all.deb out on the
Internet is defective?
But this is actually noise, as I see that other upgrades are happening
without incident, none of the cross-dev tools I'm using for work seem to
be impacted, so I can just ignore this as an easy solution.
-Pete
On 4/16/19 10:04 AM, Aaron Schrab wrote:
> At 17:19 -0400 15 Apr 2019, Pete Soper via TriLUG <trilug at trilug.org>
> wrote:
>> How do I undo whatever has tricked my system into thinking it has the
>> necessary local files to do the upgrade below? Seems if I can somehow
>> force the upgrade to go back out for the pieces and parts I'll have a
>> chance of working around this. This was a side effect of a periodic
>> "apt-get update;apt-get upgrade" or the equivalent by software updater.
>
>> dpkg: error processing archive
>> /var/cache/apt/archives/libc6-dev-armhf-cross_2.27-3ubuntu1cross1.1_all.deb
>>
>
> The line above is the location of the downloaded packages. You could
> try clearing out that directory, but I doubt if it would help. dpkg
> will check the integrity of the packages before it tries to use them;
> if they're corrupted it will just ignore the cached copy and download
> a new one.
>
>> (--unpack):
>> unable to open '/usr/arm-linux-gnueabihf/lib/Mcrt1.o.dpkg-new': No such
>> file or directory
>
> This and the similar line further down are the real errors. For some
> reason dpkg isn't able to create files in the
> `/usr/arm-linux-gnueabihf/lib/` directory. The package should include
> all of the leading directories, so that tends to indicate that there's
> some deeper problem such as filesystem corruption or misconfigured
> Mandatory Access Control.
>
> I'd run `sudo mkdir /usr/arm-linux-gnueabihf{,/lib}` to attempt to
> create the containing directory manually. dpkg should be doing that on
> it's own, even replacing any conflicting files, broken symlinks, or
> device entries. Trying that manually may reveal more about why it
> wasn't able to do so.
More information about the TriLUG
mailing list