* [Buildroot] [PATCH] libgcrypt: add license information
From: Peter Korsgaard @ 2012-11-08 21:36 UTC (permalink / raw)
To: buildroot
In-Reply-To: <50504096.5030401@mimc.co.uk>
>>>>> "Mark" == Mark Jackson <mpfj-list@mimc.co.uk> writes:
Mark> Signed-off-by: Mark Jackson <mpfj@newflow.co.uk>
Committed, thanks.
--
Bye, Peter Korsgaard
^ permalink raw reply
* [Buildroot] [git commit] libgcrypt: add license information
From: Peter Korsgaard @ 2012-11-08 21:36 UTC (permalink / raw)
To: buildroot
commit: http://git.buildroot.net/buildroot/commit/?id=ce70d058f55096a16352d4428f6833c953cd9b7c
branch: http://git.buildroot.net/buildroot/commit/?id=refs/heads/master
Signed-off-by: Mark Jackson <mpfj@newflow.co.uk>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
---
package/libgcrypt/libgcrypt.mk | 2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/package/libgcrypt/libgcrypt.mk b/package/libgcrypt/libgcrypt.mk
index db5781b..a320e48 100644
--- a/package/libgcrypt/libgcrypt.mk
+++ b/package/libgcrypt/libgcrypt.mk
@@ -6,6 +6,8 @@
LIBGCRYPT_VERSION = 1.5.0
LIBGCRYPT_SOURCE = libgcrypt-$(LIBGCRYPT_VERSION).tar.bz2
+LIBGCRYPT_LICENSE = LGPLv2.1+
+LIBGCRYPT_LICENSE_FILES = COPYING.LIB
LIBGCRYPT_SITE = ftp://ftp.gnupg.org/gcrypt/libgcrypt
LIBGCRYPT_INSTALL_STAGING = YES
^ permalink raw reply related
* [Buildroot] [PATCH] ntp: add license information
From: Peter Korsgaard @ 2012-11-08 21:35 UTC (permalink / raw)
To: buildroot
In-Reply-To: <505043B2.9030502@mimc.co.uk>
>>>>> "Mark" == Mark Jackson <mpfj-list@mimc.co.uk> writes:
Mark> Signed-off-by: Mark Jackson <mpfj@newflow.co.uk>
Commmitted, thanks.
--
Bye, Peter Korsgaard
^ permalink raw reply
* [Buildroot] [PATCH 2/2] netatalk: Make BerkeleyDB optional for Netatalk
From: Maxime Hadjinlian @ 2012-11-08 21:34 UTC (permalink / raw)
To: buildroot
In-Reply-To: <1352057123-7137-2-git-send-email-maxime.hadjinlian>
As the documentation of netatalk states :
"dbd is the default backend since version 2.1"
So cdb (which is the CNID provided by BerkeleyDB) should not be the default.
Also, this patches fixes a trouble when compiling with berkeleydb in 64bits
where netatalk would look the berkeleylib in [...]/lib64 instead of [...]/lib
Signed-off-by: Maxime Hadjinlian <maxime.hadjinlian@gmail.com>
---
package/netatalk/Config.in | 1 -
package/netatalk/netatalk.mk | 16 ++++++++++++----
2 files changed, 12 insertions(+), 5 deletions(-)
diff --git a/package/netatalk/Config.in b/package/netatalk/Config.in
index 26f14c3..e602acd 100644
--- a/package/netatalk/Config.in
+++ b/package/netatalk/Config.in
@@ -1,6 +1,5 @@
config BR2_PACKAGE_NETATALK
bool "netatalk"
- select BR2_PACKAGE_BERKELEYDB
select BR2_PACKAGE_OPENSSL
select BR2_PACKAGE_LIBGCRYPT
select BR2_PACKAGE_LIBGPG_ERROR
diff --git a/package/netatalk/netatalk.mk b/package/netatalk/netatalk.mk
index 4aa179e..70c8a13 100644
--- a/package/netatalk/netatalk.mk
+++ b/package/netatalk/netatalk.mk
@@ -7,11 +7,10 @@ NETATALK_VERSION = 3.0
NETATALK_SITE = http://downloads.sourceforge.net/project/netatalk/netatalk/$(NETATALK_VERSION)
NETATALK_SOURCE = netatalk-$(NETATALK_VERSION).tar.bz2
-NETATALK_DEPENDENCIES = host-pkg-config openssl berkeleydb libgcrypt libgpg-error
+NETATALK_DEPENDENCIES = host-pkg-config openssl libgcrypt libgpg-error
NETATALK_CONF_ENV += CC="$(TARGET_CC) -std=gnu99"
-NETATALK_CONF_OPT += --with-cnid-cdb-backend \
- --with-bdb=$(STAGING_DIR)/usr \
- --disable-zeroconf \
+
+NETATALK_CONF_OPT += --disable-zeroconf \
--with-ssl-dir=$(STAGING_DIR)/usr \
--with-libgcrypt-dir=$(STAGING_DIR)/usr \
--with-shadow \
@@ -19,6 +18,15 @@ NETATALK_CONF_OPT += --with-cnid-cdb-backend \
--without-kerberos \
--without-pam
+ifeq ($(BR2_PACKAGE_BERKELEYDB),y)
+ NETATALK_DEPENDENCIES += berkeleydb
+ NETATALK_CONF_ENV += BDB_LIB=$(STAGING_LIB)/usr/lib
+ NETATALK_CONF_OPT += --with-cnid-cdb-backend \
+ --with-bdb=$(STAGING_DIR)/usr
+else
+ NETATALK_CONF_OPT += --without-cnid-cdb-backend
+endif
+
ifeq ($(BR2_PACKAGE_CUPS),y)
NETATALK_DEPENDENCIES += cups
NETATALK_CONF_ENV += ac_cv_path_CUPS_CONFIG=$(STAGING_DIR)/usr/bin/cups-config
--
1.7.10.4
^ permalink raw reply related
* [Buildroot] [PATCH 1/2] netatalk: Add missing dependency to netatalk
From: Maxime Hadjinlian @ 2012-11-08 21:32 UTC (permalink / raw)
To: buildroot
In-Reply-To: <CAGduivyH58U-11zTOZRqpcF-HrtFxeunom1xtjPFZaPZBvswpQ@mail.gmail.com>
Netatalk need pkg-config, otherwise the configure script is complaining.
Signed-off-by: Maxime Hadjinlian <maxime.hadjinlian@gmail.com>
---
package/netatalk/netatalk.mk | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/package/netatalk/netatalk.mk b/package/netatalk/netatalk.mk
index c01e360..4aa179e 100644
--- a/package/netatalk/netatalk.mk
+++ b/package/netatalk/netatalk.mk
@@ -7,7 +7,7 @@ NETATALK_VERSION = 3.0
NETATALK_SITE = http://downloads.sourceforge.net/project/netatalk/netatalk/$(NETATALK_VERSION)
NETATALK_SOURCE = netatalk-$(NETATALK_VERSION).tar.bz2
-NETATALK_DEPENDENCIES = openssl berkeleydb libgcrypt libgpg-error
+NETATALK_DEPENDENCIES = host-pkg-config openssl berkeleydb libgcrypt libgpg-error
NETATALK_CONF_ENV += CC="$(TARGET_CC) -std=gnu99"
NETATALK_CONF_OPT += --with-cnid-cdb-backend \
--with-bdb=$(STAGING_DIR)/usr \
--
1.7.10.4
^ permalink raw reply related
* [Buildroot] [PATCH 1/2] netatalk: Add missing dependency to netatalk
From: Maxime Hadjinlian @ 2012-11-08 21:31 UTC (permalink / raw)
To: buildroot
In-Reply-To: <CAGduivyH58U-11zTOZRqpcF-HrtFxeunom1xtjPFZaPZBvswpQ@mail.gmail.com>
Netatalk need pkg-config, otherwise the configure script is complaining.
Signed-off-by: Maxime Hadjinlian <maxime.hadjinlian@gmail.com>
---
package/netatalk/netatalk.mk | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/package/netatalk/netatalk.mk b/package/netatalk/netatalk.mk
index c01e360..4aa179e 100644
--- a/package/netatalk/netatalk.mk
+++ b/package/netatalk/netatalk.mk
@@ -7,7 +7,7 @@ NETATALK_VERSION = 3.0
NETATALK_SITE = http://downloads.sourceforge.net/project/netatalk/netatalk/$(NETATALK_VERSION)
NETATALK_SOURCE = netatalk-$(NETATALK_VERSION).tar.bz2
-NETATALK_DEPENDENCIES = openssl berkeleydb libgcrypt libgpg-error
+NETATALK_DEPENDENCIES = host-pkg-config openssl berkeleydb libgcrypt libgpg-error
NETATALK_CONF_ENV += CC="$(TARGET_CC) -std=gnu99"
NETATALK_CONF_OPT += --with-cnid-cdb-backend \
--with-bdb=$(STAGING_DIR)/usr \
--
1.7.10.4
^ permalink raw reply related
* [Buildroot] [git commit] ntp: add license information
From: Peter Korsgaard @ 2012-11-08 21:30 UTC (permalink / raw)
To: buildroot
commit: http://git.buildroot.net/buildroot/commit/?id=1c03b907bb770b16e19b2b366a95c3cdedc09d57
branch: http://git.buildroot.net/buildroot/commit/?id=refs/heads/master
Signed-off-by: Mark Jackson <mpfj@newflow.co.uk>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
---
package/ntp/ntp.mk | 2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/package/ntp/ntp.mk b/package/ntp/ntp.mk
index 504ede7..a9a7f10 100644
--- a/package/ntp/ntp.mk
+++ b/package/ntp/ntp.mk
@@ -6,6 +6,8 @@
NTP_VERSION = 4.2.6p5
NTP_SITE = http://www.eecis.udel.edu/~ntp/ntp_spool/ntp4/ntp-4.2
+NTP_LICENSE = ntp license
+NTP_LICENSE_FILES = COPYRIGHT
NTP_CONF_ENV = ac_cv_lib_md5_MD5Init=no
ifneq ($(BR2_INET_IPV6),y)
^ permalink raw reply related
* [Buildroot] no jack?
From: Arnout Vandecappelle @ 2012-11-08 21:26 UTC (permalink / raw)
To: buildroot
In-Reply-To: <874nl09hs9.fsf@dell.be.48ers.dk>
On 11/08/12 17:32, Peter Korsgaard wrote:
>>>>>> "Arnout" == Arnout Vandecappelle<arnout@mind.be> writes:
>
> Arnout> On 06/11/12 22:39, Grant wrote:
> >> Is there a jack package available for buildroot?
>
> Arnout> No, but it shouldn't be too difficult to integrate. Look at
> Arnout> midori for an example of a package using waf as the build
> Arnout> system.
>
> Waf is btw a pain. It seems to fail on one of the autobuilders (host
> python issue?)
Do you have an autobuilder ref for that? I can't find any midori build
failures (but since there's no search function...)
Regards,
Arnout
--
Arnout Vandecappelle arnout at mind be
Senior Embedded Software Architect +32-16-286540
Essensium/Mind http://www.mind.be
G.Geenslaan 9, 3001 Leuven, Belgium BE 872 984 063 RPR Leuven
LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle
GPG fingerprint: 7CB5 E4CC 6C2E EFD4 6E3D A754 F963 ECAB 2450 2F1F
^ permalink raw reply
* [Buildroot] Autotest infrastructure (a bit of off-topic: git repo URL)
From: Arnout Vandecappelle @ 2012-11-08 21:21 UTC (permalink / raw)
To: buildroot
In-Reply-To: <509BDBF2.1060700@digi.com>
Pretty off-topic indeed... but I don't mind :-)
On 11/08/12 17:21, Javier Viguera wrote:
> I attended the other day to your talk on "upgrading without bricking" (congrats for that, i learned a lot) and you
> mentioned a repo where you have started collecting some tools/scripts to do the job.
>
> Could you remind me that repo URL? I shouldn't have trust i would remember it some days after.
https://gitorious.org/gupies
But as I mentioned, it's still pretty empty... I expect to really start
committing something in a week or two.
I've also created a mailing list, but it's on google groups which sucks
somewhat: https://groups.google.com/group/gupies/subscribe
If you have a better idea, I'd welcome that.
Regards,
Arnout
--
Arnout Vandecappelle arnout at mind be
Senior Embedded Software Architect +32-16-286540
Essensium/Mind http://www.mind.be
G.Geenslaan 9, 3001 Leuven, Belgium BE 872 984 063 RPR Leuven
LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle
GPG fingerprint: 7CB5 E4CC 6C2E EFD4 6E3D A754 F963 ECAB 2450 2F1F
^ permalink raw reply
* [Buildroot] Udev on a live CD system does not appear to populate /dev
From: Arnout Vandecappelle @ 2012-11-08 21:17 UTC (permalink / raw)
To: buildroot
In-Reply-To: <509BD78A.8050908@macrium.com>
On 11/08/12 17:02, Antony Vennard wrote:
> I am using grub, and have modified my grub command line to use:
>
> title LiveCD
> kernel /vmlinuz vga=0x317
> initrd /initramfs.bz2
>
> The kernel has bz2, xz and gzip initramfs support built in - so all good
> there. However, the kernel complains there's no root parameter. What
> should I specify for this?
If you build a cpio rootfs, you shouldn't need any additional command line
parameters because the kernel never gets to mounting the root filesystem. It
just runs the /init in the initramfs.
Using a cpio rootfs should also solve your problems with the device nodes,
because we provide a /init that mounts devtmpfs explicitly.
Regards,
Arnout
--
Arnout Vandecappelle arnout at mind be
Senior Embedded Software Architect +32-16-286540
Essensium/Mind http://www.mind.be
G.Geenslaan 9, 3001 Leuven, Belgium BE 872 984 063 RPR Leuven
LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle
GPG fingerprint: 7CB5 E4CC 6C2E EFD4 6E3D A754 F963 ECAB 2450 2F1F
^ permalink raw reply
* [Buildroot] Udev on a live CD system does not appear to populate /dev
From: Arnout Vandecappelle @ 2012-11-08 21:09 UTC (permalink / raw)
To: buildroot
In-Reply-To: <509AA0C4.4060506@petroprogram.com>
On 11/07/12 18:56, Stefan Fr?berg wrote:
> Nope, no sudo in my live Cd.
> Just few pre-made device nodes in fs/skeleton/dev
So, when buildroot copies these to output/target/dev you get:
cp: cannot create special file `...': Operation not permitted
unless you run the build as root.
Regards,
Arnout
--
Arnout Vandecappelle arnout at mind be
Senior Embedded Software Architect +32-16-286540
Essensium/Mind http://www.mind.be
G.Geenslaan 9, 3001 Leuven, Belgium BE 872 984 063 RPR Leuven
LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle
GPG fingerprint: 7CB5 E4CC 6C2E EFD4 6E3D A754 F963 ECAB 2450 2F1F
^ permalink raw reply
* [Buildroot] [PATCH 1/2] xtensa: add support for the Xtensa architecture
From: Arnout Vandecappelle @ 2012-11-08 21:01 UTC (permalink / raw)
To: buildroot
In-Reply-To: <509b2947.a6e6440a.547c.7082@mx.google.com>
On 11/08/12 04:38, Chris Zankel wrote:
> config BR2_USE_MMU
> - bool "Enable MMU support" if BR2_arm || BR2_armeb || BR2_mips || BR2_mipsel || BR2_sh
> + bool "Enable MMU support" if BR2_arm || BR2_armeb || BR2_mips || BR2_mipsel || BR2_sh || BR2_xtensa
> default y if !BR2_bfin
So the Xtensa, a configurable processor, always has a MMU?
Regards,
Arnout
--
Arnout Vandecappelle arnout at mind be
Senior Embedded Software Architect +32-16-286540
Essensium/Mind http://www.mind.be
G.Geenslaan 9, 3001 Leuven, Belgium BE 872 984 063 RPR Leuven
LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle
GPG fingerprint: 7CB5 E4CC 6C2E EFD4 6E3D A754 F963 ECAB 2450 2F1F
^ permalink raw reply
* [Buildroot] Need arm-buildroot config and arm-linux config
From: Stefan Fröberg @ 2012-11-08 19:25 UTC (permalink / raw)
To: buildroot
Hello everyone
I have now tried several times to build working arm-virtual image for
use with qemu.
Once i even managed to run it with qemu but then I made some changes
that I don't remember anymore
and it has stopped working again (just black screen in qemu).
Could somebody kindly provide a minimal (just kernel, uclibc and busybox
is enough),
working arm buildroot .config and arm kernel .config so
that I can run it under qemu, so that I can finally start testing
firefox under arm, so that
I can finally kick the updated, cleaned firefox patch out before
Christmas :-)
Best regards
Stefan
^ permalink raw reply
* [Buildroot] [PATCH] xlib_libX11: fix compilation of makekeys
From: Thomas Petazzoni @ 2012-11-08 19:13 UTC (permalink / raw)
To: buildroot
In-Reply-To: <1352028606-11338-1-git-send-email-arnout@mind.be>
Arnout,
On Sun, 4 Nov 2012 12:30:06 +0100, Arnout Vandecappelle
(Essensium/Mind) wrote:
> xlib_libX11 builds a makekeys executable for the host, but uses the
> targets X11_CFLAGS. This leads to build failures like
> http://autobuild.buildroot.net/results/411eb3aefea859a7e31986a44acd50b475f174cb/
>
> This problem was introduced by the version bump, because then also
> the AUTORECONF was removed so the existing fix didn't work anymore.
>
> As a slightly cleaner solution, just remove X11_CFLAGS from the
> Makefile. We know we don't need it, because the X11 stuff is in
> $(HOST_DIR)/usr/include which is already in HOST_CFLAGS.
>
> Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Hasn't this broken the xlib-x11 build? See
http://autobuild.buildroot.org/results/6a5a16f901215acca06cb7a89f7d7fb0bc1741af/build-end.log.
It is including a host header (Xos.h) which itself includes target
headers. Sounds really wrong.
Thomas
--
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
^ permalink raw reply
* [Buildroot] [PATCH v11 2/9] perl: new package
From: François Perrad @ 2012-11-08 18:02 UTC (permalink / raw)
To: buildroot
In-Reply-To: <CAB0FRsvVa1x9Lp+x0P+YSnBG2eqWNd0bchtmQrWDnhqHUxx=Cw@mail.gmail.com>
2012/11/6 Fran?ois Perrad <francois.perrad@gadz.org>:
> 2012/11/6 Fran?ois Perrad <francois.perrad@gadz.org>:
>> 2012/11/5 Fran?ois Perrad <francois.perrad@gadz.org>:
>>> 2012/10/30 Bernd Kuhls <berndkuhls@hotmail.com>:
>>>> Hi,
>>>>
>>>> Francois Perrad <fperrad@gmail.com> wrote in
>>>> news:1350652434-32020-2-git-send-email-francois.perrad at gadz.org:
>>>>
>>>> currently I am testing your patchset, but I found problems during
>>>> compiling, some I could solve myself:
>>>>
>>>>> +PERL_CONF_OPT = -des \
>>>>
>>>> [...]
>>>>
>>>>> + -Dlibc=$(STAGING_DIR)/lib/libc.so \
>>>>
>>>> I had to change this line to
>>>>
>>>> -Dlibc=$(STAGING_DIR)/usr/lib/libc.so.0 \
>>>>
>>>> for usage with uClibc 0.9.33.2
>>>>
>>>> [...]
>>>>
>>>>> + -Uoptimize
>>>>
>>>> Here I had to add "-Ud_eaccess" to avoid a compilation bug.
>>>>
>>>> Perl will still not finish to compile, stopping with this error message:
>>>>
>>>>> LD_LIBRARY_PATH=/home/bernd/.fbr/build/output/build/perl-5.16.1
>>>> /home/bernd/.fbr/build/output/build/perl-5.16.1/Cross/run-qemu-i386
>>>> ./miniperl -Ilib make_ext.pl cpan/Archive-Extract/pm_to_blib
>>>> MAKE=/home/bernd/.fbr/build/output/host/usr/bin/make LIBPERL_A=libperl.so
>>>>> Making Archive::Extract (all)
>>>>>
>>>>> Creating Makefile.PL in cpan/Archive-Extract for Archive::Extract
>>>>>
>>>>> Running Makefile.PL in cpan/Archive-Extract
>>>>> /home/bernd/.fbr/build/output/build/perl-5.16.1/Cross/run-qemu-i386
>>>> ../../miniperl -I../../lib Makefile.PL INSTALLDIRS=perl INSTALLMAN1DIR=none
>>>> INSTALLMAN3DIR=none PERL_CORE=1 LIBPERL_A=libperl.so
>>>>> -1 from cpan/Archive-Extract's Makefile.PL at make_ext.pl line 409.
>>>>> Warning: No Makefile!
>>>>> /home/bernd/.fbr/build/output/host/usr/bin/make config PERL_CORE=1
>>>> LIBPERL_A=libperl.so failed, continuing anyway...
>>>>> Making all in cpan/Archive-Extract
>>>>> /home/bernd/.fbr/build/output/build/perl-5.16.1/Cross/run-qemu-i386
>>>> /home/bernd/.fbr/build/output/host/usr/bin/make all PERL_CORE=1
>>>> LIBPERL_A=libperl.so
>>>>> Unsuccessful make(cpan/Archive-Extract): code=-1 at make_ext.pl line 468.
>>>>> make[1]: *** [cpan/Archive-Extract/pm_to_blib] Fehler 22
>>>>> make[1]: Leaving directory `/home/bernd/.fbr/build/output/build/perl-
>>>> 5.16.1'
>>>>> make: *** [/home/bernd/.fbr/build/output/build/perl-5.16.1/.stamp_built]
>>>> Fehler 2
>>>>
>>>> Executing the last command alone provides this error hinting at a problem
>>>> with host-qemu, which I was able to solve yet.
>>>>
>>>> $ /home/bernd/.fbr/build/output/build/perl-5.16.1/Cross/run-qemu-i386
>>>> /home/bernd/.fbr/build/output/host/usr/bin/make all PERL_CORE=1
>>>> LIBPERL_A=libperl.so
>>>> qemu: Unsupported syscall: 240
>>>> qemu: Unsupported syscall: 240
>>>>
>>>> First I got this error message with Debian Squeeze i386 (virtualbox guest,
>>>> Win XP host), but also on Debian wheezy amd64 running non-virtualized.
>>>>
>>>> My .config can be found here: http://pastebin.com/yz1SzeB2
>>>> I am using buildroot as part of the FLI4L source package[1].
>>>>
>>>> Kind regards, Bernd
>>>>
>>>
>>> I could reproduce the lastest problem on the HEAD of Buildroot with
>>> qemu_x86_defconfig (which is a smaller config than your FLI4L config).
>>>
>>
>> first, before manually running a command in the build tree, you must
>> set PERL_MM_OPT
>> $ export PERL_MM_OPT="PERL=`pwd`/Cross/miniperl"
>>
>> the error
>> -1 from cpan/Archive-Extract's Makefile.PL at make_ext.pl line 409.
>> comes from miniperl which fails with a 'system' call.
>>
>> this problem could be reproduced with a simple one-liner :
>>
>> $ perl -e "my \$code = system( q(echo), q(hello) ); print(\$code);"
>> hello
>> 0
>>
>> $ Cross/miniperl -e "my \$code = system( q(echo), q(hello) ); print(\$code);"
>> -1
>>
>> Fran?ois
>>
>
> after an installation on the target, this 'miniperl' works fine.
> so, the problem comes from Qemu.
>
> I write a small C example :
>
> $ cat sys.c
> #include <stdio.h>
> #include <stdlib.h>
>
> int main()
> {
> int ret = system("echo hello");
> printf("%d\n", ret);
> }
>
> $ ../../host/usr/bin/i686-buildroot-linux-uclibc-gcc -o sys sys.c
> $ file sys
> sys: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV),
> dynamically linked (uses shared libs), not stripped
> $ ../../host/usr/bin/qemu-i386 ./sys
> -1
>
> I also try on various architecture.
> I build Perl successfully with qemu-arm and qemu-mips,
> the problem occurs with qemu-i386 and qemu-x86_64,
> with a qemu-i386 version 1.2.0 built with Buildroot and with a
> qemu-i386 version 1.0.50 which comes my distro Ubuntu 12.04 LTS.
>
> Other bad new, these days, the homepage of Qemu (http://wiki.qemu.org) is down.
>
bug report filled, see https://bugs.launchpad.net/qemu/+bug/1076445
Fran?ois
> Fran?ois
>
>>> Fran?ois
>>>
>>>> [1] http://www.fli4l.de/download/tarball-version/aktuell.html
>>>>
>>>> _______________________________________________
>>>> buildroot mailing list
>>>> buildroot at busybox.net
>>>> http://lists.busybox.net/mailman/listinfo/buildroot
^ permalink raw reply
* [Buildroot] problem building a SDL app with buildroot
From: Thomas Petazzoni @ 2012-11-08 17:36 UTC (permalink / raw)
To: buildroot
In-Reply-To: <CAHXCMMJjaafke3POAv04fdK80L_DWguu+UdbDrah9HSYPfwf-g@mail.gmail.com>
Samuel,
On Thu, 8 Nov 2012 11:49:58 +0100, Samuel Martin wrote:
> As a quick fix, in your app *.mk file, you can try to add:
> <your app prefix>_CONF_OPT += -DSDL_CONFIG="$(STAGING_DIR)/usr/bin/sdl-config"
>
> You don't have to change anything in the sdl-config from the staging
> area, it is already handled by the sdl package.
>
> BTW, that an issue we are aware of, and we talked a bit about it
> during the last Buildroot Dev Days.
> We just need some time to work on and figure out the best way to fix this.
We indeed discussed it, but as far as I understood, there isn't really
another solution than what we're doing at the moment. Options we
discussed where:
(1) Install those <foo>-config scripts in $(HOST_DIR)/usr/bin. This
isn't possible as they would clash with other <foo>-config scripts
installed by host packages.
(2) Create a special directory, which is in the PATH passed when
configuring/building packages, in which we would install those
<foo>-config script. This works quite OK when those <foo>-config
scripts are self-contained (which is the case most of the time), but
not necessarily if they are more elaborate.
So in general, I think we said it wasn't really worth the effort, and
it was probably a lot better to work on moving packages to pkg-config
instead.
For example, in this case, Jeremy should rather use the pkg-config
files of SDL to discover the right compiler/linker flags. pkg-config is
very nicely integrated with CMake, it should even simplify the
CMakeLists.txt.
Best regards,
Thomas
--
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
^ permalink raw reply
* [Buildroot] no jack?
From: Peter Korsgaard @ 2012-11-08 16:32 UTC (permalink / raw)
To: buildroot
In-Reply-To: <50999970.3020308@mind.be>
>>>>> "Arnout" == Arnout Vandecappelle <arnout@mind.be> writes:
Arnout> On 06/11/12 22:39, Grant wrote:
>> Is there a jack package available for buildroot?
Arnout> No, but it shouldn't be too difficult to integrate. Look at
Arnout> midori for an example of a package using waf as the build
Arnout> system.
Waf is btw a pain. It seems to fail on one of the autobuilders (host
python issue?)
--
Bye, Peter Korsgaard
^ permalink raw reply
* [Buildroot] Udev on a live CD system does not appear to populate /dev
From: Stefan Fröberg @ 2012-11-08 16:29 UTC (permalink / raw)
To: buildroot
In-Reply-To: <509BD78A.8050908@macrium.com>
I forgot to mention one more thing:
If you ever want to use the maximum compression method supported by
modern kernels (XZ compression)
then change that initramfs generation command to this:
find . -not \( -path "./boot" -prune \) -print0 | cpio --null -ov --format=newc
| xz --check=crc32 > /livecd/initramfs.xz
Without that --check=crc32 parameter you won't be able to boot
XZ-compressed initramfs.
Regards
Stefan
8.11.2012 18:02, Antony Vennard kirjoitti:
> Hi Stefan,
>
> Thanks for that. I have followed your instructions for making a live cd
> manually with mkisofs - actually this is helpful since a later job is to
> add UEFI booting to the disk, which is easier this way (although I am
> going to look at modifying buildroot, if I can).
>
> I am using grub, and have modified my grub command line to use:
>
> title LiveCD
> kernel /vmlinuz vga=0x317
> initrd /initramfs.bz2
>
> The kernel has bz2, xz and gzip initramfs support built in - so all good
> there. However, the kernel complains there's no root parameter. What
> should I specify for this?
>
> Thanks,
>
> Antony
>
> On 08/11/2012 12:35, Stefan Fr?berg wrote:
>> Hi Antony
>>
>> Just one guestion: What bootloader are you using for your Live CD ?
>> (I use grub)
>>
>> 8.11.2012 11:56, Antony Vennard kirjoitti:
>>> Hi All,
>>>
>>> I'm not using initramfs - I'm using the ISO 9660 target which as far
>>> as I can see produces an initrd, a kernel and an ext2 raw image which
>>> it mounts as a ramdisk. If I select the initramfs options, the cpio
>>> filesystem is generated prior to the iso9660 one, *but the initramfs
>>> afterwards!* Which means, as far as I can see, that initramfs would
>>> not be placed on the disk - unless buildroot manipulates the iso
>>> filesystem post creation? I could of course mkisofs myself, but I was
>>> trying to avoid that - although if this fixes udev, I'll do it.
>>>
>> Keep in mind that the buildroot way of making initramfs (that is if you
>> select intramfs from menuconfig) is
>> to embed your initramfs directly into kernel.
>>
>> There are three disadvantages in here:
>>
>> 1 ) It will make your kernel fatter
>> 2 ) It will makes things more complicated than necessary
>> You might have two initramfs settings: One that is embedded directly
>> into your kernel and
>> another that you have made by hand by yourself. And it's very possible
>> that they could have conflicting stuff between them
>> You can have several initramfs files (at least with grub bootloader),
>> the last ones overlaying the first ones, in order.
>> 3 ) It will makes less flexibe.
>>
>> All kernels since 2.6 have initramfs inside them, it's just that by
>> default that environment is empty.
>>
>> Embedding initramfs directly to kernel might be good for those users who
>> don't use any bootloader or are using a bootloader which can't
>> be feeded external, separate initramfs file(s) (like grub) and want to
>> have minimal system always available (as piggybacked inside kernel).
>>
>>
>>> I've nothing /dev related in my fs/skeleton, and only the default
>>> values in device_table.txt. Since I'm using udev, I did expect it
>>> would populate everything it needed in /dev - although unless I add
>>> entries for null, console and a tty into device_table.txt, I end up
>>> with a distribution that loops forever saying "could not find
>>> /dev/tty1" (if I've configured tty1 as the location for getty for
>>> example). I can't mitigate this by re-writing the inittab to launch
>>> getty "once" as opposed to respawn, since buildroot rewrites that -
>>> and askfirst:/bin/sh works, except that the respawn error messages are
>>> written all over /dev/console, making it unusable...!
>>>
>>> By the sounds of things this is wrong, but I'm currently attempting to
>>> preconfigure some devices in device_table.txt - e.g. /dev/null,
>>> /dev/urandom et al pseudo devices, and I'm borrowing Ubuntu's rules.d
>>> to see if these are any more effective than Fedora's. Leaving
>>> device_table.txt as its default causes the tty1 missing loop. I am not
>>> expecting this to work - I cannot see how udev rules differ greatly
>>> between distributions - just eliminating it as a possible cause.
>>>
>>> Any further ideas as to what I can try? Is mdev a better choice?
>>>
>> Well mdev is at least easier to configure than udev.
>>
>> The only thing you must make sure in your init process is that /proc and
>> /sys are mounted as early as possible (/etc/inittab is good place for that)
>> and that echo /sbin/mdev > /proc/sys/kernel/hotplug is also somewhere
>> in /etc/init.d/rcS (maybe at the start of that file)
>>
>> And check that you have etc/mdev.conf and etc/init.d/S10mdev (witch is
>> called by /etc/init.d/rcS)
>>
>> This is what I would do (and have done with my live CD)
>> Forget the buildroot way of making initramfs for now and see if you can
>> construct live CD by hand:
>>
>> 1 ) make clean
>>
>> 2 ) make sure you have all the needed init stuff in fs/skeleton/etc
>> directory (inittab, init.d/rcS, init.d/S* files etc.....)
>> also make sure that sbin/init is a symlink to /bin/busybox
>> (I have also symlink of init --> /bin/busybox in top of fs/skeleton but
>> I not sure if that is stricly needed ...
>> I think kernel should be looking from /sbin/init if no other init found)
>>
>> 3 ) do make menuconfig as you would normally but remember to unselect
>> cpio, initramfs and iso9660 from menuconfig
>> remember to select grub from under Bootloader section if you
>> don't already have it
>> don't select too much of stuff even if you have massive amounts
>> of RAM in your test systems.
>> reason being that you are making initramfs later here from your
>> output/target directory and if you have massive
>> amount's of stuff in there then it will take forever to boot. (I
>> have managed to do live CD with massive amounts of stuff on it and
>> booting fast with only 192 MB RAM but that needed some major hacking)
>>
>> 4 ) do make linux-menuconfig and check that under General setup the
>> setting Initramfs source files is empty
>> also check the compression support here that you want to use for
>> your external initramfs (let's suppose its' the default GZ for now)
>>
>> 5 ) do make
>>
>> 6 ) after buildroot has finished make sure that everything is okay in
>> your output/target (check especially boot/ etc/ and /dev directory)
>> also make sure you have /boot/grub/menu.lst or /boot/grub/grub.conf
>> (the other is usually just symlink to other) and check it's settings
>> (If you are not familiar with grub then I can help with it's
>> settings, especially important is the line where you tell grub the external
>> initramfs file)
>> remove the symlink (iso9660 format does not support symlinks)
>>
>> 7 ) Create directory where you want to put your kernel & bootloader
>> (a.ka. the whole contents of /boot dir) and external initramfs file
>> that is generated next:
>>
>> mkdir /livecd && cp -r output/target/boot /livecd
>>
>> 8 ) from output/target dir do find . -not \( -path "./boot" -prune
>> \) -print0 | cpio --null -ov --format=newc | gzip -9 > /livecd/initramfs.gz
>> (we don't need boot directory inside initramfs. it needs to stay outside
>> of it. that why it was copied previously)
>>
>> 9 ) make iso9660 normally from the contents of your /livecd
>> mkdir /livecd_output && cd /livecd && mkisofs --joliet -R -b
>> boot/grub/stage2_eltorito -no-emul-boot -boot-load-size 4
>> -boot-info-table -iso-level 4 -hide-rr-moved -c boot.catalog -o
>> /livecd_output/your_livecd.iso .
>>
>> (remember that . at the end)
>>
>> 10) burn the iso to CD or even better use qemu or VirtualBox to boot
>> your iso without wasting CD disc.
>>
>> If this manual way worked then next try buildroot way.
>>
>> Best regards
>> Stefan
>>
>>> Thanks for your help,
>>>
>>> Antony
>>>
>>> ________________
>>>
>>> Macrium? Software is a trading name of Paramount Software UK Ltd,
>>> Registered in England and Wales Number 02973414
>>> Registered Office: Kilburn House, Manchester Science Park, Lloyd St.
>>> North, Manchester M15 6SE United Kingdom
>>>
>>> The information contained in this e-mail is confidential, privileged,
>>> or otherwise protected from disclosure. It is intended only for the
>>> use of the authorized individual as indicated in the e-mail. Any
>>> unauthorized disclosure, copying, distribution or taking of any action
>>> based on the contents of this material is strictly prohibited.
>>>
>>> If you have received this e-mail in error, please delete it immediately.
>>>
>>>
>>>
>>> _______________________________________________
>>> buildroot mailing list
>>> buildroot at busybox.net
>>> http://lists.busybox.net/mailman/listinfo/buildroot
^ permalink raw reply
* [Buildroot] [git commit] at91bootstrap: fix overlap linker issue
From: Peter Korsgaard @ 2012-11-08 16:28 UTC (permalink / raw)
To: buildroot
commit: http://git.buildroot.net/buildroot/commit/?id=3d3047f28d3016b351213dc99b73e299d2310f25
branch: http://git.buildroot.net/buildroot/commit/?id=refs/heads/master
The linker script of the at91bootstrap package has to be modified when
built from gcc-4.6.x version. Indeed a section named text.startup is
created and has to be added into the text section.
Signed-off-by: Gregory Hermant <gregory.hermant@calao-systems.com>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
---
...at91bootstrap-1.16-gcc-4.6.x-ldscript-fix.patch | 29 ++++++++++++++++++++
1 files changed, 29 insertions(+), 0 deletions(-)
diff --git a/boot/at91bootstrap/at91bootstrap-1.16-gcc-4.6.x-ldscript-fix.patch b/boot/at91bootstrap/at91bootstrap-1.16-gcc-4.6.x-ldscript-fix.patch
new file mode 100644
index 0000000..e4ed04e
--- /dev/null
+++ b/boot/at91bootstrap/at91bootstrap-1.16-gcc-4.6.x-ldscript-fix.patch
@@ -0,0 +1,29 @@
+From b783d1f9bf985c0981e755bd2c13e091e9d6837f Mon Sep 17 00:00:00 2001
+From: Gregory Hermant <gregory.hermant@calao-systems.com>
+Date: Tue, 6 Nov 2012 09:38:50 +0100
+Subject: [PATCH] at91bootstrap: fix overlap linker issue
+
+The linker script of the at91bootstrap package has to be modified when
+built from gcc-4.6.x version. Indeed a section named text.startup is
+created and has to be added into the text section.
+
+Signed-off-by: Gregory Hermant <gregory.hermant@calao-systems.com>
+---
+ elf32-littlearm.lds | 1 +
+ 1 file changed, 1 insertion(+)
+
+diff --git a/elf32-littlearm.lds b/elf32-littlearm.lds
+index a33952f..4f3ba25 100644
+--- a/elf32-littlearm.lds
++++ b/elf32-littlearm.lds
+@@ -7,6 +7,7 @@ SECTIONS
+ .text : {
+ _stext = .;
+ *(.text)
++ *(.text*)
+ *(.rodata) /* read-only data (constants) */
+ *(.rodata*)
+ . = ALIGN(4);
+--
+1.7.9.5
+
^ permalink raw reply related
* [Buildroot] [PATCH v4] at91bootstrap: fix overlap linker issue
From: Peter Korsgaard @ 2012-11-08 16:28 UTC (permalink / raw)
To: buildroot
In-Reply-To: <1352198903-6297-1-git-send-email-gregory.hermant@calao-systems.com>
>>>>> "Gregory" == Gregory Hermant <gregory.hermant@calao-systems.com> writes:
Gregory> The linker script of the at91bootstrap package has to be
Gregory> modified when built from gcc-4.6.x version. Indeed a section
Gregory> named text.startup is created and has to be added into the
Gregory> text section.
Committed, thanks.
--
Bye, Peter Korsgaard
^ permalink raw reply
* [Buildroot] Autotest infrastructure (a bit of off-topic: git repo URL)
From: Javier Viguera @ 2012-11-08 16:21 UTC (permalink / raw)
To: buildroot
In-Reply-To: <509BC913.3080902@mind.be>
Hi Arnout,
I attended the other day to your talk on "upgrading without bricking"
(congrats for that, i learned a lot) and you mentioned a repo where you
have started collecting some tools/scripts to do the job.
Could you remind me that repo URL? I shouldn't have trust i would
remember it some days after.
Sorry the rest for the thread hijacking.
--
Javier Viguera
Software Engineer
Digi International? Spain S.A.U.
^ permalink raw reply
* [Buildroot] Udev on a live CD system does not appear to populate /dev
From: Stefan Fröberg @ 2012-11-08 16:20 UTC (permalink / raw)
To: buildroot
In-Reply-To: <509BD78A.8050908@macrium.com>
8.11.2012 18:02, Antony Vennard kirjoitti:
> Hi Stefan,
>
> Thanks for that. I have followed your instructions for making a live cd
> manually with mkisofs - actually this is helpful since a later job is to
> add UEFI booting to the disk, which is easier this way (although I am
> going to look at modifying buildroot, if I can).
>
> I am using grub, and have modified my grub command line to use:
>
> title LiveCD
> kernel /vmlinuz vga=0x317
> initrd /initramfs.bz2
>
> The kernel has bz2, xz and gzip initramfs support built in - so all good
> there. However, the kernel complains there's no root parameter. What
> should I specify for this?
root=/dev/ram0
So that would be:
kernel /vmlinuz vga=0x317 root=/dev/ram0
If you want to you can give it ramdisk_size parameter (from
https://www.kernel.org/doc/Documentation/kernel-parameters.txt)
but that should not be nowadays necessary.
Just make sure that you have enough ram memory for total amount of the
size (uncompressed) of your initramfs + some ram needed to actually run
your applications.
and make sure that /dev/ram0 is in fs/skeleton/dev (or output/target/dev
if you hollowed my instructions) and
regenerate initramfs
If you hit the limit of your CD disc (or RAM) but want to still add some
more stuff into it then
me know. I have solved it, but like I said, it's hackis and dirty method :-)
Best regards
Stefan
> Thanks,
>
> Antony
>
> On 08/11/2012 12:35, Stefan Fr?berg wrote:
>> Hi Antony
>>
>> Just one guestion: What bootloader are you using for your Live CD ?
>> (I use grub)
>>
>> 8.11.2012 11:56, Antony Vennard kirjoitti:
>>> Hi All,
>>>
>>> I'm not using initramfs - I'm using the ISO 9660 target which as far
>>> as I can see produces an initrd, a kernel and an ext2 raw image which
>>> it mounts as a ramdisk. If I select the initramfs options, the cpio
>>> filesystem is generated prior to the iso9660 one, *but the initramfs
>>> afterwards!* Which means, as far as I can see, that initramfs would
>>> not be placed on the disk - unless buildroot manipulates the iso
>>> filesystem post creation? I could of course mkisofs myself, but I was
>>> trying to avoid that - although if this fixes udev, I'll do it.
>>>
>> Keep in mind that the buildroot way of making initramfs (that is if you
>> select intramfs from menuconfig) is
>> to embed your initramfs directly into kernel.
>>
>> There are three disadvantages in here:
>>
>> 1 ) It will make your kernel fatter
>> 2 ) It will makes things more complicated than necessary
>> You might have two initramfs settings: One that is embedded directly
>> into your kernel and
>> another that you have made by hand by yourself. And it's very possible
>> that they could have conflicting stuff between them
>> You can have several initramfs files (at least with grub bootloader),
>> the last ones overlaying the first ones, in order.
>> 3 ) It will makes less flexibe.
>>
>> All kernels since 2.6 have initramfs inside them, it's just that by
>> default that environment is empty.
>>
>> Embedding initramfs directly to kernel might be good for those users who
>> don't use any bootloader or are using a bootloader which can't
>> be feeded external, separate initramfs file(s) (like grub) and want to
>> have minimal system always available (as piggybacked inside kernel).
>>
>>
>>> I've nothing /dev related in my fs/skeleton, and only the default
>>> values in device_table.txt. Since I'm using udev, I did expect it
>>> would populate everything it needed in /dev - although unless I add
>>> entries for null, console and a tty into device_table.txt, I end up
>>> with a distribution that loops forever saying "could not find
>>> /dev/tty1" (if I've configured tty1 as the location for getty for
>>> example). I can't mitigate this by re-writing the inittab to launch
>>> getty "once" as opposed to respawn, since buildroot rewrites that -
>>> and askfirst:/bin/sh works, except that the respawn error messages are
>>> written all over /dev/console, making it unusable...!
>>>
>>> By the sounds of things this is wrong, but I'm currently attempting to
>>> preconfigure some devices in device_table.txt - e.g. /dev/null,
>>> /dev/urandom et al pseudo devices, and I'm borrowing Ubuntu's rules.d
>>> to see if these are any more effective than Fedora's. Leaving
>>> device_table.txt as its default causes the tty1 missing loop. I am not
>>> expecting this to work - I cannot see how udev rules differ greatly
>>> between distributions - just eliminating it as a possible cause.
>>>
>>> Any further ideas as to what I can try? Is mdev a better choice?
>>>
>> Well mdev is at least easier to configure than udev.
>>
>> The only thing you must make sure in your init process is that /proc and
>> /sys are mounted as early as possible (/etc/inittab is good place for that)
>> and that echo /sbin/mdev > /proc/sys/kernel/hotplug is also somewhere
>> in /etc/init.d/rcS (maybe at the start of that file)
>>
>> And check that you have etc/mdev.conf and etc/init.d/S10mdev (witch is
>> called by /etc/init.d/rcS)
>>
>> This is what I would do (and have done with my live CD)
>> Forget the buildroot way of making initramfs for now and see if you can
>> construct live CD by hand:
>>
>> 1 ) make clean
>>
>> 2 ) make sure you have all the needed init stuff in fs/skeleton/etc
>> directory (inittab, init.d/rcS, init.d/S* files etc.....)
>> also make sure that sbin/init is a symlink to /bin/busybox
>> (I have also symlink of init --> /bin/busybox in top of fs/skeleton but
>> I not sure if that is stricly needed ...
>> I think kernel should be looking from /sbin/init if no other init found)
>>
>> 3 ) do make menuconfig as you would normally but remember to unselect
>> cpio, initramfs and iso9660 from menuconfig
>> remember to select grub from under Bootloader section if you
>> don't already have it
>> don't select too much of stuff even if you have massive amounts
>> of RAM in your test systems.
>> reason being that you are making initramfs later here from your
>> output/target directory and if you have massive
>> amount's of stuff in there then it will take forever to boot. (I
>> have managed to do live CD with massive amounts of stuff on it and
>> booting fast with only 192 MB RAM but that needed some major hacking)
>>
>> 4 ) do make linux-menuconfig and check that under General setup the
>> setting Initramfs source files is empty
>> also check the compression support here that you want to use for
>> your external initramfs (let's suppose its' the default GZ for now)
>>
>> 5 ) do make
>>
>> 6 ) after buildroot has finished make sure that everything is okay in
>> your output/target (check especially boot/ etc/ and /dev directory)
>> also make sure you have /boot/grub/menu.lst or /boot/grub/grub.conf
>> (the other is usually just symlink to other) and check it's settings
>> (If you are not familiar with grub then I can help with it's
>> settings, especially important is the line where you tell grub the external
>> initramfs file)
>> remove the symlink (iso9660 format does not support symlinks)
>>
>> 7 ) Create directory where you want to put your kernel & bootloader
>> (a.ka. the whole contents of /boot dir) and external initramfs file
>> that is generated next:
>>
>> mkdir /livecd && cp -r output/target/boot /livecd
>>
>> 8 ) from output/target dir do find . -not \( -path "./boot" -prune
>> \) -print0 | cpio --null -ov --format=newc | gzip -9 > /livecd/initramfs.gz
>> (we don't need boot directory inside initramfs. it needs to stay outside
>> of it. that why it was copied previously)
>>
>> 9 ) make iso9660 normally from the contents of your /livecd
>> mkdir /livecd_output && cd /livecd && mkisofs --joliet -R -b
>> boot/grub/stage2_eltorito -no-emul-boot -boot-load-size 4
>> -boot-info-table -iso-level 4 -hide-rr-moved -c boot.catalog -o
>> /livecd_output/your_livecd.iso .
>>
>> (remember that . at the end)
>>
>> 10) burn the iso to CD or even better use qemu or VirtualBox to boot
>> your iso without wasting CD disc.
>>
>> If this manual way worked then next try buildroot way.
>>
>> Best regards
>> Stefan
>>
>>> Thanks for your help,
>>>
>>> Antony
>>>
>>> ________________
>>>
>>> Macrium? Software is a trading name of Paramount Software UK Ltd,
>>> Registered in England and Wales Number 02973414
>>> Registered Office: Kilburn House, Manchester Science Park, Lloyd St.
>>> North, Manchester M15 6SE United Kingdom
>>>
>>> The information contained in this e-mail is confidential, privileged,
>>> or otherwise protected from disclosure. It is intended only for the
>>> use of the authorized individual as indicated in the e-mail. Any
>>> unauthorized disclosure, copying, distribution or taking of any action
>>> based on the contents of this material is strictly prohibited.
>>>
>>> If you have received this e-mail in error, please delete it immediately.
>>>
>>>
>>>
>>> _______________________________________________
>>> buildroot mailing list
>>> buildroot at busybox.net
>>> http://lists.busybox.net/mailman/listinfo/buildroot
^ permalink raw reply
* [Buildroot] Udev on a live CD system does not appear to populate /dev
From: Antony Vennard @ 2012-11-08 16:02 UTC (permalink / raw)
To: buildroot
In-Reply-To: <509BA71B.6020009@petroprogram.com>
Hi Stefan,
Thanks for that. I have followed your instructions for making a live cd
manually with mkisofs - actually this is helpful since a later job is to
add UEFI booting to the disk, which is easier this way (although I am
going to look at modifying buildroot, if I can).
I am using grub, and have modified my grub command line to use:
title LiveCD
kernel /vmlinuz vga=0x317
initrd /initramfs.bz2
The kernel has bz2, xz and gzip initramfs support built in - so all good
there. However, the kernel complains there's no root parameter. What
should I specify for this?
Thanks,
Antony
On 08/11/2012 12:35, Stefan Fr?berg wrote:
> Hi Antony
>
> Just one guestion: What bootloader are you using for your Live CD ?
> (I use grub)
>
> 8.11.2012 11:56, Antony Vennard kirjoitti:
>> Hi All,
>>
>> I'm not using initramfs - I'm using the ISO 9660 target which as far
>> as I can see produces an initrd, a kernel and an ext2 raw image which
>> it mounts as a ramdisk. If I select the initramfs options, the cpio
>> filesystem is generated prior to the iso9660 one, *but the initramfs
>> afterwards!* Which means, as far as I can see, that initramfs would
>> not be placed on the disk - unless buildroot manipulates the iso
>> filesystem post creation? I could of course mkisofs myself, but I was
>> trying to avoid that - although if this fixes udev, I'll do it.
>>
>
> Keep in mind that the buildroot way of making initramfs (that is if you
> select intramfs from menuconfig) is
> to embed your initramfs directly into kernel.
>
> There are three disadvantages in here:
>
> 1 ) It will make your kernel fatter
> 2 ) It will makes things more complicated than necessary
> You might have two initramfs settings: One that is embedded directly
> into your kernel and
> another that you have made by hand by yourself. And it's very possible
> that they could have conflicting stuff between them
> You can have several initramfs files (at least with grub bootloader),
> the last ones overlaying the first ones, in order.
> 3 ) It will makes less flexibe.
>
> All kernels since 2.6 have initramfs inside them, it's just that by
> default that environment is empty.
>
> Embedding initramfs directly to kernel might be good for those users who
> don't use any bootloader or are using a bootloader which can't
> be feeded external, separate initramfs file(s) (like grub) and want to
> have minimal system always available (as piggybacked inside kernel).
>
>
>> I've nothing /dev related in my fs/skeleton, and only the default
>> values in device_table.txt. Since I'm using udev, I did expect it
>> would populate everything it needed in /dev - although unless I add
>> entries for null, console and a tty into device_table.txt, I end up
>> with a distribution that loops forever saying "could not find
>> /dev/tty1" (if I've configured tty1 as the location for getty for
>> example). I can't mitigate this by re-writing the inittab to launch
>> getty "once" as opposed to respawn, since buildroot rewrites that -
>> and askfirst:/bin/sh works, except that the respawn error messages are
>> written all over /dev/console, making it unusable...!
>>
>> By the sounds of things this is wrong, but I'm currently attempting to
>> preconfigure some devices in device_table.txt - e.g. /dev/null,
>> /dev/urandom et al pseudo devices, and I'm borrowing Ubuntu's rules.d
>> to see if these are any more effective than Fedora's. Leaving
>> device_table.txt as its default causes the tty1 missing loop. I am not
>> expecting this to work - I cannot see how udev rules differ greatly
>> between distributions - just eliminating it as a possible cause.
>>
>> Any further ideas as to what I can try? Is mdev a better choice?
>>
> Well mdev is at least easier to configure than udev.
>
> The only thing you must make sure in your init process is that /proc and
> /sys are mounted as early as possible (/etc/inittab is good place for that)
> and that echo /sbin/mdev > /proc/sys/kernel/hotplug is also somewhere
> in /etc/init.d/rcS (maybe at the start of that file)
>
> And check that you have etc/mdev.conf and etc/init.d/S10mdev (witch is
> called by /etc/init.d/rcS)
>
> This is what I would do (and have done with my live CD)
> Forget the buildroot way of making initramfs for now and see if you can
> construct live CD by hand:
>
> 1 ) make clean
>
> 2 ) make sure you have all the needed init stuff in fs/skeleton/etc
> directory (inittab, init.d/rcS, init.d/S* files etc.....)
> also make sure that sbin/init is a symlink to /bin/busybox
> (I have also symlink of init --> /bin/busybox in top of fs/skeleton but
> I not sure if that is stricly needed ...
> I think kernel should be looking from /sbin/init if no other init found)
>
> 3 ) do make menuconfig as you would normally but remember to unselect
> cpio, initramfs and iso9660 from menuconfig
> remember to select grub from under Bootloader section if you
> don't already have it
> don't select too much of stuff even if you have massive amounts
> of RAM in your test systems.
> reason being that you are making initramfs later here from your
> output/target directory and if you have massive
> amount's of stuff in there then it will take forever to boot. (I
> have managed to do live CD with massive amounts of stuff on it and
> booting fast with only 192 MB RAM but that needed some major hacking)
>
> 4 ) do make linux-menuconfig and check that under General setup the
> setting Initramfs source files is empty
> also check the compression support here that you want to use for
> your external initramfs (let's suppose its' the default GZ for now)
>
> 5 ) do make
>
> 6 ) after buildroot has finished make sure that everything is okay in
> your output/target (check especially boot/ etc/ and /dev directory)
> also make sure you have /boot/grub/menu.lst or /boot/grub/grub.conf
> (the other is usually just symlink to other) and check it's settings
> (If you are not familiar with grub then I can help with it's
> settings, especially important is the line where you tell grub the external
> initramfs file)
> remove the symlink (iso9660 format does not support symlinks)
>
> 7 ) Create directory where you want to put your kernel & bootloader
> (a.ka. the whole contents of /boot dir) and external initramfs file
> that is generated next:
>
> mkdir /livecd && cp -r output/target/boot /livecd
>
> 8 ) from output/target dir do find . -not \( -path "./boot" -prune
> \) -print0 | cpio --null -ov --format=newc | gzip -9 > /livecd/initramfs.gz
> (we don't need boot directory inside initramfs. it needs to stay outside
> of it. that why it was copied previously)
>
> 9 ) make iso9660 normally from the contents of your /livecd
> mkdir /livecd_output && cd /livecd && mkisofs --joliet -R -b
> boot/grub/stage2_eltorito -no-emul-boot -boot-load-size 4
> -boot-info-table -iso-level 4 -hide-rr-moved -c boot.catalog -o
> /livecd_output/your_livecd.iso .
>
> (remember that . at the end)
>
> 10) burn the iso to CD or even better use qemu or VirtualBox to boot
> your iso without wasting CD disc.
>
> If this manual way worked then next try buildroot way.
>
> Best regards
> Stefan
>
>> Thanks for your help,
>>
>> Antony
>>
>> ________________
>>
>> Macrium? Software is a trading name of Paramount Software UK Ltd,
>> Registered in England and Wales Number 02973414
>> Registered Office: Kilburn House, Manchester Science Park, Lloyd St.
>> North, Manchester M15 6SE United Kingdom
>>
>> The information contained in this e-mail is confidential, privileged,
>> or otherwise protected from disclosure. It is intended only for the
>> use of the authorized individual as indicated in the e-mail. Any
>> unauthorized disclosure, copying, distribution or taking of any action
>> based on the contents of this material is strictly prohibited.
>>
>> If you have received this e-mail in error, please delete it immediately.
>>
>>
>>
>> _______________________________________________
>> buildroot mailing list
>> buildroot at busybox.net
>> http://lists.busybox.net/mailman/listinfo/buildroot
>
--
Antony Vennard
Software Engineer
Macrium Software
Kilburn House,
Manchester Science Park
Lloyd Street North
Manchester M15 6SE
UK
Tel: +44(0)161 226 1128
Web http://www.macrium.com/
Blog http://blog.macrium.com/
Twitter http://twitter.com/MacriumReflect
Facebook http://www.facebook.com/Macrium
--
________________
Macrium? Software is a trading name of Paramount Software UK Ltd,
Registered in England and Wales Number 02973414
Registered Office: Kilburn House, Manchester Science Park, Lloyd St. North,
Manchester M15 6SE United Kingdom
The information contained in this e-mail is confidential, privileged, or
otherwise protected from disclosure. It is intended only for the use of the
authorized individual as indicated in the e-mail. Any unauthorized
disclosure, copying, distribution or taking of any action based on the
contents of this material is strictly prohibited.
If you have received this e-mail in error, please delete it immediately.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 895 bytes
Desc: OpenPGP digital signature
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20121108/5730efff/attachment.asc>
^ permalink raw reply
* [Buildroot] [git commit] lcdproc: bump version to 0.5.6
From: Peter Korsgaard @ 2012-11-08 15:41 UTC (permalink / raw)
To: buildroot
commit: http://git.buildroot.net/buildroot/commit/?id=b8a304a9f9089bf03e3649582cee7ea96718e92f
branch: http://git.buildroot.net/buildroot/commit/?id=refs/heads/master
Signed-off-by: Simon Dawson <spdawson@gmail.com>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
---
| 19 -------------------
package/lcdproc/lcdproc.mk | 2 +-
2 files changed, 1 insertions(+), 20 deletions(-)
diff --git a/package/lcdproc/lcdproc-0.5.5-fix-menu-segfault.patch b/package/lcdproc/lcdproc-0.5.5-fix-menu-segfault.patch
deleted file mode 100644
index f0ebe2d..0000000
--- a/package/lcdproc/lcdproc-0.5.5-fix-menu-segfault.patch
+++ /dev/null
@@ -1,19 +0,0 @@
-Trying to add a menu item using menu_add_item causes a segmentation fault
-in the LCDd server. This is caused by a read beyond the end of an array.
-
-This patch adds a safety check on the size of the argument array.
-
-Signed-off-by: Simon Dawson <spdawson@gmail.com>
-
-diff -Nurp a/server/commands/menu_commands.c b/server/commands/menu_commands.c
---- a/server/commands/menu_commands.c 2011-08-14 13:29:16.000000000 +0100
-+++ b/server/commands/menu_commands.c 2012-10-04 22:19:07.997409193 +0100
-@@ -198,7 +198,7 @@ menu_add_item_func(Client *c, int argc,
-
- /* call menu_set_item() with a temporarily allocated argv
- * to process the remaining options */
-- if ((argc > 5) || (argv[4][0] == '-')) {
-+ if ((argc > 5) || ((argc == 5) && argv[4][0] == '-')) {
- // menu_add_item <menuid> <newitemid> <type> [<text>]
- // menu_set_item <menuid> <itemid> {<option>}+
- int i, j;
diff --git a/package/lcdproc/lcdproc.mk b/package/lcdproc/lcdproc.mk
index 7914c85..aa204f1 100644
--- a/package/lcdproc/lcdproc.mk
+++ b/package/lcdproc/lcdproc.mk
@@ -3,7 +3,7 @@
# lcdproc
#
#############################################################
-LCDPROC_VERSION = 0.5.5
+LCDPROC_VERSION = 0.5.6
LCDPROC_SOURCE = lcdproc-$(LCDPROC_VERSION).tar.gz
LCDPROC_SITE = http://downloads.sourceforge.net/project/lcdproc/lcdproc/$(LCDPROC_VERSION)
LCDPROC_LICENSE = GPLv2+
^ permalink raw reply related
* [Buildroot] [git commit] kmod: don't build documentation if not needed
From: Peter Korsgaard @ 2012-11-08 15:26 UTC (permalink / raw)
To: buildroot
commit: http://git.buildroot.net/buildroot/commit/?id=2fc64312d4840eb777df7e10b8405a364e813b9e
branch: http://git.buildroot.net/buildroot/commit/?id=refs/heads/master
No sense in building it if we throw it away in target-finalize anyway.
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
---
package/kmod/kmod.mk | 4 ++++
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/package/kmod/kmod.mk b/package/kmod/kmod.mk
index c6ef6a1..2833629 100644
--- a/package/kmod/kmod.mk
+++ b/package/kmod/kmod.mk
@@ -4,6 +4,10 @@ KMOD_SITE = $(BR2_KERNEL_MIRROR)/linux/utils/kernel/kmod/
KMOD_INSTALL_STAGING = YES
KMOD_DEPENDENCIES = host-pkgconf
+ifneq ($(BR2_HAVE_DOCUMENTATION),y)
+KMOD_CONF_OPT += --disable-manpages
+endif
+
ifeq ($(BR2_PACKAGE_ZLIB),y)
KMOD_DEPENDENCIES += zlib
KMOD_CONF_OPT += --with-zlib
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox