[Buildroot] Improper device nodes created inside project_build_arm/uclibc/root/dev/

[Buildroot] Improper device nodes created inside project_build_arm/uclibc/root/dev/

[Hebbar]

Hi,

I am trying to build arm9 toolchain using recent buildroot toolchain.
everything works fine except the device nodes inside my
project_build_arm/uclibc/root/dev/ directory.

oot at guru_vlinux:/opt/buildroot_plain# ls -la
project_build_arm/uclibc/root/dev/
total 0
drwxr-xr-x  3 root root 192 Apr 17 23:23 .
drwxr-xr-x 16 root root 408 Apr 17 22:44 ..
-rw-rw-rw-  1 root root   0 Apr 18 00:36 console
lrwxrwxrwx  1 root root  10 Apr 17 22:14 log -> ../tmp/log
-rw-rw-rw-  1 root root   0 Apr 18 00:36 null
drwxr-xr-x  2 root root  48 Apr 17 22:14 pts
-rw-rw-rw-  1 root root   0 Apr 18 00:36 ttyAMA0
-rw-rw-rw-  1 root root   0 Apr 18 00:36 zero

While it should be 

root at guru_vlinux:/opt/buildroot_plain# ls -la /dev/console /dev/null
/dev/zero
crw------- 1 root root 5, 1 Apr 18 12:10 /dev/console
crw-rw-rw- 1 root root 1, 3 Apr 18 08:08 /dev/null
crw-rw-rw- 1 root root 1, 5 Apr 18 08:08 /dev/zero

I have to manualy delete them and cp the basic one from my system root/dev.
Once i copy from root device nodes, i am able to load the root using nfs
mount or by compressing the root directory.

Why are the device nodes not properly cretaed. I have logged into console
with root privileges.

Thanks in advance

Regards
Gururaja
-- 
View this message in context: http://www.nabble.com/Improper-device-nodes-created-inside-project_build_arm-uclibc-root-dev--tp16803332p16803332.html
Sent from the BuildRoot mailing list archive at Nabble.com.

[Buildroot] Improper device nodes created inside project_build_arm/uclibc/root/dev/

[Hamish Moffatt]

On Sun, Apr 20, 2008 at 11:14:31PM -0700, Hebbar wrote:
> I am trying to build arm9 toolchain using recent buildroot toolchain.
> everything works fine except the device nodes inside my
> project_build_arm/uclibc/root/dev/ directory.
> 
> oot at guru_vlinux:/opt/buildroot_plain# ls -la
> project_build_arm/uclibc/root/dev/
> total 0
> drwxr-xr-x  3 root root 192 Apr 17 23:23 .
> drwxr-xr-x 16 root root 408 Apr 17 22:44 ..
> -rw-rw-rw-  1 root root   0 Apr 18 00:36 console

That's normal. They are only real devices within the fakeroot instance
used during the build. They are only normal files on disk (fakeroot is
playing tricks). Outside of fakeroot you see the regular files.

> I have to manualy delete them and cp the basic one from my system root/dev.

You should not need to do that.

What output image format are you using? (ext2fs etc)? Please post the
output of the final stages of make, where the fakeroot script is
generated and the image creation tool is run.


Hamish
-- 
Hamish Moffatt VK3SB <hamish@debian.org> <hamish@cloud.net.au>

[Buildroot] Improper device nodes created inside project_build_arm/uclibc/root/dev/

[Hebbar]

Hi,

    I use the root directory as it is for nfs boot. i put this directory
inside /etc/exports and mount it on my board at boot time. when i do this
linux kernel and busybox complains about missing /dev/console, /dev/ttyAMA0.

So i have delete previous device nodes and create a fresh node. Basically
device_table and fakeroot fails to create proper device nodes.

I have logged in through "su root" in console

Finall steps of "make world" is as below

********************************************************************
<snip>
<snip>
<snip>

