Re: [CentOS] Is EPEL compatible with Stream?
On 1/3/21 8:05 PM, Mark LaPierre wrote: So how would one use this shiny bit of information? Is there a way to discover if an EPEL application is going to clobber your system before you install it? As long as the upstream developers observe semantic versioning, dnf would tell whether or not a package is "broken" by an update (it would have unresolvable dependencies.) ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Is EPEL compatible with Stream?
On 1/3/21 5:34 PM, Stephen John Smoogen wrote: Except in cases where packages in a RHEL point release are being rebased. This is something which is happening with a lot more gusto than in any previous releases so there may be points where say a QT or a gnomelib provides in Stream is ahead of EPEL QT and GTK+ are both stable within a major release, so there's no reason to worry about those: https://access.redhat.com/articles/rhel-abi-compatibility https://access.redhat.com/articles/rhel-abi-compatibility#Appendix ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Is EPEL compatible with Stream?
On 1/3/21 8:34 PM, Stephen John Smoogen wrote: On Sun, 3 Jan 2021 at 18:20, Gordon Messmer wrote: On 1/3/21 2:51 PM, Kay Schenk wrote: is it still OK to set up EPEL as a repo? Yes. CentOS Stream is expected to be backward-compatible with RHEL, for the same reason that each RHEL point release is backward-compatible with previous point releases. Except in cases where packages in a RHEL point release are being rebased. This is something which is happening with a lot more gusto than in any previous releases so there may be points where say a QT or a gnomelib provides in Stream is ahead of EPEL So how would one use this shiny bit of information? Is there a way to discover if an EPEL application is going to clobber your system before you install it? -- _ °v° /(_)\ ^ ^ Mark LaPierre ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Is EPEL compatible with Stream?
On Sun, 3 Jan 2021 at 18:20, Gordon Messmer wrote: > On 1/3/21 2:51 PM, Kay Schenk wrote: > > is it still OK to set up EPEL as a repo? > > > Yes. CentOS Stream is expected to be backward-compatible with RHEL, for > the same reason that each RHEL point release is backward-compatible with > previous point releases. > > Except in cases where packages in a RHEL point release are being rebased. This is something which is happening with a lot more gusto than in any previous releases so there may be points where say a QT or a gnomelib provides in Stream is ahead of EPEL > ___ > CentOS mailing list > CentOS@centos.org > https://lists.centos.org/mailman/listinfo/centos > -- Stephen J Smoogen. ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] rare but repeating system crash in C7
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 ls /mnt/backup ls: cannot open directory /mnt/backup: No such file or directory if I do: ls /mnt I see: backup use su to become root, then: ls -l /mnt shows: # ls -al total 4 drwxr-xr-x. 3 root root0 Jan 2 13:24 . dr-xr-xr-x. 21 root root 4096 Jan 2 09:22 .. dr-xr-xr-x. 2 root root0 Jan 2 13:24 backup ls backup shows: # ls -al backup ls: cannot open directory backup: No such file or directory why? it clearly appears to exist the FS isn't mounted, but /mnt/backup exists, so it should be visible as an entry directory. also, I can mount it manually: mount UUID=259ec5ea-e8a4-465a-9263-1c06217b9aaf /mnt/backup and then access it. but it doesn't automount with, e.g. "ls /mnt/backup" or "ls /mnt/backup/backups". I must still be doing something wrong but maybe I'm too stupid to see it. (Please don't agree with me publicly...! :=) ) Fred On Sun, Jan 3, 2021 at 4:36 PM Pete Biggs wrote: > > > > 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 mount-point filesystem-type options dump fsck > > So you should have: > > UUID=259ec5ea-e8a4-465a-9263-1c06217b9aaf /mnt/backup ext4 > x-systemd.automount,x-systemd.idle-timeout=15min,noauto 0 2 > > > > > > which is exactly as it was before except for the x-systemd entries as you > > described. > > Yeah, you put them in the wrong place. > > > P. > > > ___ > CentOS mailing list > CentOS@centos.org > https://lists.centos.org/mailman/listinfo/centos > ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Is EPEL compatible with Stream?
On 1/3/21 2:51 PM, Kay Schenk wrote: is it still OK to set up EPEL as a repo? Yes. CentOS Stream is expected to be backward-compatible with RHEL, for the same reason that each RHEL point release is backward-compatible with previous point releases. ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
[CentOS] Is EPEL compatible with Stream?
Hello all-- All good in the Stream for me. :) Because Stream will tend to be more "forward moving" than previous CentOS releases, is it still OK to set up EPEL as a repo? So far, I've only installed terminus fonts from CentOS 8 EPEL, but I'm just wondering about this. Generally, are there any cautions against enabling specific repos to use with Stream? -- - "Don't let anyone dull your sparkle." MzK ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] rare but repeating system crash in C7
> > 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 mount-point filesystem-type options dump fsck So you should have: UUID=259ec5ea-e8a4-465a-9263-1c06217b9aaf /mnt/backup ext4 x-systemd.automount,x-systemd.idle-timeout=15min,noauto 0 2 > > which is exactly as it was before except for the x-systemd entries as you > described. Yeah, you put them in the wrong place. P. ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] rare but repeating system crash in C7
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 can help me figure this out. every now and then (less than monthly, maybe every 2-4 months, or so, I'll walk up to my C7 box (my home PC) in the morning, wiggle the mouse to wake up the screen, and after a second or so, instead of a live screen, the keyboard shift-lock and scroll-lock keys light up. if I wait a few (tens of) second(s) I find it is rebooting, as the BIOS splash screen appears. it boots normally and comes up with everything apparently working fine. Note that I tend to leave myself logged in 24/7/365 since there's nobody here except my wife and myself, and she has her own Linux box. as it happened again this morning, I grabbed some lines from /var/log/messages that show the last few minutes before it rebooted and the first 3 or four statements as it began to reboot: Jan 2 08:50:12 fcshome kernel: xhci_hcd :03:00.0: Looking for event-dma a9f2cb10 trb-start a9f2cb20 trb-end a9f2cb20 seg-start a9f2c000 seg-end a9f2cff0 Jan 2 08:50:13 fcshome kernel: xhci_hcd :03:00.0: ERROR Transfer event TRB DMA ptr not part of current TD ep_index 8 comp_code 13 Jan 2 08:50:13 fcshome kernel: xhci_hcd :03:00.0: Looking for event-dma 164858d0 trb-start 164858e0 trb-end 164858e0 seg-start 16485000 seg-end 16485ff0 Jan 2 08:51:12 fcshome dbus[1192]: [system] Activating service name='org.fedoraproject.Setroubleshootd' (using servicehelper) Jan 2 08:51:13 fcshome dbus[1192]: [system] Successfully activated service 'org.fedoraproject.Setroubleshootd' Jan 2 08:51:14 fcshome setroubleshoot: SELinux is preventing /usr/sbin/smbd from read access on the sock_file cups.sock. For complete SELinux messages run: sealert -l e4620dcc-6cdc-460d-a8a4-db9ce9624646 Jan 2 08:51:14 fcshome python: SELinux is preventing /usr/sbin/smbd from read access on the sock_file cups.sock.#012#012* Plugin catchall (100. confidence) suggests **#012#012If you believe that smbd should be allowed read access on the cups.sock sock_file by default.#012Then you should report this as a bug.#012You can generate a local policy module to allow this access.#012Do#012allow this access for now by executing:#012# ausearch -c 'lpqd' --raw | audit2allow -M my-lpqd#012# semodule -i my-lpqd.pp#012 Jan 2 08:55:11 fcshome kernel: xhci_hcd :03:00.0: ERROR Transfer event TRB DMA ptr not part of current TD ep_index 8 comp_code 13 Jan 2 08:55:11 fcshome kernel: xhci_hcd :03:00.0: Looking for event-dma 16485d20 trb-start 16485d30 trb-end 16485d30 seg-start 16485000 seg-end 16485ff0 Jan 2 08:55:11 fcshome kernel: xhci_hcd :03:00.0: ERROR Transfer event TRB DMA ptr not part of current TD ep_index 8 comp_code 13 Jan 2 08:55:11 fcshome kernel: xhci_hcd :03:00.0: Looking for event-dma a9f2cae0 trb-start a9f2caf0 trb-end a9f2caf0 seg-start a9f2c000 seg-end a9f2cff0 Jan 2 08:58:00 fcshome kernel: xhci_hcd :03:00.0: ERROR Transfer event TRB DMA ptr not part of current TD ep_index 8 comp_code 13 Jan 2 08:58:00 fcshome kernel: xhci_hcd :03:00.0: Looking for event-dma a9f2c530 trb-start a9f2c540 trb-end a9f2c540 seg-start a9f2c000 seg-end a9f2cff0 Jan 2 08:59:51 fcshome kernel: xhci_hcd :03:00.0: ERROR Transfer event TRB DMA ptr not part of current TD ep_index 8 comp_code 13 Jan 2 08:59:51 fcshome kernel: xhci_hcd :03:00.0: Looking for event-dma a9f2c340 trb-start a9f2c350 trb-end a9f2c350 seg-start a9f2c000 seg-end a9f2cff0 Jan 2 08:59:51 fcshome kernel: xhci_hcd :03:00.0: ERROR Transfer event TRB DMA ptr not part of current TD ep_index 8 comp_code 13 Jan 2 08:59:51 fcshome kernel: xhci_hcd :03:00.0: Looking for event-dma a9f2cfb0 trb-start a9f2cfc0 trb-end a9f2cfc0 seg-start a9f2c000 seg-end a9f2cff0 Jan 2 09:00:02 fcshome systemd: Created slice User Slice of root. Jan 2 09:00:02 fcshome systemd: Started Session 7364 of user root. Jan 2 09:00:02 fcshome systemd: Removed slice User Slice of root. Jan 2 09:00:06 fcshome kernel: xhci_hcd :03:00.0: ERROR Transfer event TRB DMA ptr not part of current TD ep_index 8 comp_code 13 Jan 2 09:00:06 fcshome kernel: xhci_hcd :03:00.0: Looking for event-dma a9f2cd20 trb-start a9f2cd30 trb-end a9f2cd30 seg-start a9f2c000 seg-end a9f2cff0 Jan 2 09:00:59 fcshome kernel: xhci_hcd :03:00.0: ERROR Transfer event TRB DMA ptr not part of current TD ep_index 8 comp_code 13 Jan 2
Re: [CentOS] rare but repeating system crash in C7
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) > > $ 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:20:05 EST; 14h ago > Where: /mnt/backup > What: /dev/sdc1 > Docs: man:fstab(5) > man:systemd-fstab-generator(8) > Tasks: 0 > > ● mnt-backup.automount > Loaded: loaded > Active: inactive (dead) > Where: /mnt/backup > [fredex@fcshome Desktop]$ systemctl cat mnt-backup.mount > mnt-backup.automount > No files found for mnt-backup.automount. > # /run/systemd/generator/mnt-backup.mount > # Automatically generated by systemd-fstab-generator > > [Unit] > SourcePath=/etc/fstab > Documentation=man:fstab(5) man:systemd-fstab-generator(8) > RequiresOverridable=systemd-fsck@dev-disk-by > \x2duuid-259ec5ea\x2de8a4\x2d465a\x2 > After=systemd-fsck@dev-disk-by > \x2duuid-259ec5ea\x2de8a4\x2d465a\x2d9263\x2d1c062 > > [Mount] > What=/dev/disk/by-uuid/259ec5ea-e8a4-465a-9263-1c06217b9aaf > Where=/mnt/backup > Type=ext4 > Options=noauto > > the fstab statement I put in my last posting was a copy/paste from > /etc/fstab, so it should be correct as shown. I don't see a comma before > noauto. > Did you already try a reboot? Don't ask me why I ask this. Regards, Simon > > > On Sun, Jan 3, 2021 at 11:42 AM Strahil Nikolov > wrote: > >> 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 >> >> >> Are you sure that you got no "," before that "noauto" ? >> >> Best Regards, >> Strahil Nikolov >> >> >> >> >> >> >> В неделя, 3 януари 2021 г., 16:25:47 Гринуич+2, Fred < >> fred.fre...@gmail.com> написа: >> >> >> >> >> >> 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 noauto 0 >> 2 >> >> which is exactly as it was before except for the x-systemd entries as >> you >> described. >> >> and the peculiar thing is it STILL does not automount. and yes, I did do >> systemctl restart local-fs.target. >> >> do I need to reboot (or something simpler, maybe) to fully disable the >> auto.master stuff? >> >> Thanks again! >> >> Fred >> >> On Sun, Jan 3, 2021 at 5:54 AM Strahil Nikolov via CentOS < >> centos@centos.org> wrote: >> > 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 < >> fred.fre...@gmail.com> написа: >> > >> > >> > >> > >> > >> > 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 >> wrote: >> > >> >> 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 from >> the >> >> enterprise space where consumer volume can affect that sort of >> thing.) >> >> >> >> I have more than speculation to back that guess: the available >> firmware >> >> images are far too small to contain a Linux OS image, their manuals >> don’t >> >> talk about Linux or GPL that I can see, and there’s no place to >> download >> >> their Linux source code per the GPL. >> >> >> >> While doing this exploration, I’ve run into multiple problems with >> their >> >> web site, which strengthens my suspicion that this box is your >> culprit. If >> >> they’re this slipshod with their marketing material, what does that >> say >> >> about their engineering department? >> >> ___ >> >> CentOS mailing list >> >> CentOS@centos.org >> >> https://lists.centos.org/mailman/listinfo/centos >> > >> >> >> >
Re: [CentOS] rare but repeating system crash in C7
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, Strahil Nikolov В неделя, 3 януари 2021 г., 21:01:29 Гринуич+2, Fred написа: $ 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:20:05 EST; 14h ago Where: /mnt/backup What: /dev/sdc1 Docs: man:fstab(5) man:systemd-fstab-generator(8) Tasks: 0 ● mnt-backup.automount Loaded: loaded Active: inactive (dead) Where: /mnt/backup [fredex@fcshome Desktop]$ systemctl cat mnt-backup.mount mnt-backup.automount No files found for mnt-backup.automount. # /run/systemd/generator/mnt-backup.mount # Automatically generated by systemd-fstab-generator [Unit] SourcePath=/etc/fstab Documentation=man:fstab(5) man:systemd-fstab-generator(8) RequiresOverridable=systemd-fsck@dev-disk-by\x2duuid-259ec5ea\x2de8a4\x2d465a\x2 After=systemd-fsck@dev-disk-by\x2duuid-259ec5ea\x2de8a4\x2d465a\x2d9263\x2d1c062 [Mount] What=/dev/disk/by-uuid/259ec5ea-e8a4-465a-9263-1c06217b9aaf Where=/mnt/backup Type=ext4 Options=noauto the fstab statement I put in my last posting was a copy/paste from /etc/fstab, so it should be correct as shown. I don't see a comma before noauto. On Sun, Jan 3, 2021 at 11:42 AM Strahil Nikolov wrote: > 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 > > > Are you sure that you got no "," before that "noauto" ? > > Best Regards, > Strahil Nikolov > > > > > > > В неделя, 3 януари 2021 г., 16:25:47 Гринуич+2, Fred > написа: > > > > > > 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 noauto 0 2 > > which is exactly as it was before except for the x-systemd entries as you > described. > > and the peculiar thing is it STILL does not automount. and yes, I did do > systemctl restart local-fs.target. > > do I need to reboot (or something simpler, maybe) to fully disable the > auto.master stuff? > > Thanks again! > > Fred > > On Sun, Jan 3, 2021 at 5:54 AM Strahil Nikolov via CentOS > wrote: >> 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 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 wrote: >> >>> 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 from the >>> enterprise space where consumer volume can affect that sort of thing.) >>> >>> I have more than speculation to back that guess: the available firmware >>> images are far too small to contain a Linux OS image, their manuals don’t >>> talk about Linux or GPL that I can see, and there’s no place to download >>> their Linux source code per the GPL. >>> >>> While doing this exploration, I’ve run into multiple problems with their >>> web site, which strengthens my suspicion that this box is your culprit. If >>> they’re this slipshod with their marketing material, what does that say >>> about their engineering department? >>> ___ >>> CentOS mailing list >>> CentOS@centos.org >>> https://lists.centos.org/mailman/listinfo/centos >> >>> >> ___ >> CentOS mailing list >> CentOS@centos.org >> https://lists.centos.org/mailman/listinfo/centos >> ___ >> CentOS mailing list >>
Re: [CentOS] rare but repeating system crash in C7
> $ 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:20:05 EST; 14h ago > Where: /mnt/backup > What: /dev/sdc1 > Docs: man:fstab(5) >man:systemd-fstab-generator(8) > Tasks: 0 > > ● mnt-backup.automount >Loaded: loaded >Active: inactive (dead) > Where: /mnt/backup > [fredex@fcshome Desktop]$ systemctl cat mnt-backup.mount > mnt-backup.automount > No files found for mnt-backup.automount. > # /run/systemd/generator/mnt-backup.mount > # Automatically generated by systemd-fstab-generator > > [Unit] > SourcePath=/etc/fstab > Documentation=man:fstab(5) man:systemd-fstab-generator(8) > RequiresOverridable=systemd-fsck@dev-disk-by > \x2duuid-259ec5ea\x2de8a4\x2d465a\x2 > After=systemd-fsck@dev-disk-by > \x2duuid-259ec5ea\x2de8a4\x2d465a\x2d9263\x2d1c062 > > [Mount] > What=/dev/disk/by-uuid/259ec5ea-e8a4-465a-9263-1c06217b9aaf > Where=/mnt/backup > Type=ext4 > Options=noauto > > the fstab statement I put in my last posting was a copy/paste from > /etc/fstab, so it should be correct as shown. I don't see a comma before > noauto. > Did you already try a reboot? Don't ask me why I ask this. Regards, Simon > > > On Sun, Jan 3, 2021 at 11:42 AM Strahil Nikolov > wrote: > >> 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 >> >> >> Are you sure that you got no "," before that "noauto" ? >> >> Best Regards, >> Strahil Nikolov >> >> >> >> >> >> >> В неделя, 3 януари 2021 г., 16:25:47 Гринуич+2, Fred < >> fred.fre...@gmail.com> написа: >> >> >> >> >> >> 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 noauto 0 >> 2 >> >> which is exactly as it was before except for the x-systemd entries as >> you >> described. >> >> and the peculiar thing is it STILL does not automount. and yes, I did do >> systemctl restart local-fs.target. >> >> do I need to reboot (or something simpler, maybe) to fully disable the >> auto.master stuff? >> >> Thanks again! >> >> Fred >> >> On Sun, Jan 3, 2021 at 5:54 AM Strahil Nikolov via CentOS < >> centos@centos.org> wrote: >> > 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 < >> fred.fre...@gmail.com> написа: >> > >> > >> > >> > >> > >> > 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 >> wrote: >> > >> >> 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 from >> the >> >> enterprise space where consumer volume can affect that sort of >> thing.) >> >> >> >> I have more than speculation to back that guess: the available >> firmware >> >> images are far too small to contain a Linux OS image, their manuals >> don’t >> >> talk about Linux or GPL that I can see, and there’s no place to >> download >> >> their Linux source code per the GPL. >> >> >> >> While doing this exploration, I’ve run into multiple problems with >> their >> >> web site, which strengthens my suspicion that this box is your >> culprit. If >> >> they’re this slipshod with their marketing material, what does that >> say >> >> about their engineering department? >> >> ___ >> >> CentOS mailing list >> >> CentOS@centos.org >> >> https://lists.centos.org/mailman/listinfo/centos >> > >> >> >> > ___ >> > CentOS mailing list >> > CentOS@centos.org >> > https://lists.centos.org/mailman/listinfo/centos >> > ___ >> > CentOS mailing list >> >
Re: [CentOS] rare but repeating system crash in C7
$ 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:20:05 EST; 14h ago Where: /mnt/backup What: /dev/sdc1 Docs: man:fstab(5) man:systemd-fstab-generator(8) Tasks: 0 ● mnt-backup.automount Loaded: loaded Active: inactive (dead) Where: /mnt/backup [fredex@fcshome Desktop]$ systemctl cat mnt-backup.mount mnt-backup.automount No files found for mnt-backup.automount. # /run/systemd/generator/mnt-backup.mount # Automatically generated by systemd-fstab-generator [Unit] SourcePath=/etc/fstab Documentation=man:fstab(5) man:systemd-fstab-generator(8) RequiresOverridable=systemd-fsck@dev-disk-by \x2duuid-259ec5ea\x2de8a4\x2d465a\x2 After=systemd-fsck@dev-disk-by \x2duuid-259ec5ea\x2de8a4\x2d465a\x2d9263\x2d1c062 [Mount] What=/dev/disk/by-uuid/259ec5ea-e8a4-465a-9263-1c06217b9aaf Where=/mnt/backup Type=ext4 Options=noauto the fstab statement I put in my last posting was a copy/paste from /etc/fstab, so it should be correct as shown. I don't see a comma before noauto. On Sun, Jan 3, 2021 at 11:42 AM Strahil Nikolov wrote: > 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 > > > Are you sure that you got no "," before that "noauto" ? > > Best Regards, > Strahil Nikolov > > > > > > > В неделя, 3 януари 2021 г., 16:25:47 Гринуич+2, Fred < > fred.fre...@gmail.com> написа: > > > > > > 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 noauto 0 2 > > which is exactly as it was before except for the x-systemd entries as you > described. > > and the peculiar thing is it STILL does not automount. and yes, I did do > systemctl restart local-fs.target. > > do I need to reboot (or something simpler, maybe) to fully disable the > auto.master stuff? > > Thanks again! > > Fred > > On Sun, Jan 3, 2021 at 5:54 AM Strahil Nikolov via CentOS < > centos@centos.org> wrote: > > 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 < > fred.fre...@gmail.com> написа: > > > > > > > > > > > > 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 wrote: > > > >> 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 from > the > >> enterprise space where consumer volume can affect that sort of thing.) > >> > >> I have more than speculation to back that guess: the available firmware > >> images are far too small to contain a Linux OS image, their manuals > don’t > >> talk about Linux or GPL that I can see, and there’s no place to download > >> their Linux source code per the GPL. > >> > >> While doing this exploration, I’ve run into multiple problems with their > >> web site, which strengthens my suspicion that this box is your > culprit. If > >> they’re this slipshod with their marketing material, what does that say > >> about their engineering department? > >> ___ > >> CentOS mailing list > >> CentOS@centos.org > >> https://lists.centos.org/mailman/listinfo/centos > > > >> > > ___ > > CentOS mailing list > > CentOS@centos.org > > https://lists.centos.org/mailman/listinfo/centos > > ___ > > CentOS mailing list > > CentOS@centos.org > > https://lists.centos.org/mailman/listinfo/centos > > > ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] rare but repeating system crash in C7
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 Are you sure that you got no "," before that "noauto" ? Best Regards, Strahil Nikolov В неделя, 3 януари 2021 г., 16:25:47 Гринуич+2, Fred написа: 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 noauto 0 2 which is exactly as it was before except for the x-systemd entries as you described. and the peculiar thing is it STILL does not automount. and yes, I did do systemctl restart local-fs.target. do I need to reboot (or something simpler, maybe) to fully disable the auto.master stuff? Thanks again! Fred On Sun, Jan 3, 2021 at 5:54 AM Strahil Nikolov via CentOS wrote: > 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 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 wrote: > >> 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 from the >> enterprise space where consumer volume can affect that sort of thing.) >> >> I have more than speculation to back that guess: the available firmware >> images are far too small to contain a Linux OS image, their manuals don’t >> talk about Linux or GPL that I can see, and there’s no place to download >> their Linux source code per the GPL. >> >> While doing this exploration, I’ve run into multiple problems with their >> web site, which strengthens my suspicion that this box is your culprit. If >> they’re this slipshod with their marketing material, what does that say >> about their engineering department? >> ___ >> CentOS mailing list >> CentOS@centos.org >> https://lists.centos.org/mailman/listinfo/centos > >> > ___ > CentOS mailing list > CentOS@centos.org > https://lists.centos.org/mailman/listinfo/centos > ___ > CentOS mailing list > CentOS@centos.org > https://lists.centos.org/mailman/listinfo/centos > ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] rare but repeating system crash in C7
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 noauto 0 2 which is exactly as it was before except for the x-systemd entries as you described. and the peculiar thing is it STILL does not automount. and yes, I did do systemctl restart local-fs.target. do I need to reboot (or something simpler, maybe) to fully disable the auto.master stuff? Thanks again! Fred On Sun, Jan 3, 2021 at 5:54 AM Strahil Nikolov via CentOS wrote: > 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 < > fred.fre...@gmail.com> написа: > > > > > > 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 wrote: > > > 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 from the > > enterprise space where consumer volume can affect that sort of thing.) > > > > I have more than speculation to back that guess: the available firmware > > images are far too small to contain a Linux OS image, their manuals don’t > > talk about Linux or GPL that I can see, and there’s no place to download > > their Linux source code per the GPL. > > > > While doing this exploration, I’ve run into multiple problems with their > > web site, which strengthens my suspicion that this box is your culprit. > If > > they’re this slipshod with their marketing material, what does that say > > about their engineering department? > > ___ > > CentOS mailing list > > CentOS@centos.org > > https://lists.centos.org/mailman/listinfo/centos > > > > ___ > CentOS mailing list > CentOS@centos.org > https://lists.centos.org/mailman/listinfo/centos > ___ > CentOS mailing list > CentOS@centos.org > https://lists.centos.org/mailman/listinfo/centos > ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] rare but repeating system crash in C7
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 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 wrote: > 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 from the > enterprise space where consumer volume can affect that sort of thing.) > > I have more than speculation to back that guess: the available firmware > images are far too small to contain a Linux OS image, their manuals don’t > talk about Linux or GPL that I can see, and there’s no place to download > their Linux source code per the GPL. > > While doing this exploration, I’ve run into multiple problems with their > web site, which strengthens my suspicion that this box is your culprit. If > they’re this slipshod with their marketing material, what does that say > about their engineering department? > ___ > CentOS mailing list > CentOS@centos.org > https://lists.centos.org/mailman/listinfo/centos > ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
