Hi,
I have encountered a failure running live-build that I could use some help debugging.
Using the instructions in the LiveBuild wiki page:
https://wiki.linaro.org/Platform/DevPlatform/CrossCompile/LiveBuild
the procedure fails during the adduser step. The failure is:
I: create linaro user Can't set $0 with prctl(): Bad address at /usr/sbin/adduser line 86.
Here is the perl code around line 86 in adduser: ---- my %config; # configuration hash
my @defaults = ("/etc/adduser.conf"); my $nogroup_id = getgrnam("nogroup") || 65534; $0 =~ s+.*/++; <<<<<<<<< Line 86 >>>>>>>>>>> ----
This is the call to adduser from the 01-setup_user_linaro.chroot script that causes the problem:
adduser --gecos linaro --disabled-login linaro
The funny thing about this failure, if I chroot into the build area and run that command manually, everything works fine.
1st, what is that perl command doing? 2nd, anybody have any ideas on what would cause this failure?
TIA, Matt
On Fri, Jan 20, 2012 at 10:40 PM, Matt Waddel matt.waddel@linaro.org wrote:
Hi,
I have encountered a failure running live-build that I could use some help debugging.
Using the instructions in the LiveBuild wiki page:
https://wiki.linaro.org/Platform/DevPlatform/CrossCompile/LiveBuild
the procedure fails during the adduser step. The failure is:
I: create linaro user Can't set $0 with prctl(): Bad address at /usr/sbin/adduser line 86.
Here is the perl code around line 86 in adduser:
my %config; # configuration hash
my @defaults = ("/etc/adduser.conf"); my $nogroup_id = getgrnam("nogroup") || 65534; $0 =~ s+.*/++; <<<<<<<<< Line 86 >>>>>>>>>>>
This line attempts to set $0 to the substitution of a regular expression, it takes $_ as an argument and replaces the value matched by a regular expression .*/ with an empty string.
I don't pretend to understand the error message, it just seems to me that $0 is the implicit variable that contains the entire string when using regular expressions ($1... and so on are subsequent matches) and that $0 in that context might be read only.
Best regards ZK
This is the call to adduser from the 01-setup_user_linaro.chroot script that causes the problem:
adduser --gecos linaro --disabled-login linaro
The funny thing about this failure, if I chroot into the build area and run that command manually, everything works fine.
1st, what is that perl command doing? 2nd, anybody have any ideas on what would cause this failure?
TIA, Matt
linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
On 21 January 2012 10:08, Zygmunt Krynicki zygmunt.krynicki@linaro.org wrote:
On Fri, Jan 20, 2012 at 10:40 PM, Matt Waddel matt.waddel@linaro.org wrote:
I: create linaro user Can't set $0 with prctl(): Bad address at /usr/sbin/adduser line 86.
Here is the perl code around line 86 in adduser:
my %config; # configuration hash
my @defaults = ("/etc/adduser.conf"); my $nogroup_id = getgrnam("nogroup") || 65534; $0 =~ s+.*/++; <<<<<<<<< Line 86 >>>>>>>>>>>
This line attempts to set $0 to the substitution of a regular expression, it takes $_ as an argument and replaces the value matched by a regular expression .*/ with an empty string.
Isn't it substituting on $0, not $_? (it's using =~).
I don't pretend to understand the error message, it just seems to me that $0 is the implicit variable that contains the entire string when using regular expressions ($1... and so on are subsequent matches) and that $0 in that context might be read only.
$0 here is the process name, and Perl is trying to set it using prctl(PR_SET_NAME, ...). [Google says it's done that only since Perl 5.14.] I think you're running under QEMU at this point, and QEMU doesn't support PR_SET_NAME. (It does do something with prctl but it basically just feeds all the arguments across, and since for PR_SET_NAME one of them is a pointer this doesn't work since qemu guest pointers are not host pointers).
In other words, looks like a qemu bug :-)
(I think having a basic utility like adduser fiddle with its own process name is a bit cheesy though.)
-- PMM
On Sat, Jan 21, 2012 at 12:04:43PM +0000, Peter Maydell wrote:
On 21 January 2012 10:08, Zygmunt Krynicki zygmunt.krynicki@linaro.org wrote:
On Fri, Jan 20, 2012 at 10:40 PM, Matt Waddel matt.waddel@linaro.org wrote:
I: create linaro user Can't set $0 with prctl(): Bad address at /usr/sbin/adduser line 86.
Here is the perl code around line 86 in adduser:
my %config; # configuration hash
my @defaults = ("/etc/adduser.conf"); my $nogroup_id = getgrnam("nogroup") || 65534; $0 =~ s+.*/++; <<<<<<<<< Line 86 >>>>>>>>>>>
This line attempts to set $0 to the substitution of a regular expression, it takes $_ as an argument and replaces the value matched by a regular expression .*/ with an empty string.
Isn't it substituting on $0, not $_? (it's using =~).
I don't pretend to understand the error message, it just seems to me that $0 is the implicit variable that contains the entire string when using regular expressions ($1... and so on are subsequent matches) and that $0 in that context might be read only.
$0 here is the process name, and Perl is trying to set it using prctl(PR_SET_NAME, ...). [Google says it's done that only since Perl 5.14.] I think you're running under QEMU at this point, and QEMU doesn't support PR_SET_NAME. (It does do something with prctl but it basically just feeds all the arguments across, and since for PR_SET_NAME one of them is a pointer this doesn't work since qemu guest pointers are not host pointers).
In other words, looks like a qemu bug :-)
(I think having a basic utility like adduser fiddle with its own process name is a bit cheesy though.)
I saw this reported separately elsewhere this week:
http://lists.debian.org/debian-arm/2012/01/msg00061.html
which also suggests it might be a change in perl 5.14.
Cheers,
On 21 January 2012 12:04, Peter Maydell peter.maydell@linaro.org wrote:
$0 here is the process name, and Perl is trying to set it using prctl(PR_SET_NAME, ...). [Google says it's done that only since Perl 5.14.] I think you're running under QEMU at this point, and QEMU doesn't support PR_SET_NAME.
qemu-linaro bug: https://bugs.launchpad.net/qemu-linaro/+bug/926102 patches submitted upstream: http://lists.gnu.org/archive/html/qemu-devel/2012-02/msg00323.html
I've confirmed that (a) I can reproduce the original problem and (b) these patches fix it. Fix should be in qemu-linaro 2012.02 (release date 9 Feb).
-- PMM
Awesome!
Thanks much for getting this fixed Peter. Perhaps at LC you might like to see another qemu issue that keeps us from being able to cross build the Linaro Ubuntu LEB.
On Fri, Feb 3, 2012 at 8:47 AM, Peter Maydell peter.maydell@linaro.org wrote:
On 21 January 2012 12:04, Peter Maydell peter.maydell@linaro.org wrote:
$0 here is the process name, and Perl is trying to set it using prctl(PR_SET_NAME, ...). [Google says it's done that only since Perl 5.14.] I think you're running under QEMU at this point, and QEMU doesn't support PR_SET_NAME.
qemu-linaro bug: https://bugs.launchpad.net/qemu-linaro/+bug/926102 patches submitted upstream: http://lists.gnu.org/archive/html/qemu-devel/2012-02/msg00323.html
I've confirmed that (a) I can reproduce the original problem and (b) these patches fix it. Fix should be in qemu-linaro 2012.02 (release date 9 Feb).
-- PMM
linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
On 3 February 2012 15:43, Tom Gall tom.gall@linaro.org wrote:
Thanks much for getting this fixed Peter. Perhaps at LC you might like to see another qemu issue that keeps us from being able to cross build the Linaro Ubuntu LEB.
Sure; or you can always reach me via the bug tracking system :-)
-- PMM
Hi Tom,
On 3 February 2012 17:43, Tom Gall tom.gall@linaro.org wrote:
Awesome!
Thanks much for getting this fixed Peter. Perhaps at LC you might like to see another qemu issue that keeps us from being able to cross build the Linaro Ubuntu LEB.
Which issue is it and is it reported somewhere? I'm trying to build our images using live-build with cross support.
On Fri, Feb 3, 2012 at 8:47 AM, Peter Maydell peter.maydell@linaro.org wrote:
On 21 January 2012 12:04, Peter Maydell peter.maydell@linaro.org wrote:
$0 here is the process name, and Perl is trying to set it using prctl(PR_SET_NAME, ...). [Google says it's done that only since Perl 5.14.] I think you're running under QEMU at this point, and QEMU doesn't support PR_SET_NAME.
qemu-linaro bug: https://bugs.launchpad.net/qemu-linaro/+bug/926102 patches submitted upstream: http://lists.gnu.org/archive/html/qemu-devel/2012-02/msg00323.html
I've confirmed that (a) I can reproduce the original problem and (b) these patches fix it. Fix should be in qemu-linaro 2012.02 (release date 9 Feb).
-- PMM
linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
-- Regards, Tom
"Where's the kaboom!? There was supposed to be an earth-shattering kaboom!" Marvin Martian Multimedia Tech Lead | Linaro.org │ Open source software for ARM SoCs w) tom.gall att linaro.org w) tom_gall att vnet.ibm.com h) tom_gall att mac.com
linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
The last time I checked into it (last november, early december) it was the post install scripts involving a number of different mono packages. It's really easy to replicate. As Peter kindly suggested, time to revisit with the new version and author a new bug or two depending on how things go. Being able to cross assemble the LEB on intel would be a significant milestone!
Regards Tom
On Fri, Feb 3, 2012 at 11:45 AM, Fathi Boudra fathi.boudra@linaro.org wrote:
Hi Tom,
On 3 February 2012 17:43, Tom Gall tom.gall@linaro.org wrote:
Awesome!
Thanks much for getting this fixed Peter. Perhaps at LC you might like to see another qemu issue that keeps us from being able to cross build the Linaro Ubuntu LEB.
Which issue is it and is it reported somewhere? I'm trying to build our images using live-build with cross support.
On Fri, Feb 3, 2012 at 8:47 AM, Peter Maydell peter.maydell@linaro.org wrote:
On 21 January 2012 12:04, Peter Maydell peter.maydell@linaro.org wrote:
$0 here is the process name, and Perl is trying to set it using prctl(PR_SET_NAME, ...). [Google says it's done that only since Perl 5.14.] I think you're running under QEMU at this point, and QEMU doesn't support PR_SET_NAME.
qemu-linaro bug: https://bugs.launchpad.net/qemu-linaro/+bug/926102 patches submitted upstream: http://lists.gnu.org/archive/html/qemu-devel/2012-02/msg00323.html
I've confirmed that (a) I can reproduce the original problem and (b) these patches fix it. Fix should be in qemu-linaro 2012.02 (release date 9 Feb).
-- PMM
linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
-- Regards, Tom
"Where's the kaboom!? There was supposed to be an earth-shattering kaboom!" Marvin Martian Multimedia Tech Lead | Linaro.org │ Open source software for ARM SoCs w) tom.gall att linaro.org w) tom_gall att vnet.ibm.com h) tom_gall att mac.com
linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
-- Fathi Boudra Linaro Release Manager | Validation Project Manager Linaro.org | Open source software for ARM SoCs
On 3 February 2012 22:19, Tom Gall tom.gall@linaro.org wrote:
The last time I checked into it (last november, early december) it was the post install scripts involving a number of different mono packages. It's really easy to replicate. As Peter kindly suggested, time to revisit with the new version and author a new bug or two depending on how things go. Being able to cross assemble the LEB on intel would be a significant milestone!
Ah, mono is a known difficult one for QEMU emulation: https://bugs.launchpad.net/qemu-linaro/+bug/806873 https://bugs.launchpad.net/ubuntu/+source/qemu-kvm/+bug/530000
I know Alexander Graf from SuSE has done some work in this area; I'll talk to him about whether he got mono working and whether those fixes are reasonably upstreamable yet.
-- PMM
On 4 February 2012 02:39, Peter Maydell peter.maydell@linaro.org wrote:
On 3 February 2012 22:19, Tom Gall tom.gall@linaro.org wrote:
The last time I checked into it (last november, early december) it was the post install scripts involving a number of different mono packages. It's really easy to replicate. As Peter kindly suggested, time to revisit with the new version and author a new bug or two depending on how things go. Being able to cross assemble the LEB on intel would be a significant milestone!
Ah, mono is a known difficult one for QEMU emulation: https://bugs.launchpad.net/qemu-linaro/+bug/806873 https://bugs.launchpad.net/ubuntu/+source/qemu-kvm/+bug/530000
I know Alexander Graf from SuSE has done some work in this area; I'll talk to him about whether he got mono working and whether those fixes are reasonably upstreamable yet.
So the answer is that, yes, Alex has got mono working. However not all the patches are upstream. There is at least one patch which is a workaround for a nasty race which is (IMHO) not upstreamable and where the correct fix for the problem involves a fairly significant chunk of rework/refactoring.
I think if we want to be able to run mono on Linaro QEMU this is enough work that it needs to be specced out as a blueprint and prioritised against other things like KVM work. (My off the cuff guess is a couple of weeks of work.)
-- PMM
On 7 February 2012 00:50, Peter Maydell peter.maydell@linaro.org wrote:
On 4 February 2012 02:39, Peter Maydell peter.maydell@linaro.org wrote:
On 3 February 2012 22:19, Tom Gall tom.gall@linaro.org wrote:
The last time I checked into it (last november, early december) it was the post install scripts involving a number of different mono packages. It's really easy to replicate. As Peter kindly suggested, time to revisit with the new version and author a new bug or two depending on how things go. Being able to cross assemble the LEB on intel would be a significant milestone!
Ah, mono is a known difficult one for QEMU emulation: https://bugs.launchpad.net/qemu-linaro/+bug/806873 https://bugs.launchpad.net/ubuntu/+source/qemu-kvm/+bug/530000
I know Alexander Graf from SuSE has done some work in this area; I'll talk to him about whether he got mono working and whether those fixes are reasonably upstreamable yet.
So the answer is that, yes, Alex has got mono working. However not all the patches are upstream. There is at least one patch which is a workaround for a nasty race which is (IMHO) not upstreamable and where the correct fix for the problem involves a fairly significant chunk of rework/refactoring.
I think if we want to be able to run mono on Linaro QEMU this is enough work that it needs to be specced out as a blueprint and prioritised against other things like KVM work. (My off the cuff guess is a couple of weeks of work.)
When generating Oneiric based image, I get the issues triggered by mono, but also some others. find log attached, using qemu-user-static 1.0.50-2012.01-0ubuntu1 (from Precise).
Cheers,
Fathi
On 08.02.2012, at 16:54, Fathi Boudra wrote:
On 7 February 2012 00:50, Peter Maydell peter.maydell@linaro.org wrote:
On 4 February 2012 02:39, Peter Maydell peter.maydell@linaro.org wrote:
On 3 February 2012 22:19, Tom Gall tom.gall@linaro.org wrote:
The last time I checked into it (last november, early december) it was the post install scripts involving a number of different mono packages. It's really easy to replicate. As Peter kindly suggested, time to revisit with the new version and author a new bug or two depending on how things go. Being able to cross assemble the LEB on intel would be a significant milestone!
Ah, mono is a known difficult one for QEMU emulation: https://bugs.launchpad.net/qemu-linaro/+bug/806873 https://bugs.launchpad.net/ubuntu/+source/qemu-kvm/+bug/530000
I know Alexander Graf from SuSE has done some work in this area; I'll talk to him about whether he got mono working and whether those fixes are reasonably upstreamable yet.
So the answer is that, yes, Alex has got mono working. However not all the patches are upstream. There is at least one patch which is a workaround for a nasty race which is (IMHO) not upstreamable and where the correct fix for the problem involves a fairly significant chunk of rework/refactoring.
I think if we want to be able to run mono on Linaro QEMU this is enough work that it needs to be specced out as a blueprint and prioritised against other things like KVM work. (My off the cuff guess is a couple of weeks of work.)
When generating Oneiric based image, I get the issues triggered by mono, but also some others. find log attached, using qemu-user-static 1.0.50-2012.01-0ubuntu1 (from Precise).
Does this qemu work for you?
http://download.opensuse.org/repositories/openSUSE:/Factory:/ARM/standard/x8...
Alex
On 8 February 2012 17:56, Alexander Graf agraf@suse.de wrote:
On 08.02.2012, at 16:54, Fathi Boudra wrote:
On 7 February 2012 00:50, Peter Maydell peter.maydell@linaro.org wrote:
On 4 February 2012 02:39, Peter Maydell peter.maydell@linaro.org wrote:
On 3 February 2012 22:19, Tom Gall tom.gall@linaro.org wrote:
The last time I checked into it (last november, early december) it was the post install scripts involving a number of different mono packages. It's really easy to replicate. As Peter kindly suggested, time to revisit with the new version and author a new bug or two depending on how things go. Being able to cross assemble the LEB on intel would be a significant milestone!
Ah, mono is a known difficult one for QEMU emulation: https://bugs.launchpad.net/qemu-linaro/+bug/806873 https://bugs.launchpad.net/ubuntu/+source/qemu-kvm/+bug/530000
I know Alexander Graf from SuSE has done some work in this area; I'll talk to him about whether he got mono working and whether those fixes are reasonably upstreamable yet.
So the answer is that, yes, Alex has got mono working. However not all the patches are upstream. There is at least one patch which is a workaround for a nasty race which is (IMHO) not upstreamable and where the correct fix for the problem involves a fairly significant chunk of rework/refactoring.
I think if we want to be able to run mono on Linaro QEMU this is enough work that it needs to be specced out as a blueprint and prioritised against other things like KVM work. (My off the cuff guess is a couple of weeks of work.)
When generating Oneiric based image, I get the issues triggered by mono, but also some others. find log attached, using qemu-user-static 1.0.50-2012.01-0ubuntu1 (from Precise).
Does this qemu work for you?
http://download.opensuse.org/repositories/openSUSE:/Factory:/ARM/standard/x8...
Same result.
Debug info from gdb:
qemu: Unsupported syscall: 26 ptrace: Function not implemented. No threads.
================================================================= Got a SIGSEGV while executing native code. This usually indicates a fatal error in the mono runtime or one of the native libraries used by your application. =================================================================
qemu: uncaught target signal 6 (Aborted) - core dumped Aborted (core dumped)
On 09.02.2012, at 01:50, Fathi Boudra wrote:
On 8 February 2012 17:56, Alexander Graf agraf@suse.de wrote:
On 08.02.2012, at 16:54, Fathi Boudra wrote:
On 7 February 2012 00:50, Peter Maydell peter.maydell@linaro.org wrote:
On 4 February 2012 02:39, Peter Maydell peter.maydell@linaro.org wrote:
On 3 February 2012 22:19, Tom Gall tom.gall@linaro.org wrote:
The last time I checked into it (last november, early december) it was the post install scripts involving a number of different mono packages. It's really easy to replicate. As Peter kindly suggested, time to revisit with the new version and author a new bug or two depending on how things go. Being able to cross assemble the LEB on intel would be a significant milestone!
Ah, mono is a known difficult one for QEMU emulation: https://bugs.launchpad.net/qemu-linaro/+bug/806873 https://bugs.launchpad.net/ubuntu/+source/qemu-kvm/+bug/530000
I know Alexander Graf from SuSE has done some work in this area; I'll talk to him about whether he got mono working and whether those fixes are reasonably upstreamable yet.
So the answer is that, yes, Alex has got mono working. However not all the patches are upstream. There is at least one patch which is a workaround for a nasty race which is (IMHO) not upstreamable and where the correct fix for the problem involves a fairly significant chunk of rework/refactoring.
I think if we want to be able to run mono on Linaro QEMU this is enough work that it needs to be specced out as a blueprint and prioritised against other things like KVM work. (My off the cuff guess is a couple of weeks of work.)
When generating Oneiric based image, I get the issues triggered by mono, but also some others. find log attached, using qemu-user-static 1.0.50-2012.01-0ubuntu1 (from Precise).
Does this qemu work for you?
http://download.opensuse.org/repositories/openSUSE:/Factory:/ARM/standard/x8...
Same result.
Does it work on native hw?
Debug info from gdb:
qemu: Unsupported syscall: 26 ptrace: Function not implemented. No threads.
That is because you're automatically attaching gdb and qemu doesn't implement ptrace which would be required for that.
Alex
================================================================= Got a SIGSEGV while executing native code. This usually indicates a fatal error in the mono runtime or one of the native libraries used by your application. =================================================================
qemu: uncaught target signal 6 (Aborted) - core dumped Aborted (core dumped)
On 9 February 2012 00:50, Fathi Boudra fathi.boudra@linaro.org wrote:
Same result.
Debug info from gdb:
qemu: Unsupported syscall: 26 ptrace: Function not implemented. No threads.
This bit of the log is uninteresting, because it is mono attempting to automatically capture a backtrace. As Alex says, this doesn't work under qemu because we don't implement ptrace, but it's not important because it'll only happen when something has already failed to work.
-- PMM
On 09.02.2012, at 02:20, Peter Maydell wrote:
On 9 February 2012 00:50, Fathi Boudra fathi.boudra@linaro.org wrote:
Same result.
Debug info from gdb:
qemu: Unsupported syscall: 26 ptrace: Function not implemented. No threads.
This bit of the log is uninteresting, because it is mono attempting to automatically capture a backtrace. As Alex says, this doesn't work under qemu because we don't implement ptrace, but it's not important because it'll only happen when something has already failed to work.
Yes, and the error actually looks as if something goes wrong very early. Hence my question whether this same mono binary works on real hardware.
Also, it's usually a good idea to narrow down your test case to something simple and easily reproducible. Running your whole system building workflow to narrow down what's causing this is not going to work.
Alex
On 9 February 2012 03:23, Alexander Graf agraf@suse.de wrote:
On 09.02.2012, at 02:20, Peter Maydell wrote:
On 9 February 2012 00:50, Fathi Boudra fathi.boudra@linaro.org wrote:
Same result.
Debug info from gdb:
qemu: Unsupported syscall: 26 ptrace: Function not implemented. No threads.
This bit of the log is uninteresting, because it is mono attempting to automatically capture a backtrace. As Alex says, this doesn't work under qemu because we don't implement ptrace, but it's not important because it'll only happen when something has already failed to work.
Yes, and the error actually looks as if something goes wrong very early. Hence my question whether this same mono binary works on real hardware.
Also, it's usually a good idea to narrow down your test case to something simple and easily reproducible. Running your whole system building workflow to narrow down what's causing this is not going to work.
The same binaries works on native builders: http://snapshots.linaro.org/build/linaro-o-ubuntu-desktop/20120209/0/build-l...
If you take a look to the log (thanks loïc for putting on people.l.o), qemu segfault before reaching mono. I'll try to reduce the test case.
On Wed, Feb 08, 2012, Fathi Boudra wrote:
find log attached
http://people.linaro.org/~lool/linaro-dev/binary.log.gz
Hi Matt,
Say what version of ubuntu are you building this on? Would it be possible to get a complete log?
I just installed the 3.0~a40.1-1linaro13~maverick5 version of live-build out of my ppa which is referenced in the wiki page onto a "clean" oneiric machine. The cross build completed successfully.
qemu or perl issues are possible and for completeness here are the versions of each I have installed on my box that just ran to successful completion:
perl 5.12.4-4 qemu-user-static 1.0-2011.12-0ubuntu1~ppa11.10.1
Thanks, Tom
On Fri, Jan 20, 2012 at 3:40 PM, Matt Waddel matt.waddel@linaro.org wrote:
Hi,
I have encountered a failure running live-build that I could use some help debugging.
Using the instructions in the LiveBuild wiki page:
https://wiki.linaro.org/Platform/DevPlatform/CrossCompile/LiveBuild
the procedure fails during the adduser step. The failure is:
I: create linaro user Can't set $0 with prctl(): Bad address at /usr/sbin/adduser line 86.
Here is the perl code around line 86 in adduser:
my %config; # configuration hash
my @defaults = ("/etc/adduser.conf"); my $nogroup_id = getgrnam("nogroup") || 65534; $0 =~ s+.*/++; <<<<<<<<< Line 86 >>>>>>>>>>>
This is the call to adduser from the 01-setup_user_linaro.chroot script that causes the problem:
adduser --gecos linaro --disabled-login linaro
The funny thing about this failure, if I chroot into the build area and run that command manually, everything works fine.
1st, what is that perl command doing? 2nd, anybody have any ideas on what would cause this failure?
TIA, Matt
linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Hi Tom,
On 01/22/2012 12:51 PM, Tom Gall wrote:
Hi Matt,
Say what version of ubuntu are you building this on?
Oneric (11.10)
Would it be possible to get a complete log?
https://pastebin.linaro.org/387/
I just installed the 3.0~a40.1-1linaro13~maverick5 version of live-build out of my ppa which is referenced in the wiki page onto a "clean" oneiric machine. The cross build completed successfully.
Using the same versions you are:
live-build 3.0~a40.1-1linaro13~maverick5 perl 5.12.4-4 qemu-user-static 1.0-2011.12-0ubuntu1~ppa11.10.1
I don't know if this is a clue, but you'll notice in the log that I do get a lot of insserv: warnings during the build:
insserv: warning: script 'package' missing LSB tags and overrides
I didn't think the messages were related.
Thanks for helping, Matt
PS. I can log this as a bug tomorrow if you think it's more appropriate to track there. Sound's like Peter thinks it's a QEMU problem.
qemu or perl issues are possible and for completeness here are the versions of each I have installed on my box that just ran to successful completion:
perl 5.12.4-4 qemu-user-static 1.0-2011.12-0ubuntu1~ppa11.10.1
Thanks, Tom
On Fri, Jan 20, 2012 at 3:40 PM, Matt Waddel matt.waddel@linaro.org wrote:
Hi,
I have encountered a failure running live-build that I could use some help debugging.
Using the instructions in the LiveBuild wiki page:
https://wiki.linaro.org/Platform/DevPlatform/CrossCompile/LiveBuild
the procedure fails during the adduser step. The failure is:
I: create linaro user Can't set $0 with prctl(): Bad address at /usr/sbin/adduser line 86.
Here is the perl code around line 86 in adduser:
my %config; # configuration hash
my @defaults = ("/etc/adduser.conf"); my $nogroup_id = getgrnam("nogroup") || 65534; $0 =~ s+.*/++; <<<<<<<<< Line 86 >>>>>>>>>>>
This is the call to adduser from the 01-setup_user_linaro.chroot script that causes the problem:
adduser --gecos linaro --disabled-login linaro
The funny thing about this failure, if I chroot into the build area and run that command manually, everything works fine.
1st, what is that perl command doing? 2nd, anybody have any ideas on what would cause this failure?
TIA, Matt
linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
-
Alexander Graf -
Fathi Boudra -
Loïc Minier -
Matt Waddel -
Peter Maydell -
Steve McIntyre -
Tom Gall -
Zygmunt Krynicki