I am using macOS Mojave 10.14.6. I am trying to re-format my USB to FAT.
I am getting this error MBRFormat does not appear to be a valid volume name for its file system. What does it mean and how to fix it?
Why does file system says "None"?
root$ diskutil info /dev/disk5
Device Identifier: disk5
Device Node: /dev/disk5
Whole: Yes
Part of Whole: disk5
Device / Media Name: Cruzer Facet
Volume Name: Not applicable (no file system)
Mounted: Not applicable (no file system)
File System: None
Content (IOContent): GUID_partition_scheme
OS Can Be Installed: No
Media Type: Generic
Protocol: USB
SMART Status: Not Supported
Disk Size: 8.0 GB (8004304896 Bytes) (exactly 15633408 512-Byte-Units)
Device Block Size: 512 Bytes
Read-Only Media: No
Read-Only Volume: Not applicable (no file system)
Device Location: External
Removable Media: Removable
Media Removal: Software-Activated
Virtual: No
root$ sudo diskutil eraseDisk FAT32 MBRFormat /dev/disk5
Password:
MBRFormat does not appear to be a valid volume name for its file system
Is it already FAT formatted?
/dev/disk5 (external, physical):
#: TYPE NAME SIZE IDENTIFIER
0: GUID_partition_scheme *8.0 GB disk5
1: Microsoft Basic Data MyDrive 7.8 GB disk5s2
THE_NAME should be written in uppercase.
sudo diskutil eraseDisk FAT32 "THE_NAME" MBRFormat /dev/disk5
You are missing a (new) volume name after the format
sudo diskutil eraseDisk FAT32 THE_NAME MBRFormat /dev/disk5
For further info about its usage:
sudo diskutil eraseDisk
Usage: diskutil eraseDisk format name [APM[Format]|MBR[Format]|GPT[Format]]
MountPoint|DiskIdentifier|DeviceNode
And don't change THE_NAME this is an actual command and it so mandatory, I guess
Related
I'm running 10.13.4 macos.
I created an encrypted hfs usb stick with the password test. After that I unmounted it and removed it from the Macbook. Then I plugged it in again and did NOT enter the password, so that the block devices appear in the device tree.
diskutil cs list delivers
+-- Logical Volume Group FDFF1CAB-A9AC-40E8-8251-FAC5C592296B
=========================================================
Name: Ohne Titel
Status: Online
Size: 3588186112 B (3.6 GB)
Free Space: 14635008 B (14.6 MB)
|
+-< Physical Volume 0DB883F2-4AE3-4D13-AE97-5EF2E4EC28F8
| ----------------------------------------------------
| Index: 0
| Disk: disk4s2
| Status: Online
| Size: 3588186112 B (3.6 GB)
|
+-> Logical Volume Family 1865CD0A-BE9B-490A-8E02-A59498CAB371
----------------------------------------------------------
Encryption Type: AES-XTS
Encryption Status: Locked
Conversion Status: Complete
High Level Queries: Fully Secure
| Passphrase Required
| Accepts New Users
| Has Visible Users
| Has Volume Key
|
+-> Logical Volume 53D7E549-5445-4509-8E0A-2FCB9DC59E4C
---------------------------------------------------
Disk: -none-
Status: Locked
Size (Total): 3221225472 B (3.2 GB)
Revertible: No
LV Name: Ohne Titel
Content Hint: Apple_HFSX
So I tried the following:
diskutil coreStorage unlockVolume 53D7E549-5445-4509-8E0A-2FCB9DC59E4C
Passphrase:
Unable to register passphrase
It asks for the passphrase and I enter the correct one, but I get that error.
diskutil list shows:
/dev/disk4 (external, physical):
#: TYPE NAME SIZE IDENTIFIER
0: GUID_partition_scheme *3.9 GB disk4
1: EFI EFI 209.7 MB disk4s1
2: Apple_CoreStorage Ohne Titel 3.6 GB disk4s2
3: Apple_Boot Boot OS X 134.2 MB disk4s3
so I tried:
sudo hdiutil attach /dev/disk4s2
which then opens the gui where I can type in my password, if I do that it works.
Which is nice but I want a command line only option. Any hints how to do this?
Ok I figured this out I needed to use sudo diskutil coreStorage unlockVolume 53D7E549-5445-4509-8E0A-2FCB9DC59E4C because diskutil seems to silently fail if it is not called with root privileges.
I'm attempting to rebuild a development vm using the debian/stretch64 box (i.e. Debian 9). I'm using Vagrant 2.0.2, with VirtualBox 5.2.6 on MacOS Sierra 10.12.6).
In my Vagrantfile I've specified a 30GB disk:
config.disksize.size = "30GB"
Virtual Media Manager (File menu in VirtualBox) shows the "virtual size" (capacity) of the stretch.vdi as 30GB. VBoxManage showhdinfo "stretch.vdi" also gives me the same information and indicates it's a dynamic default (i.e. resizable) disk, unlike .vmdk.
However, Debian reports a much smaller file system:
/dev/sda1 8.7G 8.7G 0 100% /
(it did have some space, but rsyncing a large shared folder on boot keeps filling it up).
Before it was full:
I ran sudo cfdisk /dev/sda and found the volume was reporting 20.1G free space and only 8.7G on /dev/sda1.
I also did apt-get install lvm2 so I would have the tools with which to manage volumes.
I then used fdisk (not the curses version) to reconfigure the partitions (i.e. I deleted them all, made the first one 29G and added an extended 1G partition with the 'type' set to Linux swap).
Although I saw the message "Re-reading the partition table failed. Device or resource busy.", after a reboot the cfdisk /dev/sda output all looked correct:
Device Boot Start End Sectors Size Id Type
>> /dev/sda1 2048 60819455 60817408 29G 83 Linux
/dev/sda2 60819456 62914559 2095104 1023M 5 Extended
└─/dev/sda5 60821504 62914559 2093056 1022M 82 Linux swap / Solaris
Still however, df returns:
/dev/sda1 8.7G 8.7G 0 100% /
Various tutorials mention pvcreate and pvresize, however for the latter I get:
sudo pvresize /dev/sda
Failed to find physical volume "/dev/sda".
0 physical volume(s) resized / 0 physical volume(s) not resized
Here's my complete fdisk -l output:
Disk /dev/sda: 30 GiB, 32212254720 bytes, 62914560 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0xe133a040
Device Boot Start End Sectors Size Id Type
/dev/sda1 2048 60819455 60817408 29G 83 Linux
/dev/sda2 60819456 62914559 2095104 1023M 5 Extended
/dev/sda5 60821504 62914559 2093056 1022M 82 Linux swap / Solaris
What else should I be doing to get Debian to see the full 29G?
Fixed simply with:
sudo resize2fs /dev/sda1
Now I have:
/dev/sda1 29G 8.7G 19G 32% /
Which I found in this answer
(Have voted to close my own question).
Since MacOS 10.13 I have the following problem.
/usr/bin/hdiutil attach "target/MyDrive-tmp.dmg" -mountroot /tmp
/dev/disk3 GUID_partition_scheme
/dev/disk3s1 Apple_APFS
/dev/disk4 EF57347C-0000-11AA-AA11-0030654
/dev/disk4s1 41504653-0000-11AA-AA11-0030654 /private/tmp/MyDrive
/usr/bin/hdiutil detach -force -debug "/tmp/MyDrive" or diskutil eject "/tmp/MyDrive"
process_detach: entry with "/tmp/MyDrive"
util_verify_dev_entry: entry with "disk4s1".
process_detach_deventry: about to unmount_and_eject disk4s1
unmount_and_eject(disk4s1)
LetDIDriverSettleDown: calling IOServiceWaitQuiet...
DI_kextWaitQuiet: about to call IOServiceWaitQuiet...
DI_kextWaitQuiet: IOServiceWaitQuiet took 0.000005 seconds
LetDiskImageDriverSettleDown: wait took 0.000066 seconds
_unmountCallback: disk4
"disk4" unmounted.
"disk4" ejected.
/usr/bin/hdiutil convert "target/MyDrive-tmp.dmg" -format UDZO -o "target/MyDrive.dmg" -debug
DIIsInitialized: returning YES
DIIsInitialized: returning YES
DIBackingStoreNewWithCFURL: entry with
file:///Users/xxxx/Documents/git/Midi%20Automator/Midi%20Automator/target/MyDrive-tmp.dmg
writeable: false
DIBackingStoreInstantiatorProbe: entry
file:///Users/xxxx/Documents/git/Midi%20Automator/Midi%20Automator/target/MyDrive-tmp.dmg
writeable: false
DIBackingStoreInstantiatorProbe: probing interface 0 CBSDBackingStore
CBSDBackingStore::newProbe score 100 for
file:///Users/xxxx/Documents/git/Midi%20Automator/Midi%20Automator/target/MyDrive-tmp.dmg
DIBackingStoreInstantiatorProbe: interface 0, score 100, CBSDBackingStore
DIBackingStoreInstantiatorProbe: probing interface 1 CBundleBackingStore
CBundleBackingStore::newProbe score -1000 for
file:///Users/xxxx/Documents/git/Midi%20Automator/Midi%20Automator/target/MyDrive-tmp.dmg
DIBackingStoreInstantiatorProbe: interface 1, score -1000,
CBundleBackingStore
DIBackingStoreInstantiatorProbe: probing interface 2 CRAMBackingStore
CRAMBackingStore::probe: scheme "file": not ram: or ramdisk: scheme.
CRAMBackingStore::probe: score -1000 for
file:///Users/xxxx/Documents/git/Midi%20Automator/Midi%20Automator/target/MyDrive-tmp.dmg
DIBackingStoreInstantiatorProbe: interface 2, score -1000, CRAMBackingStore
DIBackingStoreInstantiatorProbe: probing interface 3 CCarbonBackingStore
CCarbonBackingStore::newProbe: setting initial rval to +100
CCarbonBackingStore::newProbe score 100 for
file:///Users/xxxx/Documents/git/Midi%20Automator/Midi%20Automator/target/MyDrive-tmp.dmg
DIBackingStoreInstantiatorProbe: interface 3, score 100,
CCarbonBackingStore
DIBackingStoreInstantiatorProbe: probing interface 4 CDevBackingStore
CDevBackingStore::newProbe: not /dev/disk or /dev/rdisk (/Users/xxxx/Documents/git/Midi Automator/Midi Automator/target/MyDrive-tmp.dmg).CDevBackingStore::newProbe score -1000 for file:///Users/aguelle/Documents/git/Midi%20Automator/Midi%20Automator/target/MyDrive-tmp.dmg
DIBackingStoreInstantiatorProbe: interface 4, score -1000, CDevBackingStore
DIBackingStoreInstantiatorProbe: probing interface 5 CCURLBackingStore
CCURLBackingStore::probe: scheme is: file
CCURLBackingStore::probe: not recognized URL scheme.
CCURLBackingStore::probe: score -1000 for
file:///Users/xxxx/Documents/git/Midi%20Automator/Midi%20Automator/target/MyDrive-tmp.dmg
DIBackingStoreInstantiatorProbe: interface 5, score -1000, CCURLBackingStore
DIBackingStoreInstantiatorProbe: probing interface 6 CVectoredBackingStore
CVectoredBackingStore::newProbe not "vectored" scheme.
CVectoredBackingStore::newProbe score -1000 for file:///Users/xxxx/Documents/git/Midi%20Automator/Midi%20Automator/target/MyDrive-tmp.dmg
DIBackingStoreInstantiatorProbe: interface 6, score -1000,
CVectoredBackingStore
DIBackingStoreInstantiatorProbe: selecting CBSDBackingStore
DIBackingStoreNewWithCFURL: CBSDBackingStore
CBSDBackingStore::setPermission: opening /Users/xxxx/Documents/git/Midi
Automator/Midi Automator/target/MIDI Automator-tmp.dmg
CBSDBackingStore::OpenLockFriendly: mapping flags 0x00000000 -> 0x00000014 (locks are MANDATORY)
CBSDBackingStore:OpenLockFriendly: could not open with lock 35
DIBackingStoreNewWithCFURL: instantiator returned 35
DIBackingStoreNewWithCFURL: returning 35
DIResolveURLToBackingStore: unable to resolve to any backing store class. 35.
DIResolveURLToDiskImage: resolving backing store/file encoding failed. 35.
convert: unable to recognize "target/MyDrive-tmp.dmg":
resource temporarily unavailable.hdiutil: convert: result: 35`
/usr/bin/hdiutil attach "target/MyDrive-tmp.dmg" -mountroot /tmp
Eject MyDrive via mouse click in Finder
/usr/bin/hdiutil convert "target/MyDrive-tmp.dmg" -format UDZO -o "target/MyDrive.dmg"
-> Result: Conversion worked fine
So what is the difference between hdiutil detach, diskutil eject and ejecting from Finder?
Analysis:
lsof [device] gives no output as the device is not left after hdiutil detach at least mount shows none.
diskutil info "disk4s1" or diskutil info /tmp/MyDrive:
Device Identifier: disk4s1
Device Node: /dev/disk4s1
Whole: No
Part of Whole: disk4
Volume Name: MyDrive
Mounted: Yes
Mount Point: /private/tmp/MyDrive
Partition Type: 41504653-0000-11AA-AA11-00306543ECAC
File System Personality: APFS
Type (Bundle): apfs
Name (User Visible): APFS
Owners: Disabled
OS Can Be Installed: Yes
Media Type: Generic
Protocol: Disk Image
SMART Status: Not Supported
Volume UUID: A3EE0B42-A021-47AA-B424-E494B75049D3
Disk / Partition UUID: A3EE0B42-A021-47AA-B424-E494B75049D3
Disk Size: 212.5 MB (212471808 Bytes) (exactly 414984 512-Byte-Units)
Device Block Size: 4096 Bytes
Volume Total Space: 212.5 MB (212471808 Bytes) (exactly 414984 512-Byte-Units)
Volume Used Space: 184.7 MB (184709120 Bytes) (exactly 360760 512-Byte-Units) (86.9%)
Volume Available Space: 27.8 MB (27762688 Bytes) (exactly 54224 512-Byte-Units) (13.1%)
Allocation Block Size: 4096 Bytes
Read-Only Media: No
Read-Only Volume: No
Device Location: External
Removable Media: Removable
Media Removal: Software-Activated
hdiutil is really for working with disk images just as you are doing. The eject in finder is essentially diskutil eject [device]. hdutil detach is to "detach a disk image and terminate any associated process" (from the man page). Where diskutil is for "manipulating the structure of of local disks" (from the man page). Functionally, hdiutil detach is the same as diskutil eject. How it works though depends on if Disk Arbitration is running.
Disk Arbitration is framework and is in process diskarbitrationd that gets started by launchd and is always on by default. It handles the mounting and unmounting of disks attached via USB, Firewire, Thunderbolt, ect.
According to the man page on hdutil, when Disk Arbitration is running. hdutil detach will use it to unmount any file systems and detach the image. But if diskarbitrationd is not running then it will try and unmount filesystems and detach the image directly with a system call to ioctl. I don't recall for certain if diskutil -eject uses the Disk Arbitration framework but I want to say that it does.
It might be interesting to try and figure out why you getting that error. It typically means that exclusive access was not obtainable. You might experiment with lsof [device] This will show all the ope files and PIDs and lot more for the device, and this can maybe give you clues as to what is giving the [EBUSY] error (Resource Temporarily Unavailable). You can use mount with no argument to list all the devices and mount points if you don't know what device it is. I believe that you can also do lsof [mount/point]. The man page for lsof is your friend, and it is very long.
Another diagnostic is to use the -verbose option with hdiutil. It is available with all verbs. So, /usr/bin/hdiutil -verbose convert "target/MyDrive-tmp.dmg" -format UDZO -o "target/MyDrive.dmg" might provide some enlightenment.
And yet another possible source of clues would to have have an additional Terminal.app window open with the command diskutil activity running when you try the steps that cause the error. This command continuously reports on all Disk Arbitration framework activity. Ctrl-C to stop the process.
You have a workaround that is working for you so maybe looking into why it is giving the error isn't important or interesting to you. Also, if you don't want to use Finder you can always use diskutil eject [device] from the terminal. I have noticed a lot of things that are not quite right since I 'upgraded' to High Sierra and based on blogs around the net, it seems Apple is breaking things in the name of security and their new filesystem. I doubt in this case it is security related but I wouldn't be surprised if they introduced a bug altering commands and frameworks to work with APFS.
I also observed the problem that on newer OS X versions after hdiutil detach the DMG was still occupied by diskimage-helper and I could not do hdiutil convert due to the error message you got.
My solution simply was to copy the source file first, because that works without problem and then do the convert on the copy. This works without problems for me so far.
#Angelo Thank you for the insight:
So it is a problem with APFS. Creating the image with ´/usr/bin/hdiutil create -srcfolder "target/MyApp.app" -volname "MyApp" -ov "target/MyDrive-tmp.dmg" -fs HFS+ -format UDRW´ works like a charm and solves my problem. –
Angelo Berlin
In High Sierra (10.13.6), the additional argument, -fs HFS+ resolved my (and same) issue described here.
Details:
hdiutil create foo.dmg -srcfolder junk -format UDRW -size 1.1M -volname foobar
hdiutil attach foo.dmg -readwrite
hdiutil detach /Volumes/foobar
hdiutil convert foo.dmg -format UDZO -o fooConverted.dmg -imagekey zlib-level=9
hdiutil: convert failed - Resource temporarily unavailable
No joy. Same as everyone else.
But create and specify the filesystem with -fs...
hdiutil create foo.dmg -srcfolder junk -format UDRW -size 1.1M -volname foobar **-fs HFS+** -ov
hdiutil attach foo.dmg -readwrite
hdiutil detach /Volumes/foobar
hdiutil convert foo.dmg -format UDZO -o fooConverted.dmg -imagekey zlib-level=9 -ov
created: /Users/mjo/Documents/Code/bitcoin/bitcoin/fooConverted.dmg
This works like a champ! or as stated above, a charm.
Last, I tried the sequence of hdiutil commands without -fs HFS+ on Big Sur. All's good. Clearly an (old) issue with High Sierra.
Today I started getting errors on simple operations, like creating small files in vim, the bash completion started to complain as well.
Here is the result of df -h :
vagrant#machine:/vagrant$ df -h
Filesystem Size Used Avail Use% Mounted on
/dev/sda1 40G 38G 249M 100% /
none 4.0K 0 4.0K 0% /sys/fs/cgroup
udev 2.0G 12K 2.0G 1% /dev
tmpfs 396M 396K 395M 1% /run
none 5.0M 0 5.0M 0% /run/lock
none 2.0G 0 2.0G 0% /run/shm
none 100M 0 100M 0% /run/user
overflow 1.0M 148K 876K 15% /tmp
192.168.50.1:/Users/nha/repo/assets 233G 141G 93G 61% /var/www/assets
vagrant 233G 141G 93G 61% /vagrant
So apparently / doesn`t have space anymore ? Isn't it weird since I have space in the other filesystems (or am I misreading something) ?
How do I get more space on my vm ?
Even though you have space on your Guest OS, the VM is limited.There are couple of steps required in order to increase the size of your disk:
first, vagrant haltto close your VM
resize disk
VBoxManage clonehd box-disk1.vmdk box-disk1.vdi --format vdi
VBoxManage modifyhd box-disk1.vdi --resize 50000
start Virtual box and change configuration of the VM to associate the new disk
use fdisk to resize disk
you need to create a new partition with the new space and allocate it, so first start the VM and logged on as super user
vagrant up && vagrant ssh
su -
the command (as illustrated from my instance) are
[root#oracle ~]# fdisk /dev/sda
WARNING: DOS-compatible mode is deprecated. It's strongly recommended to
switch off the mode (command 'c') and change display units to
sectors (command 'u').
Command (m for help): p
Disk /dev/sda: 52.4 GB, 52428800000 bytes
255 heads, 63 sectors/track, 6374 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x00041a53
Device Boot Start End Blocks Id System
/dev/sda1 * 1 39 307200 83 Linux
Partition 1 does not end on cylinder boundary.
/dev/sda2 39 2611 20663296 8e Linux LVM
Command (m for help): n
Command action
e extended
p primary partition (1-4)
p
Partition number (1-4): 3
First cylinder (2611-6374, default 2611):
Using default value 2611
Last cylinder, +cylinders or +size{K,M,G} (2611-6374, default 6374):
Using default value 6374
Command (m for help): w
The partition table has been altered!
Calling ioctl() to re-read partition table.
WARNING: Re-reading the partition table failed with error 16: Device or resource busy.
The kernel still uses the old table. The new table will be used at
the next reboot or after you run partprobe(8) or kpartx(8)
Syncing disks.
[root#oracle ~]#
note you might need to change /dev/sda compare to your configuration
create a new partition (again logged on as super user su -)
su -
[root#oracle ~]# pvs
PV VG Fmt Attr PSize PFree
/dev/sda2 linux lvm2 a-- 19.70g 0
[root#oracle ~]# pvcreate /dev/sda3
Physical volume "/dev/sda3" successfully created
[root#oracle ~]# pvs
PV VG Fmt Attr PSize PFree
/dev/sda2 linux lvm2 a-- 19.70g 0
/dev/sda3 lvm2 a-- 28.83g 28.83g
[root#oracle ~]# vgextend linux /dev/sda3
Volume group "linux" successfully extended
[root#oracle ~]# lvextend -l +100%FREE /dev/linux/root
[root#oracle ~]# resize2fs /dev/linux/home
resize2fs 1.41.12 (17-May-2010)
Filesystem at /dev/linux/home is mounted on /home; on-line resizing required
old desc_blocks = 1, new_desc_blocks = 2
Performing an on-line resize of /dev/linux/home to 7347200 (4k) blocks.
The filesystem on /dev/linux/home is now 7347200 blocks long.
You can increase space in your box, without losing data or creating new partitions.
Halt your VM;
Go to /home_dir/VirtualBox VMs
Change file format from .vmdk to .vdi. Then use command from the answer above to increase space.
Change the file extension back and change the file name.
Attach an extended disk to your VM.
VBoxManage storageattach <your_box_name> --storagectl "IDE Controller" --
port 0 --device 0 --type hdd --medium new_extended_file.vmdk
In your VirtualBox application go to Your_VM -> Settings -> Storage. Click on the controller and choose 'add new disk' below. Choose from existing disks the one you have just expanded.
Here's a step by step instruction how to expand the space in your vagrant box or virtual machine.
The easiest way to increase the size of the vagrant box is with the vagrant-disksize plugin.
In your vagrant root folder, run vagrant plugin install vagrant-disksize
Then add the new size to the Vagrantfile:
Vagrant.configure('2') do |config|
...
config.disksize.size = '60GB'
end
Then vagrant halt and vagrant up.
vagrant reload will not work.
I have read that the plugin has issues shrinking disk size if you overshoot.
EDIT:
On Mac, this plugin also resized the partition within the Guest OS (Ubuntu in my case).
On Windows, Vagrant reserves the space on the host OS (it enlarges the disk), but you can't use the space until resizing the partition from within the Guest OS.
I used GParted, but other solutions look simpler, such as: https://nguyenhoa93.github.io/Increase-VM-Partition
I sometimes have to destroy the machine and build it up again which in my case frees up quite a lot of space, you can do that by running
vagrant destroy
vagrant up
Please note this will result in database data being lost.
fdisk is used to create mmcblk0p3 on the 64G SD card.
Disk /dev/mmcblk0: 63.8 GB, 63864569856 bytes
255 heads, 63 sectors/track, 7764 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Device Boot Start End Blocks Id System
/dev/mmcblk0p1 * 2 6 40162+ c Win95 FAT32 (LBA)
/dev/mmcblk0p2 7 130 996030 83 Linux
/dev/mmcblk0p3 131 7764 61320105 83 Linux
The fs is then formatted like this:
$ mke2fs -L media /dev/mmcblk0p3
Filesystem label=media
OS type: Linux
Block size=4096 (log=2)
Fragment size=4096 (log=2)
3833856 inodes, 15330026 blocks
766501 blocks (5%) reserved for the super user
First data block=0
Maximum filesystem blocks=16777216
468 block groups
32768 blocks per group, 32768 fragments per group
8192 inodes per group
Superblock backups stored on blocks:
32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632, 2654208, ...
Mount point /media definitely exists and $ mount /dev/mmcblk0p3 /media works fine when mmcblk0p3 is a FAT32 FS on a Win95 FAT32 partition. I need to change from FAT32 to ext2 since the FAT32 partition 3 is too easily hosed in this embedded Linux target (power cycle, USB mass storage disconnects, etc.). An Ubuntu 10.04 desktop system has been used to verify that the partition type is ext2 and is able to mount the SD card partition but this needs to work on the embedded Linux target. The kernel version is 2.6.32-17-ridgerun with BusyBox v1.18.2.
Why does $ mount /dev/mmcblk0p3 /media cause mount: mounting /dev/mmcblk0p3 on /media failed: Invalid argument?
Why does mount -t ext2 /dev/mmcblk0p3 /media cause mount: mounting /dev/mmcblk0p3 on /media failed: No such device?
Why does $ mount /dev/mmcblk0p3 /media cause mount: mounting
/dev/mmcblk0p3 on /media failed: Invalid argument?
The kernel can probably mount the filesystem, but it wrongly guess its type.
Why does mount -t ext2 /dev/mmcblk0p3 /media cause mount: mounting
/dev/mmcblk0p3 on /media failed: No such device?
If, after you specified -t, you get a problem like that, it is very likely that the kernel cannot mount the requested filesystem for you. Check if there is a module for that filesystem and it is loaded.
lsmod # show modules
modprobe ext2 # load module
Sources : http://www.silas.net.br/doc.notes/unix/linux/busybox-troubleshooting.html
As far as I know ext2 modules are already loaded by default. But it won't hurt to check.
The problem here I think is the ambiguity due to mke2fs. mke2fs can be used to create ext2/ext3/ext4 filesystems. You have to specify the file system via -t option. Try doing this :
#mkfs -t ext2 /dev/hda1
#mkfs.ext2 /dev/hda1
You missed out -t option in your command making mke2fs format it with filesystem in default conf.