Error mounting wrong fs type bad option bad superblock on dev sda1



Не монтируется диск hdd

После переустановки системы, подключил к компу диск с данными /dev/sdb
Делаю mount -t ext4 /dev/sdb /usr/local
Выводит следующее:

В dmesg : EXT4-fs (sdb): VFS: Can’t find ext4 filesystem

Команда: fsck -fy /dev/sdb
Выводит:

Если сделать fsck -fy /dev/sdb1
То будет следующее сообщение, а далее тысячи исправлений:

Больше ничего не делал, боюсь потерять данные.
Как восстановить диск? точнее примонтировать и не потерять даные.

ФС ведь не была создана прямо на диске? Раз уж это жёсткий диск, наверное, там есть таблица разделов.

Поздно, потери уже в пути.

После переустановки системы, подключил к компу диск с данными /dev/sdb

Что именно произошло с диском между переустановкой и переподключением?

Перестало работать после того , как я через gparted изменил UUID

mount -t ext4 -o sb=32768 /dev/sdb1 /mnt тоже не сработает?

Если есть место, лучше считать весь sdb1 куда-нибудь и работать с его копиями.

Testdisk может прочитать список файлов на разделе?

К сожалению, нет возможности скопировать данные куданить
Testdisk выдаёт это

Народ. ну что? делать Write partition structure to disk ? ничего лишнего не затрёт?

Список файлов прочесть с помощью Testdisk можно!

Какие ошибки появляются в dmesg при попытке смонтировать sdb с -o sb=8193, -o sb=32768 и без -o?

Если ФС так и не смонтируется, можно попробовать считать самые важные файлы при помощи testdisk.

На все вырианты одно

sdb1 же — запарили уже тупить

[ 267.924107] EXT4-fs (sdb): VFS: Can’t find ext4 filesystem

featurelles , прошу прощения, моя опечатка. Естественно, в предыдущем сообщении имелся в виду sdb1.

Если через testdisk попробовать сделать востановление суперблока, выбором Write partition structure to disk это ведь на диске ничего не попортит?

Просто запускайте testdisk /dev/sdb1 и выбирайте Non partitioned media.

Я пробовал и sdb и sdb1 , везде одно и тоже.
Но эт уже не важно, сейчас копии файлов делаю. И далее через testdisk попробую восстановить хард.(раньше об этой проге и не слышал)
AITap — огромное спасибо за помощь!

Источник

Linux Mint Forums

Welcome to the Linux Mint forums!

[SOLVED]mount: wrong fs type, bad option, bad superblock

[SOLVED]mount: wrong fs type, bad option, bad superblock

Post by Hurricane » Sun Apr 27, 2014 4:48 pm

I’m trying to mount a vfat partition on my external hard drive. I know the drive works because it automatically mounts on my MacBook just fine.

The way it’s set up is as follows:

Re: mount: wrong fs type, bad option, bad superblock

Post by Mute Ant » Sun Apr 27, 2014 9:48 pm

I am only guessing here because I only have one drive that big, formatted with ext4. It is possible that the magic built into the ‘auto’ part is failing, so tell it exactly what you want and where just this once.

sudo mount -t vfat /dev/sdb2 /mnt

Who wired this up for you? You bought it in a shop? Oo what a terrible job.

Re: mount: wrong fs type, bad option, bad superblock

Post by Hurricane » Sun Apr 27, 2014 10:56 pm

I did it myself because I want a backup drive for my MacBook and at the same time I’m not going to dedicate a whole 1TB for that. It’s an external drive.

I tried using vfat instead of auto like you said. Still no dice.

Re: mount: wrong fs type, bad option, bad superblock

Post by Spearmint2 » Mon Apr 28, 2014 12:31 pm

Читайте также:  Error cs0101 the namespace global

Re: mount: wrong fs type, bad option, bad superblock

Post by Hurricane » Mon Apr 28, 2014 1:11 pm

Re: mount: wrong fs type, bad option, bad superblock

Post by WharfRat » Mon Apr 28, 2014 2:59 pm

I forget what the limit is for a vfat partition, but I think 500GB is well in excess.

If you don’t have any data stored on it yet, format it ntfs if you need to share it with windows otherwise consider ext3/4.

