Arch Linux

What type of filesystem are you using?

sry I forget to say that I am using ext4 filesystem

You'll have to be more precise about what is going wrong, this report doesn't help at all.

No issues here with clean installation and ext4 partition under i686 and kvm.

Please be more specific: what is "kernel level" for you?...

Okay, I have an explanation, but it is a VERY long shot: You are saying mounting the root filesystem failed. However, simply upgrading and downgrading util-linux-ng has no effect on initramfs unless you upgrade the kernel at the same time or explicitly rebuild the initramfs (which you clearly didn't do when downgrading). So ... this has actually nothing to do with the util-linux-ng upgrade itself. Actually, I assume that if you just upgrade that package again, there will be no problem.


To explain what I _think_ is going on, you have to understand a little detail about the boot process: We need to detect the filesystem type of the root filesystem somehow. We do that with the tool 'blkid'. Now, blkid has some security feature built-in: Whenever it finds two possible filesystem types that match, it will refuse to tell you anything, leaving us with an "unknown filesystem" error during boot.

Okay, here comes the long shot: The minix filesystem has a very primitive magic code - if just two bytes at the start of the volume match a certain value, it will be detected as a valid minix filesystem. Now, these two bytes reside in the same area where the ext2/3/4 superblock is. When you mount the filesystem read-write, the superblock changes - and some weird coincidence made your ext2/3/4 superblock contain the exact two magic bytes that are used for minix recognition. When you mount the filesystem again, these superblock changes again and the supposedly valid minix signature disappears (maybe not just minix has this problems, but also other very primitive filesystems).

The only reason I bring this up is because I have seen this before with an ext3 filesystem that suddenly blkid recognized as minix OR ext3. After mounting the filesystem again, the error was gone and blkid identified it as ext3 again. To work around such problems, you can add "rootfstype=ext4" to the kernel commandline - that will skip the detection and just mount it as ext4.

2 Thomas:

Ok, I upgraded again and there is no problem now. It looks like this is same problem as u explained.
There was some mention about minix and hint to use rootfstype= and I tried rootfstype=ext4. Then there was hint to type exit to try continue boot, so I typed exit and I read that it is unable to mout device to /new_root_something :) (or similar), you are on your own, bailing out :) so there wasn't much to do for me as I am not any superskilled kernel-level linux user :). Another exit made kernel panic... restart and again again. Well as u said, probably mount under boot cd makes this changes and everything is working fine now.

@Thomas: interesting, thanks for the explanation ;)

Thanks for your nice and friendly services......, pleasae give guidlines to use your software

My system freezes on "fsck" from 2.17.1-1. Reverting to 2.17.1 solves problem. Upgrading afterwards to 2.17.1-1 doesn't resolve the issue.

No output is emitted from "fsck" call. Ctrl-C and CTRL-ALT-DEL have no effect during hang. Must do hard reboot.

Kernel:2.6.32.9-1
Linux laptop-al 2.6.32-ARCH #1 SMP PREEMPT Tue Feb 23 19:43:46 CET 2010 x86_64 Intel(R) Core(TM)2 Duo CPU T7700 @ 2.40GHz GenuineIntel GNU/Linux

Your bug is entirely unrelated to the original one. Please open a NEW report for a NEW issue.