On Fri, 2018-01-26 at 00:42 +0100, Guillem Jover wrote: > Are you sure they are not fully upgraded? What makes you think so? > Just the dpkg.log below?
No, I ignored it at first cause I thought it's not so unlikely, that the log simply didn't got flushed out before the freeze. But then there was recently an upgrade to glibc (which includes local re-generation). A crash happened and afterwards e.g. gnome-terminal didn't even start anymore (with some locale related errors, when started from xterm). Once I regenerated the locales, gnome-terminal worked fine again. Of course it could simply be, that the locales didn't get flushed out in time (respectively no commit was made in btrfs),... but then dpkg shouldn't think it would be configured, right? Also, when I was actually looking at the upgrade process in aptitude... I had several times such a freeze, and it didn't even reach the "Setting up..." phase. So intuitively I'd guess it couldn't finish that after the freeze (at least the HDD LED didn't show any flashing). > Intel microcode? Unlikely, cause I've seen these freezes long before the spectre/meltdown upgrades, and at least once again after the microcode was withdrawn since. > > Normally dpkg -C would show this then, but it doesn't. > > Neither does dpkg --configure -a do anything. > > And there are no packages in the status file with Status less than > installed. And no lingering files under «/var/lib/dpkg/updates»? /var/lib/dpkg/updates/ is empty (well at least right now... not sure if it would have gotten cleaned up somehow else in the meantime). /var/lib/dpkg# grep ^Status status | sort -u Status: deinstall ok config-files Status: hold ok installed Status: install ok installed but these are all expected (i.e. the deinstall config-files are deleted/not-purged packages) > > This happened alrready quite some times now, an probably my system > > has > > many packages in a state not fully installed, while dpkg thinks > > everything > > would be fine. > > dpkg is very careful about how it handles its database. If it think > they are installed, and there are no update journal entries on the > above directory. Then this might indicate something more severe like > a very broken filesystem on-disk or implementation or hardware > failure > or similar. Arguably, btrfs isn't perfect, but so far I never found any real corruptions in case of any freezes/crashes/etc. The only thing what I ever found was that something wasn't committed yet, and got completely removed, but that in turn should dpkg protect against, AFAIU (with syncs at the appropriate places). As for the hardware: I think it could then only be the SSD, cause this is the only common thing, after I switched the notebook now. > > Interestingly: debsums -asc doesn't find problems. > > That to me would indicate that the packages are either the old > versions or the new ones, but thay match. Is there any easy way to check that (i.e. whether they files are all still old, but dpkg thinks the upgrade was performed and the new version would be in place)? I did a random sample and compared one file of libc6 and locales package, but from my system with that of the .deb,... but of course I may have just picked the wrong one that still matches. Could it be, that they always got unpacked, but not configured and that only this information would have been somehow lost? Cause that could explain why the locales haven't been regenerated. > > I have no idea how to debug this any further... please tell me if > > you need > > anything. > > btw: this is on btrfs > > That alone seems very suspect IMO. ;-) Well it's much better IMO than it's reputation. Of course when one uses not-yet-stable features like qgroups or raid56, things get easily problematic,... but other than that the design of btrfs with CoW should in principle prevent any corruptions and just allow for either-old-or- new. And as I've said, so far I never found a really corrupt file. Thanks :)
