[uClibc]Confusing uClibc messages

WILSON,RICH (A-LakeStevens,ex1) rich_wilson at agilent.com
Mon Aug 26 16:01:04 UTC 2002


Karim,

I had a very similar-looking problem with mount on power-pc.  I spent
some time tracking it down to a bug in the kernel.

I found that I could work around the problem by typing, for example,

# mount -t jffs2 -o kernelhasabug /dev/mtdblock5 /mnt

If you strace the failing call, you'll probably see an argument to
the kernel system call that's right at the end of valid memory,
and that confuses the kernel.  Changing almost anything causes
more memory to be allocated, and the problem seems to go away.

Rich

Rich Wilson
Agilent Technologies
425-335-2245
rich_wilson at agilent.com

> -----Original Message-----
> From: Karim Yaghmour [mailto:karim at opersys.com]
> Sent: Friday, August 23, 2002 10:59 PM
> To: uClibc
> Subject: [uClibc]Confusing uClibc messages
> 
> 
> 
> I had been conducting tests with uClibc which involved quite a few
> steps. One of them was mounting a filesystem using BusyBox. Here's
> what was happening:
> # mount -t jffs2 /dev/mtdblock5 /mnt
> mount: Mounting /dev/mtdblock5 on /mnt failed: Bad address
> 
> No need to say that "Bad address" wasn't very informative. Especially
> since the kernel had JFFS2 support and both /dev/mtdblockX and /mnt
> existed on the rootfs.
> 
> I dug a little and tried a couple of things, including changing the
> root fs a couple of times. At some point I decided to give glibc
> a try. Using the same command as earlier, I got:
> # mount -t jffs2 /dev/mtdblock5 /mnt
> mount: Mounting /dev/mtdblock5 on /mnt failed: No such file 
> or directory
> 
> Apparently, I had forgotten to recreate the /mnt directory while
> rebuilding my rootfs during my experiments. Earlier, however, the
> directory was indeed present. Hence, I have a case here where there
> was an undetermined error in the begining that I later fixed
> at some point during my experiments but uClibc kept reporting
> "Bad address" throughout. I cannot therefore determine either the
> nature of the initial error nor the point at which I fixed it.
> 
> Is there any reason why uClibc would report different messages (i.e.
> see different system call errors) from glibc?
> 
> Karim
> 
> ===================================================
>                  Karim Yaghmour
>                karim at opersys.com
>       Embedded and Real-Time Linux Expert
> ===================================================
> _______________________________________________
> uClibc mailing list
> uClibc at uclibc.org
> http://uclibc.org/mailman/listinfo/uclibc
> 



More information about the uClibc mailing list