| mpt | xnox, hi, I'm working on the LVM design again. When you make a logical volume, do you get to name it? If so, what are the constraints on the name? | 11:36 |
|---|---|---|
| cjwatson | mpt: Yes, you get to name it. The valid names are documented in http://manpages.ubuntu.com/manpages/precise/en/man8/lvm.8.html#contenttoc7 | 11:38 |
| mpt | a-z A-Z 0-9 + _ . - | 11:40 |
| mpt | Thanks cjwatson | 11:41 |
| mpt | I wonder what a sensible default name would be | 11:41 |
| cjwatson | Let me check what partman-lvm does. | 11:41 |
| mpt | lv1, lv2, etc? | 11:42 |
| cjwatson | Can't say sequence numbers are desperately pleasant. | 11:42 |
| cjwatson | Does it need a default? LV names are supposed to be human-meaningful; that's kind of one of the benefits. | 11:42 |
| cjwatson | d-i doesn't supply a default name and I don't remember hearing complaints about that. | 11:43 |
| cjwatson | I tend to name them based on what I plan to use them for ... | 11:43 |
| mpt | It doesn't need a default, it's just a choice between having a default (pre-selected for typing over) vs. a greater possibility of presenting an error message | 11:44 |
| mpt | (though that error message would still be needed if you explicitly tried to set the name to "") | 11:44 |
| cjwatson | Or one of the special reserved names. | 11:45 |
| cjwatson | People aren't likely to use "pvmove" by accident, but "snapshot" isn't that far out of the question. | 11:46 |
| mpt | Maybe the same error for that, hopefully a slightly different one | 11:46 |
| mpt | Having anything exposed in Ubiquity opens it up to a wider range of audience, and therefore complaints, than d-i :-) | 11:46 |
| cjwatson | Perhaps. The flip side is that in some ways its users tend to be a bit more conventional. | 11:47 |
| cjwatson | Arguably. | 11:48 |
| xnox | mpt: I named my LVM Group as interalhdd | 11:54 |
| xnox | mpt: individual volumes I named after the mountpoint - e.g full name endedup with internalhdd/root internallhdd/home | 11:55 |
| mpt | There's such a thing as an LVM group? | 12:03 |
| mpt | oh, huh | 12:04 |
| cjwatson | volume group | 12:04 |
| mpt | Oh, a "volume group" is what I thought was called a "logical volume" | 12:05 |
| mpt | ok | 12:05 |
| xnox | /dev/sda + /dev/sdb (physical volumes) = (physical group) => (logical group) "internalhdd" | 12:06 |
| cjwatson | s/physical group/volume group/ | 12:06 |
| xnox | (logicalgroup) "internalhdd" => logical volumes, e.g. root home usr, with mount points and filesystems | 12:06 |
| mpt | xnox, hm, so are "internalhdd/root" and "internalhdd/home" partitions you put on this logical volume group? | 12:06 |
| xnox | yeap. you partition a volume group into logical volumes with is transperant/equivalent to partitioning a drive into partitions | 12:07 |
| cjwatson | "internalhdd" is a VG; "root" and "home" are LVs. You put filesystems on LVs. | 12:07 |
| mpt | Okay, I have sketches of two possible designs for this, I'll scan them and you can see what you think | 12:16 |
| * xnox is excited | 12:17 | |
| mpt | xnox, http://imgur.com/RnyVL | 12:23 |
| mpt | So in the first one you have separate panes for (a) all the physical disks and (b) all the current VGs | 12:24 |
| mpt | and funnel-like shading between the two, to show which physical disks make up which VG | 12:25 |
| mpt | In the second, a single tree view, with a branch at the start for any physical disks that aren't currently in a VG | 12:26 |
| mpt | Drawback of the first design is that it could be a bit cramped horizontally. Drawback of the second design is that if you have lots of VGs, you might not be able to see a VG, and the disk you want to add to it, simultaneously. | 12:28 |
| cjwatson | PVs (the constituent elements of VGs) are normally partitions rather than disks (although it's technically possible to use whole disks for them). | 12:31 |
| cjwatson | I generally strongly recommend using partitions because that way it's clearer where to put things like boot loaders. | 12:31 |
| cjwatson | So I would s/disks/partitions/g there I think. | 12:32 |
| mpt | oh, huh | 12:32 |
| mpt | So what does "physical" mean, then, if not "something you can hold in your hand"? | 12:32 |
| mpt | Or would knowing that make my head hurt? | 12:32 |
| cjwatson | It means something with defined physical extents on a disk. | 12:32 |
| cjwatson | Rather than something that's free to move around at will. | 12:32 |
| cjwatson | s/defined/fixed/ | 12:32 |
| mpt | If a PV can be a partition, and LVGs can be partitioned, does that mean LVM can be nested? | 12:33 |
| cjwatson | It's more or less the same metaphor as physical vs. virtual memory | 12:33 |
| xnox | physical volume can be: whole disk (sda), parition (sda1), complex device (crypt), already assembled raid device (md0) | 12:33 |
| cjwatson | Pass :-) But you don't normally partition LVs. | 12:33 |
| cjwatson | In principle you might be able to use an LV as a PV, but, err, maybe the tools prohibit it because it's stupid. I've never tried. | 12:33 |
| xnox | mpt: no, lvm should not be nested. | 12:34 |
| mpt | Is the difference between logical and physical volumes anything to do with the difference between logical and physical partitions? | 12:34 |
| cjwatson | I like your first design better than your second. | 12:34 |
| mpt | Or are they just coincidental uses of the same terms? | 12:34 |
| cjwatson | I think that's mostly coincidental, unfortunately. | 12:34 |
| cjwatson | Well, different layers perhaps | 12:34 |
| mpt | phew+ugh | 12:34 |
| cjwatson | Actually | 12:34 |
| cjwatson | It's logical vs. primary partitions, not logical vs. physica. | 12:35 |
| cjwatson | +l | 12:35 |
| xnox | i like second if it has three heading types: no LVM; lvmgroup hdd; new group. With ability to drag and drop. Dropping a partition on the the 'new group' should ask to name it | 12:35 |
| mpt | xnox, drag and drop would be possible in either design, I think | 12:35 |
| xnox | ok | 12:35 |
| cjwatson | Drag and drop is a bit unpleasant when you have to scroll. | 12:35 |
| mpt | yes, not the primary interaction method, just a bonus | 12:35 |
| xnox | if drap and drop possible, first design is better if you have many disks/partitions. | 12:36 |
| cjwatson | Right, what I mean is that if it's there as a bonus, we should make sure that the design is such that you can have the drag source and target on screen simultaneously. Otherwise it's more like a taunt. | 12:36 |
| mpt | fair enough | 12:36 |
| * xnox yeah trying to scroll while dragging is a pain, both with good intention and by mistake | 12:37 | |
| mpt | Autoscroll while dragging is something developers often get wrong | 12:37 |
| cjwatson | I don't think horizontal space should be too bad with the first design; physical partition names will generally be short (except maybe in some crazy raid cases or something, but still not that long), and usually VG names aren't essays. | 12:37 |
| cjwatson | We can default the VG name to "ubuntu". | 12:37 |
| mpt | Bearing in mind that the dialog can be wider than my sketch, I just did it that narrow so I could fit two on one page :-) | 12:37 |
| cjwatson | Since most people will only have one. | 12:37 |
| cjwatson | (And lots of LVs.) | 12:37 |
| xnox | cjwatson: mpt has proposed to not offer lvm&crypt in the auto-partition page in this itteration, do you agree that it's only for manual partitioning? shall auto-recipes for lvm/lvmcrypt be available for pre-seeding only? | 12:38 |
| * xnox notes, get dual-widescreen pages for mpt =)))) | 12:38 | |
| * mpt rotates the paper 90 degrees | 12:39 | |
| cjwatson | I don't agree that it's only for manual partitioning in general, but if you want to prune it as a scope control exercise for this release then I'm OK with that, I guess. | 12:39 |
| cjwatson | LVM+crypto is the easiest way to get a completely encrypted system. | 12:39 |
| cjwatson | So I do think it's something we should aim to present as an automatic option. | 12:39 |
| mpt | cjwatson, I can imagine either an "Encrypt this disk" checkbox which does LVM+crypto behind the scenes for whichever auto partitioning option you chose | 12:40 |
| mpt | (minus the partitions belonging to other OSes, of course) | 12:40 |
| cjwatson | (Reason to use LVM on top of crypto rather than crypto alone: you generally have more than one partition-like object at the bottom level, and if you only have a single encrypted container then you only have to enter one password.) | 12:41 |
| mpt | Or, a separate "Disk encryption" step that asks you with more explanation up-front | 12:41 |
| mpt | But yes, I do think we should start with it just in the advanced partitioner, and work out from there. | 12:42 |
| mpt | Avoid feature regression before doing new stuff. | 12:43 |
| cjwatson | Makes sense | 12:43 |
| mpt | I'll let you think about the design until tomorrow, and then I'll draw it in higher resolution and write it up in detail | 12:45 |
| * xnox feels like writting a concept optional plugin for ubiquity automatic partitioner to add that as a demo, for smart people who know how respin CD's / update ubiquity in the live session. High enough barrier of entry. | 12:45 | |
| cjwatson | ubiquity --enable-blah | 12:50 |
| cjwatson | We had the opposite for migration-assistant for a while, so there's precedent. | 12:51 |
| cjwatson | In fact I think that's how I deployed the advanced partitioner rewrite in feisty. | 12:51 |
| xnox | you did. | 12:51 |
| xnox | I was thinking | 12:51 |
| xnox | ubiquity --danger-do-not-use | 12:51 |
| cjwatson | Yeah, you had to say 'ubiquity --new-partitioner' | 12:51 |
| * xnox following btrfs release naming scheme | 12:52 | |
| xnox | cjwatson: ok, gotcha. | 12:52 |
| cjwatson | Having to use a command line option is sufficient deterrent to the casual. | 12:53 |
| cjwatson | IMO anyway. | 12:53 |
| xnox | yeah, I keep forgetting that casuals don't use terminals | 12:54 |
| antarus | heh, casuals | 12:54 |
| xnox | although I did train my relatives to reliably open reverse ssh port forward to trusted people only (me) | 12:55 |
| xnox | cjwatson: have you seen my email/question on the ubuntu-installer mailing list, w.r.t ubi_partman not picking up lvm recepes/options into the statemachine to be a valid answer for a question | 15:30 |
| xnox | and how to best adjust datastructure to accomodate for multiple variants per installation type | 15:31 |
| * cjwatson goes to read list mail | 15:31 | |
| cjwatson | Expect some delay, sounds like a hard question ;-) | 15:31 |
| xnox | cjwatson: you answered half of the email with 'just use something like --new-partitioner' flag to hide ugly non-designed ui | 15:32 |
| bdmurray | stgraber: could you look at bug 929092? | 18:24 |
| ubot2 | Launchpad bug 929092 in oem-priority "ubiquity crashed with DBusException in call_blocking(): org.freedesktop.DBus.GLib.UnmappedError.NmSettingWirelessSecurityErrorQuark.Code1: Failed to determine AP security information" [Critical,Confirmed] https://launchpad.net/bugs/929092 | 18:24 |
| stgraber | bdmurray: the fix does sound good, would need someone to test this though | 18:32 |
| bdmurray | someone like? | 18:33 |
| stgraber | someone who has a test machine with a wireless card ;) | 18:33 |
| stgraber | trying to reproduce with a WPA key of less than 8 characters, then doing an in place change of /usr/lib/ubiquity/plugins/ubi-wireless.py, adding the proposed try/except block and checking that ubi-wireless no longer crashes | 18:35 |
| stgraber | if that works, I'm certainly happy to commit the change to ubiquity's trunk and precise branch (can't SRU just yet as there's already one in -proposed) | 18:35 |
| skaet | slangasek, ev, in errors.ubuntu.com, for 12.04, over last month period, there's an ubiquity crash showing up, without a bug number (freq 4600, first seen 2.10.8, last seen 2.10.17) | 19:13 |
| ev | skaet: yeah, I'm still working on the ability to create a bug from errors.ubuntu.com | 19:15 |
| ev | it became complicated when I found out launchpadlib wasn't thread safe | 19:15 |
| ev | which was further complication from not being able to use OAuth | 19:15 |
| skaet | ev, ah... thanks. ok, just was wondering if it was something we should be targetting to fix for 12.04.1 | 19:16 |
| * skaet looking forward to the bugs getting auto created. | 19:16 | |
| ev | skaet: I can't say about the specific crash. That's up to whoever is hacking on ubiquity | 19:17 |
| ev | bugs wont be auto-created, there was push back on that | 19:17 |
| ev | but we're trying to find middle ground | 19:17 |
| ev | we'll likely auto-create for the top X | 19:17 |
| skaet | ev, that'll work. | 19:17 |
| ev | and then leave the rest to someone clicking a link on errors.ubuntu.com | 19:17 |
| skaet | yeah, clicking on the ones that are worrisome and the bugs being created would solve it | 19:18 |
| skaet | ev, top 20 over the last month might be reasonable goal for the auto create, but getting so that we click and a bug get opened so we can track it in our other systems would be higher priority to me. | 19:20 |
| ev | yup, I basically had the latter working | 19:21 |
| ev | but due to the issues around lplib, I'll have to either push it behind rabbit/celery | 19:21 |
| ev | or just hit launchpad directly with good ol http | 19:21 |
| ev | s/basically/did/ | 19:22 |
| ev | skaet: rob just approved hitting LP's API directly, rather than going through lplib. So expect the create bug links before the weekend, or next week at the latest. | 20:21 |
| skaet | woot! :) | 20:22 |
| skaet | thanks ev! | 20:22 |
| ev | skaet: Do you think it's reasonable to let anyone click on them, or do you think we really need to be authenticated to open ID to initiate that (they'll all be created by a bot user). | 20:23 |
| ev | I'm inclined to say "anyone", as we're only doing it this way to avoid doing it for every single one, regardless of size, and it's unlikely that people will see the really small ones. | 20:23 |
| ev | the create bug links, that is | 20:23 |
| skaet | ev, I'm biased to let it be everyone intially, and then ratchet it back to members of certain groups only if we have problems. | 20:24 |
| ev | sounds excellent | 20:24 |
| ev | thanks | 20:24 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!