test -x
/opt/buildroot_plain/build_arm/staging_dir/usr/bin/arm-linux-uclibcgnueabi-ldconfig
&&
/opt/buildroot_plain/build_arm/staging_dir/usr/bin/arm-linux-uclibcgnueabi-ldconfig
-r /opt/buildroot_plain/project_build_arm/uclibc/root 2>/dev/null
# Use fakeroot to pretend all target binaries are owned by root
rm -f
/opt/buildroot_plain/project_build_arm/uclibc/_fakeroot.rootfs.arm.ext2
touch /opt/buildroot_plain/project_build_arm/uclibc/.fakeroot.00000
cat /opt/buildroot_plain/project_build_arm/uclibc/.fakeroot* >
/opt/buildroot_plain/project_build_arm/uclibc/_fakeroot.rootfs.arm.ext2
echo "chown -R 0:0 /opt/buildroot_plain/project_build_arm/uclibc/root" >>
/opt/buildroot_plain/project_build_arm/uclibc/_fakeroot.rootfs.arm.ext2
# Use fakeroot to pretend to create all needed device nodes
echo "/opt/buildroot_plain/build_arm/staging_dir/bin/makedevs -d
target/device/Sanyo/kboard/device_table.txt
/opt/buildroot_plain/project_build_arm/uclibc/root" \
                >>
/opt/buildroot_plain/project_build_arm/uclibc/_fakeroot.rootfs.arm.ext2
# Use fakeroot so genext2fs believes the previous fakery
GENEXT2_REALSIZE=`LC_ALL=C du -s -c -k
/opt/buildroot_plain/project_build_arm/uclibc/root | grep total | sed -e
"s/total//"`; \
        GENEXT2_ADDTOROOTSIZE=`if [ $GENEXT2_REALSIZE -ge 20000 ]; then echo
16384; else echo 2400; fi`; \
        GENEXT2_SIZE=`expr $GENEXT2_REALSIZE + $GENEXT2_ADDTOROOTSIZE`; \
        GENEXT2_ADDTOINODESIZE=`find
/opt/buildroot_plain/project_build_arm/uclibc/root | wc -l`; \
        GENEXT2_INODES=`expr $GENEXT2_ADDTOINODESIZE + 400`; \
        set -x; \
        echo "/opt/buildroot_plain/build_arm/genext2fs-1.4/genext2fs -b
$GENEXT2_SIZE " \
                "-N $GENEXT2_INODES -d
/opt/buildroot_plain/project_build_arm/uclibc/root " \
                " -m 0 /opt/buildroot_plain/binaries/uclibc/rootfs.arm.ext2"
>> /opt/buildroot_plain/project_build_arm/uclibc/_fakeroot.rootfs.arm.ext2
+ echo '/opt/buildroot_plain/build_arm/genext2fs-1.4/genext2fs -b 18030 '
'-N 842 -d /opt/buildroot_plain/project_build_arm/uclibc/root ' ' -m 0
/opt/buildroot_plain/binaries/uclibc/rootfs.arm.ext2'
chmod a+x
/opt/buildroot_plain/project_build_arm/uclibc/_fakeroot.rootfs.arm.ext2
/opt/buildroot_plain/build_arm/staging_dir/usr/bin/fakeroot --
/opt/buildroot_plain/project_build_arm/uclibc/_fakeroot.rootfs.arm.ext2
rootdir=/opt/buildroot_plain/project_build_arm/uclibc/root
table='target/device/Sanyo/kboard/device_table.txt'
-rw-r--r-- 1 root root 18462720 Apr 22 11:51
/opt/buildroot_plain/binaries/uclibc/rootfs.arm.ext2
rm -f /opt/buildroot_plain/project_build_arm/uclibc/.fakeroot*

*************************************************************************

root at guru_vlinux:/opt/buildroot_plain# ls -la
project_build_arm/uclibc/root/dev/
total 0
drwxr-xr-x  2 root root 144 Apr 22 11:51 .
drwxr-xr-x 17 root root 432 Apr 22 11:50 ..
-rw-rw-rw-  1 root root   0 Apr 22 11:51 console
-rw-rw-rw-  1 root root   0 Apr 22 11:51 null
-rw-rw-rw-  1 root root   0 Apr 22 11:51 ttyAMA0
-rw-rw-rw-  1 root root   0 Apr 22 11:51 zero

