Seems to be. Thanks again!
Fred
On Thu, Jan 7, 2021 at 1:46 AM Simon Matter wrote:
> Hi Fred, no I was asking about the auto mount and umount issue you had.
> Did you get it to work correctly?
>
> Simon
>
> > Simon, if you're talking about the occasional crash, I don't know, since
> > it
> > ha
Hi Fred, no I was asking about the auto mount and umount issue you had.
Did you get it to work correctly?
Simon
> Simon, if you're talking about the occasional crash, I don't know, since
> it
> happens only occasionally. If I can make it thru six months without seeing
> it, then I'll declare it f
Simon, if you're talking about the occasional crash, I don't know, since it
happens only occasionally. If I can make it thru six months without seeing
it, then I'll declare it fixed.
Thanks!
On Wed, Jan 6, 2021 at 1:23 PM Simon Matter wrote:
> Have you been able to fix the issue?
>
> Regards,
>
Have you been able to fix the issue?
Regards,
Simon
> OK, here's where I stand now:
> 1. I stopped and disabled autofs. (I have 2 SMB filesystems out on the LAN
> that have also been automounting with autofs, do I need to do similar
> changes in fstab for them?)
> 2. yes it has.
> 3. none I can s
OK, here's where I stand now:
1. I stopped and disabled autofs. (I have 2 SMB filesystems out on the LAN
that have also been automounting with autofs, do I need to do similar
changes in fstab for them?)
2. yes it has.
3. none I can see.
4. nothing that leaps out at me. there are a couple about /mnt
Verify that:
1. Autofs is not running
2. Systemd has created '.mount' and '.automount' units
systemctl status mnt-backup.mount mnt-backup.automount
systemctl cat mnt-backup.mount mnt-backup.automount
3. Verify that there are no errors in local-fs.target
systemctl status local-fs.target
4. Check f
OK, I think I've got it set up as described here, while fixing the
misplaced fields in /etc/fstab:
UUID=259ec5ea-e8a4-465a-9263-1c06217b9aaf /mnt/backup ext4
x-systemd.automount,x-systemd.idle-timeout=15min,noauto 0 2
now when I do, e.g., "ls /mnt/backup"
I get:
$ sudo !!
sudo
>
> I commented out those entries in /etc/auto.master before modifying the
> fstab entry:
>
> UUID=259ec5ea-e8a4-465a-9263-1c06217b9aaf /mnt/backup
> ext4,x-systemd.automount,x-systemd.idle-timeout=15min noauto 0 2
That's not correct. See 'man fstab'. It should be
device m
The first question I would have is this: Has the auto-reboot occurred
since the machine was last built or did this begin at some point after
the build?
Apologies if I missed this in the many threads stemming from your OP…
- - -
On 2 Jan 2021, at 6:44, Fred wrote:
Hi all, I'm hoping someone
Reboot is not necessary as long as local-fs.target is restarted, but a fix for
the /etc/fstab might be needed.
Best Regards,
Strahil Nikolov
В неделя, 3 януари 2021 г., 21:18:30 Гринуич+2, Simon Matter
написа:
> $ cat /etc/centos-release
> CentOS Linux release 7.9.2009 (Core)
>
> $
Erm ... the noauto should be part of the options column, so append it to the
previous option (and of course delimit with a ",").
I see that the '.automount' was not generated ... Maybe it's related to the
noauto issue.
By the way , "mount -a" should complain if fstab is not OK.
Best Regards,
S
> $ cat /etc/centos-release
> CentOS Linux release 7.9.2009 (Core)
>
> $ sudo systemctl status mnt-backup.mount mnt-backup.automount
> [sudo] password for fredex:
> ● mnt-backup.mount - /mnt/backup
>Loaded: loaded (/etc/fstab; bad; vendor preset: disabled)
>Active: active (mounted) since Sa
$ cat /etc/centos-release
CentOS Linux release 7.9.2009 (Core)
$ sudo systemctl status mnt-backup.mount mnt-backup.automount
[sudo] password for fredex:
● mnt-backup.mount - /mnt/backup
Loaded: loaded (/etc/fstab; bad; vendor preset: disabled)
Active: active (mounted) since Sat 2021-01-02 22
Are you still on 7.6 ? I recently discovered that a bug in sysstat was fixed in
7.7 that prevented autofs from umounting the filesystem.
The following should show if it's taking into action:
systemctl status mnt-backup.mount mnt-backup.automount
systemctl cat mnt-backup.mount mnt-backup.automount
Strahil:
I WAS using that, but the automatic umount never worked, leaving it mounted
all the time.
I commented out those entries in /etc/auto.master before modifying the
fstab entry:
UUID=259ec5ea-e8a4-465a-9263-1c06217b9aaf /mnt/backup
ext4,x-systemd.automount,x-systemd.idle-timeout=15min
Hi Fred,
do you use automatic umount for the map in /etc/auto.master (--timeout) ?
If yes, then the systemd mount options probably won't help.
Best Regards,
Strahil Nikolov
В неделя, 3 януари 2021 г., 04:27:17 Гринуич+2, Fred
написа:
Yeah, and the instructions for setting RAID-1
Yeah, and the instructions for setting RAID-1 or RAID-0 have the switch
positions exactly reversed.
Strahil: I'm using autofs to automount the unit. but just turned that off
and enabled the xsystemd.automount in fstab, we'll see how that works.
Fred
On Sat, Jan 2, 2021 at 4:11 PM Warren Young
On Jan 2, 2021, at 11:17 AM, Fred wrote:
>
> I assume that the yottamaster device runs Linux, just like 99% of other
> such devices.
99% of NAS boxes, maybe, but not dumb RAID boxes like the one I believe you’re
referring to.
(And I doubt even that, with the likes of FreeNAS extending down fro
> Just add "x-systemd.automount,x-systemd.idle-timeout=10min" in the
> fstab mount options , or create an ".mount" + ".automount" entries
> for
> it (autofs is also an option) and test.
If you picked the systemd automounter as an option, you will have to
run:
systemctl restart local-fs.target
Be
> I assume that the yottamaster device runs Linux, just like 99% of
> other
> such devices. as to whether it uses linux software raid or some cheap
> (megaraid???) chipset, I don't know, nor know how to tell. but I'll
> check
> that URL you sent and see what happens.
Just add "x-systemd.automount
Warren, thanks for the additional info.
I assume that the yottamaster device runs Linux, just like 99% of other
such devices. as to whether it uses linux software raid or some cheap
(megaraid???) chipset, I don't know, nor know how to tell. but I'll check
that URL you sent and see what happens.
T
On Jan 2, 2021, at 9:55 AM, Fred wrote:
>
> Plantronics USB headset/microphone?
> Yottamaster RAID-1 storage (USB3)?
> Behringer USB audio interface?
> Logitech wireless mouse?
> Leopold USB keyboard?
HID devices won’t go to sleep when the computer does, else they couldn’t wake
it back up. (Ke
Warren, thanks for the reply!
Plantronics USB headset/microphone?
Yottamaster RAID-1 storage (USB3)?
Behringer USB audio interface?
Logitech wireless mouse?
Leopold USB keyboard?
Does any one of them sound more likely than the others?
Of all those, the yottamaster device is the most recent. Unfo
On Jan 2, 2021, at 7:44 AM, Fred wrote:
>
> I'm further guessing that "xhci_hcd" has something to do with USB
Yup:
https://en.wikipedia.org/wiki/Extensible_Host_Controller_Interface#Virtualization_support
> If so I don't know what it would be...
My guess: you have USB-attached storage that’s
24 matches
Mail list logo
