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
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.
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
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
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
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
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.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
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.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
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:
This is certainly not true:
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:
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
Oh, two more things:
1. I have tried adding rootfstype=ext4 to kernel line
2. /etc/fstab:
sysfs is definitely wrong.
Does it helps to add "rootfstype=ext4" to the cmdline?
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:
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.
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.
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:
messages in dmesg, although they are perhaps caused by log level raised to 8, so they won't bother most of users.
Thanks!