e4rat fails to recognize root as ext4

[Mirosław Zalewski]

Hi

I am using Debian testing on amd64 machine with e4rat 0.2.2 downloaded from SF (.deb package). Unfortunately, e4rat is unable to recognize my root partition as ext4. Error message is:

/dev/sda5 is not an ext4 filesystem
Filesystem of /dev/sda5 is sysfs

This is certainly not true:

blkid /dev/sda5
/dev/sda5: LABEL="ROOT_FS" UUID="2e9337c0-168e-4bb8-9814-937eb6f458fa" TYPE="ext4"

What is most confusing, e4rat works fine with my /home/ partition and collects files from it. I don't see any difference between / and /home - they were both formatted as ext4 during the same installation with default Debian settings.

There is some info you may find useful:

# uname -a
Linux pingwin 3.2.0-2-amd64 #1 SMP Tue Mar 20 18:36:37 UTC 2012 x86_64 GNU/Linux

# cat /etc/mtab 
rootfs / rootfs rw 0 0
sysfs /sys sysfs rw,nosuid,nodev,noexec,relatime 0 0
proc /proc proc rw,nosuid,nodev,noexec,relatime 0 0
udev /dev devtmpfs rw,relatime,size=1475632k,nr_inodes=368908,mode=755 0 0
devpts /dev/pts devpts rw,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=000 0 0
tmpfs /run tmpfs rw,nosuid,noexec,relatime,size=296044k,mode=755 0 0
/dev/disk/by-uuid/2e9337c0-168e-4bb8-9814-937eb6f458fa / ext4 rw,noatime,errors=remount-ro,user_xattr,acl,barrier=1,data=ordered 0 0
tmpfs /run/lock tmpfs rw,nosuid,nodev,noexec,relatime,size=5120k 0 0
tmpfs /tmp tmpfs rw,nosuid,nodev,relatime,size=592084k 0 0
proc /proc proc rw,nosuid,nodev,noexec,relatime 0 0
sysfs /sys sysfs rw,nosuid,nodev,noexec,relatime 0 0
tmpfs /run/shm tmpfs rw,nosuid,nodev,relatime,size=592084k 0 0
/dev/sda3 /boot ext2 rw,relatime,errors=continue 0 0
/dev/sda7 /home ext4 rw,noatime,user_xattr,acl,barrier=1,data=ordered 0 0
fusectl /sys/fs/fuse/connections fusectl rw,relatime 0 0

# debugfs -R feature /dev/sda5 # /
debugfs 1.42.2 (27-Mar-2012)
Filesystem features: has_journal ext_attr resize_inode dir_index filetype needs_recovery extent flex_bg sparse_super large_file huge_file uninit_bg dir_nlink extra_isize
root@pingwin:~# debugfs -R feature /dev/sda7 # /home
debugfs 1.42.2 (27-Mar-2012)
Filesystem features: has_journal ext_attr resize_inode dir_index filetype needs_recovery extent flex_bg sparse_super large_file huge_file uninit_bg dir_nlink extra_isize

full dumpe2fs for / and /home (it's quite huge - more than 1MB)
kernel .config file (it's default Debian kernel)

At least few Debian users have reported that e4rat does not collect files from their / filesystem, only /home. OTOH, some users report that it's working without any problems.

I have failed to find any meaningful differences between mine system and system of users who reports that e4rat is working for them.

What should I check? How can I make e4rat working?

Thanks in advance
Mirosław Zalewski

[Mirosław Zalewski]

Oh, two more things:
1. I have tried adding rootfstype=ext4 to kernel line
2. /etc/fstab:

# /etc/fstab: static file system information.
#
# Use 'vol_id --uuid' 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>
proc            /proc           proc    defaults        0       0
# / was on /dev/sda5 during installation
UUID=2e9337c0-168e-4bb8-9814-937eb6f458fa /               ext4    errors=remount-ro,noatime 0       1
# /boot was on /dev/sda3 during installation
UUID=c672121e-260f-4456-a635-25890f0f6233 /boot           ext2    defaults        0       2
# ./home
UUID=e5bf949f-c8bd-48a4-a5df-8840c478c4a0 /home     ext4    defaults,noatime    0   2
UUID=98B85D82B85D5FB4   /mnt/zewnetrzny     ntfs-3g defaults    0   0
UUID=99b9ac61-cc7b-4a8c-a21d-e7d5d3a4aca5   /mnt/backup ext4    defaults,noauto 0   0
# swap was on /dev/sda6 during installation
UUID=e973d4c5-e3bd-482d-b75f-f58786f988a9 none            swap    sw              0       0
#/dev/scd0       /media/cdrom0   udf,iso9660 user,noauto     0       0

[conso]

sysfs is definitely wrong.
Does it helps to add "rootfstype=ext4" to the cmdline?

[Mirosław Zalewski]

No, adding rootfstype does not change anything.

I have found, that this problem is related to double /proc and /sys entries in /etc/mtab (while /etc/mtab is symlink to/proc/mounts in Debian testing and sid). I think that it may be somehow related to Debian bug #653073, but I'm not really sure how.

I have found workaround for this issue:

# delete /etc/mtab symlink
rm /etc/mtab
# copy existing /proc/mounts to /etc/mtab
cp /proc/mounts /etc/mtab
# add writing bit
chmod +w /etc/mtab
# edit /etc/mtab and delete /proc and /sys lines which are EARLIER in the file. If you delete lines which are later, nothing will happern
$EDITOR /etc/mtab
# reboot and make sure that /sbin/e4rat-collect is run

During next boot Debian will make /etc/mtab symlink again, but only after e4rat fires up, so it will not complain about / being not ext4.
(If someone prefers to have static /etc/mtab, it is possible to comment out mtab_migrate in /etc/init.d/checkroot.sh. But please note that it may cause problems when Debian bug #659473 is solved.)

I have tested Debian in virtualbox (installed basic stable release, upgraded to testing and checked /proc/mounts) and found out that double /proc and /sys entries are somehow standard setting. This means that this issue should hit most of users of Debian Wheezy and later. Perhaps it should be fixed on Debian (and not e4rat), but I really don't know how.

[conso]

OK. I have fixed the /etc/mtab symblick link issue to /proc/mounts. If e4rat-collect cannot recognise the file system type, cause proc is not mounted, it accepts the file and is keep going.

Please let me know if it's working for you.

[Mirosław Zalewski]

With latest e4rat from git e4rat-collect is working by default. I think that my issue has been fixed.

Only side-effect is a lot of:

Neither /proc/mounts nor /etc/mtab is readable.

messages in dmesg, although they are perhaps caused by log level raised to 8, so they won't bother most of users.

Thanks!