Unknown fs on usb?

Error mounting: mount exited with exit code 1: helper failed with:
mount: wrong fs type, bad option, bad superblock on /dev/sdb1,
       missing codepage or helper program, or other error
       In some cases useful info is found in syslog - try
       dmesg | tail  or so

This happens when I try to mount a usb-stick, that did work before the update on wheezy.
After updating I typed as root after changing to /etc/apt

cat sources.list 

getting this

# deb cdrom:[Debian GNU/Linux 7.1.0 _Wheezy_ - Official amd64 NETINST Binary-1 20130615-23:04]/ wheezy main 

deb ftp://ftp.br.debian.org/debian/ wheezy main contrib non-free 
# deb-src ftp://ftp.br.debian.org/debian/ wheezy main contrib non-free 

deb http://security.debian.org/ wheezy/updates main contrib non-free 
# deb-src ftp://ftp.br.debian.org/debian/ wheezy/updates main contrib non-free 

# wheezy-updates, previously known as 'volatile'
deb ftp://ftp.br.debian.org/debian/ wheezy-updates main contrib non-free 
deb ftp://ftp.br.debian.org/debian/ wheezy-proposed-updates contrib non-free main 
# deb-src ftp://ftp.br.debian.org/debian/ wheezy-updates main contrib non-free 

When typing the so called help

syslog - try dmesg | tail

(whith od without the blank before the "try") I am getting the notice, no such command. So may someone has a hint. The usb-stick used to work with ext4. What coud have happend?

mount /dev/sda1 /home/<my-user-name>/usb_stick -t vfat

does not help either. Glad for any help, thanks in advance.

going ahead trying this

tail -f /var/log/syslog

after that plugging in the usb-stick the terminal (using as root) tells me tons of tails

Feb  2 17:10:10 rechenknecht2 kernel: [ 7115.424057] usb 8-1: new high-speed USB device number 6 using ehci_hcd
Feb  2 17:10:10 rechenknecht2 kernel: [ 7115.558038] usb 8-1: New USB device found, idVendor=1307, idProduct=0165
Feb  2 17:10:10 rechenknecht2 kernel: [ 7115.558041] usb 8-1: New USB device strings: Mfr=1, Product=2, SerialNumber=3
Feb  2 17:10:10 rechenknecht2 kernel: [ 7115.558044] usb 8-1: Product: USB Mass Storage Device
Feb  2 17:10:10 rechenknecht2 kernel: [ 7115.558046] usb 8-1: Manufacturer: USBest Technology
Feb  2 17:10:10 rechenknecht2 kernel: [ 7115.558047] usb 8-1: SerialNumber: 09022453564397
Feb  2 17:10:10 rechenknecht2 kernel: [ 7115.558895] scsi9 : usb-storage 8-1:1.0
Feb  2 17:10:10 rechenknecht2 mtp-probe: checking bus 8, device 6: "/sys/devices/pci0000:00/0000:00:1d.7/usb8/8-1"
Feb  2 17:10:10 rechenknecht2 mtp-probe: bus: 8, device: 6 was not an MTP device
Feb  2 17:10:11 rechenknecht2 kernel: [ 7116.556916] scsi 9:0:0:0: Direct-Access                               0.00 PQ: 0 ANSI: 2
Feb  2 17:10:11 rechenknecht2 kernel: [ 7116.558686] sd 9:0:0:0: Attached scsi generic sg2 type 0
Feb  2 17:10:11 rechenknecht2 kernel: [ 7116.559288] sd 9:0:0:0: [sdb] 15794176 512-byte logical blocks: (8.08 GB/7.53 GiB)
Feb  2 17:10:11 rechenknecht2 kernel: [ 7116.559906] sd 9:0:0:0: [sdb] Write Protect is off
Feb  2 17:10:11 rechenknecht2 kernel: [ 7116.559909] sd 9:0:0:0: [sdb] Mode Sense: 00 00 00 00
Feb  2 17:10:11 rechenknecht2 kernel: [ 7116.560533] sd 9:0:0:0: [sdb] Asking for cache data failed
Feb  2 17:10:11 rechenknecht2 kernel: [ 7116.560537] sd 9:0:0:0: [sdb] Assuming drive cache: write through
Feb  2 17:10:11 rechenknecht2 kernel: [ 7116.564919] sd 9:0:0:0: [sdb] Asking for cache data failed
Feb  2 17:10:11 rechenknecht2 kernel: [ 7116.564923] sd 9:0:0:0: [sdb] Assuming drive cache: write through
Feb  2 17:10:11 rechenknecht2 kernel: [ 7116.697969]  sdb: sdb1
Feb  2 17:10:12 rechenknecht2 kernel: [ 7117.397668] sd 9:0:0:0: [sdb] Asking for cache data failed
Feb  2 17:10:12 rechenknecht2 kernel: [ 7117.397673] sd 9:0:0:0: [sdb] Assuming drive cache: write through
Feb  2 17:10:12 rechenknecht2 kernel: [ 7117.397676] sd 9:0:0:0: [sdb] Attached SCSI removable disk
Feb  2 17:10:13 rechenknecht2 kernel: [ 7117.983909] EXT3-fs error (device sdb1): ext3_check_descriptors: Block bitmap for group 0 not in group (block 16646647)!
Feb  2 17:10:13 rechenknecht2 kernel: [ 7117.999060] EXT3-fs (sdb1): error: group descriptors corrupted