Good luck

Re: mount: wrong fs type, bad option, bad superblock

Post by Spearmint2 » Mon Apr 28, 2014 3:29 pm

Re: mount: wrong fs type, bad option, bad superblock

Post by WharfRat » Mon Apr 28, 2014 3:58 pm

But will dosfstools or mount -t vfat be compatible

I once formated a a 32GIG flash with -F16 and had a similar problem when copying files to it. I then used -F32 and it was fine.

Re: mount: wrong fs type, bad option, bad superblock

Post by Spearmint2 » Mon Apr 28, 2014 4:36 pm

They should. Here’s my Linux box with FAT32 partitions larger than 32 GB on it.

Re: mount: wrong fs type, bad option, bad superblock

Post by WharfRat » Mon Apr 28, 2014 5:19 pm

Well I guess I have to stand corrected then

Nothing was mentioned in the vfat kernel documentation about that, just the addition of long file names.

Re: mount: wrong fs type, bad option, bad superblock

Post by Hurricane » Mon Apr 28, 2014 5:39 pm

Re: mount: wrong fs type, bad option, bad superblock

Post by WharfRat » Mon Apr 28, 2014 7:58 pm

Just out of curiosity did you try it on a windows system Did you try formatting it vfat on a windows system

I still suspect vfat at 500GB, but I’m often wrong

Re: mount: wrong fs type, bad option, bad superblock

Post by Mute Ant » Mon Apr 28, 2014 9:11 pm

Re: mount: wrong fs type, bad option, bad superblock

Post by Hurricane » Mon Apr 28, 2014 9:19 pm

It mounts on Windows as well. So that just leaves Mint.

Of course, the HFS partition doesn’t mount, and I don’t expect it to. I’m only talking about the VFAT. Windows doesn’t even know the HFS partition exists. At least Linux can see it.

fsck says everything’s okay. It mounts on other systems. I’m really confused. I’m starting to suspect the VFAT module might have a bug.

Re: mount: wrong fs type, bad option, bad superblock

Post by WharfRat » Mon Apr 28, 2014 10:56 pm

Hurricane wrote: It mounts on Windows as well. So that just leaves Mint.

Of course, the HFS partition doesn’t mount, and I don’t expect it to. I’m only talking about the VFAT. Windows doesn’t even know the HFS partition exists. At least Linux can see it.

fsck says everything’s okay. It mounts on other systems. I’m really confused. I’m starting to suspect the VFAT module might have a bug.

I don’t think it’s wise to attempt to use large vfat partitions in linux

Also vfat is kernel built-in

Re: mount: wrong fs type, bad option, bad superblock

Post by Hurricane » Mon Apr 28, 2014 11:31 pm

Re: mount: wrong fs type, bad option, bad superblock

Post by Hurricane » Mon Apr 28, 2014 11:44 pm

Читайте также:  Curlftpfs error connecting to ftp access denied 530

Okay. Figured out how to get the grub menu to show. Booted into the old 3.11 kernel that came stock with Mint. Everything works perfectly.

Thanks for all the help.

Re: mount: wrong fs type, bad option, bad superblock

Post by WharfRat » Mon Apr 28, 2014 11:52 pm

So you have a custom kernel, but I don’t understand can’t get the grub menu to show

Did you remove the distro’s version

What I do is symlink the kernel and initrd so I can swap them if I have other versions.

Источник

Problem FAQ

Contents

General topics

How do I report bugs and issues?

Please report bugs on Bugzilla on kernel.org (requires registration) setting the component to Btrfs, and report bugs and issues to the mailing list (linux-btrfs@vger.kernel.org; you are not required to subscribe). For quick questions you may want to join the IRC #btrfs channel on libera.chat (and stay around for some time in case you do not get the answer right away).

Please use btrfs-progs somewhere in the bug subject if you’re reporting a bug for the userspace tools.

If you include kernel log backtraces in bug reports sent to the mailing list, please disable word wrapping in your mail user agent to keep the kernel log in a readable format.

Please attach files (like logs or dumps) directly to the bug and don’t use pastebin-like services.

Mount/unmount problems

