On October 30, 2014 3:51:53 PM EDT, Michael Hamilton
On Fri, 31 Oct 2014, Greg Freemyer wrote:
On October 25, 2014 5:57:07 PM EDT, Michael Hamilton
wrote: <snip>
I'm not interested in another sd bashing session (if you don't like it, contribute to an alternative, or lobby elsewhere). But it would be good to get some pointers in how to do admin in a systemX environment. Does anyone know of a HOWTO for doing standard system maintenance tasks, such as re-sizing filesystems, in a systemX environment?
This whole thread and earlier threads have been way tl;dr.
Is there an answer to the above?
I.e. how are things supposed to work in 13.1 and newer? What are the bugs? Does noauto always work if set on boot? How to change a volume from auto to noauto during maintenance?
Greg -- Sent from my Android phone with K-9 Mail. Please excuse my brevity.
I haven't really seen a satisfactory answer, from just reading the documentation, but not actually trying anything, the following might work:
1) change the fstab to make a mount point noauto (man systemX.mount) 2) systemctl daemon-reload to reload the manager configuration (man systemctl) 3) umount and make changes. 4) reverse fstab changes and do another reload of the manager configuration
But if this is supposed to be a UNIX-like system, I think the unexpected behaviour subsequent to umount is wrong.
It seems that, for better or worse, GNU Linux is now transitioning to something that is truly not UNIX.
It may be better to make a clean break rather than creating a minefield for old players. GNU Linux++ or LinuxNT perhaps.
If noauto can be set in fstab and it works I theoretically can live with it. My real concern is for drives that don't have an entry in stab. For my day job, on occasion I _need_ to be able to connect random USB drives (thumbs/rotating/ssd) and never have them automount. I do this today by being in "init 3" state before connecting the drives. Is systemd changing this? This is a seriously important question for me. I can't trust Windows to ignore random drives being connected. Even with a physical write-blocker in place, Windows can become unstable because a drive it doesn't understand gets connected to it. It refuses to simply ignore the drive. Historically with Linux, in "init 3" state I was in total control of random drives I connect to my machine. If I loose that control, I will have to loose systemd one way or another. Fyi: in the security:forensic repo there are tools to work with raw drives. There are imaging tools, parsing tools, timeline analysis tools, file carving tools, data recovery tools. Proper use of those tools needs the drives to not be mounted at all once the forensic analysis of the drives commences. That is my day job and why I maintain that repo. Greg Greg -- Sent from my Android phone with K-9 Mail. Please excuse my brevity. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org