If this is what it is suppose to do, then how to mount the same for NFS
boot. 

I checked the ext2 file created inside binaries/uclibc/rootfs.arm.ext2. I
mounted this ext2 file and found that the device nodes are properly created
inside /dev directory.

Kindly let me know what i should do to copy the root directory from
project_build_arm/uclibc/root for nfs boot.

Thanks in advance.

Regards
Gururaja


>That's normal. They are only real devices within the fakeroot instance
>used during the build. They are only normal files on disk (fakeroot is
>playing tricks). Outside of fakeroot you see the regular files.
>
>> I have to manualy delete them and cp the basic one from my system
>> root/dev.
>
>You should not need to do that.
>
>What output image format are you using? (ext2fs etc)? Please post the
>output of the final stages of make, where the fakeroot script is
>generated and the image creation tool is run.
>
>
>Hamish
>-- 
>Hamish Moffatt VK3SB <hamish@debian.org> <hamish@cloud.net.au>

-- 
View this message in context: http://www.nabble.com/Improper-device-nodes-created-inside-project_build_arm-uclibc-root-dev--tp16803332p16819059.html
Sent from the BuildRoot mailing list archive at Nabble.com.

[Buildroot] Improper device nodes created inside project_build_arm/uclibc/root/dev/

[Hamish Moffatt]

On Mon, Apr 21, 2008 at 05:12:30PM -0700, Hebbar wrote:
>     I use the root directory as it is for nfs boot. i put this directory
> inside /etc/exports and mount it on my board at boot time. when i do this
> linux kernel and busybox complains about missing /dev/console, /dev/ttyAMA0.
> 
> So i have delete previous device nodes and create a fresh node. Basically
> device_table and fakeroot fails to create proper device nodes.

