On Tuesday 27 October 2015 18:18:18 J. Roeleveld wrote: > On 27 October 2015 17:36:00 CET, Peter Humphrey <[email protected]> wrote: > >On Tuesday 27 October 2015 15:16:26 J. Roeleveld wrote: > >> 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. > > > > I have been scanning dmesg and /var/log/messages by eye and not noticed > > anything. I'll keep doing it though. > > What does your fstab look like?
I gave the two relevant lines in my first message, but here's the whole thing: LABEL=RescueSys / ext4 relatime 1 1 LABEL=RescUsrBits /usr-bits ext4 relatime 1 2 /dev/md1 /boot ext2 relatime,noauto 1 2 /dev/md5 /mnt/main ext4 relatime,noauto,dev,exec 0 2 /dev/vg7/local /mnt/main/usr/local ext4 relatime,noauto 0 3 /dev/vg7/home /mnt/main/home ext4 relatime,noauto 0 3 /dev/vg7/common /mnt/main/home/prh/common ext4 relatime,noauto 0 4 /dev/vg7/virt /mnt/main/home/prh/.VirtualBox ext4 relatime,noauto 0 4 /dev/vg7/boinc /mnt/main/home/prh/boinc ext4 relatime,noauto 0 4 /dev/vg7/var /mnt/main/var ext4 relatime,noauto 0 2 /dev/vg7/portage /mnt/main/usr/portage ext4 relatime,noauto 0 2 /dev/vg7/packages /mnt/main/usr/portage/packages ext4 relatime,noauto 0 3 /dev/vg7/distfiles /mnt/main/usr/portage/distfiles ext4 relatime,noauto 0 3 /dev/vg7/opt /mnt/main/opt ext4 relatime,noauto 0 3 /dev/vg7/atom /mnt/main/mnt/atom ext4 relatime,noauto 0 3 /dev/vg7/atomresc /mnt/main/mnt/atomresc ext4 relatime,noauto 0 3 /dev/vg7/tpad /mnt/main/mnt/tpad ext4 relatime,noauto 0 3 /dev/vg7/vartmp /mnt/main/var/tmp ext4 relatime,noauto 0 3 /dev/sdc5 /mnt/sdc ext4 relatime,noauto,user 0 0 /dev/sdd5 /mnt/sdd ext4 relatime,noauto,user 0 0 /dev/sr0 /mnt/dvd iso9660 noauto,user 0 0 /dev/sda2 none swap sw 0 0 /dev/sdb2 none swap sw 0 0 tmpfs /tmp tmpfs nodev,nosuid,size=6G 0 0 proc /proc proc defaults 0 0 shm /dev/shm tmpfs nodev,nosuid,noexec 0 0 /dev/md8 /mnt/qt5 ext4 noauto,relatime 0 0 /dev/vg9/home /mnt/qt5/home ext4 noauto,relatime 0 0 /dev/vg9/var /mnt/qt5/var ext4 noauto,relatime 0 0 /dev/vg9/vartmp /mnt/qt5/var/tmp ext4 noauto,relatime,nosuid,nodev 0 0 /dev/vg9/local /mnt/qt5/usr/local ext4 noauto,relatime 0 0 /dev/vg9/portage /mnt/qt5/usr/portage ext4 noauto,relatime 0 0 /dev/vg9/packages /mnt/qt5/usr/portage/packages ext4 noauto,relatime 0 0 /dev/vg9/distfiles /mnt/qt5/usr/portage/distfiles ext4 noauto,relatime 0 0 > And maybe some more info, like which kernel version. Mount version. > And maybe check for some weird crontab entry somewhere? No cron installed. Kernel was 4.0.5 at the time of writing, upgraded to 4.0.9 yesterday. Mount is in sys-apps/util-linux-2.26.2 - was 2.25.2-r2 until 27 September but the problem occurred with both versions. > You could also rule out the use of umount by replacing it with a wrapper > script that logs every call with as much info as is possible? Hm. That may be above my bash grade. I'm inclined to suspect the kernel. No real evidence, just that I've booted the rescue system twice since installing the new kernel and everything worked as it should. -- Rgds Peter
