[01:44] <cyphermox> infinity: still around?
[01:47] <cyphermox> I've spent more time testing my tasksel merge, and it doesn't even look like we use it anywhere to build images (we'd use apt instead AFAICT), the only current use appears as though it would be as a tool to potentially install more stuff on a system, which appears to work. I'd be quite interested to know if there is some other use I've missed
[01:48] <cyphermox> fwiw, in the merge I drop all the task packages from Debian, and kept enough of our changes (or I guess the task-fields magic) to handle our tasks
[01:48] <cyphermox> so far from what I could test (since I may have missed some use case that breaks badly), it works just as it previously did
[01:49] <cyphermox> in fact, slightly better on openstack, as the current tasksel + aptitude seems to explode in some way right now, and apt-only works correctly, it seems
[14:56] <infinity> cyphermox: Do we not still use it from d-i?  Maybe we switched to apt there when I wasn't looking.
[14:57] <cyphermox> well, towards the end of the install on server (when not using live-installer), you would get a tasksel-looking thing
[14:57] <cyphermox> I think that's pkgsel
[14:58] <cyphermox> but since the behavior appears to be the same when running tasksel after install, seems like that would be fine
[14:59] <cyphermox> oh wait, you're right there's something important I forgot there.
[15:00] <cyphermox> at the very least we're calling tasksel with options that no longer exist
[15:04] <cyphermox> infinity: there are --debconf-apt-to and --debconf-apt-from for progress that are delta we've had for a long while
[17:08] <xnox> cyphermox, i take it bad things happen, when there is no partman-auto recipe for an architecture?!
[17:08] <xnox> bug #1527328
[17:09] <cyphermox> probably yeah
[17:09] <cyphermox> should be sufficient to copy those from s390.
[17:10] <cyphermox> if there were any
[17:10] <cyphermox> ah, did that format in mbr format?
[17:11] <cyphermox> xnox: could you add syslog to the bug
[17:13] <xnox> nah, i cannot share logs ;-)
[17:13] <xnox> that would be telling, what actually is going on.
[17:13] <cyphermox> ok
[17:13] <cyphermox> well, partman-auto should make a gpt partition table anyway, not a MBR one.
[17:13] <xnox> looking at partman-auto it seems like neither s390 nor s390x support was ever there.
[17:13] <cyphermox> nope
[17:14] <xnox> i'm not sure what default partition table for them is.....
[17:14] <cyphermox> but it also doesn't look like it should matter
[17:15] <cjwatson> default mbr vs. gpt is up to partman-partitioning, not -auto
[17:15] <xnox> from docs it can be any. however ipl should be able to read the bootmap from the boot partition....
[17:15] <cyphermox> ah? but partman-auto's /lib/partman/recipes reads gpt in atomic.
[17:15] <cyphermox> nevermind I can't read, apparently
[17:16] <xnox> cyphermox, ipl -> as in hypervisor z/VM CMS console.
[17:16] <cjwatson> it has a bit of special handling, but the recipes are mostly partition-table-agnostic
[17:16] <cyphermox> yeah, I just fail at reading
[17:17] <cyphermox> msdos on s390x?
[17:17] <cyphermox> that was a regex.
[17:17] <xnox> cyphermox, i'm inclined to copy ppc64el (or symlink) that to s390x.
[17:17] <cjwatson> last I checked, yeah
[17:17] <xnox> it looks "reasonable"
[17:17] <cjwatson> errrr
[17:17] <cjwatson> you don't want prep
[17:17] <cyphermox> indeed
[17:17] <xnox> ah, true.
[17:18] <cjwatson> it can probably be pretty similar to ppc64el, but not a symlink
[17:18] <cyphermox> do you really need to create one? looks to me like the generic one should work
[17:18] <xnox> however, i can do something good. there is zipl support to boot of lvm directly. so e.g. i can test doing /boot -less lvm by default.
[17:19] <xnox> cyphermox, it doesn't as per bug report. do you need more details from it?
[17:19] <cyphermox> xnox: yeah, your "too high partition numbers" isn't very clear
[17:19] <cjwatson> yeah, that's not about absence of recipe
[17:19] <cyphermox> is that causing some failure somewhere
[17:19] <xnox> horum.
[17:20] <xnox> let me get more logs.
[17:20] <cjwatson> partman tries very hard to use logical partitions where it can
[17:20] <cjwatson> I'm very sceptical about this business of logical partitions not working
[17:20] <cjwatson> feel like that needs some digging
[17:20] <cyphermox> because when you jump from 1 to 5 it simply looks like it's using msdos and making you one primary and one extended partition, hence the 5
[17:20] <xnox> ..
[17:20] <xnox> the method biosgrub and defaultingore are not giving me confidence.
[17:20] <cjwatson> defaultignore is about lvm
[17:21] <xnox> right, yes. i recall that now.
[17:21] <cjwatson> so, if gpt works, that would avoid the logical partition business, but if something cares about logical partitions then it may also care about the partition table format
[17:22] <cjwatson> try a fresh install with partman-partitioning/default_label=gpt on the command line
[17:22] <cjwatson> if that works then it would probably be reasonable to switch the default over
[17:23] <cjwatson> i.e. a fresh install with that and with default recipes etc.
[17:25] <xnox> ok.
[17:26] <xnox> release noted.
=== xnox is now known as xnox_2016