Re: cross-compiling ARM img question

[bch]

On Mon, Nov 27, 2017 at 2:47 PM Robert Elz  wrote:

> Date:Mon, 27 Nov 2017 11:41:56 -0800
> From:bch 
> Message-ID:  <
> cabfrot_vnzfemnduj678c_iexdrequxxurvmago5uj6y2g4...@mail.gmail.com>
>
>   | Turns out it was /tmp filling up. This wasn't indicated in the error
>   | message, but running the mkimage via "sh -x" illuminated the issue.
>
> Ah, OK, I am so use to /tmp being a mounted filesys (tmpfs usually) that
> I didn't really even consider that possibility.
>
> So what this means is that the mkimage script needs to honour TMPDIR so
> the files can be put somewhere with more space, right?
>

It might already be honouring TMPDIR, but I cleared up space in the
/-mounted to get the script running. The error *did* in fact say / was
full, but it looked like it was indicating something to do w /boot which
was a bit confusing and non-sensical in my case. TMPDIR is worth exploring
though.

-bch


> kre
>
>

Re: cross-compiling ARM img question

[Chavdar Ivanov]

Just to mention, I haven't ran build.sh manually for years. I always
install sysutils/sysbuild and sysupdate and have never had such a problem.
Although my last rPi build was for 8.99.3,, so things may have changed.

Chavdar

On Mon, 27 Nov 2017, 03:48 bch,  wrote:

> On Sun, Nov 26, 2017 at 6:20 PM Robert Elz  wrote:
>
>> Date:Sun, 26 Nov 2017 14:25:35 -0800
>> From:bch 
>> Message-ID:  <
>> cabfrot8f-uvae_srhdgrz5mnzmnd0vccxnj_zaoa9gocgtk...@mail.gmail.com>
>>
>>   | That's not fixing things... that's adjusting what used to be
>>   | destdir.evbarm in the OBJDIR.
>>
>> OK, just trying the simple things first...
>>
>
> Same here :)
>
>
> I was hoping somebody would be able to eyeball it and say “oh, you’re
> doing this incorrectly” For my Pi, I got it’s image from
> nyftp.netbsd.org, but it’d be nice to be able to create arbitrary images
> on demand.
>
> Anyway, in the meantime  I’ll look harder at it and see if it’s
> debuggable. Thanks for the hints :)
>
> -bch
>
>
>
>> It looks to be coming from src/distrib/utils/embedded/mkimage and in
>> particular from populate() in .../conf/armv7.conf
>>
>> But it appears as if it should be going to /tmp//mnt/boot
>> rather
>> than /boot.
>>
>> Any chance that there is a mktemp (command) in your path which does not
>> work correctly?
>>
>> As in where:
>>
>> tmp="$(mktemp -d "/tmp/$PROG.XX")"
>> mnt="${tmp}/mnt"
>>
>> leaves mnt as ""  ??   (It seems a little unlikeloy!)
>>
>> Apart from that possibility I don't see how this could happen in a current
>> install.  Nothing else appears to alter ${mnt} and taht appears to be
>> where the files are placed.  Or should be.   That line should probably be
>> ${TMPDIR:-/tmp) rather that just /tmp but that can't be the issue.
>>
>> kre
>>
>>

Re: cross-compiling ARM img question

[Robert Elz]

Date:Mon, 27 Nov 2017 22:57:43 +
From:bch 
Message-ID:  



  | It might already be honouring TMPDIR,

It doesn't.

  | The error *did* in fact say / was full,

Yes, that is why I assumed it was not actually writing to /tmp and
was trying to determine how it was writing to / ... I am just so unused
to anyone not using a mounted /tmp (of some form).

As an aside, I highly recommend not leaving /tmp on root - /tmp is very
volatile, and you *really* want to avoid the root filesys being seriously
messed up if the system crashes (incl sudden power off.)

  | but it looked like it was indicating something to do w /boot

Yes, the message could probably be more clear - at least when it fails.

kre

Re: cross-compiling ARM img question

[bch]

