Improper device nodes created inside project_build_arm/uclibc/root/dev/
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
Signature · 2 lines
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.
Quoted 10 lines · Hebbar
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.
Quoted 1 line
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
Signature · 1 line
Hamish Moffatt VK3SB <[email protected]> <[email protected]>
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"
Quoted 1 line
Quoted 1 line
/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
Quoted 17 lines
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.
Quoted 2 lines
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
Signature · 1 line
Hamish Moffatt VK3SB <[email protected]> <[email protected]>
Signature · 2 lines
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.
Quoted 6 lines · Hebbar
I use the root directory as it is for nfs boot. i put this directory
inside/etc/exportsand 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_tableand 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.
Quoted 2 lines
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
Signature · 1 line
Hamish Moffatt VK3SB <[email protected]> <[email protected]>
[Buildroot] Improper device nodes created insideproject_build_arm/uclibc/root/dev/
Hi,
Thanks for the help.
Quoted 1 line
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
Quoted 1 line
You could mount a generated image file somewhere via the loopback
device.
Quoted 2 lines
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.
Quoted 1 line
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/
Hi,
Quoted 6 lines · Gururaja Hebbar K R
Quoted 1 line
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 thisroot 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.
Quoted 5 lines
Quoted 1 line
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
Signature · 1 line
Hamish Moffatt VK3SB <[email protected]> <[email protected]>
[Buildroot] Improper device nodes created insideproject_build_arm/uclibc/root/dev/
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
"Hamish" == Hamish Moffatt <[email protected]> writes:
Hi,
Quoted 6 lines
Quoted 6 lines
Quoted 1 line
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 thisroot 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 ;)
Signature · 1 line
Bye, Peter Korsgaard
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
"Hamish" == Hamish Moffatt <[email protected]> writes:
Hi,
Quoted 2 lines
Quoted 2 lines
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.
Signature · 1 line
Bye, Peter Korsgaard
Quoted 7 lines · Peter Korsgaard
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
"Hamish" == Hamish Moffatt <[email protected]> writes:
Hi,
Quoted 2 lines
Quoted 2 lines
If this is what it is suppose to do, then how to mount the same for NFS boot.
Quoted 7 lines
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
Signature · 1 line
Hamish Moffatt VK3SB <[email protected]> <[email protected]>
[Buildroot] Improper device nodes createdinside project_build_arm/uclibc/root/dev/
Quoted 14 lines · Peter Korsgaard
Quoted 11 lines
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
"Hamish" == Hamish Moffatt <[email protected]> writes:
Hi,
Quoted 2 lines
Quoted 2 lines
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?
Quoted 9 lines
Quoted 3 lines
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/
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
"Ulf" == Ulf Samuelsson <[email protected]> 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).
Signature · 1 line
Bye, Peter Korsgaard
[Buildroot] Improper device nodes createdinside project_build_arm/uclibc/root/dev/
Quoted 13 lines
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
"Ulf" == Ulf Samuelsson <[email protected]> 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).
Signature · 1 line
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/
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
"Ulf" == Ulf Samuelsson <[email protected]> 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.
Signature · 1 line
Bye, Peter Korsgaard
[Buildroot] Improper device nodes createdinside project_build_arm/uclibc/root/dev/
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.
Quoted 23 lines · Peter Korsgaard
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
"Ulf" == Ulf Samuelsson <[email protected]> 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/
Quoted 7 lines
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?
Quoted 11 lines
Quoted 11 lines
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/
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
"Ulf" == Ulf Samuelsson <[email protected]> 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.
Quoted 1 line
Quoted 1 line
Quoted 1 line
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?
Signature · 1 line
Bye, Peter Korsgaard
[Buildroot] Improper device nodes createdinsideproject_build_arm/uclibc/root/dev/
Subject: Re: [Buildroot] Improper device nodes createdinsideproject_build_arm/uclibc/root/dev/
Quoted 8 lines
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
"Ulf" == Ulf Samuelsson <[email protected]> writes:
Hi,
Ulf> You could generate scripts to build all packages...
Ulf> Then you can remove ALL package/*/*.mk.
Quoted 7 lines
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"
Quoted 3 lines
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
Quoted 7 lines
Quoted 1 line
Quoted 1 line
Quoted 1 line
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.
Quoted 4 lines
Signature · 2 lines
-- Bye, Peter Korsgaard
Best Regards
Ulf Samuelsson
[Buildroot] Improper device nodes createdinsideproject_build_arm/uclibc/root/dev/
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
"Ulf" == Ulf Samuelsson <[email protected]> writes:
Hi,
Quoted 2 lines
Quoted 2 lines
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?
Quoted 2 lines
Quoted 2 lines
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.
Signature · 1 line
Bye, Peter Korsgaard
[Buildroot] Improper device nodes createdinsideproject_build_arm/uclibc/root/dev/
Quoted 5 lines · Peter Korsgaard
Quoted 4 lines
Quoted 4 lines
Quoted 1 line
Quoted 1 line
Quoted 1 line
"Ulf" == Ulf Samuelsson <[email protected]> writes:
Sure, but where to stop? I think most if not all disk based needs are covered by the existing tar/ext2/ext3 support.
Quoted 7 lines
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.
Quoted 6 lines
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.
Quoted 15 lines
Quoted 3 lines
Quoted 3 lines
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_DIRand on some block device is permissions. You can do everything in buildroot without root permissions, let's not change that.--
Bye, Peter Korsgaard
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
"Hebbar" == Hebbar <[email protected]> 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.
Signature · 1 line
Bye, Peter Korsgaard
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
Signature · 2 lines
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.