[09:46] <xnox> cpaelzer, hey. in addition to the IPL bug, the installer on FBA devices tries to use (a) msdos partition table (b) create logical partition #5 which fails.
[09:46] <xnox> on FBA devices, what partition table should be used?
[10:07] <cpaelzer> xnox: hi
[10:07] <cpaelzer> xnox: I only saw it uses fdasd and reported that -so you are saying "afterwards" it is using msdos parts which fails as well
[10:07] <cpaelzer> hmm
[10:07] <cpaelzer> xnox: let me check the docs what partition table format should be used
[10:08] <xnox> cpaelzer, i tried autopartitioning, and it clearly went to use msdos because the label is not "dasd"
[10:08] <xnox> dasdfmt complaints "this is not eckd" device and
[10:08] <cpaelzer> xnox: yeah this type can't be formatted by Linux at all
[10:08] <xnox> and fdasd also complaints.
[10:08] <cpaelzer> xnox: that is what I meant with "we should put something in docs" in the bug
[10:09] <cpaelzer> xnox: yeah it is not fdasd, it is what a scsi disk would be
[10:09] <cpaelzer> xnox: fdisk ?
[10:09] <cpaelzer> what does it use?
[10:09] <xnox> fdisk can do anything under the moon =)
[10:09] <xnox> "It understands GPT, MBR, Sun, SGI and BSD partition tables."
[10:09] <xnox> i'll try gpt, if possible, but i think that blows up too =)
[10:09] <cpaelzer> xnox: still searching the table I've seen last week ...
[10:11] <cpaelzer> xnox: http://public.dhe.ibm.com/software/dw/linux390/docu/l4n4dd29.pdf page 159
[10:11] <cpaelzer> xnox: lets start there
[10:12] <cpaelzer> FBA disks are column #3
[10:12] <cpaelzer> and as they don't work with dasdfmt they won't have CDL/LDL disk layout
[10:12] <cpaelzer> instead only CMS disk layout is supported
[10:12] <cpaelzer> and only one partition ...
[10:12] <cpaelzer> they don't name the/a tool to partition
[10:13] <cpaelzer> maybe it doesn't even have one - I mean there is a "max partition = 1"
[10:13] <cpaelzer> xnox: ^^
[10:13] <cpaelzer> I asked jfh to put a FBA disk as secondary device to his VMs so we could try with the power of a full linux instead of install env
[10:13] <cpaelzer> jfh: is that ready somewhere ?
[10:13] <xnox> cpaelzer, yes
[10:13] <xnox> i have that
[10:13] <cpaelzer> xnox: great
[10:14] <xnox> let me try to create two primary partitions
[10:14] <cpaelzer> I'd be bold and say maybe it is never partitioned at all - but please try the multitude of options you'd have with fdisk or so
[10:15] <xnox> cpaelzer, this starting to make sense.
[10:15] <cpaelzer> hca: I never worked that much with FBA - could you comment/confirm on the partitioning no FBA a bit?
[10:15] <cpaelzer> hca: who needs that FBA cruft (well sadly some people like it)
[10:15] <xnox> so in debian, for a long time it had short-circuited "automatic partioning" cause at the time of debian port only FBA was common, and if it can only have one partition.... partman autoparitioning into 5 partitions makes no sense.
[10:16] <cpaelzer> xnox: ack
[10:16] <cpaelzer> xnox: and dasd CDL format can only have three, not
[10:16] <cpaelzer> 5
[10:16] <cpaelzer> which is most common today
[10:16] <xnox> sure, but we use fdasd there which is sensible.
[10:17] <cpaelzer> xnox: as long as you are not using fdasd trying to do >3 :-)
[10:17] <cpaelzer> xnox: I'll have to go to lunch now - but yes for FBA you'll likely have to revive the old short-circuit
[10:39] <sth> cpaelzer let me clarify a few things about FBA devices
[10:40] <sth> cpaelzer they do not have to and even can not be formatted using dasdfmt
[10:40] <sth> cpaelzer per default there is a single partition implicit partition, meaning the partition is created by the DASD driver and has no information written to the disk
[10:40] <sth> cpaelzer within z/VM you can use CMS FORMAT to generate a CMS partition
[10:40] <sth> cpaelzer as of today IBM does not support the usage of fdisk for FBA devices
[10:41] <sth> cpaelzer I tested it to a certain degree and it works with msdos style partition tables and up to 3 partitions
[10:42] <sth> cpaelzer as far as I remember there is a conflict with GPT and zipl on FBA devices, there might be a risk of data corruption because of overlapping areas on the disk
[10:42] <cpaelzer> sth: hi Stefan
[10:42] <jfh> @cpaezler and @xnox: sorry for joining this conversation so late ...
[10:43] <jfh> afair there is no special partition table for FBA, and defaults back to msdos
[10:43] <cpaelzer> sth: thanks a lot, that confirmed all I found so far in a much more condensed way - great
[10:44] <cpaelzer> jfh: see above the explanation of sth about partitions
[10:44] <jfh> and I think fdisk does automatically use msdos if no table is there ...
[10:44] <jfh> oh - okay ...
[10:44] <cpaelzer> jfh: and all sth reports matches what I found in the device drivers handbook
[10:44] <cpaelzer> also he owns the driver so there very unlikely is a better source of information :-)
[10:47] <jfh> I see, but didn't know that fdisk is (still) not officially supported ... due to the fact that is used by lot's of folks on FBA devices ... and is even described in that way in the virt cookbooks ... anyhow ...
[10:48] <sth> cpaelzer: no problem, let me know if you need more information
[10:50] <xnox> sth, what i'm taking out of this discussion is that (a) parted is buggy, and tries to create extended/logical partitions (b) i should fix our installer to not do that on FBA and CKD devices
[10:50] <xnox> (c) there is still the IPL bug off FBA devices =(
[10:51] <sth> xnox, a b c yes and I am working on c
[10:56] <xnox> sth, during 16.04 development we mostly used uncompressed kernel images, and switched to compressed images very late. I wonder if using scripts from kernel source tree to uncompress the kernel image would help to mitigate the IPL bug, or be able to investigate it easier.
[10:56] <jfh> @sth: Hmm, I'm wondering if EDEV FBA can really be an officially supported scenario in this case ?!
[10:57] <cpaelzer> jfh: it can, just not with partitioning
[10:57] <cpaelzer> sth: the implicit partition by the dsasd-fba driver is the supported solution right?
[10:58] <sth> xnox it might help to mitigate but as the bugs hits on special kernel sizes/offsets it might also not
[11:00] <jfh> that's btw the suggested step from the virt. cookbook "parted -s /dev/dasde mklabel msdos mkpart primary 0% 100%"  (dasde being an FBA device)
[11:00] <cpaelzer> sth: not that I'd vote to pad the kernel, but is the pattern of bad size/offset already known ?
[11:01] <xnox> cpaelzer, well at the moment we have a bug with ECKD drives too - if one forces to use msdos partition table, it will caboom with automatic partitioning recipy.
[11:01] <cpaelzer> ouch
[11:01] <xnox> so this bug is worth fixing
[11:01] <sth> jfh as of today there is a bug in the loader for FBA devices and i think the install image needs to be updated with a fixed zipl to get this fixed, I do not know if you would like to restrict this scenario officially
[11:03] <xnox> sth, we have new media published on 21st of July for 16.04.1 release. It would be nice to have a fix for this before then (july 14th the latest)
[11:03] <jfh> @sth: not necessarily, if not needed ... ;-)
[11:03] <sth> cpaelzer we create chunks of the kernel image thats adresses are written to the bootmap file, if one of those chunks consists exactly of 128 blocks it will break the loader
[11:03] <jfh> @xnox: agreed
[11:04] <xnox> sth, about restricting.... in general there is plenty of ways of shooting one in the foot. And obvious ways of shooting oneself in the foot should not be the default =) like it currently is with clicking "continue" throughout the installer on an fba device.
[11:04] <xnox> (with partitioning & IPL imploding)
[11:06] <jfh> @xnox, @sth: is case we don't have a proper solution until 16.04.1 we should at least add a comment to the release notes, right ? But let's see ...
[11:06] <cpaelzer> sth: thanks for the info, are these chunks the offset list created due to filesystem fragmentation - shouldn't be too much on a newly installed system
[11:07] <sth> jfh regarding the usage of parted/fdisk on FBA, at least I am not aware of an official support statement, I do not know if the cookbook can be seen as such a statement
[11:08] <sth> jfh as far as I have tested the described usage of parted should work
[11:10] <sth> cpaelzer I am not 100% sure about the list generation but I think no
[11:10] <sth> i have a fix for the loader in test
[11:11] <sth> should be included in our bugzilla next week, I think
[11:12] <jfh> @sth: that usually worked for me as well and for lot's of other folks (even for customers in prod) - so I assumed that it is officially supported - so "support due to long-term and traditional usage" ;-)
[11:13] <sth> jfh ;)
[11:17] <xnox> https://bugs.launchpad.net/ubuntu/+source/partman-base/+bug/1595495
[11:17] <ubottu> Launchpad bug 1595495 in partman-base (Ubuntu) "DASD drives can only hold 3 partitions" [Undecided,New]
[11:34] <xnox> uploaded a fix to yakkety to short-circuit extended partitions usage on dasd drives.
[11:35] <xnox> will retest, and sru into xenial.
=== fbader_ is now known as fbader