antix2usb fails: USB drive in use by the system

dirkd · posted: 2014-08-10 19:34

Since my last post I got quite good in making snapshots. I routinely end up with usable .iso files. However, the next step, transferring this iso file to a bootable usb often goes wrong. I found that essentially only one set of options works reliably when choosing the ext2 filesystem:

use full device
extlinux boot loader

Ideally, I would want to use only half of the USB drive for the antix system, and format the other half as a FAT32 partition, to make exchange of data with Windows more easy. However, if I do so, or if I choose the GRUB loader, the resulting USB key doesn't boot. What's worse: I cannot correct the mistake. The antix2usb script is no longer able to make a file system on that USB drive. It does wipe the partition table, but then issues the error message

Code: Select all

/dev/sdb1 is apparently in use by the system; will not make a filesystem here!

The error has nothing to do with data on the USB drive: I can use that same USB drive on another antix system, and there I can succesfully run the antix2usb script. Untill I make a mistake there, and then the same thing happens there. Also, I can mount another USB key as /dev/sdb1, then insert the malfunctioning USB key as /dev/sdc and use it without problems with the antix2usb script. So there must be some erroneous configuration file on the system itself, not on the USB key.

I have two Antix systems running now. One has malfunctioning /dev/sdb and /dev/sdc, the other one only /dev/sdc. The first one is a virtual drive. So I could presumably add a dummy hdd with 2 partitions, which would occupy sdb and sdc and then the USB key would get assigned to /dev/sdd. But I would like to solve the problem in a more fundamental way. What is particularly worrying is that the problem is inherited by the imaged system: so the 'child' antix systems also cannot use sdb and sdc in the antix2usb script.

I googled around for the error message. It's a known problem, but I didn't find a solution that seemed applicable here.

dolphin_oracle · posted: 2014-08-11 02:31

How big is your iso?

I have used unetbootin to make bootable usb's from snapshot isos. This lets me use the whole stick as fat32. but you are limited file sizes of less than 4gb that way. depending on how much you image, that could be a problem.

BitJam · posted: 2014-08-11 04:12

========= SCRAPER REMOVED AN EMBEDDED LINK HERE ===========
url was:"http://www.overclockers.com/forums/showthread.php?t=667317"
linktext was:"The first Google hit"
====================================
contains a fairly good answer in
========= SCRAPER REMOVED AN EMBEDDED LINK HERE ===========
url was:"http://www.overclockers.com/forums/showpost.php?p=6749336&postcount=9"
linktext was:"post 9"
====================================
:

So, if you find this page via Google and have this issue:

Make sure the partition isn't mounted.
Make sure the partition or drive is not in a RAID array.
Stop any MDADM devices that are not legitimate and remove them.
This should allow you do work with the drives.

It took me a long time to find this information and to piece it together, so I really hope this helps someone. If you are reading this issue and this information does not help, create an account and respond here.

Further down in the thread there are some posts that talk about LVM (Linux Volume Management) being the culprit. The author of post 9 zeroed out his entire drive and it still didn't work. Apparently at one time the system saw something on the drive that made it think it was part of a RAID. After that no changes to the drive itself would fix the problem. He/she had to use the RAID software (mdadm) in order to tell the system that the problem drive was not part of a RAID. There can be a similar problem with LVM. I have never heard of anything like this before.

dirkd · posted: 2014-08-11 10:01

dolphin_oracle wrote:How big is your iso?

I have used unetbootin to make bootable usb's from snapshot isos. This lets me use the whole stick as fat32. but you are limited file sizes of less than 4gb that way. depending on how much you image, that could be a problem.

My iso is only 3 Gb, so I'm pretty sure that unetbootin would do the trick. It's just that I would like to teach others how to transfer the iso to USB, and antix2usb is as easy to use as one could wish for. Also I would like to understand just what is goin on. There's also some other functionality that is affected: gparted has difficulties with /dev/sdb. It shows an unrecognised partition but refuses to delete it. Strangely I have been able to format it (using gpartes) as an ext2 filesystem. It became visible then in spacefm, but I still couldn't use it with antix2usb. Which maybe could be expected, since antix2usb starts cleaning the partitiontable right away.

@bitjam: that was not applicable here I think. As far as I can see mdadm is not even included in Antix. When I type 'mdadm' in a console, I get a 'command not found' error. Strangely also fdisk seems absent. I thought that was pretty much standard in linux?

BitJam · posted: 2014-08-11 11:41

dirkd wrote:@bitjam: that was not applicable here I think. As far as I can see mdadm is not even included in Antix. When I type 'mdadm' in a console, I get a 'command not found' error. Strangely also fdisk seems absent. I thought that was pretty much standard in linux?

LVM (Linux Volume Management) does come on antiX. Further down in the thread people say this is a possible culprit.

If you do have mdadm installed then it should be in the /sbin directory which is not on the default PATH for a normal user. You should become root first to see if you can run it. You could also try the"find" command but switching to root is faster:

