Public bug reported:
Working on a new app to do full-disk backup and recovery, I'm having
trouble with clearing existing partitions on a target drive. The man
page for wipefs says that wipefs -a <drive> should wipe all partitions
on the drive, but I have a situation where it has a strange result:
lsblk reports one partition still remains.
Steps to reproduce:
- zero the first and last megabytes on the target drive
- partition the drive with 'sfdisk /dev/drive <sf-dump
where <sfdump> is the name of the file attached to this report
- wipefs -a <drive>
- lsblk
What I see at this point is a drive with one partition -- oddly 1,3,4,5
and 6 have disappeared, but partition 2 remains. This persists even
after doing 'partprobe'.
The problem seems to be that something in the label looks like an atari
disk label(!!!), and 'wipefs -a' is not clearing it.
I can get around the problem by using the --force parameter so: 'wipefs
-f -a', and it reports an "atari" signature that was hiding in my DOS
MBR somehow. Since I had zeroed the entire disk label area, this has to
be a kind of mirage created by a specific configuration of bits.
This behavior is a sneaky trap. It took me a very long time to stumble
upon the cause and the fix I've just described. It seems best to me if
wipefs can detect this issue and clear any odd artifacts like this.
ProblemType: Bug
DistroRelease: Ubuntu 20.04
Package: util-linux 2.34-0.1ubuntu9.3
Uname: Linux 5.18.10-76051810-generic x86_64
NonfreeKernelModules: nvidia_modeset nvidia
ApportVersion: 2.20.11-0ubuntu27.24
Architecture: amd64
CasperMD5CheckResult: skip
Date: Mon Jun 19 11:19:03 2023
SourcePackage: util-linux
UpgradeStatus: Upgraded to focal on 2022-05-13 (402 days ago)
modified.conffile..etc.default.apport:
# set this to 0 to disable apport, or to 1 to enable it
# you can temporarily override this with
# sudo service apport start force_start=1
enabled=0
mtime.conffile..etc.default.apport: 2017-05-02T14:12:29.908000
** Affects: util-linux (Ubuntu)
Importance: Undecided
Status: New
** Tags: amd64 apport-bug focal third-party-packages
** Attachment added: "sfdisk --dump output"
https://bugs.launchpad.net/bugs/2024398/+attachment/5680804/+files/camelot-20210218-sda-dump.txt
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to util-linux in Ubuntu.
https://bugs.launchpad.net/bugs/2024398
Title:
wipefs not working as documented
Status in util-linux package in Ubuntu:
New
Bug description:
Working on a new app to do full-disk backup and recovery, I'm having
trouble with clearing existing partitions on a target drive. The man
page for wipefs says that wipefs -a <drive> should wipe all partitions
on the drive, but I have a situation where it has a strange result:
lsblk reports one partition still remains.
Steps to reproduce:
- zero the first and last megabytes on the target drive
- partition the drive with 'sfdisk /dev/drive <sf-dump
where <sfdump> is the name of the file attached to this report
- wipefs -a <drive>
- lsblk
What I see at this point is a drive with one partition -- oddly
1,3,4,5 and 6 have disappeared, but partition 2 remains. This
persists even after doing 'partprobe'.
The problem seems to be that something in the label looks like an
atari disk label(!!!), and 'wipefs -a' is not clearing it.
I can get around the problem by using the --force parameter so:
'wipefs -f -a', and it reports an "atari" signature that was hiding in
my DOS MBR somehow. Since I had zeroed the entire disk label area,
this has to be a kind of mirage created by a specific configuration of
bits.
This behavior is a sneaky trap. It took me a very long time to
stumble upon the cause and the fix I've just described. It seems
best to me if wipefs can detect this issue and clear any odd artifacts
like this.
ProblemType: Bug
DistroRelease: Ubuntu 20.04
Package: util-linux 2.34-0.1ubuntu9.3
Uname: Linux 5.18.10-76051810-generic x86_64
NonfreeKernelModules: nvidia_modeset nvidia
ApportVersion: 2.20.11-0ubuntu27.24
Architecture: amd64
CasperMD5CheckResult: skip
Date: Mon Jun 19 11:19:03 2023
SourcePackage: util-linux
UpgradeStatus: Upgraded to focal on 2022-05-13 (402 days ago)
modified.conffile..etc.default.apport:
# set this to 0 to disable apport, or to 1 to enable it
# you can temporarily override this with
# sudo service apport start force_start=1
enabled=0
mtime.conffile..etc.default.apport: 2017-05-02T14:12:29.908000
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/util-linux/+bug/2024398/+subscriptions
--
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help : https://help.launchpad.net/ListHelp