I can’t mount my filesystem, and I get a kernel oops!

First, update your kernel to the latest one available and try mounting again. If you have your kernel on a btrfs filesystem, then you will probably have to find a recovery disk with a recent kernel on it.

Second, try mounting with options -o recovery or -o ro or -o recovery,ro (using the new kernel). One of these may work successfully.

Finally, if and only if the kernel oops in your logs has something like this in the middle of it,

then you should try using btrfs rescure zero-log (see Manpage/btrfs-rescue).

Filesystem can’t be mounted by label

See the next section.

Only one disk of a multi-volume filesystem will mount

If you have labelled your filesystem and put it in /etc/fstab, but you get:

or if one volume of a multi-volume filesystem fails when mounting, but the other succeeds:

Then you need to ensure that you run a btrfs device scan first:

This should be in many distributions’ startup scripts (and initrd images, if your root filesystem is btrfs), but you may have to add it yourself.

My filesystem won’t mount and none of the above helped. Is there any hope for my data?

Maybe. Any number of things might be wrong. The restore tool is a non-destructive way to dump data to a backup drive and may be able to recover some or all of your data, even if we can’t save the existing filesystem.

Unsorted/uncategorized

Defragmenting a directory doesn’t work

does not defragment the contents of the directory.

This is by design. btrfs fi defrag operates on the single filesystem object passed to it, e.g. a (regular) file. When ran on a directory, it defragments the metadata held by the subvolume containing the directory, and not the contents of the directory. If you want to defragment the contents of a directory, you have to use the recursive mode with the -r flag (see recursive defragmentation).

Читайте также:  The above error occurred in the component

Compression doesn’t work / poor compression ratios

First of all make sure you have passed «compress» mount option in fstab or mount command. If yes, and ratios are unsatisfactory, then you might try «compress-force» option. This way you make the btrfs to compress everything. The reason why «compress» ratios are so low is because btrfs very easily backs out of compress decision. (Probably not to waste too much CPU time on bad compressing data).

Copy-on-write doesn’t work

You’ve just copied a large file, but still it consumed free space. Try:

I get the message «failed to open /dev/btrfs-control skipping device registration» from «btrfs dev scan»

You are missing the /dev/btrfs-control device node. This is usually set up by udev. However, if you are not using udev, you will need to create it yourself:

You might also want to report to your distribution that their configuration without udev is missing this device.

I get «No space left on device» errors, but df says I’ve got lots of space

First, check how much space has been allocated on your filesystem:

Note that in this case, all of the devices (the only device) in the filesystem are fully utilised. This is your first clue.

Next, check how much of your metadata allocation has been used up:

Note that the Metadata used value is fairly close (75% or more) to the Metadata total value, but there’s lots of Data space left. What has happened is that the filesystem has allocated all of the available space to either data or metadata, and then one of those has filled up (usually, it’s the metadata space that does this). For now, a workaround is to run a partial balance:

Note that there should be no space between the -d and the usage. This command will attempt to relocate data in empty or near-empty data chunks (at most 5% used, in this example), allowing the space to be reclaimed and reassigned to metadata.

If the balance command ends with «Done, had to relocate 0 out of XX chunks», then you need to increase the «dusage» percentage parameter till at least one chunk is relocated. More information is available elsewhere in this wiki, if you want to know what a balance does, or what options are available for the balance command.

I cannot delete an empty directory

First case, if you get:

  • rmdir: failed to remove ‘emptydir’: Operation not permitted

then this is probably because «emptydir» is actually a subvolume.

You can check whether this is the case with:

To delete the subvolume you’ll have to run:

Second case, if you get:

  • rmdir: failed to remove ‘emptydir’: Directory not empty

then you may have an empty directory with a non-zero i_size.

You can check whether this is the case with:

Running «btrfs check» on that (unmounted) filesystem will confirm the issue and list other problematic directories (if any).

You will get a similar output (excerpt):

Such errors should be fixable with «btrfs check —repair» provided you run a recent enough version of btrfs-progs.

Note that «btrfs check —repair» should not be used lightly as in some cases it can make a problem worse instead of fixing anything.

Источник

Оцените статью
toolgir.ru
Adblock
detector