Code: Select all

sudo su -
which mdadm

The sudo command will ask you for your *user* password. The fdisk program is also in /sbin so you will get"command not found" if your try to run it as a normal user. If you know where the program is then you can run it with the full path:

Code: Select all

sudo /sbin/fdisk

Another trick is to add /sbin and /usr/sbin to your PATH in your .bashrc file. Add this line:

Code: Select all

PATH="/sbin:/usr/sbin:$PATH"

To get the change to show up in a terminal window that is already open, run:

Code: Select all

source ~/.bashrc

An even easier way is to just start a new bash shell:

Code: Select all

bash

You will usually not be able to run programs that are in /sbin and in /usr/sbin as a normal user but by adding those directories to your PATH, you can use run them with sudo:

Code: Select all

sudo fdisk

I think the next version of antiX will have /sbin and /usr/sbin on the PATH OOTB. That's what I always do and it is what Dave always does and it is just an big cause of confusion not have them on the PATH.

HTH

fatmac · posted: 2014-08-11 12:57

dirkd wrote:

Code: Select all

/dev/sdb1 is apparently in use by the system; will not make a filesystem here!

Sounds like the system is auto mounting your pendrive, use a terminal and unmount it.
I have had this problem before, sometimes having to unmount several times.

SamK · posted: 2014-08-11 16:04

dirkd wrote:Ideally, I would want to use only half of the USB drive for the antix system, and format the other half as a FAT32 partition, to make exchange of data with Windows more easy.

I also see a lot of value in this. I made the suggestion way back that it would be a worthwhile addition, but it was not picked up. Since then it has been a case of creating it manually.
post26295.html?hilit=LINWIN%20ZONE#p26295

dirkd wrote:I found that essentially only one set of options works reliably when choosing the ext2 filesystem:

use full device

extlinux boot loader
...
...if I choose the GRUB loader, the resulting USB key doesn't boot.

I can't reproduce this.
Starting with an 8GB USB stick with two partitions (see below) and the system booted from antiX-13.2-Full-Stable-Live-CD, specifying GRUB and ext2, together with a partition size of 4GB, produced a bootable USB installation that works as expected.

Code: Select all

blkid -o list /dev/sdb[1,2]
device     fs_type label    mount point    UUID
-------------------------------------------------------------------------------
/dev/sdb1  vfat    LINWIN-ZONE (not mounted) EE84-F565
/dev/sdb2  ext2    LINUX-ZONE (not mounted) ea362fbd-ad21-494d-8e50-329bc3ca8727

sdb1=1GiB
sdb2=6.4GiB
antix2usb from main menu
ISO=antiX-13.2_386-full.iso
System Partition=4096MB (Full device not seleceted)
Format=ext2
Bootloader=GRUB
blkid -o list /dev/sdb[1,2]
device     fs_type label    mount point    UUID
-------------------------------------------------------------------------------
/dev/sdb1  ext2    antiXlive (not mounted) 2387c552-88f3-4903-9808-72c90cb0ae9a

dirkd wrote:but then issues the error message
Code: Select all
/dev/sdb1 is apparently in use by the system; will not make a filesystem here!

This is often seen, particularly on systems that use automounting upon plugging in and sticks that have multiple partitions.

I will offer a totally unsubstantiated guess. When the script was designed it inherited the working pattern of someone who worked extensively at the command line and conducted mounting predominately manually rather than automatically.

It is likely that a significant number of users routinely have their systems automount USB devices, and multiple partitions are not uncommon. Perhaps there is a usability gain to be obtained by having the script unmount all file systems on the stick and also offer to create multiple partitions/file systems.

BitJam · posted: 2014-08-11 21:02

@SamK, I agree with you that having a fat32 partition on a LiveUSB that is running from ext2/3/4 is an excellent idea. I am compiling a list of antix2usb change requests. I will add it to the list. I suggest using either ext3 or even ext4 (if the boot loader supports it) because the file system checks are so much faster and more robust. ISTM it is very easy to unplug a LiveUSB while it is still mounted. I think this triggers a file system check on the next boot.

Yes, some people suggest that a journaling filesystem will wear out a usb stick faster. I have not seen any hard evidence that backs this up. The journal usually records only meta-data.
========= SCRAPER REMOVED AN EMBEDDED LINK HERE ===========
url was:"http://rwmj.wordpress.com/2009/11/08/filesystem-metadata-overhead/"
linktext was:"this page"
====================================
says the meta-data is only a few percent of the actual data. If this is correct (it rings true to me) then adding a journal only decreases the life span by a few percent assuming there is some wear leveling.

dirkd · posted: 2014-08-11 21:14

Thank you all for your extensive feedback on my question.