So I see it is ext checking, and now I am looking for clues, because there it says that this is ext3 as fs.
And

udevinfo -a -p /sys/block/sdh

this command does not help at all

It's not saying it's ext3 as fs, it's saying it's not...

fdisk -l /dev/sdb

fdisk -l /dev/sdb

works fine to show the following:

Disk /dev/sdb: 8086 MB, 8086618112 bytes
255 heads, 63 sectors/track, 983 cylinders, total 15794176 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
Disk identifier: 0x0004f327

   Device Boot      Start         End      Blocks   Id  System
/dev/sdb1              63    15791894     7895916   83  Linux

not beeing cheeky but typing as root just

blkid 

it tells me

/dev/sda5: UUID="c95dabb2-85b9-4778-b9cb-8bd7727fd77a" TYPE="swap" 
/dev/sda1: UUID="71d40357-4318-4e08-a4f3-ab3f019c194f" TYPE="ext4" 
/dev/sdb1: UUID="641ea5c8-47d2-4473-ae01-6499d2f7ccba" TYPE="ext3"

I am sure that sda1 UUID="71d.." so on is my hdd on this laptop. That means sdb1 UUID="641..."
must be that usb-device.
So changing to /etc and typing

cat /fstab 

brings me this,

root@rechenknecht2:/etc# cat fstab
# /etc/fstab: static file system information.
#
# Use 'blkid' to print the universally unique identifier for a
# device; this may be used with UUID= as a more robust way to name devices
# that works even if disks are added and removed. See fstab(5).
#
# <file system> <mount point>   <type>  <options>       <dump>  <pass>
# / was on /dev/sda1 during installation
UUID=71d40357-4318-4e08-a4f3-ab3f019c194f /               ext4    errors=remount-ro 0       1
# swap was on /dev/sda5 during installation
UUID=c95dabb2-85b9-4778-b9cb-8bd7727fd77a none            swap    sw              0       0
/dev/sr0        /media/cdrom0   udf,iso9660 user,noauto     0       0
/dev/sdb1       /media/usb0     auto    rw,user,noauto  0       0

what was not supposed to be, that there is "noauto" for /media/usb0.
Well now I'll try to fetch how to change the fstab file.

---------- Post updated at 09:32 PM ---------- Previous update was at 09:07 PM ----------

Trying to do so, it did not work out. But my fstab is read like this below:

