-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 2013-06-04 23:22, Roger Oberholtzer wrote:

I saw this and will do this. I am still curious how the contents of /media are being put back after boot when it is a tmpfs. Life is full of mysteries.

It shouldn't. It is a tmpfs precisely to destroy everything on boot. I don't believe they did any thing to restore directories. Are you sure it is a tmpfs in your computer? Please verify it. - -- Cheers / Saludos, Carlos E. R. (from 12.1 x86_64 "Asparagus" at Telcontar) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlGuWlUACgkQIvFNjefEBxrYfwCgwDJInmx9MWMrT6kXwsLJPPQQ AhIAmwXMAD/EOm2sYF6pVz/lpcFWbAAq =wh7v -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 2013-06-05 08:20, Roger Oberholtzer wrote:

On Tue, 2013-06-04 at 23:21 +0200, Carlos E. R. wrote:

...

Are you sure it is a tmpfs in your computer? Please verify it.

Yes it is. mount reports:

tmpfs on /media type tmpfs (rw,nosuid,nodev,noexec,relatime,mode=755)

Upon reboot (did one just now to be sure), the directory is not empty. It contains come directories and sub-directories that were created there some time in the past.

You should verify, booting from a live cd, that the mount point /media does not exist. Maybe it does, and contains somethings, and maybe those things are copied to the tmpfs when created. Check both you computers, and also verify that both are using a tmpfs there.

If I want to populate /media with something so things can be mounted, I guess I have two options:

You should not use /media for anything manually mounted. NEVER. Use /mnt instead, that is what it is for (external or internal, does not matter).

1. Add something to a system startup script that makes what I need. I do not want to edit an init script as it may be overwritten. I see the /etc/tmpfiles.d directory where I could add a file. But I think this is done before boot.localfs is run. So if I make what I need there then /media will not be mounted as tmpfs. I do not want to change the expected system behavior. I want to compliment it.

boot.localfs only runs in systemv mode. Any solution that you implement on /media is very temporary, weeks. 12.1 is EOL, although the announcement has not been made yet. - -- Cheers / Saludos, Carlos E. R. (from 12.1 x86_64 "Asparagus" at Telcontar) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlGvHzMACgkQIvFNjefEBxrzcwCgwlDzolVS4iGeqgkxiu/DytZp 7xoAoMnTotIG3ctbaJ7uRlmvQ3GgJPgM =Vxn5 -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

El 04/06/13 13:44, Carlos E. R. escribió:

I don't know if systemd in 12.1 uses the script or not.

No, systemd does nothing with /media (does not mount it, create it, handle in anyway at all) neither uses boot.localfs which is a sysvinit early boot script. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On Wed, 2013-06-05 at 00:02 +0200, Carlos E. R. wrote:

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1

On 2013-06-04 23:34, Cristian Rodríguez wrote:

...

El 04/06/13 13:44, Carlos E. R. escribió:

...

I don't know if systemd in 12.1 uses the script or not.

No, systemd does nothing with /media (does not mount it, create it, handle in anyway at all) neither uses boot.localfs which is a sysvinit early boot script.

In 12.1 it must do something about /media. sysvinit does, so systemd does it to, else the directory would me missing, and 12.1 uses it.

Getting closer. On one 12.1 system, during boot, if the directory and sub directories of the /media mount point listed in /etc/fstab do not exist, they are silently created. Note that the same behavior does not happen after boot. Then the mount command will complain that the mount point does not exist, which is the traditional behavior. But at initial boot there seems to be additional magic. This is where the mysterious populating of /media at boot is coming from. If I comment out the entries in /etc/fstab, the mount points do not get created. So it is not that we have some script somewhere creating the mount points on this system. On another 12.1 system, the system will not boot completely and takes you to a root login to perform magic. I cannot see why the two systems act differently. It is 100% reproduceable. I am guessing that the first system is acting as expected and that the second system has some mysterious problem... Could it be that the ordering between applying all the udev rules to existing devices does not always complete before things in /etc/fstab are mounted? Yours sincerely, Roger Oberholtzer Ramböll RST / Systems Office: Int +46 10-615 60 20 Mobile: Int +46 70-815 1696 roger.oberholtzer@ramboll.se ________________________________________ Ramböll Sverige AB Krukmakargatan 21 P.O. Box 17009 SE-104 62 Stockholm, Sweden www.rambollrst.se -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On Wed, 2013-06-05 at 06:33 -0400, Anton Aylward wrote:

I don't have a 12.1 system to hand but my memory of it is that there is a config file and appropriate script to populate /media and others tmpfs (or not) on boot.