@SamK: I'm a little confused. I start the santix2usb script from the antix control center. I've never seen the kind of output in the console that you show in your post. USB drives are indeed automounted, and for the purpose I have in mind, this should remain so. When I forget to dismount the targest USB, antix2usb issues a warning. I can then umount the target USB (I do so in spacefm) and proceed. I seem to remember that at one time I did produce a bootable USB with GRUB, but last time I tried I had two failures in a row. I also don't see how you could ever use a target USB key with more than one partition, since ALL data are removed from the stick.

By the way, that too is a mystery to me: if /dev/sdb1 is truly in use by the system, how can Antix remove the partitiontable? And after it has done so, it refuses to make a new filesystem?

@bitjam: In the meantime I found out that fdisk needs a sudo. I also found out that lvm2 is installed. I'll have to do some study though, before I can use that. I also tried to 'sudo apt-get install mdadm', but I couldn't. I got a message saying the package was absent from the repository (I use 'sid' btw).

dirkd · posted: 2014-08-12 12:41

OK, I may have found something. If I mount the target USB key and open mtab, I see the following in the entry for /dev/sdb1:

on the system where antix2usb fails there is an option 'errors=remount-ro'
on a system where antix2usb does make the filesystem the corresponding option is 'errors=continue'

I have the feeling that this may explain the different behaviour of the antix2usb script. Only thing is: mtab is generated automatically, and I don't know how to configure the entries the system makes in mtab. Any suggestions?

Thanks.

SamK · posted: 2014-08-12 13:18

dirkd wrote:I start the santix2usb script from the antix control center.

Ditto.

dirkd wrote:I've never seen the kind of output in the console that you show in your post.

Perhaps the meaning of that section is not as clear as I intended. It is meant to indicate the position before, during and after using antix2usb rather than indicate feedback from it.

The first blkid command was issued in a terminal. It shows the stick contains two partitions.

The antix2usb from main menu section shows the details entered into the antix2usb GUI.

The final blkid command was issued in a terminal. It shows the condition of the stick produced by antix2usb.

dirkd wrote:USB drives are indeed automounted, and for the purpose I have in mind, this should remain so.

I suspect this is representative of the way many (most?) users work with the Full versions of antiX, hence my comment that antix2usb will be improved by automatically unmounting file systems on the stick.

dirkd wrote:I also don't see how you could ever use a target USB key with more than one partition, since ALL data are removed from the stick.

In its current form, antix2usb is unable to produce a stick, with multiple partitions. This is confirmed by the before, during and after info. Also, have a look back at my earlier post in this topic. I mention that presently, it must be done manually.

SamK · posted: 2014-08-12 14:51

BitJam wrote:I suggest using either ext3 or even ext4...

Because dirkd reported issues with ext2 and GRUB they were used in a test to try and reproduce the reported behaviour.

Offering choice is at the heart of antiX, so offering ext2/3/4... is a good fit. To avoid taking this thread off topic I will perhaps post separately further ideas and suggestions for antix2usb.

dirkd · posted: 2014-08-12 15:41

Found the culprit!

Who or what is mounting my USB's? SpaceFM of course. But - bless spacefm! - that filemanager makes the mount process configurable! Under the menu /Devices/Settings/Mount Command I saw I was able to choose between no less than 4 different mount commands.

Default setting is

Code: Select all

/usr/bin/pmount %v

but changing that to

Code: Select all

/usr/bin/udevil mount -o %o %v

did the trick.

My USB's still automount, but when I look at the mtab file sdb1 is mounted with the option

Code: Select all

errors=continue

in stead of

Code: Select all

errors=remount-ro.

Here's my guess at what's going on. When antix2usb clears the partitiontable on the device /dev/sdb it generates some kind of error on the device. Then it gets remounted immediately in a read-only state, presumably again causing an error, since no partitions are present on the device. That's why the system thinks /dev/sdb1 is 'in use' by the system, and refuses to make a new filesystem. It's just a guess, I don't really understand much of what's going on behind the scenes. Also, at the start of the process /dev/sdb is unmounted, so the entry in mtab is not even there at that time.

I just finished a succesfull test using the whole device and choosing the ext2 boot loader. Next thing to try: using part of the device and GRUB.

dirkd · posted: 2014-08-12 21:07

Two final tests. No trouble anymore to run antix2usb, using only part of the target USB. That is: if I choose the extlinux bootloader.

If I use GRUB, the USB still won't boot (although antix2usb claims to have completed succesfully). When trying to boot I see two messages on the startup screen:

'GRUB 1.5'

'GRUB loading... please wait' (or something very similar)

and then the system hangs...

Maybe I'll look into it at a later time. For the moment I can live with the situation as it is.

BitJam · posted: 2014-08-12 22:50

1) select syslinux instead of grub. The files for grub aren't in the lastest iso files.

2) the worst thing about antix2usb is that it lies about completing successfully and hides all error messages. Look in /var/log/antix2usb.log to see if there are any error messages, and if so, to see what they are.