Charles,With Bering-uClibc, initial ramdisk 1.5 Mbyte.
Very odd. Is this with Bering or Bering-uClibc? How big is your initial ramdisk?
It looks like the initial ramdisk might be filling up prior to getting the new tmpfs root created and running pivot_root (possibly because I'm creating the devices directory prior tomountingroot...maybe /dev should be temporarily mounted on a /tmpfs?).That's possible but strange, because the contents of the initrd is "smaller" than with Bering (smaller libs in initrd).
OK, I'm running into two distinct problems so-far, and I haven't even tried booting with your initrd file yet!
Testing procedure:
Decompress initial ramdisk file and mount as a loopback device on a handy linux box.
Chroot to the initial ramdisk and run ash: chroot /mnt/wherever /bin/ash
Manually run bits of /linuxrc at the command prompt until something odd happens. I do this with two ssh windows open, one to vi editing /linuxrc, and one to the chroot'd environment. I just skip the kernel and command-line specific bits (ie: installing modules and bailing if root != /dev/ram).
The problems I've seen so far:
1) The creation of the FILESYSTEMS variable doesn't seem to be 'sticking'. The variable is getting properly created, but it doesn't seem to be visible outside the routine that creates it:
# set -x # cat /proc/filesystems | > while read FS ; do > case $FS in > nodev*) continue ;; > esac > FILESYSTEMS="$FILESYSTEMS $FS" > done ; echo $FILESYSTEMS + cat /proc/filesystems + read FS + continue + read FS + continue + read FS + continue + read FS + continue + read FS + continue + read FS + continue + read FS + continue + read FS + FILESYSTEMS= ext2 + read FS + continue + read FS + FILESYSTEMS= ext2 iso9660 + read FS + continue + read FS + FILESYSTEMS= ext2 iso9660 ext3 + read FS + continue + read FS + continue + read FS + continue + read FS + FILESYSTEMS= ext2 iso9660 ext3 vfat + read FS + FILESYSTEMS= ext2 iso9660 ext3 vfat minix + read FS + FILESYSTEMS= ext2 iso9660 ext3 vfat minix msdos + read FS + echo
# echo $FILESYSTEMS + echo
#
2) The ramdisk is filling up when running root.dev.mk:
ln -sf ram0 ramdisk >null 2>&1 + ln -sf ram0 ramdisk ln -sf ram0 ram >null 2>&1 + ln -sf ram0 ram
# Locate an IDE or SSCI CD-ROM drive
unset CDDEV + unset CDDEV
for file in /proc/ide/hd?/media /proc/scsi/scsi; do
[ -r $file ] || continue
while read line ; do
case $line in
*CD-ROM*|*cdrom*)
CDDEV=${file#/proc/*/}
CDDEV=${CDDEV%/media}
[ "$CDDEV" = "scsi" ] && CDDEV=scd0
break 2
;;
esac
done <$file
done
+ [ -r /proc/ide/hda/media ]
+ read line
+ read line
+ [ -r /proc/ide/hdb/media ]
+ read line
+ CDDEV=hdb/media
+ CDDEV=hdb
+ [ hdb = scsi ]
+ break 2[ -n "$CDDEV" ] && ln -sf /dev/$CDDEV /dev/cdrom + [ -n hdb ] + ln -sf /dev/hdb /dev/cdrom ln: /dev/cdrom: No space left on device
# ubd devices for UML (J. Nilo) mknod /dev/ubd0 b 98 0 >null 2>&1 + mknod /dev/ubd0 b 98 0 mknod /dev/ubd1 b 98 1 >null 2>&1 + mknod /dev/ubd1 b 98 1
cd / + cd / #
NOTES)
The ramdisk is not actually full of data. In fact, it's only about 58% full:
# df <snip> /home/charles/testing/initrd 1480 856 624 58% /mnt/initrd
...however, I strongly suspect the ramdisk has run out of inodes.
Why this is happening with Bering-uClibc and not with 'regular' Bering, is unclear, unless the initial ramdisk images were formatted differently (it's possible to specify the number of inodes when running mkfs.minix).
I believe either (or both) of these would be enough to prevent proper boot, but it looks like the full ramdisk problem is what you're running into, based on the error output.
Possible solutions include increasing the number of available inodes in the initrd image, reducing the number of devices in root.dev.mk (perhaps splitting this into two files...one for boot/package devices, and one for everything else...only block devices would need to be created prior to creating/mounting the real tmpfs root, which shouldn't have space/inode problems), mounting a tmpfs /dev just for finding the leaf.cfg device, and probably other solutions I'm not thinking of right now.
Of the above, I'd probably suggest the second option (split the device creation into multiple files), possibly combined with the first solution (add more inodes to the minix filesystem image).
Any idea why the FILESYSTEMS variable is behaving oddly?
-- Charles Steinkuehler [EMAIL PROTECTED]
------------------------------------------------------- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
_______________________________________________ leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
