Clean up disks before recreating partitions/volumes/filesystems/...

[jsmeix]

Hereby I propose to let a "cleanupdisk" script run early
(i.e. before anything is done with the harddisk,
in particular before a "parted" command is run).

The purpose of the "cleanupdisk" script is to wipe any
possibly remainders of various kind of metadata information
from the harddisk that could belong to various higher layers
of storage objects.

Currently (cf. #540) "wipefs" is run in
130_include_filesystem_code.sh for each partition device node
before a filesystem is created on that partition device node.

But after I wrote #791 (comment) I noticed that running "wipefs" before filesystems are created is probably too late.

I had this "too late" problem already recognized in #540 (comment) (there "it failed for RHEL6 at the partitioning level because of old data of the MD level so that before partitioning the MD tool would have to be run to clean up old MD data") but unfortunately that had slipped my lossy mind :-(

See #791 (comment) for the reason why "wipefs" musts probably be run before anything is done with the harddisk, in particular before a "parted" command is run (excerpt):

For example if you re-use a harddisk that
had before LVM on it, it may happen that
after creating partitions from scatch on
that hsrddisk, udev may also trigger
to run LVM tools ...
When those LVM tools detect remaining
old/outdated LVM metadata information
on the harddisk, there could be arbitrarily
unexpected results (e.g. all of a sudden
LVM issues may get in your way regardless
that you only had called parted to create
partitions).

Here what I get in the ReaR recovery system
directly after login as root
on pristine new hardware
(where "pristine new hardware" is a new
from scratch created QEMU/KVM virtual
machine with full hardware virtualization):

 # ls -l /dev/sd*
brw-rw---- 1 root disk 8, 0 Mar 15 14:36 /dev/sda

# parted /dev/sda print
Error: /dev/sda: unrecognised disk label
Model: ATA QEMU HARDDISK (scsi)                                           
Disk /dev/sda: 21.5GB
Sector size (logical/physical): 512B/512B
Partition Table: unknown
Disk Flags: 

And now ( tada - surprise! - not really ;-)
what I get in the ReaR recovery system
directly after login as root
on same kind of a machine where I already
had done a "rear recover" some time before
(i.e. where a subsequent "rear recover" would run
on a system where the harddisk was already in use):

# ls -l /dev/sd*
brw-rw---- 1 root disk 8, 0 Mar 15 14:31 /dev/sda
brw-rw---- 1 root disk 8, 1 Mar 15 14:31 /dev/sda1
brw-rw---- 1 root disk 8, 2 Mar 15 14:31 /dev/sda2

# parted /dev/sda print
Model: ATA QEMU HARDDISK (scsi)
Disk /dev/sda: 21.5GB
Sector size (logical/physical): 512B/512B
Partition Table: msdos
Disk Flags: 

Number  Start   End     Size    Type     File system     Flags
 1      1049kB  1571MB  1570MB  primary  linux-swap(v1)  type=83
 2      1571MB  21.5GB  19.9GB  primary  ext4            boot, type=83

Accordingly I think ReaR should run something like

wipefs -a -f /dev/sda2
wipefs -a -f /dev/sda1
wipefs -a -f /dev/sda

to fully clean up the used harddisk before doing anything with it.

Regarding the '-f' option see #540 (comment)

[jsmeix]

@gdha @schlomo @thefrenchone @tbsky

I ask you all for feedback what you think about it.

[jsmeix]

What wipefs results in the rear recovery system
directly after login as root
on the above mentioned (second) machine
where the harddisk was already in use:

Welcome to Relax and Recover. Run "rear recover" to restore your system !

RESCUE f197:~ # ls -l /dev/sd*
brw-rw---- 1 root disk 8, 0 Mar 16 11:02 /dev/sda
brw-rw---- 1 root disk 8, 1 Mar 16 11:02 /dev/sda1
brw-rw---- 1 root disk 8, 2 Mar 16 11:02 /dev/sda2

RESCUE f197:~ # parted /dev/sda print
Model: ATA QEMU HARDDISK (scsi)
Disk /dev/sda: 21.5GB
Sector size (logical/physical): 512B/512B
Partition Table: msdos
Disk Flags: 
Number  Start   End     Size    Type     File system     Flags
 1      1049kB  1571MB  1570MB  primary  linux-swap(v1)  type=83
 2      1571MB  21.5GB  19.9GB  primary  ext4            boot, type=83

RESCUE f197:~ # wipefs -a -f /dev/sda2
/dev/sda2: 2 bytes were erased at offset 0x00000438 (ext4): 53 ef

RESCUE f197:~ # ls -l /dev/sd*
brw-rw---- 1 root disk 8, 0 Mar 16 11:42 /dev/sda
brw-rw---- 1 root disk 8, 1 Mar 16 11:02 /dev/sda1
brw-rw---- 1 root disk 8, 2 Mar 16 11:42 /dev/sda2

RESCUE f197:~ # parted /dev/sda print
Model: ATA QEMU HARDDISK (scsi)
Disk /dev/sda: 21.5GB
Sector size (logical/physical): 512B/512B
Partition Table: msdos
Disk Flags: 
Number  Start   End     Size    Type     File system     Flags
 1      1049kB  1571MB  1570MB  primary  linux-swap(v1)  type=83
 2      1571MB  21.5GB  19.9GB  primary                  boot, type=83

RESCUE f197:~ # wipefs -a -f /dev/sda1
/dev/sda1: 10 bytes were erased at offset 0x00000ff6 (swap): 53 57 41 50 53 50 41 43 45 32

RESCUE f197:~ # parted /dev/sda print
Model: ATA QEMU HARDDISK (scsi)
Disk /dev/sda: 21.5GB
Sector size (logical/physical): 512B/512B
Partition Table: msdos
Disk Flags: 
Number  Start   End     Size    Type     File system  Flags
 1      1049kB  1571MB  1570MB  primary               type=83
 2      1571MB  21.5GB  19.9GB  primary               boot, type=83

RESCUE f197:~ # ls -l /dev/sd*
brw-rw---- 1 root disk 8, 0 Mar 16 11:42 /dev/sda
brw-rw---- 1 root disk 8, 1 Mar 16 11:42 /dev/sda1
brw-rw---- 1 root disk 8, 2 Mar 16 11:42 /dev/sda2

RESCUE f197:~ # wipefs -a -f /dev/sda
/dev/sda: 2 bytes were erased at offset 0x000001fe (dos): 55 aa

RESCUE f197:~ # parted /dev/sda print
Error: /dev/sda: unrecognised disk label
Model: ATA QEMU HARDDISK (scsi)                                           
Disk /dev/sda: 21.5GB
Sector size (logical/physical): 512B/512B
Partition Table: unknown
Disk Flags: 

RESCUE f197:~ # ls -l /dev/sd*
brw-rw---- 1 root disk 8, 0 Mar 16 11:42 /dev/sda
brw-rw---- 1 root disk 8, 1 Mar 16 11:42 /dev/sda1
brw-rw---- 1 root disk 8, 2 Mar 16 11:42 /dev/sda2

RESCUE f197:~ # partprobe -s /dev/sda

RESCUE f197:~ # ls -l /dev/sd*
brw-rw---- 1 root disk 8, 0 Mar 16 11:47 /dev/sda
brw-rw---- 1 root disk 8, 1 Mar 16 11:42 /dev/sda1
brw-rw---- 1 root disk 8, 2 Mar 16 11:42 /dev/sda2

RESCUE f197:~ # parted /dev/sda mklabel msdos
Information: You may need to update /etc/fstab.

RESCUE f197:~ # ls -l /dev/sd*
brw-rw---- 1 root disk 8, 0 Mar 16 11:51 /dev/sda

RESCUE f197:~ # partprobe -s /dev/sda
/dev/sda: msdos partitions

RESCUE f197:~ # parted /dev/sda print
Model: ATA QEMU HARDDISK (scsi)
Disk /dev/sda: 21.5GB
Sector size (logical/physical): 512B/512B
Partition Table: msdos
Disk Flags: 
Number  Start  End  Size  Type  File system  Flags

RESCUE f197:~ # parted /dev/sda mklabel gpt
Warning: The existing disk label on /dev/sda will be destroyed
and all data on this disk will be lost.
Do you want to continue?
Yes/No? y                                                                 
Information: You may need to update /etc/fstab.

RESCUE f197:~ # parted /dev/sda print
Model: ATA QEMU HARDDISK (scsi)
Disk /dev/sda: 21.5GB
Sector size (logical/physical): 512B/512B
Partition Table: gpt
Disk Flags: 
Number  Start  End  Size  File system  Name  Flags

RESCUE f197:~ # ls -l /dev/sd*
brw-rw---- 1 root disk 8, 0 Mar 16 11:55 /dev/sda

Summary:

After wipefs the harddisk /dev/sda looks empty for parted
but nevertheless regardless of a partprobe call
the old/outdated partition device nodes (/dev/sda1and /dev/sda2)
do not go away.

To make the old/outdated partition device nodes go away
an explicit "parted /dev/sda mklabel" command is needed.

It seems to be fail-safe to set a hardcoded "msdos" dummy label
in such a "cleanupdisk" script via "parted /dev/... mklabel msdos"
to make old/outdated partition device nodes go away because
later the actual disk label (e.g. "gpt") will be set
in 10_include_partition_code.sh via

parted -s $device mklabel $label >&2

[thefrenchone]

wipefs would be great to have run earlier. It's code generated from 10_include_partition_code.sh that would occasionally fail or require extra time for me. Just removing LVM information was usually enough.

At the moment I can't test this but hopefully soon I'll be able to. I'll try adding the wipefs command to clear the disk earlier.

[jsmeix]

@mattihautameki
I remembered your issue #649 that also seems to be related to disk cleanup (cf. #649 (comment)) so that this issue here could be also of interest for you.

[jsmeix]

For the fun of it:
It seems SUSE implements a new parted option --wipesignatures,
see
https://bugzilla.opensuse.org/show_bug.cgi?id=980834

For the current sources see the
"parted-implement-wipesignatures-option.patch" at
https://build.opensuse.org/package/show/Base:System/parted

But it seems that fails curently in the same way
as the initial comment in #793 (comment)

It seems currently "everybody" has issues with "udev vs. parted",
cf. #791 (comment)

[jsmeix]

Because the more I learn about it
the more I get confused how to make it working
I postpone this issue to any later unspecified
"future rear version".

[jsmeix]

An addedum regarding a higher stack of storage objects
in particular regarding MD devices (aka Linux Software RAID):

One can try to remove mdadm superblocks from hardrives by

mdadm --zero-superblock /dev/sd{a,b,c,d}

to avoid hdds to be detected as mdadm devices.

Ideally only calling the generic "wipefs" tool
would do all what is needed but perhaps
we may have to also call the individual tools
of each particular higher level storage object
to really clean up everything properly.

[jsmeix]

FYI regarding
"How do I delete a RAID volume that was created with mdadm?"

One may have a look at
https://forums.opensuse.org/showthread.php/489778-How-do-I-delete-a-RAID-volume-that-was-created-with-mdadm

Key steps:

• Stop the RAID

  # mdadm --stop /dev/md0
  

• Remove the RAID signatures from every (!) part of the RAID

  # mdadm --zero-superblock /dev/sd??
  

  It should also work to use "wipefs".

[gdha]

@jsmeix perhaps shred utility could also be useful (http://www.computerhope.com/unix/shred.htm). I noticed that RH engineers are using this command to wipe a disk (before doing rear recover test) - e.g. shred /dev/sda

[schlomo]

Let's just make sure that we don't touch the hard disks before

1. The user actually starts rear recover.

2. The verify stage was run successfully.

[jsmeix]

I think to have such a "cleanupdisk" script behave
in compliance with how "rear recover" currently works
the script must not work directly on the harddisk(s)
but instead output commands that clean up disks
into the LAYOUT_CODE script (i.e. diskrestore.sh).

Such an early "cleanupdisk" script would have to run
before scripts like
layout/prepare/GNU/Linux/100_include_partition_code.sh
...
layout/prepare/GNU/Linux/130_include_filesystem_code.sh
to get the disk cleanup commands are at the beinning
of the diskrestore.sh script, cf. my initial
#799 (comment)

... "wipefs" musts probably be run before anything
is done with the harddisk, in particular before
a "parted" command is run ...

[schlomo]

@jsmeix very good point. Yes, of course the cleanup stuff should be added to the beginning of the diskrestore.sh and not run directly.

[gdha]

As the PR #2514 is in progress we better re-open this issue

[github-actions]

Stale issue message

[jsmeix]

I like to merge #2514
tomorrow afternoon unless there are objections
to have at least a first step that can be used in ReaR.
Then we can improve things as needed step by step.

[jsmeix]

With #2514 merged
disks can be wiped before recreating partitions/volumes/filesystems/...

There is now the new DISKS_TO_BE_WIPED in default.conf
and for details and some background information see
usr/share/rear/layout/recreate/default/README.wipe_disks
https://github.com/rear/rear/blob/master/usr/share/rear/layout/recreate/default/README.wipe_disks

This is currently new and experimental functionality so that
currently by default via DISKS_TO_BE_WIPED='false' no disk is wiped
to avoid possible regressions until this new feature was more tested
by interested users via explicit DISKS_TO_BE_WIPED='' in local.conf

[jsmeix]

Phew!
I created this issue on Mar 15 2016
and closed it today on Mar 17 2021
which is 5 years and two days later
and it is still not completely solved, cf.
#2514 (comment)