[13:10] cyphermox, i'm pondering to enable disk-detect/multipath/enable to true by default on s390x, because it works fine there. [13:11] i also think it does work fine everywhere else too, and if things are multipath, we really shouldn't be presenting each path as a separate disk.... [13:11] should we enable it by default to true on all architectures? [13:11] or shall i stick to s390x only for now? [13:26] xnox: why even on s390x? [13:26] you may have a not fully provisioned box without all the drives in, I suppose. [13:27] cyphermox, on s390x there are dasd drives - these are non-multipath ones, and s390-zfcp which is fibre-channel, almost always properly multipath. And I have a tonne of bug reports from IBM and customers, who are failing to discover diskt-detect/multipath/enable [13:28] and it just works, and one can even boot off multipath device on s390x. [13:28] so on s390x people expect multipath with zfcp. [13:45] heh [13:46] the same logic goes for ppc64el then; perhaps it would be best to make it the default there too [13:47] ie. the controller can multipath, then it's up to you whether you want to use it or not [13:48] OTOH, could you also not have zfcp? [13:49] if you test it to a reasonable level of certainty that it doesn't break the obvious test cases, I'm fine with enabling multipath anywhere / everywhere, really [13:50] normally multipath should work fine and not take over non-multipath drives [13:50] xnox: maybe ask rharper / smoser's opinions too [13:50] cyphermox, well, i tested it sufficiently on s390x [13:50] never touched ppc64el yet (as in physical machines, i was on kvm instances before) [13:50] not sure about other arches. [13:58] xnox: well, the same logic is valid on all arches -- you don't usually have multipath-capable things, but if you do, it's nice to have it enabled [13:58] it's always dependent on you doing the right hardware setup first [13:59] even with FC -- you don't necessarily put two paths to NAS [14:01] so shall i shoot a email out to enable it by default everywhere then? and solicit feedback? [14:36] would be best especially by now [15:46] xnox: how are you testing the translation magic? [15:46] it certainly looks to be retrieving the main-menu translations correctly here for russian [15:46] not that I can read it, but I get upside down and reversed characters [15:46] cyphermox, boot amd64 server iso in qemu-kvm, select russian in boot menu, start install, go back, main-menu is in english [15:47] that's exactly what I did [15:47] thing is, you need to go through localechooser first [15:47] let me sync in new server image..... [15:47] hm. [15:48] perhaps we should preseed more forcefully from gfxboot, and that would fix that part.. [15:48] except if someone picks a lang on the gfxboot menu and then wants to use something different, it's going to be ugly [15:50] huh, i went through locale chooser changed russian to latvian and things work fine, e.g. everything is in latvian now. [16:04] d-i partman-auto/disk string /dev/sda - fails on a box that gives sda to a card reader, and there is no card, so it errors. Is there a way to say "find a drive and use it"? (which some would call dangerous, but I am ok with that) [16:11] CarlFK: not aside from using an early_command to write your own script to do that [16:13] bleck. too much work/clutter for this problem [16:13] I can pass it in as a kernel parameter, right? [16:37] cyphermox, i wonder if translation menus work on e.g. powerpc. [16:37] infinity, is main menu translated on powerpc? [16:37] why would it be different there? [16:37] big endian like s390x =) [16:37] I can try it just as soon as this meeting is done [16:38] oh, actually, before since I can use another system to avoid cutting the link