I wonder if anybody else have seen something like that.
I have a disk, a rather sizeable one, on which just was written a partition table and it looks like that:
Disk /dev/sdb: 250.0 GB, 250059350016 bytes 255 heads, 63 sectors/track, 30401 cylinders Units = cylinders of 16065 * 512 = 8225280 bytes
Device Boot Start End Blocks Id System /dev/sdb1 1 30401 244196001 83 Linux
No problems so far. Now I am trying to create a file system on this.
# mke2fs -j /dev/sdb1 mke2fs 1.39 (29-May-2006) /dev/sdb1 is apparently in use by the system; will not make a filesystem here!
??? Neither fuser, nor lsof, nor searches for anything else reveal why /dev/sdb1 could be "in use". OK, lets try to force the issue
# mke2fs -F -j /dev/sdb1 mke2fs 1.39 (29-May-2006) /dev/sdb1 is apparently in use by the system; mke2fs forced anyway. /dev/sdb1: Device or resource busy while setting up superblock
If I will try "strace" the above then I can only see:
stat("/dev/sdb1", {st_mode=S_IFBLK|0640, st_rdev=makedev(8, 17), ...}) = 0 open("/dev/sdb1", O_RDONLY|O_EXCL) = -1 EBUSY (Device or resource busy)
and I am not much wiser. It does not appear that anythying on initrd or udev is really holding to /dev/sdb or /dev/sdb1, or at least not in some obvious manner.
Actually I started trying to add that disk to LVM, and with no partitioning at all, but 'pvcreate' also refuses to do anythning because this disk is "busy" (while 'fdisk' was happy to oblidge).
If instead of rawhide I will boot some older distro on the same hardware then 'mke2fs' does not have problems with the same partition. Any ideas what is going on here? Makes adding a disk space to an installation somewhat "interesting".
Oh, this disk shows as /dev/sdb as this is a SATA device.
Michal
Michal Jaegermann wrote:
I wonder if anybody else have seen something like that.
...
# mke2fs -j /dev/sdb1 mke2fs 1.39 (29-May-2006) /dev/sdb1 is apparently in use by the system; will not make a filesystem here!
??? Neither fuser, nor lsof, nor searches for anything else reveal why /dev/sdb1 could be "in use". OK, lets try to force the issue
# mke2fs -F -j /dev/sdb1 mke2fs 1.39 (29-May-2006) /dev/sdb1 is apparently in use by the system; mke2fs forced anyway. /dev/sdb1: Device or resource busy while setting up superblock
take a look at https://www.redhat.com/archives/fedora-list/2006-September/msg02311.html
the last part !
On Sat, Sep 30, 2006 at 01:37:46AM +0200, ronald wrote:
Michal Jaegermann wrote:
??? Neither fuser, nor lsof, nor searches for anything else reveal why /dev/sdb1 could be "in use".
take a look at https://www.redhat.com/archives/fedora-list/2006-September/msg02311.html
the last part !
You really mean "Re: Setting hostname error, at startup" posting?
I have some doubts if this is really a dmraid issue as at some moment I had no dmraid in my initrd at all and this did not help. I my try that later again. I do not have any RAID on my test box.
Thanks, Michal
Michal Jaegermann wrote:
On Sat, Sep 30, 2006 at 01:37:46AM +0200, ronald wrote:
Michal Jaegermann wrote:
??? Neither fuser, nor lsof, nor searches for anything else reveal why /dev/sdb1 could be "in use".
take a look at https://www.redhat.com/archives/fedora-list/2006-September/msg02311.html
the last part !
You really mean "Re: Setting hostname error, at startup" posting?
the hostname error lead my to the solution of my problem to access my disk at the fc6t3 installation: https://www.redhat.com/archives/fedora-test-list/2006-September/msg00206.htm...
I have some doubts if this is really a dmraid issue as at some moment I had no dmraid in my initrd at all and this did not help. I my try that later again. I do not have any RAID on my test box.
my disk was not accessible caused by a membership in a raid system month ago, but still containing a label/signature from that. i could fdisk the drive, but couldn't not swap on it or delete/create partitions/file systems on it.
after reading your posting i remembered it, but if it's not your problem: okay ! it was just my idea...
On Sat, Sep 30, 2006 at 02:32:52AM +0200, ronald wrote:
my disk was not accessible caused by a membership in a raid system month ago, but still containing a label/signature from that. i could fdisk the drive, but couldn't not swap on it or delete/create partitions/file systems on it.
after reading your posting i remembered it, but if it's not your problem: okay ! it was just my idea...
Maybe it is after all. I do not know at this moment but I will try to re-check that. Not right away, though. Thanks! I know that I did check that condition when no dmraid was on initrd, but this was a side-effect of other issues and I did not pay a close attention if possibly there was some other point when this disk was "grabbed".
I am still somewhat baffled what makes that disk "busy" on a system level even if a dmraid track is correct.
Michal
On Sat, Sep 30, 2006 at 02:32:52AM +0200, ronald wrote:
Michal Jaegermann wrote:
??? Neither fuser, nor lsof, nor searches for anything else reveal why /dev/sdb1 could be "in use".
my disk was not accessible caused by a membership in a raid system month ago, but still containing a label/signature from that. i could fdisk the drive, but couldn't not swap on it or delete/create partitions/file systems on it.
You were right that problems were caused by dmraid. This is a "recycled" disk and I was not even really aware that in the past it was used in RAID. It turns out that mkinitrd adds such disk to dm map and after a boot every partition on such disk either "does not exist", even if it is there, or is "busy". All of that without a trace of a hint anywhere why there is a problem. Talk about the least surprise!
It is not enough to remove that signature with 'dmraid -r -E ...' from such disk. One has to rebuild mkinitrd as well before that disk becomes accesible. Does some piece of documentation even mentions such things? I am not aware so far.
Michal
Michal Jaegermann wrote:
On Sat, Sep 30, 2006 at 02:32:52AM +0200, ronald wrote:
Michal Jaegermann wrote:
??? Neither fuser, nor lsof, nor searches for anything else reveal why /dev/sdb1 could be "in use".
my disk was not accessible caused by a membership in a raid system month ago, but still containing a label/signature from that. i could fdisk the drive, but couldn't not swap on it or delete/create partitions/file systems on it.
You were right that problems were caused by dmraid. This is
good to hear !
a "recycled" disk and I was not even really aware that in the past it was used in RAID. It turns out that mkinitrd adds such disk to dm map and after a boot every partition on such disk either "does not exist", even if it is there, or is "busy". All of that without a trace of a hint anywhere why there is a problem. Talk about the least surprise!
It is not enough to remove that signature with 'dmraid -r -E ...' from such disk. One has to rebuild mkinitrd as well before that disk becomes accesible. Does some piece of documentation even mentions such things? I am not aware so far.
Michal
yes, documentation...?!,cause it's a tricky trap/feature. i would opt to *feature* -it does the correct things-, but first it's a trap...