# / was on /dev/sda1 during installation
UUID=71d40357-4318-4e08-a4f3-ab3f019c194f /               ext4    errors=remount-ro 0       1
# swap was on /dev/sda5 during installation
UUID=c95dabb2-85b9-4778-b9cb-8bd7727fd77a none            swap    sw              0       0
/dev/sr0        /media/cdrom0   udf,iso9660 user,noauto     0       0
/dev/sdb1       /media/usb0     auto    rw,user,auto  0       0

So should I write it

/dev/sdb1      /media/usb0     auto     rw,user,auto  0       0
UUID=641ea5c8-47d2-4473-ae01-6499d2f7ccba                ext3

Well I did, but the error remains the same.

to be honest about wheezy and this change for the UUID of a device, that I still work on squeeze, although it is not state of the art, it makes me wonder how to remember any UUID for working with different mobile storages, any, would that mean to change for any machine the fstab for that very single UUID? Is that an enhancement?

This

Feb  2 17:10:13 rechenknecht2 kernel: [ 7117.983909] EXT3-fs error (device sdb1): ext3_check_descriptors: Block bitmap for group 0 not in group (block 16646647)! 
Feb  2 17:10:13 rechenknecht2 kernel: [ 7117.999060] EXT3-fs (sdb1): error: group descriptors corrupted

makes me suspicious. Does the stick work on other systems? What's the result of an fsck /dev/sdb1 ?

I used to plug this usb-storage on different machines, without any trouble, but after the last update of wheezy yesterday, this came up. And typing

fsck /dev/sdb1

brings me

root@rechenknecht2:/home/wurzel# fsck /dev/sdb1
fsck from util-linux 2.20.1
e2fsck 1.42.5 (29-Jul-2012)
ext2fs_check_desc: Corrupt group descriptor: bad block for block bitmap
fsck.ext3: Group descriptors look bad... trying backup blocks...
Superblock has an invalid journal (inode 8).
Clear<y>?

that means bad block for block bitmap, sorry, I don't understand why there is a hint to try to backup any blocks.
In case I agree to clear the journal, as the invalid journal (inode 8) means to be, does it erase the content, my content?
Thanks for your reply.

well played, well done, I don't know, really. this is the output after cleaning up, a downgrade to ext2, to set up a new fs?

root@rechenknecht2:/home/wurzel# fsck /dev/sdb1
fsck from util-linux 2.20.1
e2fsck 1.42.5 (29-Jul-2012)
ext2fs_check_desc: Corrupt group descriptor: bad block for block bitmap
fsck.ext3: Group descriptors look bad... trying backup blocks...
Superblock has an invalid journal (inode 8).
Clear<y>? yes
*** ext3 journal has been deleted - filesystem is now ext2 only ***

The filesystem size (according to the superblock) is 1974264 blocks
The physical size of the device is 1973979 blocks
Either the superblock or the partition table is likely to be corrupt!
Abort<y>? yes

/dev/sdb1: ***** FILE SYSTEM WAS MODIFIED *****

btw, the LED still is constantly on, the file manager says there is an unknown type of device.

Do other computer systems read the file system?

No! The latest news for just half a year of work is this, after typing

root@rechenknecht2:~# cd /media/usb0
root@rechenknecht2:/media/usb0# ls -lsh
total 0

This means, zero, nothing. Allright, start all over, have a coffee and a smoke.

Is that file system actually mounted on /media/usb0 ?

That media or usb-storage is not mounted actually on the wheezy machine. If so, it appears in the file-manager, but it remains the error. While booting that laptop the GRUB loader tells me he is expecting that device, because I changed the fstab-file to that content as follows

root@rechenknecht2:/etc# cat fstab
# /etc/fstab: static file system information.
#
# Use 'blkid' to print the universally unique identifier for a
# device; this may be used with UUID= as a more robust way to name devices
# that works even if disks are added and removed. See fstab(5).
#
# <file system> <mount point>   <type>  <options>       <dump>  <pass>
# / was on /dev/sda1 during installation
UUID=71d40357-4318-4e08-a4f3-ab3f019c194f /               ext4    errors=remount-ro 0       1
# swap was on /dev/sda5 during installation
UUID=c95dabb2-85b9-4778-b9cb-8bd7727fd77a none            swap    sw              0       0
/dev/sr0        /media/cdrom0   udf,iso9660 user,noauto     0       0
/dev/sdb1       /media/usb0     auto    rw,user,auto  0       0
#UUID=641ea5c8-47d2-4473-ae01-6499d2f7ccba  /media/usb0  ext3 auto, defaults 0 2