boot.localfs ensures that if /media does not exist, it is mounted as a tmpfs file system. When that happens relative to udev rules being executed at boot or mounting from /etc/fstab is very unclear. I think this is what results in the differences between the systems.

Now that's where it becomes interesting and that's where one needs to do an absolute side-by-side comparison to see how the config structure differs. I suspect that because you aren't/weren't ware of tmpfiles.d that the config there may differ between machines.

tmpfiles.d and/or tmpdirs.s don't seem to be involved in /media. That is in boot.localfs. IMO it seems sloppy to have a system that ensures the existence of various files and dirs and then not use it and instead make a few directories elsewhere. It sure messes up any attempt at serialization. If boot.localfs has not yet created /media, I would not want some other step to try to place something into it. What is unclear to me is the order all these things happen on boot: udev rules tmpfiles.d and tmpdirs.d boot.localfs /etc/fstab And are they guaranteed to complete before the next starts? Yours sincerely, Roger Oberholtzer Ramböll RST / Systems Office: Int +46 10-615 60 20 Mobile: Int +46 70-815 1696 roger.oberholtzer@ramboll.se ________________________________________ Ramböll Sverige AB Krukmakargatan 21 P.O. Box 17009 SE-104 62 Stockholm, Sweden www.rambollrst.se -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

В Wed, 05 Jun 2013 17:33:37 +0200 Istvan Gabor пишет:

2013. június 5. 14:27 napon Roger Oberholtzer írta:

...

On Wed, 2013-06-05 at 06:33 -0400, Anton Aylward wrote:

...

I don't have a 12.1 system to hand but my memory of it is that there is a config file and appropriate script to populate /media and others tmpfs (or not) on boot.

boot.localfs ensures that if /media does not exist, it is mounted as a tmpfs file system. When that happens relative to udev rules being executed at boot or mounting from /etc/fstab is very unclear. I think this is what results in the differences between the systems.

...

Now that's where it becomes interesting and that's where one needs to do an absolute side-by-side comparison to see how the config structure differs. I suspect that because you aren't/weren't ware of tmpfiles.d that the config there may differ between machines.

tmpfiles.d and/or tmpdirs.s don't seem to be involved in /media. That is in boot.localfs. IMO it seems sloppy to have a system that ensures the existence of various files and dirs and then not use it and instead make a few directories elsewhere. It sure messes up any attempt at serialization. If boot.localfs has not yet created /media, I would not want some other step to try to place something into it.

What is unclear to me is the order all these things happen on boot:

udev rules tmpfiles.d and tmpdirs.d boot.localfs /etc/fstab

And are they guaranteed to complete before the next starts?

This is a very interesting topic. I prefer the pre 12.x SUSE way, when /media directory is only a subdirectory of the normal root ext3 (or whatever) filesystem, and is static (created files or directories are not removed at boot).

I have one openSUSE 12.1 system, and I would like to set up the old /media behavior on it. Is it doable? How?

By updating to 12.3 :) -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

* Istvan Gabor [06-05-13 13:06]:

2013. június 5. 18:30 napon Andrey Borzenkov írta:

...

...

I have one openSUSE 12.1 system, and I would like to set up the old /media behavior on it. Is it doable? How? By updating to 12.3 :)

Thanks for the advice but I won't follow it. Since SuSE 11.x when I updated to the latest version it always caused more trouble than benefit.

Your words, but in this case only words, ie: no substance.

Second, I don't want systemd, I think it is still not as stable and reliable as required on a production machine.

A personal choice and ubstantiated *opinion*.

Finally, I am not sure that updating would result in a /media which keeps manually added subdirectories (eg. /media/floppy). Would it?

I don't understand the use case, but upon inserting a "floppy", the "/media/floppy" directory automatically appears. There is no need for *persistance* except for personal desires. I have usb and cd/dvd drives that appear no-where until there is a need, but upon the need arising, the necessary directories automagically appear satisfying that need. It may eventially become necessary to see more than what is immediately in front of you. -- (paka)Patrick Shanahan Plainfield, Indiana, USA HOG # US1244711 http://wahoo.no-ip.org Photo Album: http://wahoo.no-ip.org/gallery2 http://en.opensuse.org openSUSE Community Member Registered Linux User #207535 @ http://linuxcounter.net -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

Patrick Shanahan said the following on 06/05/2013 02:23 PM:

* Istvan Gabor [06-05-13 13:06]:

...

Second, I don't want systemd, I think it is still not as stable and reliable as required on a production machine.

A personal choice and ubstantiated *opinion*.

