I have /dev/sdb1 mounted on / and supposedly /dev/sdb2 mounted on a broken out /boot. I didn't notice the problem because corrupted
superblock on /dev/sdb2 prevented mounting but didn't prevent booting or having access to its files.

$ ls /boot
<expected files>
$ ls -la / | grep vmlinuz
lrwxrwxrwx 1 root root 28 Dec 5 2014 vmlinuz -> boot/vmlinuz-3.2.0-4-686-pae
$ mount | grep sdb2
<nothing>

So mount does not know it is mounted! I backup the contents of /boot and do:

# e2fsck -c /dev/sdb2
Error reading block 5799936 (Invalid argument). Ignore error<y>?
Force rewrite <y>?
Ignore error<y>?
Superblock has an invalid journal (inode 8).
Clear<y>
*** ext3 journal has been deleted - filesystem is now ext2 only ***
Superblock has_journal flag is clear, but a journal inode is present.
clear<y>

I stop at this point, fearing I'll have no file system at all. I do:

# e2fsck -f /dev/sdb2
Error reading block 5799936 (Invalid argument). Ignore error<y>?

This just puts back into the same routine. I search for alternative superblocks:

# mke2fs -n /dev/sdb2
...
* Superblock backups stored on blocks:
32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632

I try the first:L

# e2fsck -f -b 32789 /dev/sdb2
e2fsck: Bad magic number in super-block while trying to open /dev/sdb2

So I try another:

# e2fsck -f -b 98304 /dev/sdb2
Error reading block 5799936 (Invalid argument). Ignore error<y>?
Force rewrite<y>?
Superblock has an invalid journal (inode 8).
Clear<y>?
*** ext3 journal has been deleted - filesystem is now ext2 only ***
Superblock has_journal flag is clear, but a journal inode is present.
Clear<?>?
The filesystem size (according to the superblock) is 12207359 blocks
The physical size of the device is 2441880 blocks
Either the superblock or the partition table is likely to be corrupt!
Abort<y>?
Error writing block 5799936 (Invalid argument). Ignore error<y>?
/dev/sdb2: ***** FILE SYSTEM WAS MODIFIED *****

I change the fs type in /etc/fstab and do

# mount -a | grep sdb2
mount: wrong fs type, bad option, bad superblock on /dev/sdb2,
missing codepage or helper program, or other error
In some cases useful info is found in syslog - try
dmesg | tail or so

I seems the partition is seen as being larger than it actually is, and so
alternative superblocks are not reachable. But I'm ignorant about these
matters, and so would like advice what to do next.

Haines

It looks like the system is not using the separate /boot partition, but is using the /boot directory as an ordinary directory off /. I wouldn't worry too much about the separate /boot partition, because the system works without it.

1 members found this post helpful.

Can you please paste the output from the following command:

Also, have you manually resized any of your partitions at any point using a partition manager?

I don't think so. Post the data requested above, plus fstab. Oh, and relax a little.

Hydurga, my lsblk command seems a different version than your own, for it lacks a PARTTYPE column.

$ lsblk -l -o NAME,LABEL,FSTYPE,TYPE,SIZE,STATE,MOUNTPOINT | sort -g -k1.4 | grep sdb
sdb disk 931.5G running
sdb1 part 953M /
sdb2 part 9.3G
sdb3 part 1K
sdb5 part 55.9G /home
sdb6 part 55.9G /usr
sdb7 part 37.3G /var
sdb8 part 18.6G /tmp
sdb9 part 55.9G /usr/local
sdb10 part 29.8G
sdb11 part 93.1G /info
sdb12 part 186.3G /storage
sdb13 part 351.3G

