=== superm1_ is now known as superm1 === plars is now known as plars-away [14:20] cjwatson: in partman-crypto we default to not erase data, yet i don't see a way to pressed that value in an automatic install such that it _does_ erase disk =/ [14:22] it's "skip_erase" in a recipe - if that's omitted then it'll erase [14:23] that's the intent anyway [14:25] antarus: sorry for the delay. the best documentation I suspect is in doc/devel/ in the debian-installer source package. the "multiraid" and "condpart" strings you're referring to aren't really keywords, but are covered by: [14:26] ::=_:: [14:26] The purpose of is to allow translation of the names of [14:26] the recipes into different languages. [14:26] (I suspect this isn't generally convenient, as it requires injecting a debconf template) [14:26] cjwatson: hm, looking at ubiquity, it's using partman-auto-crypto - not manual partitioning which allows to drive/toggle the erase flag. [14:28] erase is still done by partman-crypto though [14:28] and default is hard-coded and not based on any debconf question (e.g. a bool with low priority) [14:28] yeah, but ubiquity can always just prod the partman flag directly - it has support for that kind of thing [14:29] interesting, i don't think i've done that yet. I'll have a look. [14:31] p.remove_part_entry(part_id, "skip_erase") or some such [21:24] xnox: did I misremember that there was some work being done to get a sane swap allocation by default? a friend of mine just told me that on a system with 512GB of RAM and 900GB of SSD, an auto install produced a swap much larger than /... [21:25] since we don't care about suspend to disk anyway, we really should set an upper limit to a sane value, say, maybe 4GB or so... [21:27] xnox: apparently on that box, partman decided that a 540GB swap was appropriate ;) [21:40] I would not expect sane anything on a box with that much ram ;) [21:44] stgraber: there have been strong demands to "appropriately allocate swap" but nobody yet came up with a formula. [21:45] stgraber: the most halarious combination is when RAM >> "/", then we allocate more swap then space for "/" and thus fail the install as we run out of disk-space on "/" [21:46] stgraber: 540GB swap with 512GB RAM sounds like a bug, since it should be ~= 1xRAM, no more than that. [21:46] stgraber: i find 32GB of swap, with 32GB of ram with a 1TB spinny disk appropriate. [21:48] yeah, on large disks it's not a huge deal indeed, on expensive enterprise grade SSDs, it's a bit more annoying :) [21:49] I guess swap == RAM with an upper limit for RAM at 32GB and an upper limit for SWAP at 10% of the total space would be vaguely sane [21:50] that'd keep the 1 to 1 mapping for most systems but hopefully not kill small SSDs with a large swap and not allocate a completely insane amount of swap on systems with a ton of RAM [21:52] stgraber: i would have thought the limit would be 5% of total disk-space, not 10%. E.g. 4GB of RAM, 4GB of swap with a 80GB disk. [21:54] hmm, yeah, 5% should be fine too [21:55] and i don't care about VMs / cloud much - cause they either don't use d-i installer, or hypervisor knows how to suspend them. [21:57] stgraber: whoops, we go for: 96 512 200% at the moment. 200% is in terms of RAM, not total disk space, hm.... [22:00] xnox: https://docs.google.com/spreadsheets/d/12Roi8YnMm2VDEtnitsr0fjRRnRJfSwXofM6JTAGzSpA/edit#gid=0 [22:00] stgraber: that does not open for me =/ [22:01] ah, works now, thanks. [22:07] stgraber: looks good, i'll send that formula to debian-boot for discussion. [22:10] xnox: cool, thanks!