[Discuss] Serious error in /usr

[Alan W. Irwin]

On 2016-04-22 19:56-0700 Murray Strome wrote:

> When I reboot into Ubuntu (16.04) on at least one computer, first it will not 
> boot. If I chose Advanced Options, and Upstart I get a message saying 
> something like "Serious error in /usr", which is a separate partition.
>
> I am given a few options, but if I chose "I" to ignore the error, it does 
> boot OK, and I have several options for Windows managers. In the past, Icewm 
> was often the best, but right now, Plasma (i.e. KDE) seems to be working the 
> best.
>
> What I would like to know is:
> How can I find out what the "serious errors" might be, and how can I fix 
> them?  I really do not want to have to go through the pain of reinstalling 
> Ubuntu if I don't have to do so.
>
> Any help would be greatly appreciated.

Hi Murray:

One obvious possibility for a serious error is you have some
bad memory.  To check memory, I suggest you install and use the
memtest86+ Ubuntu package (if you haven't installed that
already).  That will create an extra grub option to run
that memory test every time you get concerned about system
integrity.

Assuming that test gives good results, then another possibility is
your disk is dying (i.e., ran out of spare blocks to replace the bad
ones that modern disks self detect).  To check for that possibility, I
suggest you umount your /usr partition, then do a file system check on
that unmounted partition to see if your file system is consistent or
not.

man fsck

Also, if you are using rsync for backups to an external disk, then if
you have ever experimented by repeating the rsync command for a
filesystem you will find that second rsync to be extremely fast and it
should show no changes for the second rsync assuming there have been
no writes to the internal filesystem in the interval between the two
rsync commands.  In addition from time to time you might also want to
try using the --checksum option (man rsync) for a third rsync command.
That effectively runs a checksum on every file on the internal
filesystem and the external filesystem and updates the external
filesystem if there are any checksum differences. So it is quite slow
compared to normal rsync operations, but it does constitute a complete
end-to-end check that both internal disk and external disk have
identical files. So assuming your external disk is healthy, that tests
that your internal disk is being read consistently without random bit
flips between the particual rsync command that wrote each of the
external files and the last rsync command.  So it is a fairly good
check that all is well with both the internal and external disks, and
I have formed the habit of using this check (which typically takes
several hours) whenever there is any question concerning system
integrity.

Alan
__________________________
Alan W. Irwin

Astronomical research affiliation with Department of Physics and Astronomy,
University of Victoria (astrowww.phys.uvic.ca).

Programming affiliations with the FreeEOS equation-of-state
implementation for stellar interiors (freeeos.sf.net); the Time
Ephemerides project (timeephem.sf.net); PLplot scientific plotting
software package (plplot.sf.net); the libLASi project
(unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);
and the Linux Brochure Project (lbproject.sf.net).
__________________________

Linux-powered Science
__________________________