=== lfaraone is now known as lfaraone_
=== 18VABY2YZ is now known as elmo
=== gerald is now known as Guest69264
=== swordsmanz is now known as hugbot
=== hugbot is now known as swordsmanz
=== lan3y is now known as Laney
smoserapw, workdir= for overlayfs...15:35
apwsmoser, yes15:35
smoserit cannot be under upperdir ?15:36
apwsmoser, it cannot15:36
smoserthats annoying.15:36
apwsmoser, yes, it is very annoying15:36
smoserbasically means i can't have overlay go to the root of a filesystem.15:36
apwsmoser, in other places i have done like $upperdir-workdir, and where .. isn't on the same filesystem it fails to mount15:37
apwsmoser, no indeed, it means exactly that, which is a royal pain15:37
apwsmoser, i have tended to take the <dir> people supply and make upper and workdir in there15:37
smoserdo you have  suggestion on how to determine if i have use workdir= ?15:37
apwsmoser, i have tended to mount with workdir= and when that fails mount without, though if that is hard15:38
apwsmoser, and in overlayroot, i believe that is hard because we build the fstab first15:38
apwsmoser, then you can use version > 3.18.0-015:38
smoseri dont think fstab is an issue. as we dont even write the "correct" mount options tehre.15:40
cyphermoxhey, I've added a task for linux to https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/1408495; looks like any moving of a file on the underlying read-only filesystem of the overlayfs on the CD leaves behind a 0,0 character device of the same name; could someone check if there would be an explanation for this as an overlayfs bug?15:44
ubot5Launchpad bug 1408495 in ubiquity (Ubuntu Vivid) "Ubiquity crashes prior to keyboard configuration in 15.04" [High,Confirmed]15:44
=== spideyman is now known as Guest16233
cyphermoxapw: looks like my bug 1408495 is most likely a duplicate of bug 141048016:39
ubot5bug 1408495 in ubiquity (Ubuntu Vivid) "Ubiquity crashes prior to keyboard configuration in 15.04" [High,Confirmed] https://launchpad.net/bugs/140849516:39
ubot5bug 1410480 in linux (Ubuntu) "overlayfs v1: renaming existing file uses chardev whiteout (should be symlink)" [High,In progress] https://launchpad.net/bugs/141048016:39
apwcyphermox, yes given you had a c------- device, that is nominally a whiteout, and wrong, and the second bug yes16:41
apwcyphermox, i am working on that one right now, feel free to dup yours to it16:41
cyphermoxalright, so I'll mark duplicate16:41
=== Guest4292 is now known as kgunn
apwsmoser, it occurs to me where these are in tmpfs, that you can (and likely should) use V2 format, ie use -t overlay16:57
apwsmoser, for the maas use case they are ephemeral right ?16:57
smosermaas is backed by tmpfs.16:59
smoserwhat is 'v2 format' ?16:59
smoserapw, ^17:00
apwupstream overlayfs format ... in v3.18 there are two filessytem overlayfs which is (in theory, and actually not right now) backwards compatible on disk, and overlay which is how upstream is doing it going forward17:22
apwsmoser, ^17:25
smoserapw, does 'overlay' have the same symantics as overlayfs from client 'mount' ?17:53
apwsmoser, yes17:53
smoserso just '-t' overlay17:53
smoserwhy did you ask about 'tmpfs' ?17:54
smoseroh. i see. because of data format.17:57
apwsmoser, right, if the upperdir is empty you can use the new form cause you really have no old data18:27
smoserapw, would there be an easy way to know the format of the data ?18:37
smoserbecause if i try to be smart and "auto" select overlay rather than overlayfs, then i have to later on make the right choice.18:38
apwsmoser, no none18:39
apwsmoser, a filesystem with no superblock, it is a bit of a disaster18:40
smoserthen i think its best to just be stupid, and not try to "help" the user at all.18:42
smoserapw, why would i want the new 'overlay' type for tmpfs ? ie, you're right we could make that decision, but why would i want to18:43
apwbecause the old one is going to go awy, for tmpfs, as it is ephemeral the new one is most appropriate because it is going to go away anyhow18:50
apwsmoser, and the new form is upstream supported, and should be more reliable as a result18:52
=== bjf[afk] is now known as bjf

Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!