I have to agree with Patrick on this; systemd is quite stable, thank you! More to the point, Roger ask is about order and determinacy. Yes it is iffy and this is one to the issues that systemd is there to address and resolve.

...

Finally, I am not sure that updating would result in a /media which keeps manually added subdirectories (eg. /media/floppy). Would it?

I don't understand the use case, but upon inserting a "floppy", the "/media/floppy" directory automatically appears. There is no need for *persistance* except for personal desires.

And if you want it to be there after every boot, why that's what /etc/tmfiles.d is for! But as Patrick says, it seems a strange request when its dealt with dynamically. Or do you mean the old 8" floppies where the machine might have to poll to see if ifs been inserted?

I have usb and cd/dvd drives that appear no-where until there is a need, but upon the need arising, the necessary directories automagically appear satisfying that need.

And very satisfying it is too. All it needs is to be accompanied by a ice cold lager ...

It may eventially become necessary to see more than what is immediately in front of you.

Like the ice cold lager? -- How long did the whining go on when KDE2 went on KDE3? The only universal constant is change. If a species can not adapt it goes extinct. That's the law of the universe, adapt or die. -- Billie Walsh, May 18 2013 -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On Thu, 2013-06-06 at 04:25 +0200, Carlos E. R. wrote:

On 2013-06-06 02:11, Anton Aylward wrote:

...

Patrick Shanahan said the following on 06/05/2013 02:23 PM:

And if you want it to be there after every boot, why that's what /etc/tmfiles.d is for!

But as Patrick says, it seems a strange request when its dealt with dynamically.

I think that he is doing tricks to make some external media be mounted always in the same folder. I think that the disk label (the filesystem label, actually) is used to name the automatically created mount point.

What I would do is rename all those disks to the same label, and thus they would appear automatically on the same directory.

Not the disk label. There are thousands of disks. Each driver bay has a unique SCSI ID. This way we can use any formatted disk. The bay it gets inserted into in the collection system starts it out in life without user intervention. Our system allows to detect if disks are inserted improperly in the analysis system. The only requirement a user has is: 1. Format a disk somehow. No fancy option or disk-specific options are needed. 2. In the collection system, insert it in the drive bay for the transducer of interest (label on computer tells the transducer). Any new disk can go anywhere as needed. 3. In the analysis system, insert the disk in a drive bay with the same label as the bay it was in in the collection system. If done improperly, the analysis software will complain and tell what is wrong. KISS was the guiding principle. Require as little from the user as possible. Yours sincerely, Roger Oberholtzer Ramböll RST / Systems Office: Int +46 10-615 60 20 Mobile: Int +46 70-815 1696 roger.oberholtzer@ramboll.se ________________________________________ Ramböll Sverige AB Krukmakargatan 21 P.O. Box 17009 SE-104 62 Stockholm, Sweden www.rambollrst.se -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On Mon, 2013-06-10 at 18:31 +0200, Carlos E. R. wrote:

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1

On 2013-06-10 18:20, Roger Oberholtzer wrote:

...

On Thu, 2013-06-06 at 04:25 +0200, Carlos E. R. wrote:

...

...

KISS was the guiding principle. Require as little from the user as possible.

Interesting system.

I think that if you create fstab entries using "/dev/disk/by-path/", the disks will not mount automatically, and you can mount them manually instead (a clickable icon triggering a command, for example).

We have always used a udev rule to great effect. This whole thread started because that began to fail. I did not at first see that in 12.1 /media would loose it's contents at each boot (i.e., had become a tmpfs). Or seem to, as items listed in /etc/fstab that should be mounted in /media do magically get their mount points made - at boot only... Yours sincerely, Roger Oberholtzer Ramböll RST / Systems Office: Int +46 10-615 60 20 Mobile: Int +46 70-815 1696 roger.oberholtzer@ramboll.se ________________________________________ Ramböll Sverige AB Krukmakargatan 21 P.O. Box 17009 SE-104 62 Stockholm, Sweden www.rambollrst.se -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On Tue, 2013-06-11 at 14:01 +0200, Carlos E. R. wrote:

On 12.3 it is back to a persistent directory. You may want to disable tmpfs in 12.1 (for /media).

I saw that. I was just curious if some system component assumed some property that tmpfs has and did not want to change this for /media. Of course, as I have sorted it in a udev rule, I no longer am effected by this. As long as the udev rules for disks happen after any required files/directories in / are made :) That was why I asked about the expected ordering of these things (elsewhere in this thread). Without that definition, my (or any) solution works until it no longer works... Yours sincerely, Roger Oberholtzer Ramböll RST / Systems Office: Int +46 10-615 60 20 Mobile: Int +46 70-815 1696 roger.oberholtzer@ramboll.se ________________________________________ Ramböll Sverige AB Krukmakargatan 21 P.O. Box 17009 SE-104 62 Stockholm, Sweden www.rambollrst.se -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On Wed, 2013-06-05 at 20:11 -0400, Anton Aylward wrote:

