[Touch-packages] [Bug 1375640] Re: fsck should do some sanity checks to avoid damaging an ext3/ext4 file system

2024-01-10 Thread Michael Mess
Thank you for you recommendations. I was able to restore some of the data which has been lost. The nvidia graphics card was causing all the trouble, after a replacement with intel graphics, I have never experienced any issues again. It is likely that the closed source driver caused also other is

[Touch-packages] [Bug 1375640] Re: fsck should do some sanity checks to avoid damaging an ext3/ext4 file system

2014-09-30 Thread Michael Mess
It should be necessary to type "yes" to continue. Just "y" or hitting enter should not not do it and abort the command. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to e2fsprogs in Ubuntu. https://bugs.launchpad.net/bugs/13756

[Touch-packages] [Bug 1375640] Re: fsck should do some sanity checks to avoid damaging an ext3/ext4 file system

2014-09-30 Thread Theodore Ts'o
You're jumping to conclusions here that the damage was caused by the lack of "-t ext4" to fsck. #1, the fsck program will determine the file system type based on the file system type found in /etc/fstab. So if the /etc/fstab file indicates that you were using ext4, then it wlil do the equivalent

[Touch-packages] [Bug 1375640] Re: fsck should do some sanity checks to avoid damaging an ext3/ext4 file system

2014-10-02 Thread Michael Mess
Thank you for the information. I was thinking, that I have destroyed the extents and other features of the ext4 file system by using a tool that is not aware of the special ext4 features, leading to filesystem coruption. What happens, if I hit CTRL-C during fsck? Can that leave the filesystem in

[Touch-packages] [Bug 1375640] Re: fsck should do some sanity checks to avoid damaging an ext3/ext4 file system

2014-10-02 Thread Theodore Ts'o
1) e2fsck (which is what fsck.ext[234] is hard linked to) is designed to be safe when getting interrupted by ^C 2) The all kernel code uses the same address space. So if there is a wild pointer in the Nvidia driver scribbles on random kernel memory, literally anything can happen. There is a r