On 11/26/17, bch  wrote:
> I've got an invocation like this, hoping to get an armv7 img to dd
> onto an SD card:
>
> $ nice ./build.sh  -j1 -u -U -R /home/bch/releasedir -O
> /home/bch/usr/obj_nanopi/ -m evbearmv7hf-el release
>
>
> But the build step is trying to install things to root (/boot/...). It
> seemed to me that the -R switch should have the release installed to
> the supplied dir. I've got nothing at all in
> /home/bch/releasedir/evbarm/binary/gzimg, though I've got sets built
> (/home/bch/releasedir/evbarm/binary/sets/*)
>
> What am I missing?


Turns out it was /tmp filling up. This wasn't indicated in the error
message, but running the mkimage via "sh -x" illuminated the issue.

-bch


> Here's the final output from the build.sh as indicated above:
>
> [...]
>
> release ===> etc/evbarm/cdroms
> release ===> etc/evbarm/cdroms/installcd
> /home/bch/usr/obj_nanopi/tooldir.NetBSD-8.99.7-amd64/bin/armv7--netbsdelf-eabihf-install
> -r -p -c -m 444
> /home/bch/usr/obj_nanopi/sys/arch/evbarm/stand/boot2440/bootmini2440
> /home/bch/releasedir/evbarm/installation
> TOOL_MAKE=/home/bch/usr/obj_nanopi/tooldir.NetBSD-8.99.7-amd64/bin/nbmake
> TOOL_MAKEFS=/home/bch/usr/obj_nanopi/tooldir.NetBSD-8.99.7-amd64/bin/nbmakefs
> TOOL_DISKLABEL=/home/bch/usr/obj_nanopi/tooldir.NetBSD-8.99.7-amd64/bin/nbdisklabel
> TOOL_FDISK=/home/bch/usr/obj_nanopi/tooldir.NetBSD-8.99.7-amd64/bin/armv7--netbsdelf-eabihf-fdisk
>  TOOL_GZIP=gzip
> TOOL_MKNOD=/home/bch/usr/obj_nanopi/tooldir.NetBSD-8.99.7-amd64/bin/nbmknod
>  TOOL_PAX=/home/bch/usr/obj_nanopi/tooldir.NetBSD-8.99.7-amd64/bin/nbpax
> TOOL_MKUBOOTIMAGE=/home/bch/usr/obj_nanopi/tooldir.NetBSD-8.99.7-amd64/bin/nbmkubootimage
> TOOL_MTREE=/home/bch/usr/obj_nanopi/tooldir.NetBSD-8.99.7-amd64/bin/nbmtree
>  HOST_SH=/bin/sh
> KERNOBJDIR=/home/bch/usr/obj_nanopi/sys/arch/evbarm/compile
> MACHINE=evbarm  /bin/sh /usr/src/distrib/utils/embedded/mkimage -x -h
> armv7 -D /home/bch/usr/obj_nanopi/destdir.evbarm  -S /usr/src -B le -K
> /home/bch/releasedir/evbarm/binary/kernel
> /home/bch/releasedir/evbarm/binary/gzimg/armv7.img.gz
> === configuring sets ===
> === running MAKEDEV ===
> === fixing up permissions
> === looking for kernels in /home/bch/releasedir/evbarm/binary/kernel ===
> === installing
> /home/bch/releasedir/evbarm/binary/kernel/netbsd-BEAGLEBOARD.ub.gz
> to /boot/netbsd-BEAGLEBOARD.ub ===
> === installing
> /home/bch/releasedir/evbarm/binary/kernel/netbsd-BEAGLEBONE.ub.gz
> to /boot/netbsd-BEAGLEBONE.ub ===
> === installing /home/bch/releasedir/evbarm/binary/kernel/netbsd-BPI.ub.gz
> to /boot/netbsd-BPI.ub ===
> === installing
> /home/bch/releasedir/evbarm/binary/kernel/netbsd-CUBIEBOARD.ub.gz
> to /boot/netbsd-CUBIEBOARD.ub ===
> === installing
> /home/bch/releasedir/evbarm/binary/kernel/netbsd-CUBIETRUCK.ub.gz
> to /boot/netbsd-CUBIETRUCK.ub ===
>
> /: write failed, file system is full
> gzip: error writing to output: No space left on device
> gzip: /home/bch/releasedir/evbarm/binary/kernel/netbsd-CUBIETRUCK.ub.gz:
> uncompress failed
> *** [smp_armv7] Error code 1
>
> nbmake[1]: stopped in /usr/src/etc
> 1 error
>
> nbmake[1]: stopped in /usr/src/etc
> *** [release] Error code 2
>
> nbmake: stopped in /usr/src
> 1 error
>
> nbmake: stopped in /usr/src
>
> ERROR: Failed to make release
> *** BUILD ABORTED ***
> ing inat though t I' got   sets builtr.r.r.
> kjhhjkjkjhhlhlhhhlhlhhkjkjllhxhh final  output
>

Re: cross-compiling ARM img question

[bch]

On Sun, Nov 26, 2017 at 6:20 PM Robert Elz  wrote:

> Date:Sun, 26 Nov 2017 14:25:35 -0800
> From:bch 
> Message-ID:  <
> cabfrot8f-uvae_srhdgrz5mnzmnd0vccxnj_zaoa9gocgtk...@mail.gmail.com>
>
>   | That's not fixing things... that's adjusting what used to be
>   | destdir.evbarm in the OBJDIR.
>
> OK, just trying the simple things first...
>

Same here :)


I was hoping somebody would be able to eyeball it and say “oh, you’re doing
this incorrectly” For my Pi, I got it’s image from nyftp.netbsd.org,
but it’d be nice to be able to create arbitrary images on demand.

Anyway, in the meantime  I’ll look harder at it and see if it’s debuggable.
Thanks for the hints :)

-bch



> It looks to be coming from src/distrib/utils/embedded/mkimage and in
> particular from populate() in .../conf/armv7.conf
>
> But it appears as if it should be going to /tmp//mnt/boot rather
> than /boot.
>
> Any chance that there is a mktemp (command) in your path which does not
> work correctly?
>
> As in where:
>
> tmp="$(mktemp -d "/tmp/$PROG.XX")"
> mnt="${tmp}/mnt"
>
> leaves mnt as ""  ??   (It seems a little unlikeloy!)
>
> Apart from that possibility I don't see how this could happen in a current
> install.  Nothing else appears to alter ${mnt} and taht appears to be
> where the files are placed.  Or should be.   That line should probably be
> ${TMPDIR:-/tmp) rather that just /tmp but that can't be the issue.
>
> kre
>
>

Re: cross-compiling ARM img question

[bch]

On 11/26/17, Robert Elz  wrote:
> Date:Sun, 26 Nov 2017 14:25:35 -0800
> From:bch 
> Message-ID:
> 
>
>   | That's not fixing things... that's adjusting what used to be
>   | destdir.evbarm in the OBJDIR.
>
> OK, just trying the simple things first...
>
> It looks to be coming from src/distrib/utils/embedded/mkimage and in
> particular from populate() in .../conf/armv7.conf
>
> But it appears as if it should be going to /tmp//mnt/boot rather
> than /boot.
>
> Any chance that there is a mktemp (command) in your path which does not
> work correctly?

That's a good thought, but the explicit "/mnt" string should at least
show up in the path, as it's ${mnt} that is prefixing /boot later on.


> As in where:
>
>   tmp="$(mktemp -d "/tmp/$PROG.XX")"
>   mnt="${tmp}/mnt"
>
> leaves mnt as ""  ??   (It seems a little unlikeloy!)
>
> Apart from that possibility I don't see how this could happen in a current
> install.  Nothing else appears to alter ${mnt} and taht appears to be
> where the files are placed.  Or should be.   That line should probably be
> ${TMPDIR:-/tmp) rather that just /tmp but that can't be the issue.
>
> kre
>
>

Re: cross-compiling ARM img question

[Robert Elz]

Date:Sun, 26 Nov 2017 14:25:35 -0800
From:bch 
Message-ID:  


  | That's not fixing things... that's adjusting what used to be
  | destdir.evbarm in the OBJDIR.

OK, just trying the simple things first...

It looks to be coming from src/distrib/utils/embedded/mkimage and in
particular from populate() in .../conf/armv7.conf

But it appears as if it should be going to /tmp//mnt/boot rather
than /boot.

Any chance that there is a mktemp (command) in your path which does not
work correctly?

As in where:

tmp="$(mktemp -d "/tmp/$PROG.XX")"
mnt="${tmp}/mnt"

leaves mnt as ""  ??   (It seems a little unlikeloy!)

Apart from that possibility I don't see how this could happen in a current
install.  Nothing else appears to alter ${mnt} and taht appears to be
where the files are placed.  Or should be.   That line should probably be
${TMPDIR:-/tmp) rather that just /tmp but that can't be the issue.

kre

Re: cross-compiling ARM img question

[bch]

On 11/26/17, Robert Elz  wrote:
> Date:Sun, 26 Nov 2017 09:55:55 -0800
> From:bch 
> Message-ID:
> 
>
>   | I've got an invocation like this, hoping to get an armv7 img to dd
>   | onto an SD card:
>   |
>   | $ nice ./build.sh  -j1 -u -U -R /home/bch/releasedir -O
>   | /home/bch/usr/obj_nanopi/ -m evbearmv7hf-el release
>   |
>   |
>   | But the build step is trying to install things to root (/boot/...). It
>   | seemed to me that the -R switch should have the release installed to
>   | the supplied dir.
>
> It does.   That's where the final release ends up.   But you're missing -D
> which sets the destination DESTDIR for the build - where the binaries are
> installed.


That's not fixing things... that's adjusting what used to be
destdir.evbarm in the OBJDIR.


-bch


> kre
>
>

Re: cross-compiling ARM img question

[Robert Elz]

Date:Sun, 26 Nov 2017 09:55:55 -0800
From:bch 
Message-ID:  


  | I've got an invocation like this, hoping to get an armv7 img to dd
  | onto an SD card:
  | 
  | $ nice ./build.sh  -j1 -u -U -R /home/bch/releasedir -O
  | /home/bch/usr/obj_nanopi/ -m evbearmv7hf-el release
  | 
  | 
  | But the build step is trying to install things to root (/boot/...). It
  | seemed to me that the -R switch should have the release installed to
  | the supplied dir.

It does.   That's where the final release ends up.   But you're missing -D
which sets the destination DESTDIR for the build - where the binaries are
installed.

kre