And if you want it to be there after every boot, why that's what /etc/tmfiles.d is for!

As long as /etc/tmpfiles.d is GUARANTEED to run after boot.localfs is 100% complete. If it runs before, the nice sub-dirs created in /media may be hidden when boot.localfs later mounts /media. Or, since /etc/tmpfiles.d made the /media and subdirectories before boot.locafs ran, the later running boot.localfs will not mount /media as a tmpfs (which is actually the case). These two (and the others I listed) interact. But I still do not know what the intended interaction is. Who gets first/last crack at things? Without this clearly stared the behavior is non-deterministic. AKA, unsafe.

But as Patrick says, it seems a strange request when its dealt with dynamically.

Define 'dynamically' :) I see (repeatable and verifiable) that if a removeable disk is in the machine when it boots (*), directories and subdirectories as defined in /etc/fstab are created, and the disk mounted as expected. The same disk, when inserted after the system boots (exact same udev rules and /etc/fstab entries), does not get the same behavior. An even more interesting thing is that when the disks are removed (via umount) the /media entries go away. And since reinsertion after boot does not result in the same mount point creation in /media, we have a problem. We use udev rules and /etc/fstab because these SATA disks are not USB devices. Even though they are removable, there is no way I know of to have them show up in the device notifier (kde) so that the operator can safely remove them via that familiar interface. So, we use umount, referring to things in /etc/fstab. Each drive bay contains data from a specific device. So, the physical drive bay and a 'smart' /etc/fstab entry is how we identify the data on the disk and systematically control swapping. FYI, our final solution was to put the creation of the mount directories and the mount command in our udev rule for the each drive bay. This freed us from worrying if the rest of the system would act consistently. But we still need to unmount the disks via a umount command. It would be nice if that could be via KDE's device notifier. One system to rule them all.. (*) The SuperMicro systems we have require this or the drive bay is disabled by the BIOS. Strange but true. SuperMicro blame the intel chipset that deals with removable SATS disks. Yours sincerely, Roger Oberholtzer Ramböll RST / Systems Office: Int +46 10-615 60 20 Mobile: Int +46 70-815 1696 roger.oberholtzer@ramboll.se ________________________________________ Ramböll Sverige AB Krukmakargatan 21 P.O. Box 17009 SE-104 62 Stockholm, Sweden www.rambollrst.se -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 2013-06-10 17:27, Patrick Shanahan wrote:

I have made several *special* assignments particular to my work-flow. They are text files at ~/.kde4/share/apps/solid/actions/ ie, Transfer-Photos-MC-Soccer.desktop

Those may not apply to a disk present on boot. - -- Cheers / Saludos, Carlos E. R. (from 12.3 x86_64 "Dartmouth" at Telcontar) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlG19QoACgkQIvFNjefEBxr2lACgq305eDL2qG52ZBsjO2vPZrBn n8YAoLR2jc0yo7cR/mifJXjtDVYjWnaf =/F69 -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On Mon, 2013-06-10 at 17:31 +0200, Carlos E. R. wrote:

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1

On 2013-06-10 17:00, Roger Oberholtzer wrote:

...

On Wed, 2013-06-05 at 20:11 -0400, Anton Aylward wrote:

...

I see (repeatable and verifiable) that if a removeable disk is in the machine when it boots (*), directories and subdirectories as defined in /etc/fstab are created, and the disk mounted as expected. The same disk, when inserted after the system boots (exact same udev rules and /etc/fstab entries), does not get the same behavior. An even more interesting thing is that when the disks are removed (via umount) the /media entries go away. And since reinsertion after boot does not result in the same mount point creation in /media, we have a problem.

Notice that what is plugged in before booting does not gets mounted by the desktop - that's the difference. I think they get mounted on behalf of "root", but I don't know exactly by what process.

...

(*) The SuperMicro systems we have require this or the drive bay is disabled by the BIOS. Strange but true. SuperMicro blame the intel chipset that deals with removable SATS disks.

Maybe related.

I got recently a bay for inserting hard disks into my desktop from the outside, hotw-swap. My motherboard has 6 SATA connectors on one side, 2 eSATA connector on the back edge of the board, and 2 connectors inside that are raid capable, and which I had connected via an eSATA plug to the outside.

