On Tuesday, October 27, 2015 12:25:07 PM Peter Humphrey wrote: > On Tuesday 27 October 2015 12:04:46 Stefan G. Weichinger wrote: > > Am 26.10.2015 um 15:47 schrieb Peter Humphrey: > > > I keep the portage tree under /usr-bits. > > > > > > # dmesg | grep sdb3 > > > [ 1.753508] sdb: sdb1 sdb2 sdb3 sdb4 < sdb5 sdb6 sdb7 sdb8 sdb9 > > > > [ 4.833460] EXT4-fs (sdb3): mounted filesystem with ordered data > > > mode. > > > Opts: (null) > > > [ 107.205918] EXT4-fs (sdb3): mounted filesystem with ordered data > > > mode. > > > Opts: (null) > > > > > > You can see the successful mount at 4.8 s; the entry at 107 s is me > > > mounting it again manually. > > > > > > I've rewritten the partition label, and I've run a smartctl test which > > > reported no faults found. I've also just reduced the speed of the > > > chipset, > > > which has three settings: good performance, better performance and > > > turbo. > > > It adopts the turbo setting by default and I've now set it to "better". > > > It's too early yet to see if that will help. > > > > interesting ... > > > > What init-system? openrc or systemd? > > Openrc. > > > No trace of the actual unmount in any logs? > > Not that I can find, no. > > > Maybe also look/grep for the LABEL of the fs. > > Nope, nor that. > > > Maybe test if using the device-name itself ( /dev/sdb3 ) or the UUID in > > fstab changes the behavior. > > I'll try reverting to /dev/sdb3 and see if that helps. > > > I use UUIDs here without problems (with systemd). > > The only thing I use UUIDs for here is in mdadm.conf to get the LVs started > reliably for the main system*. Those live in partitions /dev/sd[ab][5789]. > > Three more things: I've had the cover off and checked the seating of the > SATA cables; while the lid was off I watched the MB LEDs during startup, > which seemed okay; and today the kernel was upgraded from 4.0.5 to 4.0.9; > that may help too. (Hm ... too many changes at once.) > > * Now that I think of it, one of the LVs came up as inactive the other day, > and nothing I could think of would activate it (consulting man mdadm of > course). In the end I had to reboot. This machine has shown some bizarre > behaviour over the last few months. Something is definitely wrong; I just > can't figure out what it is.
The full log for that entire period might be useful. If a disk is umounted/removed, something needs to be logged somewhere. Might even be a comment from the scsi-subsystem or the SATA driver. I usually only grep the log to try to find specific messages. If I know the time-period something weird happened in, I tend to go through the unfiltered log for that period. -- Joost
