• Welcome to Overclockers Forums! Join us to reply in threads, receive reduced ads, and to customize your site experience!

Unable to format drive - "is apparently in use by the system"

Overclockers is supported by our readers. When you click a link to make a purchase, we may earn a commission. Learn More.
If /dev/sdb1 is a physical volume, I believe you can use "pvremove /dev/sdb1" to remove it. If it is a logical volume, then "lvremove /dev/sdb1".

Been awhile since I messed around with LVM.
 
Code:
root@server1 [~]# pvremove /dev/sdb1
  PV /dev/sdb1 belongs to Volume Group vg so please use vgreduce first.
  (If you are certain you need pvremove, then confirm by using --force twice.)

Code:
root@server1 [~]# lvremove /dev/sdb1
  Volume group "sdb1" not found
  Skipping volume group sdb1
 
Try "dmsetup remove /dev/sdb1" to remove the LVM from a low level. You may have to remove the 1 off of sdb, depending on how it was setup.
 
Code:
root@server1 [~]# dmsetup remove /dev/sdb1
Device sdb1 not found
Command failed
root@server1 [~]# dmsetup remove /dev/sdb
Device sdb not found
Command failed
root@server1 [~]#

What I think may be going on here is the second drive might have been installed on a previous system and never formatted. The server is not local to me and I only have SSH access to it. Does that make any sense?
 
Sorry, I'm not sure what to suggest and I'm not in a position to provide much help at the moment.
 
Code:
root@server1 [~]# mdadm --detail /dev/md127
mdadm: cannot open /dev/md127: No such file or directory

Is this MD device supposed to be there?

ISTR running into similar difficulty (and having a phantom /dev/md127) and that error message when MD saw the signature for a partition at the beginning of the partition and IIRC confused it with an MD partition for the entire drive. I think that later versions of MD either had the option to or defaulted to moving the signature to another location within the partition. Or maybe it was at the end of the partition. :shrug: It's been a while but I do recall the device number (0b1111111 in binary) and the 'in use' diagnostic. My recollection was the solution was to zero out the MD signature. The command is
Code:
 mdadm --zero-superblock devicepath
And of course I accept no responsibility for your use or misuse of this command. If there is valuable data at hand, it's one of those that I want to type, stare at a moment and maybe get a cup of coffee before I hit return. ;)
 
Well there is data on my primary drive that I want to keep so I am scared that;

1. The LVM might be part of the primary drive where the OS is installed.
2. The LVM might actually BE the primary drive for whatever reason.

Here is a LVS command.

Code:
root@server1 [~]# lvs
  LV   VG   Attr       LSize   Pool Origin Data%  Move Log Cpy%Sync Convert
  root vg   -wi-ao---- 922.66g
  swap vg   -wi-a-----   7.84g
  tmp  vg   -wi-ao----   1.00g

There shouldn't be anything on the second hard drive, which should be the LVM that I am concerned with.

After skimming the man page of mdadm, I see that running --zero-superblock just rewrites the drive with nothing but 0s. I am pretty sure the drive(s) are not in any RAID array. I asked my server provider and they assured me my hardware isn't capable of hardware RAID and software RAID isn't being used.
 
After skimming the man page of mdadm, I see that running --zero-superblock just rewrites the drive with nothing but 0s. I am pretty sure the drive(s) are not in any RAID array. I asked my server provider and they assured me my hardware isn't capable of hardware RAID and software RAID isn't being used.
Yes, destructive command.

If you have no RAID then it seems like there is something on the drive that the RAID S/W thinks is a RAID partition. Since you are not using RAID, I would either disable the S/W that looks for RAID volumes on startup or even uninstall the RAID S/W. On my system the former are:

Code:
hbarta@olive:~$ ls  /etc/init.d/mdadm*
/etc/init.d/mdadm  /etc/init.d/mdadm-raid  /etc/init.d/mdadm-waitidle
hbarta@olive:~$

And the later:
Code:
hbarta@olive:~$ dpkg -l|grep mdadm
ii  mdadm                                 3.3-2                          amd64        tool to administer Linux MD arrays (software RAID)
hbarta@olive:~$

This is on a Mint system which is likely typical of any Debian derived distros.
 
What I think I had discovered is this.

The primary install is a LVM installed on the drive that I was thought was empty. This drive was the /dev/sdb drive. The empty drive is actually /dev/sda. Now why on Earth my datacenter would install the operating system on /dev/sdb and not /dev/sda is beyond me.

Now I am scared to reboot the server since I've already deleted the partition using fdisk. Pretty sure if I reboot it, the system will fail to boot.
 
I just want to say thank you to thideras! Your #9 post solved my headache I've hade for the past days trying to figure this out.

THANKS!
 
Hi all,

Thanks for this excellent write-up on that really nasty "cannot format" problem, which manifested as follows for me:

root@128:~# mkfs.ext4 /dev/sda6
mke2fs 1.42.9 (28-Dec-2013)
/dev/sda6 is apparently in use by the system; will not make a filesystem here!

For me, the problem (and solution) turned out to be something different not mentioned here yet:
- /dev/sda6 was not mounted (mount | grep sda6)
- I had not md drivers of any sort (ls /dev/md* ; mdadm --detail /dev/md0)
- I also had no swap activated.

After a lot of trial and error I tried this:

dmesg | grep sda6
[ 3.831755] sda: sda1 sda2 sda3 sda4 < sda5 sda6 sda7 >
[ 34.215409] EXT3-fs (sda6): using internal journal
[ 34.218922] EXT3-fs (sda6): mounted filesystem with ordered data mode

Guess what, Kernel was checking the filesystem even though nobody mounted it !
I suspect that the Kernel inspected each disk for file systems, and when an existing ext* was found it was checked.
Once that was isolated as the culprit the fix was to wipe the partition to keep the kernel from touching it (this was a 32GB disk):

dd if=/dev/zero of=/dev/sda6 bs=1024000 count=32000
reboot

And voila, after the reboot I could mkfs.ext4 /dev/sda6.

Hope this helps others ... (and PS, could an admin perhaps list the various different solutions on the top of this posting? There's now at least #9, #13 and my comment).
Thanks again !
Martin
 
Made an account just to say, thank you. Your information helped me save a USB drive I thought was toast. =)
 
Back