Installer cannot use DASD if it was used with LVM before

Bug #1536664 reported by bugproxy on 2016-01-21
This bug affects 1 person
Affects Status Importance Assigned to Milestone
lvm2 (Ubuntu)
Dimitri John Ledkov

Bug Description

== Comment: #0 - Michael Roesch <email address hidden> - 2016-01-21 07:31:16 ==
A DASD that has been used with and partitioned for LVM, cannot be used for installation. The installer cannot format the disk. It throws the error "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)".
When you just select the DASD without formatting, the installer accepts the DASD, but hangs at "Scanning disks..." at 45 percent. I have attached the syslog.

bugproxy (bugproxy) wrote : Syslog

Default Comment by Bridge

tags: added: architecture-s39064 bugnameltc-135878 severity-medium targetmilestone-inin1604
Changed in ubuntu:
assignee: nobody → Taco Screen team (taco-screen-team)
Steve Langasek (vorlon) on 2016-01-21
affects: ubuntu → debian-installer (Ubuntu)
Changed in debian-installer (Ubuntu):
assignee: Taco Screen team (taco-screen-team) → Dimitri John Ledkov (xnox)
Changed in debian-installer (Ubuntu):
importance: Undecided → High
Dimitri John Ledkov (xnox) wrote :

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.

Dimitri John Ledkov (xnox) wrote :
Dimitri John Ledkov (xnox) wrote :

not a duplicate, separate issue.

affects: debian-installer (Ubuntu) → lvm2 (Ubuntu)
Changed in lvm2 (Ubuntu):
status: New → Fix Committed
Launchpad Janitor (janitor) wrote :

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

Changed in lvm2 (Ubuntu):
status: Fix Committed → Fix Released

------- 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-------

Dimitri John Ledkov (xnox) wrote :

@ 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.

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers