|Summary:||anaconda refuses to mount ext2 file system|
|Product:||[Fedora] Fedora||Reporter:||Michal Jaegermann <michal>|
|Component:||anaconda||Assignee:||Anaconda Maintenance Team <anaconda-maint-list>|
|Status:||CLOSED RAWHIDE||QA Contact:|
|Fixed In Version:||Doc Type:||Bug Fix|
|Doc Text:||Story Points:||---|
|Last Closed:||2007-03-12 18:42:29 UTC||Type:||---|
|oVirt Team:||---||RHEL 7.3 requirements from Atomic Host:|
|Cloudforms Team:||---||Target Upstream Version:|
Description Michal Jaegermann 2007-03-04 23:37:15 UTC
Description of problem: I am booting over a network from images which are using kernel-2.6.20-1.2962.fc7 on x86_64 (after supplying fixed raid.py) in a rescue mode. Anaconda refuses to mount my boot partition. When trying directly mount /dev/sda1 /mnt/sysimage/boot a response is "failed: Invalid argument". An attempt to use '/mnt/sysimage/bin/mount' for the same operation gets even more interesting response: "mount: unknown filesystem type 'ext2'". ???? Nothing interesting in anaconda.log or syslog. A presence or absence of selinux does not matter. Version-Release number of selected component (if applicable): anaconda-188.8.131.52-1 How reproducible: always
Comment 1 Michal Jaegermann 2007-03-04 23:55:27 UTC
Full anaconda log, if of interest here, is attached to bug 230948.
Comment 2 Michal Jaegermann 2007-03-05 18:35:37 UTC
I started to wonder if 2.6.20-1.2962.fc7 has troubles mouting ext2 filesystems. This is NOT the case. When used outside of anaconda this kernel does not create any obstacles in mounting ext2 at all.
Comment 3 Jeremy Katz 2007-03-05 20:46:20 UTC
Does it work if you do 'mount -t ext2'? And what are the contents of /proc/filesystems?
Comment 4 Michal Jaegermann 2007-03-05 20:54:46 UTC
> Does it work if you do 'mount -t ext2'? Nope. That I tried. > And what are the contents of /proc/filesystems? Will have to check later. I'll be back.
Comment 5 Michal Jaegermann 2007-03-06 00:42:55 UTC
> And what are the contents of /proc/filesystems? Here we go: nodev sysfs nodev rootfs nodev bdev nodev proc nodev cpuset nodev binfmt_misc nodev debugfs nodev securityfs nodev sockfs nodev usbfs nodev pipefs nodev futexfs nodev tmpfs nodev inotifyfs nodev eventpollfs nodev devpts nodev ramfs nodev hugetlbfs iso9660 nodev mqueue nodev selinuxfs cramfs vfat nodev rpc_pipefs nodev nfs nodev nfs4 squashfs ext3 msdos gfs2 gfs2meta reiserfs jfs xfs and ext2 is indeed nowhere on that list. Oh, "mount -t ext2 /dev/sda1 /mnt/sysimage/boot" gets "... failed: No such device" error even after 'mknod /dev/sda1'. 'fdisk' and /tmp/syslog clearly show that this is really not the case.
Comment 6 David Lehman 2007-03-06 02:36:01 UTC
*** Bug 230916 has been marked as a duplicate of this bug. ***
Comment 7 Jeremy Katz 2007-03-06 02:43:51 UTC
ext2 was changed to be a module instead of built-in. Added to anaconda's module list and will probably be doing a build later tonight; if not, then tomorrow.
Comment 8 Bruno Wolff III 2007-03-08 18:17:41 UTC
I am still seeing problems using ext2 update floppies with today's and yesterday's boot.iso images. I thought I saw that 184.108.40.206-1 was being used; it certainly was available as an rpm before today's boot.iso image was made. According to the changelog file, that version should have the fix.
Comment 9 Michal Jaegermann 2007-03-08 22:54:14 UTC
The current rawhide anaconda indeed does have ext2 module in its initrd.img but the catch is that nothing loads it. I had the same mount failure with 20070308 images as before and 'grep ext /proc/filesystems' shows only ext3. Only after I unpacked ext2.ko from modules.cgz on initrd.img and did 'insmod ext2.ko' I was able to mount ext2 file system again. That worked but it is likely too much for a user who just wants to run some upgrades. :-) Oh, and after that insmod ext2 did show up in /proc/filesystems (not a real surprise).
Comment 10 Chris Lumens 2007-03-08 23:30:07 UTC
Thanks for the extra report. This should be fixed in the next build.
Comment 11 Michal Jaegermann 2007-03-12 19:41:30 UTC
Worksforme with images from 20070312 (2.6.20-1.2982.fc7 kernel is in use there). An output from lsmod from a shell provided by "rescue" in my case looks like follows and ext2 is there. Module Size Used by Not tainted dm_emc 15049 0 dm_round_robin 12481 0 dm_multipath 29145 2 dm_emc,dm_round_robin dm_snapshot 26593 0 dm_mirror 31745 0 dm_zero 10945 0 dm_mod 72945 11 dm_multipath,dm_snapshot,dm_mirror,dm_zero xfs 509833 0 jfs 178161 0 reiserfs 257137 0 lock_nolock 12609 0 gfs2 495865 1 lock_nolock msdos 19009 0 raid456 133761 0 xor 14545 1 raid456 raid1 33617 0 raid0 16705 0 pata_via 22085 0 sata_promise 23365 2 sata_via 21957 0 libata 133105 3 pata_via,sata_promise,sata_via skge 52193 0 e100 47337 0 mii 14657 1 e100 uhci_hcd 35561 0 ehci_hcd 44761 0 iscsi_tcp 34113 0 libiscsi 35793 1 iscsi_tcp scsi_transport_iscsi 41049 2 iscsi_tcp,libiscsi sr_mod 26981 0 sd_mod 31169 3 scsi_mod 170393 6 libata,iscsi_tcp,libiscsi,scsi_transport_iscsi,sr_mod,sd_mod cdrom 44777 1 sr_mod ipv6 347553 8 ext2 80121 1 ext3 145921 1 mbcache 18889 2 ext2,ext3 jbd 75601 1 ext3 squashfs 49393 1 pcspkr 12225 0 edd 19273 0 floppy 75465 0 loop 27489 2 nfs 265281 1 nfs_acl 12481 1 nfs lockd 78001 1 nfs sunrpc 195561 4 nfs,nfs_acl,lockd vfat 22465 0 fat 63753 2 msdos,vfat cramfs 52869 0