Summary: | sys-kernel/genkernel-3.4.10_pre7 EXT2-fs warning (device sda3): ext2_fill_super: mounting ext3 filesystem as ext2 | ||
---|---|---|---|
Product: | Gentoo Hosted Projects | Reporter: | Sylvain BERTRAND <sylvain.bertrand> |
Component: | genkernel | Assignee: | Gentoo Genkernel Maintainers <genkernel> |
Status: | RESOLVED DUPLICATE | ||
Severity: | major | CC: | candrews, jkrzyszt, sir_tuam |
Priority: | High | ||
Version: | unspecified | ||
Hardware: | AMD64 | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Bug Depends on: | |||
Bug Blocks: | 245389 |
Description
Sylvain BERTRAND
2008-03-16 00:44:49 UTC
Really don't see how's this related to genkernel... When does this happen? What does your fstab look like? My system fstab related section is: /dev/sda1 /boot ext2 noauto,noatime 1 2 /dev/sda3 / ext3 noatime 0 1 /dev/sda2 none swap sw 0 0 In early user space, when running linuxrc, line 395 mounts ro my root fs: mount -o ro ${REAL_ROOT} ${NEW_ROOT} When I run "cat /proc/mounts" after this line I get: rootfs / rootfs rw 0 0 proc /proc proc rw 0 0 /sys /sys sysfs rw 0 0 /dev/sda3 /newroot ext2 ro 0 0 If I run "cat /proc/filesystems" before this linux I get: ... ext2 ext3 that means ext3 is available when that mount command is run. That's wrong, it should be ext3. Namely busybox mount fs autodetect is buggy or genkernel early user space misses something for busybox mount to work properly or I don't known, I did not pushed further the investigation. There's not really anything we can do in genkenel to prevent this. I'm not touching busybox again as I *just* upgraded it from 1.1.3 to 1.7.4. We can't go any higher anyway without a lot of work forward porting some patches. The only solution I see is to introduce *another* boot-time commandline option like real_root_type=, but that seems silly. >The only solution I see is to introduce *another* boot-time commandline option
>like real_root_type=, but that seems silly.
You are damn right.
I checked the code of busy box 1.7 and 1.9.
The singlemount function in mount.c (util-linux) code will try fs-type using fs-types in /etc/filesystems then /proc/filesystems.
It relies on the wrong idea that a fs cannot mount another fs. Of course this is untrue with ext2 and ext3.
So I added an initramfs overlay *one* file with *one* line:
/etc/filesystems:
ext3
That's it, mount will try first ext3.
You just need to add to the initramfs the /etc/filesystems with ext3 in it.
Don't randomly put other people on the CC. I already get bugmail via genkernel@g.o. That is an ugly, nasty hack. That will *never* go into the genkernel code. If you want to use it yourself, the --initramfs-overlay option is there for you to use. Ok, you think it's "a ugly hack". Great, but that does not help solve this pb, so: What would be the changes to perform on a GNU/Linux system in order to solve this issue "in a not ugly, neither nasty, hack way"? I see no reason why not to patch busybox for this. It's definitely the cleanest solution. Then, what would be the busybox proper "behavior" regarding that issue? Well, it should do the same thing that e2fsprogs does, which is the expected behavior, I'm sure. mount is part of sys-apps/util-linux, not the e2fsprogs. And busy box mimics the behavior of sys-apps/utils-linux (namely it does implement /etc/filesystems support). Looks like we just need an /etc/filesystems in the initramfs, no? I have been using the initramfs overlay feature of genkernel for a while. /etc/filesystems works. Another solution: do not use ext2 filesystem. I reckon we may have the same issue with ext3 and ext4 in the near future... (In reply to comment #3) > There's not really anything we can do in genkenel to prevent this. Well, I think there is one thing you can try. You can just change the order modules are loaded by changing MODULES_FS variable in /usr/share/genkernel/*/modules_load from "... ext2 ext3 ..." to "... ext3 ext2 ...". It works for me. The only exception I can see: ext2 is compiled in and ext3 as a module. Cheers, Janusz It looks like this issue is related to #221245 - and they probably share the same solution. Now I use the ext4 module for all my ext filesystems... seems to do the trick. This bug seems largely similar to bug #221245. To avoid duplication I am closing this bug as a duplicate. This is not meant to silence anyone of you. Please continue to discuss a solution with us on bug #221245 instead, which bugzilla should auto-CC you to at the moment the bug is closed as a duplicate. Let's see if that works. *** This bug has been marked as a duplicate of bug 221245 *** |