As far as I know these values defaults 0 and 2 are for checking the media and the number of boots or not. But anyway it is still there on the wheezy-laptop, while shutting down the same message appears that there has been a failure to that specific device. So I still will find out how to recover, but....with little hope, 'cause on the squeeze system there appears just nothing plugging it in. Anyway it has been a backup for some data, that does not mean for me to make a backup for a backup or even going for any cloud service.

---------- Post updated 02-04-15 at 07:51 AM ---------- Previous update was 02-03-15 at 09:29 PM ----------

After re-writing the /etc/fstab-file changing

/dev/sdb1       /media/usb0     auto    rw,user,auto  0       0

to

/dev/sdb1       /media/sdb1    auto    rw,user,auto  0       0

and saving it, it is overwritten to the first line, (re-writing as root) somehow, and appears at wheezy, but the media itself appears empty and doesn't show up as or at usb0, although changing to /etc
typing ls there shoud be. As root I got no permission to make this changes. So first chmod. To be continued.
But

 find /etc -type f -exec chmod 777 {} +

or

 find /etc -type d -exec chmod 777 {} +

just tells me that I got no permission, as root, to change this file. This remembers me of sudo. rrrubbish. sorry

If you had done this without -type d , the effects on your system would have been absolutely ruinous.

As is, you should still probably reinstall from scratch. Strange things are likely to happen from here on out. You have tampered with the permissions of many important folders. 777 is not the magic sledgehammer to fix all permissions problems.

What folder did it tell you you didn't have permission to change, by the way...?

The fstab isn't magic. All it does is mount. If mount doesn't work, fstab isn't going to help.

At this point I would recommend sending your USB drive to a specialist data recovery service to see if they can undo your destructive changes.

find /etc -type d -exec chmod 777 {} +

Sure, you are right, I should improve the original, this specific line I used to handle the archive themself, just for using this media on several machines, so it would be e.g., sorry for the misunderstanding.

find /media/usb0/sounds5 -type f -exec chmod 777 {} +

to get this straight.

777 is not the magic sledgehammer to fix all permissions problems.

Try 750.

Okay, I'll remember, 'cause apart of this, it is an endless journey.

I hope you realize that completely compromises your machine.

Anyone who can access the box can now replace files such as /etc/passwd or /etc/shadow, change out SSH keys, have init and services run arbitrary code, and a slew of other things.

Anything and everything under /etc can be replaced. By anyone.

Gents, sorry for the misunderstanding, I use this for archives, not for the complete partition or machine.

find /media/usb0/sounds5 -type f -exec chmod 777 {} +

Could be as well

find /media/usb0/sounds5 -type d -exec chmod 777 {} +

for directories. I did not intend to spread any bad commands. And changing the magic sledgehammer to 750.

That's even worse. All setting a folder executable does is let you cd into it, but doing that to files sets them all as world-writable, executable programs. Wrong and dangerous! Try 640. Better yet, find out what these numbers mean (man chmod) and plan ahead.

10644 or 640 is just what I did not wanted. And yes, I read the man pages for chmod before, not only the man pages, but more about this. That is why I came to the conclusion of the other values, they serve better for my purposes. As using only my machinery, how it comes that there is such a worry about user rights for files of a backup media. Okay, before starting another discussion let it stay like this. Beeing well aware of 755, 750, 644 and others.

If you're tapdancing blindfolded, don't set out minefields for yourself. You're going to get tripped by the mess you have made eventually.

Besides which, many programs care about the permissions of certain files, too. By changing everything, you have made your backups useless in a few important ways.

I am closing this thread before you can fill it with more very horrible advice.