Ah. The build process is not intended to create proper device nodes on
desk (non-root user can't do that); the image generation tools either
add the devices directly to the image or we use fakeroot to fake them.

> If this is what it is suppose to do, then how to mount the same for NFS
> boot. 

You could mount a generated image file somewhere via the loopback
device. Then you would have the devices that are in the image. ext2
would be a good choice. Do you want to write back to the root or not?

Alternatively you could add a new target output format for NFS root.

Finally you could use something other than NFS root, if you don't need
to write back to it. Perhaps have your boot loader load a ramdisk via tftp.


Hamish
-- 
Hamish Moffatt VK3SB <hamish@debian.org> <hamish@cloud.net.au>

[Buildroot] Improper device nodes created insideproject_build_arm/uclibc/root/dev/

[Gururaja Hebbar K R]

Hi,

Thanks for the help.

> The build process is not intended to create proper device nodes on
desk (non-root user can't do that)
i have logged into console with su root. i am using root shell for this

root at guru_vlinux:/opt/buildroot_plain# whoami
root

>You could mount a generated image file somewhere via the loopback
device. 
>
>Finally you could use something other than NFS root, if you don't need
to write back to it. Perhaps have your boot loader load a ramdisk via
tftp.
yes i tried this and this is working fine. But i am doing a development
project and i need to update the root all the time. so i use NFS boot.

>Alternatively you could add a new target output format for NFS root.
I need to do little study for this. once i know abt this i will try to
create a patch and send it to buildroot.

Regards
Gururaja

[Buildroot] Improper device nodes created insideproject_build_arm/uclibc/root/dev/

[Hamish Moffatt]

Hi,

On Tue, Apr 22, 2008 at 07:28:49AM +0530, Gururaja Hebbar K R wrote:
> > The build process is not intended to create proper device nodes on
> desk (non-root user can't do that)
> i have logged into console with su root. i am using root shell for this
> 
> root at guru_vlinux:/opt/buildroot_plain# whoami
> root

It doesn't matter, buildroot will use fakeroot anyway. It's not a good
idea to do development as the root user.

Also, some of the target methods don't create the device entries in the
project_build_$arch/$project/root directory at all - they are added to
the image by the generator tool without ever being on disk.

> >Finally you could use something other than NFS root, if you don't need
> to write back to it. Perhaps have your boot loader load a ramdisk via
> tftp.
> yes i tried this and this is working fine. But i am doing a development
> project and i need to update the root all the time. so i use NFS boot.

Although your changes will be lost when you rebuild the project anyway?
The project_build_$arch/$project/root is temporary.


Hamish
-- 
Hamish Moffatt VK3SB <hamish@debian.org> <hamish@cloud.net.au>

[Buildroot] Improper device nodes created insideproject_build_arm/uclibc/root/dev/

[Peter Korsgaard]

>>>>> "Hamish" == Hamish Moffatt <hamish@cloud.net.au> writes:

Hi,

 >> > The build process is not intended to create proper device nodes on
 >> desk (non-root user can't do that)
 >> i have logged into console with su root. i am using root shell for this
 >> 
 >> root at guru_vlinux:/opt/buildroot_plain# whoami
 >> root

Don't compile as root! Or atleast, don't come complaining when we make
a typo somewhere and accidently remove something critical on your
machine like /lib ;)

-- 
Bye, Peter Korsgaard

[Buildroot] Improper device nodes created inside project_build_arm/uclibc/root/dev/

[Peter Korsgaard]

>>>>> "Hamish" == Hamish Moffatt <hamish@cloud.net.au> writes:

Hi,

 >> If this is what it is suppose to do, then how to mount the same for NFS
 >> boot. 

 Hamish> You could mount a generated image file somewhere via the loopback
 Hamish> device. Then you would have the devices that are in the image. ext2
 Hamish> would be a good choice. Do you want to write back to the root or not?

 Hamish> Alternatively you could add a new target output format for NFS root.

We already have that - tarball creation.

-- 
Bye, Peter Korsgaard

[Buildroot] Improper device nodes created inside project_build_arm/uclibc/root/dev/

[Hamish Moffatt]

On Tue, Apr 22, 2008 at 09:14:16AM +0200, Peter Korsgaard wrote:
> >>>>> "Hamish" == Hamish Moffatt <hamish@cloud.net.au> writes:
> 
> Hi,
> 
>  >> If this is what it is suppose to do, then how to mount the same for NFS
>  >> boot. 
> 
>  Hamish> You could mount a generated image file somewhere via the loopback
>  Hamish> device. Then you would have the devices that are in the image. ext2
>  Hamish> would be a good choice. Do you want to write back to the root or not?
> 
>  Hamish> Alternatively you could add a new target output format for NFS root.
> 
> We already have that - tarball creation.

Good point. So, Hebbar: just use the tarball target, and extract it somewhere
(as root) for use by your target system. Don't mount the
buildroot/project_build.../.../root directory directly as it won't
contain the real devices.


Hamish
-- 
Hamish Moffatt VK3SB <hamish@debian.org> <hamish@cloud.net.au>

[Buildroot] Improper device nodes createdinside project_build_arm/uclibc/root/dev/

[Ulf Samuelsson]

> On Tue, Apr 22, 2008 at 09:14:16AM +0200, Peter Korsgaard wrote:
>> >>>>> "Hamish" == Hamish Moffatt <hamish@cloud.net.au> writes:
>> 
>> Hi,
>> 
>>  >> If this is what it is suppose to do, then how to mount the same for NFS
>>  >> boot. 
>> 
>>  Hamish> You could mount a generated image file somewhere via the loopback
>>  Hamish> device. Then you would have the devices that are in the image. ext2
>>  Hamish> would be a good choice. Do you want to write back to the root or not?
>> 
>>  Hamish> Alternatively you could add a new target output format for NFS root.
>> 
>> We already have that - tarball creation.
> 
> Good point. So, Hebbar: just use the tarball target, and extract it somewhere
> (as root) for use by your target system. Don't mount the
> buildroot/project_build.../.../root directory directly as it won't
> contain the real devices.
> 


Maybe we should have a configuration item allowing this to happen
automatically using "sudo".

I guess, in that case, we should have another 
configuration item (defaulting to no) which enables use of "sudo".

If we decide to do this, then I think that we need to be pretty
careful so we do not allow to untar in the host "/" directory or 
other directories which will destroy the host installation.

Maybe we should only allow it to be in "~/.buildroot/<project>/root".

Opinions?

Best Regards
Ulf Samuelsson                ulf at atmel.com
Atmel Nordic AB
Mail:  Box 2033, 174 02 Sundbyberg, Sweden
Visit:  Kavalleriv?gen 24, 174 58 Sundbyberg, Sweden
Phone +46 (8) 441 54 22     Fax +46 (8) 441 54 29
GSM    +46 (706) 22 44 57

[Buildroot] Improper device nodes createdinside project_build_arm/uclibc/root/dev/

[Peter Korsgaard]

>>>>> "Ulf" == Ulf Samuelsson <ulf.samuelsson@atmel.com> writes:

Hi,

 Ulf> Maybe we should have a configuration item allowing this to happen
 Ulf> automatically using "sudo".

I respectfully disagree. It doesn't add anything to using the tarball
option, and it opens up a can of worms (system libs getting
overridden).

-- 
Bye, Peter Korsgaard

[Buildroot] Improper device nodes createdinside project_build_arm/uclibc/root/dev/

[Ulf Samuelsson]

>>>>>> "Ulf" == Ulf Samuelsson <ulf.samuelsson@atmel.com> writes:
> 
> Hi,
> 
> Ulf> Maybe we should have a configuration item allowing this to happen
> Ulf> automatically using "sudo".
> 
> I respectfully disagree. It doesn't add anything to using the tarball
> option, and it opens up a can of worms (system libs getting
> overridden).
> 
> -- 
> Bye, Peter Korsgaard

Using the tarball is a manual process.
Manual processes are error-prone.
I agree that it is dangerous though, and needs to be carefully thought through.



Best Regards
Ulf Samuelsson                ulf at atmel.com
Atmel Nordic AB
Mail:  Box 2033, 174 02 Sundbyberg, Sweden
Visit:  Kavalleriv?gen 24, 174 58 Sundbyberg, Sweden
Phone +46 (8) 441 54 22     Fax +46 (8) 441 54 29
GSM    +46 (706) 22 44 57

[Buildroot] Improper device nodes createdinside project_build_arm/uclibc/root/dev/

[Peter Korsgaard]

>>>>> "Ulf" == Ulf Samuelsson <ulf.samuelsson@atmel.com> writes:

Hi,

 Ulf> Using the tarball is a manual process.
 Ulf> Manual processes are error-prone.

Well, if you can type make, then you can probably also type tar xvf

 Ulf> I agree that it is dangerous though, and needs to be carefully
 Ulf> thought through.

I still think it's needless bloat.

-- 
Bye, Peter Korsgaard

[Buildroot] Improper device nodes createdinside project_build_arm/uclibc/root/dev/

[Thiago A. Corrêa]

I have my own script for that, formats the sdcard, mounts it and
extracts the tar.

One could have a similar script in ~/buildroot/scripts for that, like
the one we have for the ext3 images. Then just point it out, no need
to have it on the make targets.

On Tue, Apr 22, 2008 at 5:52 PM, Peter Korsgaard <jacmet@uclibc.org> wrote:
> >>>>> "Ulf" == Ulf Samuelsson <ulf.samuelsson@atmel.com> writes:
>
>  Hi,
>
>   Ulf> Using the tarball is a manual process.
>   Ulf> Manual processes are error-prone.
>
>  Well, if you can type make, then you can probably also type tar xvf
>
>   Ulf> I agree that it is dangerous though, and needs to be carefully
>   Ulf> thought through.
>
>  I still think it's needless bloat.
>
>  --
>  Bye, Peter Korsgaard
>
>
> _______________________________________________
>  buildroot mailing list
>  buildroot at uclibc.org
>  http://busybox.net/mailman/listinfo/buildroot
>

[Buildroot] Improper device nodes createdinsideproject_build_arm/uclibc/root/dev/

[Ulf Samuelsson]

>I have my own script for that, formats the sdcard, mounts it and
> extracts the tar.
> 
> One could have a similar script in ~/buildroot/scripts for that, like
> the one we have for the ext3 images. Then just point it out, no need
> to have it on the make targets.
> 

You could generate scripts to build all packages...

Then you can remove ALL package/*/*.mk.

I do not think this is an improvement.

Why is it better to run a script than to be able to configure to
generate an SD-Card as part of the make?

>>  Hi,
>>
>>   Ulf> Using the tarball is a manual process.
>>   Ulf> Manual processes are error-prone.
>>
>>  Well, if you can type make, then you can probably also type tar xvf
>>
>>   Ulf> I agree that it is dangerous though, and needs to be carefully
>>   Ulf> thought through.
>>
>>  I still think it's needless bloat.

Do you generate SD-Cards images or not?
Have a feeling you here define bloat as something you do not use.

Best Regards
Ulf Samuelsson

[Buildroot] Improper device nodes createdinsideproject_build_arm/uclibc/root/dev/

[Peter Korsgaard]

>>>>> "Ulf" == Ulf Samuelsson <ulf.samuelsson@atmel.com> writes:

Hi,

 Ulf> You could generate scripts to build all packages...

 Ulf> Then you can remove ALL package/*/*.mk.

 Ulf> I do not think this is an improvement.

 Ulf> Why is it better to run a script than to be able to configure to
 Ulf> generate an SD-Card as part of the make?

Sure, but where to stop? I think most if not all disk based needs are
covered by the existing tar/ext2/ext3 support.

Adding more config options for really specialized stuff doesn't
increase usability imho.

 >>> I still think it's needless bloat.

 Ulf> Do you generate SD-Cards images or not?
 Ulf> Have a feeling you here define bloat as something you do not use.

Not in a current project, no - But I have (or rather CF cards, but
that's the same). What's the problem with the existing ext2 support?

-- 
Bye, Peter Korsgaard

[Buildroot] Improper device nodes createdinsideproject_build_arm/uclibc/root/dev/

[Ulf Samuelsson]

Subject: Re: [Buildroot] Improper device nodes createdinsideproject_build_arm/uclibc/root/dev/


>>>>>> "Ulf" == Ulf Samuelsson <ulf.samuelsson@atmel.com> writes:
> 
> Hi,
> 
> Ulf> You could generate scripts to build all packages...
> 
> Ulf> Then you can remove ALL package/*/*.mk.
> 
> Ulf> I do not think this is an improvement.
> 
> Ulf> Why is it better to run a script than to be able to configure to
> Ulf> generate an SD-Card as part of the make?
> 
> Sure, but where to stop? I think most if not all disk based needs are
> covered by the existing tar/ext2/ext3 support.

I am just talking about a configuration option which will 
write a file system generated using the existing options
to the SD-Card card.

config BR2_WRITE_SD_CARD
        string    "Write to SD-Card in the /mnt area"
        default "sdcard"


> 
> Adding more config options for really specialized stuff doesn't
> increase usability imho.

$(BR2_WRITE_TO_SD_CARD)/bin:    $(BINARIES_DIR)/<rootfs>
        extract "$(BINARIES_DIR)/<rootfs>" to "/mnt/$(BR2_WRITE_SD_CARD)"

Isn't really "specialilzed" stuff

> >>> I still think it's needless bloat.
> 
> Ulf> Do you generate SD-Cards images or not?
> Ulf> Have a feeling you here define bloat as something you do not use.
> 
> Not in a current project, no - But I have (or rather CF cards, but
> that's the same). What's the problem with the existing ext2 support?

It creates the file in $(BINARIES_DIR) and not on the SD-card.
It would make sense to allow creating a CF-card as well.

> 
> -- 
> Bye, Peter Korsgaard
>



Best Regards
Ulf Samuelsson

[Buildroot] Improper device nodes createdinsideproject_build_arm/uclibc/root/dev/

[Peter Korsgaard]

>>>>> "Ulf" == Ulf Samuelsson <ulf.samuelsson@atmel.com> writes:

Hi,

 >> Sure, but where to stop? I think most if not all disk based needs are
 >> covered by the existing tar/ext2/ext3 support.

 Ulf> I am just talking about a configuration option which will 
 Ulf> write a file system generated using the existing options
 Ulf> to the SD-Card card.

 Ulf> config BR2_WRITE_SD_CARD
 Ulf>         string    "Write to SD-Card in the /mnt area"
 Ulf>         default "sdcard"

Why special case SD cards? it can be any block device you want. What
about permissions?

I still think it's silly - What is next, add stuff to fire up a
terminal emulator (with config options for port and baudrate) and
upload file to bootloader?

 >> Not in a current project, no - But I have (or rather CF cards, but
 >> that's the same). What's the problem with the existing ext2 support?

 Ulf> It creates the file in $(BINARIES_DIR) and not on the SD-card.
 Ulf> It would make sense to allow creating a CF-card as well.

What's the difference between CF and SD card support? The big
difference between putting stuff in BINARIES_DIR and on some block
device is permissions. You can do everything in buildroot without root
permissions, let's not change that.

-- 
Bye, Peter Korsgaard

[Buildroot] Improper device nodes createdinsideproject_build_arm/uclibc/root/dev/

[Thiago A. Corrêa]

On Thu, Apr 24, 2008 at 6:31 AM, Peter Korsgaard <jacmet@uclibc.org> wrote:
> >>>>> "Ulf" == Ulf Samuelsson <ulf.samuelsson@atmel.com> writes:
>
>  >> Sure, but where to stop? I think most if not all disk based needs are
>   >> covered by the existing tar/ext2/ext3 support.
>
>   Ulf> I am just talking about a configuration option which will
>   Ulf> write a file system generated using the existing options
>   Ulf> to the SD-Card card.
>
>   Ulf> config BR2_WRITE_SD_CARD
>   Ulf>         string    "Write to SD-Card in the /mnt area"
>   Ulf>         default "sdcard"

This is not enough. You will also want to initialize the card... if
it's brand new, it has FAT in it,not ext2. And, if it has been used
before, it can have files in it from previous builds that will not be
in the current build.
To add to the issue, it's a removable media, you will want to make
sure it's mounted.

>  Why special case SD cards? it can be any block device you want. What
>  about permissions?
>
>  I still think it's silly - What is next, add stuff to fire up a
>  terminal emulator (with config options for port and baudrate) and
>  upload file to bootloader?

I agree... If you want to go an extra mile for the users, why not add
a script to ~/buildroot/script? It could be customized to one's need
if it's not perfect.

>
>   >> Not in a current project, no - But I have (or rather CF cards, but
>   >> that's the same). What's the problem with the existing ext2 support?
>
>   Ulf> It creates the file in $(BINARIES_DIR) and not on the SD-card.
>   Ulf> It would make sense to allow creating a CF-card as well.
>
>  What's the difference between CF and SD card support? The big
>  difference between putting stuff in BINARIES_DIR and on some block
>  device is permissions. You can do everything in buildroot without root
>  permissions, let's not change that.
>
>  --
>  Bye, Peter Korsgaard
>

[Buildroot] Improper device nodes created inside project_build_arm/uclibc/root/dev/

[Peter Korsgaard]

>>>>> "Hebbar" == Hebbar  <gururajakr@sanyo.co.in> writes:

 Hebbar> Hi,

 Hebbar>     I use the root directory as it is for nfs boot. i put
 Hebbar> this directory inside /etc/exports and mount it on my board
 Hebbar> at boot time. when i do this linux kernel and busybox
 Hebbar> complains about missing /dev/console, /dev/ttyAMA0.

Ahh, this is not how you should do it. Instead select the option to
create a tarball of the system and unpack it (with root permissions)
in your nfsroot.

-- 
Bye, Peter Korsgaard

[Buildroot] Improper device nodes created inside project_build_arm/uclibc/root/dev/

[Hebbar]

Hi,

Thanks to everyone for their valuable inputs. Now i am using tarball. i
untar and mount it for nfsboot and everything works fine now.  

Thanks again

Regards
Gururaja
-- 
View this message in context: http://www.nabble.com/Improper-device-nodes-created-inside-project_build_arm-uclibc-root-dev--tp16803332p16831542.html
Sent from the BuildRoot mailing list archive at Nabble.com.