=== 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 [15:35] apw, workdir= for overlayfs... [15:35] smoser, yes [15:36] it cannot be under upperdir ? [15:36] smoser, it cannot [15:36] thats annoying. [15:36] smoser, yes, it is very annoying [15:36] basically means i can't have overlay go to the root of a filesystem. [15:37] smoser, in other places i have done like $upperdir-workdir, and where .. isn't on the same filesystem it fails to mount [15:37] smoser, no indeed, it means exactly that, which is a royal pain [15:37] smoser, i have tended to take the people supply and make upper and workdir in there [15:37] do you have suggestion on how to determine if i have use workdir= ? [15:38] smoser, i have tended to mount with workdir= and when that fails mount without, though if that is hard [15:38] smoser, and in overlayroot, i believe that is hard because we build the fstab first [15:38] smoser, then you can use version > 3.18.0-0 [15:40] i dont think fstab is an issue. as we dont even write the "correct" mount options tehre. [15:44] hey, 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] Launchpad bug 1408495 in ubiquity (Ubuntu Vivid) "Ubiquity crashes prior to keyboard configuration in 15.04" [High,Confirmed] === spideyman is now known as Guest16233 [16:39] apw: looks like my bug 1408495 is most likely a duplicate of bug 1410480 [16:39] bug 1408495 in ubiquity (Ubuntu Vivid) "Ubiquity crashes prior to keyboard configuration in 15.04" [High,Confirmed] https://launchpad.net/bugs/1408495 [16:39] bug 1410480 in linux (Ubuntu) "overlayfs v1: renaming existing file uses chardev whiteout (should be symlink)" [High,In progress] https://launchpad.net/bugs/1410480 [16:41] cyphermox, yes given you had a c------- device, that is nominally a whiteout, and wrong, and the second bug yes [16:41] cyphermox, i am working on that one right now, feel free to dup yours to it [16:41] alright, so I'll mark duplicate [16:41] thanks! === Guest4292 is now known as kgunn [16:57] smoser, it occurs to me where these are in tmpfs, that you can (and likely should) use V2 format, ie use -t overlay [16:57] smoser, for the maas use case they are ephemeral right ? [16:59] maas is backed by tmpfs. [16:59] what is 'v2 format' ? [17:00] apw, ^ [17:22] upstream 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 forward [17:25] smoser, ^ [17:53] apw, does 'overlay' have the same symantics as overlayfs from client 'mount' ? [17:53] smoser, yes [17:53] so just '-t' overlay [17:54] why did you ask about 'tmpfs' ? [17:57] oh. i see. because of data format. [18:27] smoser, right, if the upperdir is empty you can use the new form cause you really have no old data [18:37] apw, would there be an easy way to know the format of the data ? [18:38] because if i try to be smart and "auto" select overlay rather than overlayfs, then i have to later on make the right choice. [18:39] smoser, no none [18:40] smoser, a filesystem with no superblock, it is a bit of a disaster [18:42] then i think its best to just be stupid, and not try to "help" the user at all. [18:43] apw, why would i want the new 'overlay' type for tmpfs ? ie, you're right we could make that decision, but why would i want to [18:50] because 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 anyhow [18:52] smoser, and the new form is upstream supported, and should be more reliable as a result === bjf[afk] is now known as bjf