From patchwork Wed Jan 20 15:06:20 2016 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Ian Campbell X-Patchwork-Id: 8072491 Return-Path: X-Original-To: patchwork-xen-devel@patchwork.kernel.org Delivered-To: patchwork-parsemail@patchwork2.web.kernel.org Received: from mail.kernel.org (mail.kernel.org [198.145.29.136]) by patchwork2.web.kernel.org (Postfix) with ESMTP id 1570CBEEE5 for ; Wed, 20 Jan 2016 15:09:43 +0000 (UTC) Received: from mail.kernel.org (localhost [127.0.0.1]) by mail.kernel.org (Postfix) with ESMTP id 3A13F204AE for ; Wed, 20 Jan 2016 15:09:42 +0000 (UTC) Received: from lists.xen.org (lists.xenproject.org [50.57.142.19]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 412F620461 for ; Wed, 20 Jan 2016 15:09:40 +0000 (UTC) Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1aLuLW-00031J-HM; Wed, 20 Jan 2016 15:06:54 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1aLuLV-00030p-EN for xen-devel@lists.xen.org; Wed, 20 Jan 2016 15:06:53 +0000 Received: from [85.158.139.211] by server-7.bemta-5.messagelabs.com id 70/46-13905-C82AF965; Wed, 20 Jan 2016 15:06:52 +0000 X-Env-Sender: prvs=820a2b0fb=Ian.Campbell@citrix.com X-Msg-Ref: server-10.tower-206.messagelabs.com!1453302410!17029870!1 X-Originating-IP: [66.165.176.89] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n, received_headers: No Received headers X-StarScan-Received: X-StarScan-Version: 7.35.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 4649 invoked from network); 20 Jan 2016 15:06:51 -0000 Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89) by server-10.tower-206.messagelabs.com with RC4-SHA encrypted SMTP; 20 Jan 2016 15:06:51 -0000 X-IronPort-AV: E=Sophos;i="5.22,321,1449532800"; d="scan'208";a="326446382" From: Ian Campbell To: , Date: Wed, 20 Jan 2016 15:06:20 +0000 Message-ID: <1453302381-28692-2-git-send-email-ian.campbell@citrix.com> X-Mailer: git-send-email 2.6.1 In-Reply-To: <1453302359.26343.133.camel@citrix.com> References: <1453302359.26343.133.camel@citrix.com> MIME-Version: 1.0 X-DLP: MIA1 Cc: Ian Campbell Subject: [Xen-devel] [PATCH OSSTEST 2/3] Debian: erase-other-disks: erase partitions first X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org X-Spam-Status: No, score=-4.2 required=5.0 tests=BAYES_00, RCVD_IN_DNSWL_MED, UNPARSEABLE_RELAY autolearn=unavailable version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on mail.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP It seems that when sdX is zeroed there is some chance that sdX[0-9] will disappear before we get to them. When partman comes along and recreates the partitions it is likely that they will occupy the same disk space as before (since d-i's autopartition is deterministic), meaning that LVM will find the old PV headers again. This is in particular problematic on multi disk systems where we end up with an LV spanning sda5 and sdb. sdb is successfully erased here but sda5 is not, however LVM will still find the LV with missing PV, which is sufficient to trigger partman-lvm's checks for erasing devices which weren't explicitly listed, resulting in: !! ERROR: Unable to automatically remove LVM data Because the volume group(s) on the selected device also consist of physical volumes on other devices, it is not considered safe to remove its LVM data automatically. If you wish to use this device for partitioning, please remove its LVM data first. which cannot be preseeded around. If the autopartitioning is not deterministic (as might be the case when installing a different version of Debian to last time) then going from layout A -> B -> A' risks B (by chance) not destroying the headers created by A, meaning that A' will find them and suffer again from the problem above. This is handled via the use of ts-host-install-twice which will cause A' to run twice, i.e. A -> B -> (A' -> A''). In this case A' will fail as above, but A'' will startup seeing the partition layout put in place by A' (which matches A) and erase those partitions, leading to success later on. Also erase partitions for all sd/hd? not just sda+hda. Signed-off-by: Ian Campbell Acked-by: Ian Jackson --- Osstest/Debian.pm | 7 ++++--- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git a/Osstest/Debian.pm b/Osstest/Debian.pm index cf3486b..20f3de7 100644 --- a/Osstest/Debian.pm +++ b/Osstest/Debian.pm @@ -1057,12 +1057,13 @@ udevadm settle for sd in sd hd; do log "\${sd} devices present before: `echo /dev/\${sd}*`" for b in a b c d e f; do + for dev in /dev/\${sd}\${b}[0-9]; do + zero + done + dev=/dev/\${sd}\${b} zero done - for dev in /dev/\${sd}a[0-9]; do - zero - done udevadm settle log "\${sd} devices present after: `echo /dev/\${sd}*`" done