This problem I've spotted today from inspection of /etc/kernels/genkernel script. I suffered the exact same bug in SuSE-7.3, having (ironically) followed drobbins article on Advanced filesystems at the IBM developer site. For example, having mounted a tmpfs partion on /dev/shm/tmp : TEMP=/dev/shm/tmp; mount -t ext2 -o loop ${TEMP}/initrd ${TEMP}/kernel-initrd mount: wrong fs type, bad option, bad superblock on /dev/loop0, or too many mounted file systems (could this be the IDE device where you in fact use ide-scsi so that sr0 or sda or so is needed?) The comments on LKML for 2.4 was that it was non-trivial to fix loopback mounting on tmpfs, due to it's interaction with the VM. I got the same error today with 2.6-test4, so I don't think things will change. The patch I submitted to SuSE overcame this by looping round a list of likely locations for the initrd, seeking one that was likely to be loopback mountable and would make sense. I tried to code it for generality, allowing complete list of 'bad' filesystems, and easy addition of locations of temp directories. They didn't actually use this patch as a -t tmpdir option to allow user intervention was added, which just postponed the problem when automatic rpm kernel upgrades were added to the distro ; --- mk_initrd 2002/01/13 14:35:03 1.2 +++ mk_initrd 2002/01/14 15:59:07 @@ -1,5 +1,9 @@ #! /bin/bash +# +# $Id: mk_initrd,v 1.3 2002/01/14 15:58:07 rob Exp $ +# + # mk_initrd - create the inital ramdisk images # usage: see below usage() or call with -h # @@ -323,8 +327,19 @@ [ -n "$1" ] && root_dir="$1" [ "$root_dir" ] || root_dir=/ -tmp_initrd=$root_dir/tmp/initrd$$ +# 2002/01/14 : Rob : loopback mount fails when /tmp is tmpfs. +# : : Alter to check a list of temporary directories for +# : : 'banned' filesystem types. Default to /tmp if none pass. +# set -x +for tmp_initrddir in /tmp /var/tmp ~root /tmp +do + find ${root_dir}${tmp_initrddir} -maxdepth 0 -printf %F \ + | egrep -qs '(tmpfs|iso9660)' || break +done +tmp_initrd=${root_dir}${tmp_initrddir}/initrd$$ tmp_initrd_small=${tmp_initrd}_small +# set +x +# 2002/01/14 : Rob : End of patch. x1=`mount 2>/dev/null | grep "on $root_dir " | tail -1` x2=`echo \`echo "$x1" | wc -l\`` @@ -642,3 +657,11 @@ fi exit $exit_code + +# +# $Log: mk_initrd,v $ +# Revision 1.3 2002/01/14 15:58:07 rob +# Make initrd tmp directory scan a list, avoiding tmpfs file systems. Loopback mounts fail at moment (up to 2.4.16 SuSE kernel) looping back on tmpfs. +# Added RCS tags. +# +#
If you want a similar fix I will prepare a patch for /etc/kernels/genkernel, in busybox () : dd if=/dev/zero of=${TEMP}/initrd bs=1k count=5000 mke2fs -F -q -N5000 ${TEMP}/initrd mount -t ext2 -o loop ${TEMP}/initrd ${TEMP}/kernel-initrd would require altering to use an ${INITRD} calculated in way to check the file system. A simpler solution, would be to simply use /var/tmp, which traditionally cannot be tmpfs because of the directory /var/tmp/vi.recover.
OK, thanks for this info. I have to say, the fact that you can't loopback mount on tmpfs is rather nasty. A filesystem should be a filesystem and the underlying script shouldn't have to worry about this kind of thing :/ Not your fault of course... I'll cc pfeifer@gentoo.org and we'll see if there is some kind of kernel solution for this. Otherwise, any/all scripts that loopback mount will need to have special hackery to avoid b0rking.
Some pointers : The tmpfs implementer had described it as 'painful' to implement loopback in past, but more recently Andrew Morton said : http://marc.theaimsgroup.com/?l=linux-kernel&m=101009990816776&w=2 > /tmp# losetup /dev/loop/5 foo # Give foo to /dev/loop/5 > ioctl: LOOP_SET_FD: Invalid argument # DISCO!!! <o > <o > Yup, tmpfs doesn't provide some of the facilities which the loop driver requires. Specifically, prepare_write() and commit_write(). Probably it's not too hard to change loop to use generic_file_write(), and it will then permit tmpfs file-backed loop mounts. So may be altering loop is the way to go but that was said January 2002, and 2.6 is almost here, and loop still operating same old way. The simplest solution is to use /var/tmp for loopbacks, or use my fallback strategy testing /tmp. Maybe a script mklooptemp on lines of mktemp(1) would be a good solution?
What kernel are you using? Andrew Morton says this was fixed long ago: (pasted reply below...) Daniel Robbins <drobbins@gentoo.org> wrote: > > We have an open bug on tmpfs on loopback. That should have been fixed ages ago. It works for me: mount none /mnt/tmpfs -t tmpfs cd /mnt/tmpfs dd if=/dev/zero of=1 bs=1M count=100 mke2fs -F 1 mount -o loop /mnt/tmpfs/1 /mnt/loop0 It may be a matter of our kernel not being quite as up-to-date as it needs to be, or maybe you're using an older kernel?
Oh it's a regression then! I'm running 2.6.0-test4-mm5
I re-checked vanilla 2.4.22, 2.6.0-test4{,-mm5}, Andrew's right it has been fixed. Please close this report! On a SuSE 2.4.20 kernel I have 'ioctl: LOOP_SET_FD: Invalid argument'. So as long as Gentoo doesn't need to support older kernels, there's no problem. Guess I made a slip yesterday in my test not expecting it to work, so did not search for a mistake. Anyway that's good news it was a long standing irritating nit :) My apologies for the time, wonder how I missed the fix, I try to follow Changelogs, but I guess if there's a report on <= 2.4.20 it'll help.
Yeah, it's good to know what kernels are affected. Closing this bug.