This does not show /dev/sdb2 mounted on /boot as it should. I've not resized any partitions, and
the sizes above look right. However, I found thats both /dev/sdb1 (/) and /dev/sdb2 (/boot) were
marked bootable for somehow (fdisk doen't let you do it). But I fixed this after I had already
discovered the superblock problem.

In /etc/fstab there is:
# ===========================================================================================
# SDB HARD DISK: Debian Wheezy /dev/sdb (ignore "was" sda)
# ===========================================================================================
#
# <file system> <mount point> <type> <options> <dump> <pass>
# / root was on /dev/sda1 during installation
UUID=b0673fe5-e6b2-42a5-9121-5fcf32b7135d / ext4 errors=remount-ro 0 1
# /boot
UUID="22df155c-55a9-4c78-b2a1-47b0ddaedfc0" /boot ext4 defaults 0 2
# /home was on /dev/sda5 during installation
UUID=3cb9ae2e-1ca6-4365-94b4-bf99c63f9cb6 /home ext4 defaults 0 2
# /info was on /dev/sda11 during installation
UUID=be4e05b3-c44d-4e96-a48b-e71a68a5a2e4 /info ext4 defaults 0 2
# /storage was on /dev/sda12 during installation
UUID=dd683292-f7ce-42bc-98e4-fe28f8e7a45a /storage ext4 defaults 0 2
# /tmp was on /dev/sda8 during installation
UUID=dcc4c3a5-111e-4e69-86d0-65cfb2ddb670 /tmp ext4 defaults 0 2
# /usr was on /dev/sda6 during installation
UUID=6e865f47-c20f-41bc-85e5-42052229bd09 /usr ext4 defaults 0 2
# /usr/local was on /dev/sda9 during installation
UUID=5acc0210-5932-45f4-b852-c91c89dd3669 /usr/local ext4 defaults 0 2
# /var was on /dev/sda7 during installation
UUID=a74ef46b-3883-43d6-a170-d57b3c9aa2bf /var ext4 defaults 0 2
# swap was on /dev/sda10 during installation
UUID=784e0c0a-6604-4ff5-a111-7862b81dfca9 none swap sw 0 0

The sda/sdb ambiguity probably because I may have switched SATA ports when adding the new
disk.

# blkid | grep sdb2
/dev/sdb2: UUID="22df155c-55a9-4c78-b2a1-47b0ddaedfc0" TYPE="ext4"

Fdisk returns this:

Device Boot Start End Blocks Id System
/dev/sdb1 * 2048 1953791 975872 83 Linux
/dev/sdb2 1953792 21488831 9767520 83 Linux
/dev/sdb3 99612670 1953523711 926955521 5 Extended
/dev/sdb5 99612672 216797183 58592256 83 Linux
/dev/sdb6 216799232 333983743 58592256 83 Linux
/dev/sdb7 333985792 412108799 39061504 83 Linux
/dev/sdb8 412110848 451170303 19529728 83 Linux
/dev/sdb9 451172352 568356863 58592256 83 Linux
/dev/sdb10 568358912 630857727 31249408 82 Linux swap / Solaris
/dev/sdb11 630859776 826169343 97654784 83 Linux
/dev/sdb12 826171392 1216794623 195311616 83 Linux
/dev/sdb13 1216796672 1953523711 368363520 83 Linux

Mount returns this:

mount | grep sdb
/dev/sdb1 on / type ext4 (rw,relatime,errors=remount-ro,user_xattr,barrier=1,data=ordered)
/dev/sdb5 on /home type ext4 (rw,relatime,user_xattr,barrier=1,data=ordered)
/dev/sdb11 on /info type ext4 (rw,relatime,user_xattr,barrier=1,data=ordered)
/dev/sdb12 on /storage type ext4 (rw,relatime,user_xattr,barrier=1,data=ordered)
/dev/sdb8 on /tmp type ext4 (rw,relatime,user_xattr,barrier=1,data=ordered)
/dev/sdb6 on /usr type ext4 (rw,relatime,user_xattr,barrier=1,data=ordered)
/dev/sdb9 on /usr/local type ext4 (rw,relatime,user_xattr,barrier=1,data=ordered)
/dev/sdb7 on /var type ext4 (rw,relatime,user_xattr,barrier=1,data=ordered)

This does not report that in fact /dev/sdb2 is mounted on /boot, for I can access its files.
I should have mentioned that I don't boot this disk with its GRUB menu, but from that of a Jessie
GRUB menu on another drive. I suspect that if I tried to boot /dev/sdb with its own booter, it
would fail.

A question: if mount does not see that /dev/sdb2 is mounted, is this why there is the report
of corrupted superblock?

Ok, as far as I can see it:

. mount does not see or report sdb2 as mounted because it isn't mounted. The files you see when you look at /boot are in fact in the /boot directory on the root partition. Perhaps you have 2 copies of the boot directory, one on the root partition, which you are using, and one on the borked sdb2 partition.

. Your fstab is trying to mount sdb2 but encountering errors and thus failing to do so (as per mount -a). It's interesting that /boot is the only entry that does not have a connected comment in fstab (you don't need to keep these comments by the way) saying that it was on /dev/sdax during installation, indicating that this problem may have originally occurred during installation.

You have two choices - (i) carry on as things are now (remove sdb2 from fstab and consider it as free space); (ii) create a fresh filesystem on sdb2 and then copy over the relevant files from /boot.

A couple of ancillary points:

. You should use the CODE tags here on LQ for your output (see the '#' button on the Advanced Editor).

. Do you really need a 9.3GB boot partition? It is usually in the order of 300-500MB. Generally your various partition sizes seem excessive.

You ask if I really need a 9.3 Gb boot partition. Well, that's the problem, I meant to create a 2 Gb partition
(fdisk thinks it is this size). However, dmesg says: [sdb2]: bad geometry: block count 12207359 exceeds size
of device (2441880 blocks).

/dev/sdb2 does not get mounted, which is apparently why I must do a Ctl-D to complete a boot. Your suggestion
that /boot is mounted on / instead of being broken out is helpful. I'll take your suggestion regarding a fix
(comment the /boot mount line in /etc/fstab, run fdisk on /sdb2 to format it, copy contents of /boot from a
backup over to it).

As for CODE tags, I didn't think I entered any code.

Thanks, Haines

/boot is not mounted. It is simply a directory in the / partition. It is not mounted on /. It just simply is not mounted. You also do not need to mount anything at /boot, because the system already has everything it needs in the /boot directory.

/boot is never going to mount, ever, until you reformat the partition /dev/sda2, ever. No matter how many times you type the word "mount" in your posts, /boot will still not be mounted. You must either reformat /dev/sda2, or remove the entry for /boot in fstab.

Let us know how you get on. You'll need to test the new boot partition with sudo mount -a once you have it set up and have added it to fstab. I personally would copy /boot from your current root file system rather than a backup so it mimics exactly your current boot setup.

You should probably fsck all your ext file systems just in case.

CODE tags, despite the name, are also used for the output from commands.