Our SuperMicro systems are chosen specifically because the disks are hot swappable. The system very happily gets add events when a disk is inserted. Our current udev rules are: SUBSYSTEM=="block", ENV{ID_PATH}=="*-2-scsi-0:0:0:0", ENV{ID_PART_ENTRY_NUMBER}=="1", SYMLINK="cameraA 0:0:0:0", RUN+="/bin/mkdir -p /media/jboc/cameraA", RUN+="/bin/mount -oro /dev/cameraA /media/jboc/cameraA" SUBSYSTEM=="block", ENV{ID_PATH}=="*-2-scsi-1:0:0:0", ENV{ID_PART_ENTRY_NUMBER}=="1", SYMLINK="cameraB 1:0:0:0", RUN+="/bin/mkdir -p /media/jboc/cameraB", RUN+="/bin/mount -oro /dev/cameraB /media/jboc/cameraB" SUBSYSTEM=="block", ENV{ID_PATH}=="*-2-scsi-2:0:0:0", ENV{ID_PART_ENTRY_NUMBER}=="1", SYMLINK="cameraC 2:0:0:0", RUN+="/bin/mkdir -p /media/jboc/cameraC", RUN+="/bin/mount -oro /dev/cameraC /media/jboc/cameraC" SUBSYSTEM=="block", ENV{ID_PATH}=="*-2-scsi-3:0:0:0", ENV{ID_PART_ENTRY_NUMBER}=="1", SYMLINK="cameraD 3:0:0:0", RUN+="/bin/mkdir -p /media/jboc/cameraD", RUN+="/bin/mount -oro /dev/cameraD /media/jboc/cameraD" The ID_PATH tells the physical drive slot. and is system-specific. Note that we make the mount point and do the mount command at that time. Yours sincerely, Roger Oberholtzer Ramböll RST / Systems Office: Int +46 10-615 60 20 Mobile: Int +46 70-815 1696 roger.oberholtzer@ramboll.se ________________________________________ Ramböll Sverige AB Krukmakargatan 21 P.O. Box 17009 SE-104 62 Stockholm, Sweden www.rambollrst.se -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On Wed, 2013-06-05 at 23:16 +0200, Carlos E. R. wrote:

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1

On Wednesday, 2013-06-05 at 14:27 +0200, Roger Oberholtzer wrote:

...

What is unclear to me is the order all these things happen on boot:

udev rules tmpfiles.d and tmpdirs.d boot.localfs /etc/fstab

To answer you questions, you must clarify first: are you using systemd or systemv?

systemd, as installeb with 12.1 Yours sincerely, Roger Oberholtzer Ramböll RST / Systems Office: Int +46 10-615 60 20 Mobile: Int +46 70-815 1696 roger.oberholtzer@ramboll.se ________________________________________ Ramböll Sverige AB Krukmakargatan 21 P.O. Box 17009 SE-104 62 Stockholm, Sweden www.rambollrst.se -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On Mon, 2013-06-10 at 17:49 +0200, Carlos E. R. wrote:

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1

On 2013-06-10 16:36, Roger Oberholtzer wrote:

...

On Wed, 2013-06-05 at 23:16 +0200, Carlos E. R. wrote:

...

...

...

What is unclear to me is the order all these things happen on boot:

udev rules tmpfiles.d and tmpdirs.d boot.localfs /etc/fstab

To answer you questions, you must clarify first: are you using systemd or systemv?

systemd, as installeb with 12.1

In that case, boot.localfs does not run.

Mysteriouser and mysteriouser. That is the only place I found /media being mounted as tmpfs. Other on the list also pointed me there. So, in a systemd system, how does /media get mounted? Yours sincerely, Roger Oberholtzer Ramböll RST / Systems Office: Int +46 10-615 60 20 Mobile: Int +46 70-815 1696 roger.oberholtzer@ramboll.se ________________________________________ Ramböll Sverige AB Krukmakargatan 21 P.O. Box 17009 SE-104 62 Stockholm, Sweden www.rambollrst.se -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

El 05/06/13 06:33, Anton Aylward escribió:

On my 12.2 there is /etc/tmpdirs.d and /etc/tmpfiles.d which are used to locally override their counterparts in /usr/lib/

Nope, systemd-tmpfiles does not have the ability to create/mount filesystems. only to create directories or files on already mounted ones. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

El 04/06/13 18:02, Carlos E. R. escribió:

In 12.1 it must do something about /media. sysvinit does, so systemd does it to, else the directory would me missing, and 12.1 uses it.

OK, that's in 12.1, in current versions however it does not. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org