Installer cannot use DASD if it was used with LVM before

Default Comment by Bridge

Investigating this further here is what happens:
1) one puts a dasd drive online
2) udev rules are processed and detect an lvm2 volume group
3) which is then activated straight away
4) dasd drive cannot be formated as the device is now busy

I think we really ought to not automatically lvm2 volume groups in d-i, as there are separate partitioning menus to do so. I am not sure how such a change will affect ubiquity installer on desktop platforms. I shall consult with installer team.

see bug 1541510

not a duplicate, separate issue.

This bug was fixed in the package lvm2 - 2.02.133-1ubuntu5

---------------
lvm2 (2.02.133-1ubuntu5) xenial; urgency=medium

  * Drop udev rules from lvm2-udeb package. Otherwise, lvm groups and
    volumes are activated behind partman's back e.g. after dasd drive
    activation. And thus prevents dasdfmt from succeeding. LP: #1536664
  * Drop watershed-udeb dependency, no longer needed.
  * Keep dmsetup udev rules.

 -- Dimitri John Ledkov <email address hidden> Tue, 09 Feb 2016 10:14:58 +0000

------- Comment From <email address hidden> 2016-02-10 10:13 EDT-------
With this fix you can format a DASD that was used for LVM.

I have however found a problem, of which I don't know if this is related or a new one or is even expected behaviour. If this is separate, please tell me so that I can open a new bug for this.

Here's what I tried:

- Select DASD (which I used for an installation with LVM before)
- Format the Device -> no
- Finish
- Partitioning method: manual

- Menu "Partition disks":
DASD 0.0.5d32 (ECKD) - 7.4 GB IBM S390 DASD drive
> #1 500.0 MB ext2
> #2 6.9 GB K lvm
> 49.2 kB FREE SPACE
LVM VG rootVG, LV rootLV - 6.9 GB Linux device-mapper (linear)
> #1 6.9 GB ext4

- Go Back

- Select "Configure direct access storage devices (DASD)"

- Select previous DASD again; DASD is displayed as 0.0.5d32 (online)

- Format the device -> Yes

- Error:

Installation step failed
An installation step failed. You can try to run the failing item again from the menu, or skip it and choose something
else. The failing step is: Configure direct access storage devices (DASD)

/proc/partitions looks like this:

major minor #blocks name

1 0 40000 ram0
1 1 40000 ram1
1 2 40000 ram2
1 3 40000 ram3
1 4 40000 ram4
1 5 40000 ram5
1 6 40000 ram6
1 7 40000 ram7
1 8 40000 ram8
1 9 40000 ram9
1 10 40000 ram10
1 11 40000 ram11
1 12 40000 ram12
1 13 40000 ram13
1 14 40000 ram14
1 15 40000 ram15
94 0 7212240 dasda
94 1 488304 dasda1
94 2 6723792 dasda2
252 0 6721536 dm-0

I have attached the syslog that was created during my test.

------- Comment (attachment only) From <email address hidden> 2016-02-10 10:17 EDT-------

@ roesch3

it's best to open new (more) bugs to track subtle things separately. And fix them, close them as duplicate, remove duplicate flags etc.

Most likely you have to deactive the volume groups before attempting to re-dasdformat the drive. And that's a slightly separate issue. The root cause that I can see, is that dasdformat step does not "force" the formatting (-F) flag which would, well force the formatting, hopefully. =)

Please open a new bug report with this newly reported issue.

------- Comment From <email address hidden> 2016-02-11 04:49 EDT-------
Ok I will open a separate bug for that problem.
I think we can now close this bug here.