[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