From rob at landley.net  Wed May  4 07:34:40 2011
From: rob at landley.net (Rob Landley)
Date: Wed, 04 May 2011 02:34:40 -0500
Subject: [Aboriginal] Checking in.
Message-ID: <4DC10190.6030805@landley.net>

Sorry for the delay, had to go back to my old laptop (parallels wanted
the one I was using back) and it always takes a while to set my
development environment back up the way I like it.  (Plus I took a week
off to just relax and unwind.)

I reverted to the stable uClibc with pthreads, and did a build of all
the targets, but there are too many platform regressions to release
as-is.  I think it's mostly kernel version skew that did it, but
something has broken armv6l, sh4, and sparc.  And now for some reason
when I native build hello world on powerpc the result is segfaulting.
(But only the threaded version, not the nonthreaded version.)

That's waaaaay too many regressions, I need to get those platforms
working again before cutting a release.

Oh, I about doubled the speed of the miniconfig.sh generator script,
that's in my blog.

Rob

 1304494480.0

From rob at landley.net  Tue May 10 06:14:37 2011
From: rob at landley.net (Rob Landley)
Date: Tue, 10 May 2011 01:14:37 -0500
Subject: [Aboriginal] Grind grind grind...
Message-ID: <4DC8D7CD.4020802@landley.net>

Still need to fix the regressions.  I got distracted by the 9p
filesystem in the kernel, looking into making the qemu -kernel option
take a vmlinux ELF image on all platforms (not trivial as it turns out,
still researching), I still need to finish my OLS paper...

Not dead, just distracted. :)

Rob

 1305008077.0

From onefang at gmail.com  Tue May 10 09:46:53 2011
From: onefang at gmail.com (David Seikel)
Date: Tue, 10 May 2011 19:46:53 +1000
Subject: [Aboriginal] Grind grind grind...
In-Reply-To: <4DC8D7CD.4020802@landley.net>
References: <4DC8D7CD.4020802@landley.net>
Message-ID: <20110510194653.69cc1714@U64-desktop>

On Tue, 10 May 2011 01:14:37 -0500 Rob Landley <rob at landley.net> wrote:

> Not dead, just distracted. :)

Not dead, just unpaid.  Next payment should come tomorrow, then I get
back to it.

Though I was hugely distracted by the company that was my regular gig
closing down.  B-(

-- 
A big old stinking pile of genius that no one wants
coz there are too many silver coated monkeys in the world.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL: <http://lists.landley.net/pipermail/aboriginal/attachments/20110510/91376610/attachment.sig>

From rob at landley.net  Wed May 11 00:11:39 2011
From: rob at landley.net (Rob Landley)
Date: Tue, 10 May 2011 19:11:39 -0500
Subject: [Aboriginal] Grind grind grind...
In-Reply-To: <20110510194653.69cc1714@U64-desktop>
References: <4DC8D7CD.4020802@landley.net>
	<20110510194653.69cc1714@U64-desktop>
Message-ID: <4DC9D43B.9020309@landley.net>

On 05/10/2011 04:46 AM, David Seikel wrote:
> On Tue, 10 May 2011 01:14:37 -0500 Rob Landley <rob at landley.net> wrote:
> 
>> Not dead, just distracted. :)
> 
> Not dead, just unpaid.  Next payment should come tomorrow, then I get
> back to it.
> 
> Though I was hugely distracted by the company that was my regular gig
> closing down.  B-(

My job also ended last month, although in my case that gives me more
time to work on open source stuff.  But I've also diverged into kernel
development, the 9p filesystem, LXC and containers, and about five other
things.  (For example, my big time sink yesterday was bisecting a qemu
regression...)

As I said, grinding along...

Rob

 1305072699.0

From rob at landley.net  Wed May 11 22:16:16 2011
From: rob at landley.net (Rob Landley)
Date: Wed, 11 May 2011 17:16:16 -0500
Subject: [Aboriginal] By the way, if anybody is really bored...
Message-ID: <4DCB0AB0.2060503@landley.net>

A lot of interesting stuff has been going on lately to make my todo list
longer:

QEMU is growing DEC Alpha system emulation:

  http://lists.nongnu.org/archive/html/qemu-devel/2011-05/msg00766.html

QEMU's emulated Alpha applications forever, but didn't do the MMU or the
protected mode instructions, and didn't have a board emulation.  Now
it's got a patch set for it.  uClibc theoretically supports this, I had
a target file for it at one point but had no way to test the output.

QEMU is growing S390x emulation:

  http://lists.nongnu.org/archive/html/qemu-devel/2011-05/msg00303.html

Finally, qemu can boot mainframe Linux, ala hercules.  I have some links
for this but basically google for "s390 linux" and you'll find most of
'em.  This is a target I've wanted to support for a while, but the
problem is uClibc does NOT support this, so it would need glibc.  Which
is a can of worms...

The device tree stuff:


http://lists.ozlabs.org/pipermail/devicetree-discuss/2011-March/005112.html

Virtio:

  In theory this is a paravirtualization driver QEMU supports, which be
used for both block devices and serial I/O, meaning I could get MUCH
more generic boards

Oh, and the aranym devices went into 2.6.39, so in theory m68k no longer
requires patching the kernel.  So I should dig that up again and see if
I can get it working again and merged...

Rob

 1305152176.0

From onefang at gmail.com  Thu May 19 13:23:49 2011
From: onefang at gmail.com (David Seikel)
Date: Thu, 19 May 2011 23:23:49 +1000
Subject: [Aboriginal] Development tools in /usr/tools
Message-ID: <20110519232349.4d2fdace@U64-desktop>

The problem with this current contract of mine is that I only work on
it when the client pays in advance, and he's not always able to come up
with money.  So sometimes I forget things and have to come up to speed
again.

I remember there was talk of having development tools in /usr/tools.
Having a bit of a poke around a recent build, I noticed that only the
basic tools are there, the rest are installed in / where they usually
want to live.  Plus tools is a symlink to a platform dependent name.

I'm thinking it would be great for my project, and likely good for
others, if there was something like /usr/tools that was a mount point
for yet another disk image, like the one used for building control
images.  This disk image would have all the purely needed for
development stuff on it.  With suitable links if needed.  Then it can
be unmounted to get just the image with the resulting embedded system
on it.  At least that's the theory.  More or less.

Are there plans to do such a thing?  I can likely do that myself, it
fits within the scope of my contract.

-- 
A big old stinking pile of genius that no one wants
coz there are too many silver coated monkeys in the world.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL: <http://lists.landley.net/pipermail/aboriginal/attachments/20110519/6f479262/attachment.sig>

From rob at landley.net  Fri May 20 11:22:08 2011
From: rob at landley.net (Rob Landley)
Date: Fri, 20 May 2011 06:22:08 -0500
Subject: [Aboriginal] Development tools in /usr/tools
In-Reply-To: <20110519232349.4d2fdace@U64-desktop>
References: <20110519232349.4d2fdace@U64-desktop>
Message-ID: <4DD64EE0.4030906@landley.net>

On 05/19/2011 08:23 AM, David Seikel wrote:
> The problem with this current contract of mine is that I only work on
> it when the client pays in advance, and he's not always able to come up
> with money.  So sometimes I forget things and have to come up to speed
> again.
> 
> I remember there was talk of having development tools in /usr/tools.
> Having a bit of a poke around a recent build, I noticed that only the
> basic tools are there, the rest are installed in / where they usually
> want to live.  Plus tools is a symlink to a platform dependent name.

In gcc/binutils, the name "gcc" is a wrapper around the tools that do
the real work (cc1, as, ld) which live in the above strangely named
directory.  The "tools" symlink is so ccwrap can find it in a
target-independent way, basically as "../tools" from the bin directory
ccwrap is installed in.

> I'm thinking it would be great for my project, and likely good for
> others, if there was something like /usr/tools that was a mount point
> for yet another disk image, like the one used for building control
> images.  This disk image would have all the purely needed for
> development stuff on it.  With suitable links if needed.  Then it can
> be unmounted to get just the image with the resulting embedded system
> on it.  At least that's the theory.  More or less.

The native-compiler tarball sort of works like that now.  Note that
ccwrap doesn't care where it's installed, as long as all the other
directories are relative to it.  So you should be able to extract it on
any system in an arbitrary directory and run it from there.

The down side is if you don't install the shared libraries on the host
you won't be able to run the resulting binaries (unless they're
statically linked), because the shared library loader location is
hardwired into each binary as an absolute path, that's a limitation of
the ELF spec.  You can specify a different location for it to hardwire
in (export CCWRAP_DYNAMIC_LINKER=/blah/ld-uClibc.so.0), but that's not
much of an improvement.

> Are there plans to do such a thing?  I can likely do that myself, it
> fits within the scope of my contract.

You need to define the problem a little more tightly.  What exactly are
you trying to accomplish, and remember the shared libraries you're
linking against need to be deployed on target for you to run the result.

Note that simple-root-filesystem.sh is doing a gross hack to collect
shared libraries out of the cross compiler:

# Do we need shared libraries?

if [ "$BUILD_STATIC" != all ]
then
  echo Copying compiler libraries...
  mkdir -p "$STAGE_DIR/lib" || dienow
  (path_search \
     "$("$ARCH-cc" --print-search-dirs | sed -n 's/^libraries: =*//p')" \
      "*.so*" 'cp -H "$DIR/$FILE" "$STAGE_DIR/lib/$FILE"' \
      || dienow) | dotprogress

  [ -z "$SKIP_STRIP" ] &&
    "${ARCH}-strip" --strip-unneeded "$STAGE_DIR"/lib/*.so
fi

And the end result is unfortunately subtly broken in ways I've never
quite gotten around to fixing because mostly when I use the simple root
filesystem, I'm building static binaries for it that don't install
shared libraries.  (The root-filesystem.sh step discards the shared
libraries out of simple-root-filesystem and replaces them with the ones
in the native compiler.)

# Remove shared libraries copied from cross compiler, and let /bin/sh point
# to bash out of native compiler instead of busybox shell.

rm -rf "$BUILD/root-filesystem-$ARCH/"{usr/lib,bin/sh} 2>/dev/null

That's ugly and should be improved upon.  (What if you have shared
libraries in an overlay?  Nobody's ever done it, but they COULD...)

Rob

 1305890528.0

From robertt.thompson at gmail.com  Fri May 20 20:39:52 2011
From: robertt.thompson at gmail.com (Robert Thompson)
Date: Fri, 20 May 2011 15:39:52 -0500
Subject: [Aboriginal] Aboriginal Digest, Vol 4, Issue 6
In-Reply-To: <mailman.1.1305923413.3096.aboriginal-landley.net@lists.landley.net>
References: <mailman.1.1305923413.3096.aboriginal-landley.net@lists.landley.net>
Message-ID: <BANLkTinO+XB0htUXjVLSOpTkH9a9V0_Psg@mail.gmail.com>

>The down side is if you don't install the shared libraries on the host
>you won't be able to run the resulting binaries (unless they're
>statically linked), because the shared library loader location is
>hardwired into each binary as an absolute path, that's a limitation of
>the ELF spec.  You can specify a different location for it to hardwire
>in (export CCWRAP_DYNAMIC_LINKER=/blah/ld-uClibc.so.0), but that's not
>much of an improvement.

I don't know if it's useful to anybody, but PatchELF (
http://nixos.org/patchelf.html ) allows you to add, modify, and delete an
ELF executable's RPATH or interpreter path. Also, the old, unmaintained
chrpath (dead upstream, still available in Debian) allows you to modify the
RPATH, with some limitations.

I've found chrpath useful once or twice when I need to build stuff in an
environment where the libraries must be relocated as part of post-build
deployment, and PatchELF looks like it's a vast improvement over chrpath. I
haven't yet used it, though.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.landley.net/pipermail/aboriginal/attachments/20110520/7b751804/attachment.htm>

From rob at landley.net  Fri May 20 22:11:07 2011
From: rob at landley.net (Rob Landley)
Date: Fri, 20 May 2011 17:11:07 -0500
Subject: [Aboriginal] Aboriginal Digest, Vol 4, Issue 6
In-Reply-To: <BANLkTinO+XB0htUXjVLSOpTkH9a9V0_Psg@mail.gmail.com>
References: <mailman.1.1305923413.3096.aboriginal-landley.net@lists.landley.net>
	<BANLkTinO+XB0htUXjVLSOpTkH9a9V0_Psg@mail.gmail.com>
Message-ID: <4DD6E6FB.70602@landley.net>

On 05/20/2011 03:39 PM, Robert Thompson wrote:
>>The down side is if you don't install the shared libraries on the host
>>you won't be able to run the resulting binaries (unless they're
>>statically linked), because the shared library loader location is
>>hardwired into each binary as an absolute path, that's a limitation of
>>the ELF spec.  You can specify a different location for it to hardwire
>>in (export CCWRAP_DYNAMIC_LINKER=/blah/ld-uClibc.so.0), but that's not
>>much of an improvement.
> 
> I don't know if it's useful to anybody, but PatchELF (
> http://nixos.org/patchelf.html ) allows you to add, modify, and delete
> an ELF executable's RPATH or interpreter path. Also, the old,
> unmaintained chrpath (dead upstream, still available in Debian) allows
> you to modify the RPATH, with some limitations.

While I do have "LDSO_RUNPATH=y" set in sources/baseconfig-uClibc,
that's a property of the dynamic linker, meaning the dynamic linker has
to be running, meaning the kernel has to have found and executed the
dynamic linker in order for the RPATH to get checked.

I.E. this is a later step.

It should be possible to rewrite the interpreter value after the fact.
Let's see...

  http://refspecs.freestandards.org/elf/elf.pdf

The ELF header at the start of the file (section 1 page 4) has an
e_phoff value which indicates the start of the program header table in
the file, then section 2 page 3 says we want the entry with p_type equal
to 3 (PT_INTERP), which points to a string table entry.  Except book
three talks about the special section name .interp...

Sigh, I read through all this last year.  At some point I just need to
break down and write my own objdump/objcopy variant so that I properly
understand all this stuff.  I can generally remember about the
http://www.muppetlabs.com/~breadbox/software/tiny/teensy.html level of
this stuff, but dynamic linking at least quadruples the complexity...

Rob

 1305929467.0

From onefang at gmail.com  Fri May 20 23:35:05 2011
From: onefang at gmail.com (David Seikel)
Date: Sat, 21 May 2011 09:35:05 +1000
Subject: [Aboriginal] Development tools in /usr/tools
In-Reply-To: <4DD64EE0.4030906@landley.net>
References: <20110519232349.4d2fdace@U64-desktop>
	<4DD64EE0.4030906@landley.net>
Message-ID: <20110521093505.70b43630@U64-desktop>

On Fri, 20 May 2011 06:22:08 -0500 Rob Landley <rob at landley.net> wrote:

> On 05/19/2011 08:23 AM, David Seikel wrote:
> > I'm thinking it would be great for my project, and likely good for
> > others, if there was something like /usr/tools that was a mount
> > point for yet another disk image, like the one used for building
> > control images.  This disk image would have all the purely needed
> > for development stuff on it.  With suitable links if needed.  Then
> > it can be unmounted to get just the image with the resulting
> > embedded system on it.  At least that's the theory.  More or less.
> 
> The native-compiler tarball sort of works like that now.  Note that
> ccwrap doesn't care where it's installed, as long as all the other
> directories are relative to it.  So you should be able to extract it
> on any system in an arbitrary directory and run it from there.
> 
> The down side is if you don't install the shared libraries on the host
> you won't be able to run the resulting binaries (unless they're
> statically linked), because the shared library loader location is
> hardwired into each binary as an absolute path, that's a limitation of
> the ELF spec.  You can specify a different location for it to hardwire
> in (export CCWRAP_DYNAMIC_LINKER=/blah/ld-uClibc.so.0), but that's not
> much of an improvement.

I was not talking about the shared libraries.  If using such shared
libraries in the resulting system, then they must stay.

> > Are there plans to do such a thing?  I can likely do that myself, it
> > fits within the scope of my contract.
> 
> You need to define the problem a little more tightly.  What exactly
> are you trying to accomplish, and remember the shared libraries you're
> linking against need to be deployed on target for you to run the
> result.

I want to easily separate the tools used to build the result from the
result.  Shared libraries stay if shared libraries are part of the
result.  I have yet to decide if shared libraries or static linking
will be used in general in my project.  At this point, I like my
options on that matter to be open.

Things like include files, and the various development executables that
end up in /usr/bin are not needed for the resulting system, only needed
to build them.  Linker libraries should be included in this part.

To help, I'll mention the exact use case I have for my current
contract.  One of the government requirements for this device is that
ONLY the data needed to perform the legally sanctioned functions of the
device must ship on the resulting device.  "Data" in this case refers
to every single bit in all persistent storage media in the device.

The audit labs needs all source code, and the ability to recreate the
"data" from that source code, as well as a sample of the shipping
device.  So, I want to hand the audit labs the device as it will ship,
and a hard drive. The hard drive will include the source code, and the
development environment we use to build it. This development
environment is what I'm building now using Aboriginal Linux as the base.

The audit lab can plug the hard drive into the sample device, run my
build script, and come back hours later to see that it has replicated
itself, and created a disk image that matches the one in the device.
This plus copious documentation should make the lab very happy.  A very
happy audit lab will charge less, making my client very happy.

Sooo, I need to be able to separate the build environment from the
finished system, then mount it back in later.  To help shake out bugs
from this process, that's EXACTLY what I will use for the development
itself.  Being able to strip the finished system down to the bare
minimum is a goal as stated above.

Yes, I'm well aware that I have no source for the BIOS, or any other
standard firmware that may end up on whatever board we end up using.
The audit labs and government is fine with that, as our main board
hardware falls within the guidelines.  There IS a PIC chip based
daughter board.  We have source code for that, coz I wrote it.

-- 
A big old stinking pile of genius that no one wants
coz there are too many silver coated monkeys in the world.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL: <http://lists.landley.net/pipermail/aboriginal/attachments/20110521/edf2d263/attachment.sig>

From rob at landley.net  Sat May 21 07:49:50 2011
From: rob at landley.net (Rob Landley)
Date: Sat, 21 May 2011 02:49:50 -0500
Subject: [Aboriginal] Development tools in /usr/tools
In-Reply-To: <20110521093505.70b43630@U64-desktop>
References: <20110519232349.4d2fdace@U64-desktop>	<4DD64EE0.4030906@landley.net>
	<20110521093505.70b43630@U64-desktop>
Message-ID: <4DD76E9E.7060104@landley.net>

On 05/20/2011 06:35 PM, David Seikel wrote:
> On Fri, 20 May 2011 06:22:08 -0500 Rob Landley <rob at landley.net> wrote:
> 
>> On 05/19/2011 08:23 AM, David Seikel wrote:
>>> I'm thinking it would be great for my project, and likely good for
>>> others, if there was something like /usr/tools that was a mount
>>> point for yet another disk image, like the one used for building
>>> control images.  This disk image would have all the purely needed
>>> for development stuff on it.  With suitable links if needed.  Then
>>> it can be unmounted to get just the image with the resulting
>>> embedded system on it.  At least that's the theory.  More or less.
>>
>> The native-compiler tarball sort of works like that now.  Note that
>> ccwrap doesn't care where it's installed, as long as all the other
>> directories are relative to it.  So you should be able to extract it
>> on any system in an arbitrary directory and run it from there.
>>
>> The down side is if you don't install the shared libraries on the host
>> you won't be able to run the resulting binaries (unless they're
>> statically linked), because the shared library loader location is
>> hardwired into each binary as an absolute path, that's a limitation of
>> the ELF spec.  You can specify a different location for it to hardwire
>> in (export CCWRAP_DYNAMIC_LINKER=/blah/ld-uClibc.so.0), but that's not
>> much of an improvement.
> 
> I was not talking about the shared libraries.  If using such shared
> libraries in the resulting system, then they must stay.

I believe if you delete the *.so files out of the toolchain, it'll
statically link everything by default.

>>> Are there plans to do such a thing?  I can likely do that myself, it
>>> fits within the scope of my contract.
>>
>> You need to define the problem a little more tightly.  What exactly
>> are you trying to accomplish, and remember the shared libraries you're
>> linking against need to be deployed on target for you to run the
>> result.
> 
> I want to easily separate the tools used to build the result from the
> result.  Shared libraries stay if shared libraries are part of the
> result.  I have yet to decide if shared libraries or static linking
> will be used in general in my project.  At this point, I like my
> options on that matter to be open.

It should work now then?

Hmmm...  Technically I chould teach ccwrap to check for the presence of
the shared library loader at the /usr/bin location, and if it doesn't
find it to either hardwire in the absolute path to wherever the one in
the toolchain lives or to force static linking.

The problems with this are:

A) Which of those options is the correct behavior?

B) This is native compling behavior, not cross compiling, and right now
the wrapper doesn't distinguish between them.

Which is why I haven't done it so far...

> Things like include files, and the various development executables that
> end up in /usr/bin are not needed for the resulting system, only needed
> to build them.  Linker libraries should be included in this part.

The native toolchain tarball already handles that part.  That's why I
packaget that up separately, and why it's built around ccwrap so it's
just as relocatable as the cross compiler is.  (Except for the fiddly
"running the result" issue, which stubbornly cares about where the
shared library loader lives.  I think it'll automatically find the
shared libraries if they're in the same directory as the loader, but I'd
have to look up what other directories it checks and what order it falls
back in.  Building uClibc binaries on a glibc/newlib/bionic/klibc system
is cross compiling too, even if the result runs locally.  When in doubt:
statically link.)

> To help, I'll mention the exact use case I have for my current
> contract.  One of the government requirements for this device is that
> ONLY the data needed to perform the legally sanctioned functions of the
> device must ship on the resulting device.  "Data" in this case refers
> to every single bit in all persistent storage media in the device.

Ah, you probably want to do this then:

Build a simple-root-filesystem version of your target system, but also
build the native compiler tarball:

  NO_NATIVE_COMPILER=1 ./build.sh $TARGET
  ./native-compiler.sh $TARGET

Then fire up the target, and under the emulator:

  Copy your system to writeable space (setup-chroot /home/blah /bin/ash)

  Install the native compiler (extract the native-compiler tarball into
  /home, and add its' bin directory to your $PATH.)

  Swap out the host's libraries for the toolchain libraries:

    rm -rf /usr/lib
    mv /home/native-compiler-$TARGET/lib /usr/lib
    ln -s /usr/lib /home/native-compiler-$TARGET/lib

  Make /bin/sh point to bash:

    ln -sf bash /bin/sh

That gives you the development environment but with the toolchain living
under /home, so you can conveniently delete it later.

Does that sound about right?  (Read root-filesystem.sh to see how it
splices the two together, that's basically what it does.)

> The audit labs needs all source code, and the ability to recreate the
> "data" from that source code, as well as a sample of the shipping
> device.  So, I want to hand the audit labs the device as it will ship,
> and a hard drive. The hard drive will include the source code, and the
> development environment we use to build it. This development
> environment is what I'm building now using Aboriginal Linux as the base.
> 
> The audit lab can plug the hard drive into the sample device, run my
> build script, and come back hours later to see that it has replicated
> itself, and created a disk image that matches the one in the device.
> This plus copious documentation should make the lab very happy.  A very
> happy audit lab will charge less, making my client very happy.
> 
> Sooo, I need to be able to separate the build environment from the
> finished system, then mount it back in later.  To help shake out bugs
> from this process, that's EXACTLY what I will use for the development
> itself.  Being able to strip the finished system down to the bare
> minimum is a goal as stated above.

I think the above may do what you want then?  (Lemme know, if not I'll
come up with something.)

> Yes, I'm well aware that I have no source for the BIOS

http://www.coreboot.org/Welcome_to_coreboot
http://www.coreboot.org/Supported_Motherboards
http://blogs.coreboot.org/blog/2011/05/06/amd-commits-to-coreboot/

The project formerly known as "LinuxBIOS" grew up. :)

Rob

 1305964190.0

From rob at landley.net  Sun May 22 11:13:31 2011
From: rob at landley.net (Rob Landley)
Date: Sun, 22 May 2011 06:13:31 -0500
Subject: [Aboriginal] Getting unblocked...
Message-ID: <4DD8EFDB.4010106@landley.net>

Ok, I kicked the uClibc -rc3 release over to UNSTABLE and put 0.9.31
back, along with its associated patch stack, and I'm tackling a backlog
of other cleanups.  Test-building 2.6.39 kernel as we speak.  I've also
grabbed sh4 config the openembedded maintainer told me about when I
bumped into him at scale, and I'll see if I can get that to boot under
current qemu.  That and an armv6l board emulation is probably enough for
a release.  (Ok, I also need to finish converting the README files to
web pages, and redo the snapshots page...)

Rob

 1306062811.0

From aljamms8 at cs.man.ac.uk  Mon May 23 18:14:56 2011
From: aljamms8 at cs.man.ac.uk (Salman Aljammaz)
Date: Mon, 23 May 2011 19:14:56 +0100
Subject: [Aboriginal] 9p VirtFS for /home
Message-ID: <BANLkTik_poOdTTg745QHqipKMC7LS3uz0w@mail.gmail.com>

I have a fairly trivial change to share.

I've modified the init script, the kernel config, and the qemu command
to mount the host user's $HOME on /home and the host's root on
/mnt/host on bootup, using 9p [1].  I found this to be easier to work
with than using an hdb image and FTP.  (The choice of directories to
export was just for my convenience)

Caveat: Because this uses VitrIO, this currently only works for x86
targets.  I believe there was an effort to make that work with ARM as
well [2] but I don't know what's happened with that.  Meanwhile we
could just run a real 9p server (inferno/npfs) and mount it over the
network.  I wonder why qemu doesn't do 9p with its user mode network,
like cifs...  I should look into that.

s

P.S. Thanks for making aboriginal linux!  I was at the verge of losing
faith in linux cross compiling; but i discovered this stuff, and it
actually works!

[1] http://www.kernel.org/doc/Documentation/filesystems/9p.txt
[2] https://wiki.linaro.org/WorkingGroups/Kernel/Specs/VirtIO
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 9p.diff
Type: text/x-patch
Size: 2448 bytes
Desc: not available
URL: <http://lists.landley.net/pipermail/aboriginal/attachments/20110523/78167e23/attachment.bin>

From rob at landley.net  Tue May 24 05:49:29 2011
From: rob at landley.net (Rob Landley)
Date: Tue, 24 May 2011 00:49:29 -0500
Subject: [Aboriginal] 2.6.39 kernel broken on mips.
Message-ID: <4DDB46E9.6060008@landley.net>

It panics during boot.  I bisected it to commit
7eaceaccab5f40bbfda044629a6298616aeaed50 which doesn't look like
something trivial I can reverse, I'll see if I can get anybody to look
at it on the lists...

FYI.

Rob

 1306216169.0

From rob at landley.net  Tue May 24 06:29:04 2011
From: rob at landley.net (Rob Landley)
Date: Tue, 24 May 2011 01:29:04 -0500
Subject: [Aboriginal] 9p VirtFS for /home
In-Reply-To: <BANLkTik_poOdTTg745QHqipKMC7LS3uz0w@mail.gmail.com>
References: <BANLkTik_poOdTTg745QHqipKMC7LS3uz0w@mail.gmail.com>
Message-ID: <4DDB5030.5030205@landley.net>

Oh good, I've actually been looking at 9p for a couple months now:

  http://lists.nongnu.org/archive/html/qemu-devel/2011-01/msg02481.html

I just haven't worked out the UI details for adding it to Aboriginal.
(And it's new enough that most distro QEMU versions don't support it yet.)

My local baseconfig-linux has the NFS symbols yanked and the 9p symbols
added, both for the diod tcp server and for virtfs...

On 05/23/2011 01:14 PM, Salman Aljammaz wrote:
> I have a fairly trivial change to share.
> 
> I've modified the init script, the kernel config, and the qemu command
> to mount the host user's $HOME on /home and the host's root on
> /mnt/host on bootup, using 9p [1].  I found this to be easier to work
> with than using an hdb image and FTP.  (The choice of directories to
> export was just for my convenience)

Hmmm...  The problem is that native-build.sh mounts the hdc control
image on /mnt.  (I admit that /mnt/host makes sense, but it's already in
use.)

Read read read.  Think think think...

In root-filesystem, there's a "root" top level directory, added by
commit 1266 as a mount point for the root user's home directory,  (This
is because when you ssh you need a .ssh directory for keys and
known_hosts and such, or else dropbear gets sad.  This mountpoint gives
you some place to slap a tmpfs onto if you need that.)

However, this might also be a great place to mount the root directory of
the host system.  I can just change the passwd entry for root to have
/home/root or such be the home directory of the root user, then creating
and populating it is your problem...

Sound like a plan?

> Caveat: Because this uses VitrIO, this currently only works for x86
> targets.  I believe there was an effort to make that work with ARM as
> well [2] but I don't know what's happened with that.

There's no excuse for virtio NOT to work with other targets, but this
came from KVM rather than QEMU, which means they did a half-assed job
and then stopped, which is SOP for them:

  http://lists.nongnu.org/archive/html/qemu-devel/2011-01/msg02272.html

I'm STILL waiting for decent documentation on virtconsole:

  http://lists.nongnu.org/archive/html/qemu-devel/2011-05/msg00390.html

> Meanwhile we
> could just run a real 9p server (inferno/npfs) and mount it over the
> network.

There's only _one_ that actually works right now with 9p2000.L, and
thats the "Distributed I/O Daemon":

  http://code.google.com/p/diod/

It's undergoing a lot of polishing as the author drops -pre releases
before 1.0 (and as I bitch at him about stuff :), I'd recommend grabbing
the git version.  That's what I'm testing against here.

> I wonder why qemu doesn't do 9p with its user mode network,
> like cifs...  I should look into that.

Exactly.  Before Diod I was poking the qemu guys about genericizing
their infrastructure:

  http://lists.nongnu.org/archive/html/qemu-devel/2011-04/msg00971.html

But then diod came along...

> P.S. Thanks for making aboriginal linux!  I was at the verge of losing
> faith in linux cross compiling; but i discovered this stuff, and it
> actually works!

Thanks.  I'm not a big fan of cross compiling myself, which is why I'm
trying to isolate it.

Unfortunately, I'm running into some limitations.  For example, QEMU
recently grew s390 support but uClibc hasn't got that, so I may need to
add a glibc option for some targets (which has perl as a build
prerequisite, which is too ugly for words)...

Plus I'm stuck on gcc 4.2.1 because the next dot release went GPLv3 and
I only do non-open-source development when paid to, but there's _also_
the fact that 4.3 split out 2 of gcc's subdirectories as separate
packages for no obvious reason, and then gcc 4.5 went "screw it, let's
rewrite the whole thing in C++"...

But 4.2 doesn't support ARMv7 and thumb2, which is kind of important
these days.  Luckily, my layers are orthogonal enough I can build
toolchains with crosstool-ng and slot 'em in.  Unluckily, crosstool is a
flaming pain in the ass to configure and use...

*shrug*  The usual...

 Rob

 1306218544.0

From rob at landley.net  Tue May 24 07:34:41 2011
From: rob at landley.net (Rob Landley)
Date: Tue, 24 May 2011 02:34:41 -0500
Subject: [Aboriginal] 9p VirtFS for /home
In-Reply-To: <BANLkTik_poOdTTg745QHqipKMC7LS3uz0w@mail.gmail.com>
References: <BANLkTik_poOdTTg745QHqipKMC7LS3uz0w@mail.gmail.com>
Message-ID: <4DDB5F91.1030001@landley.net>

On 05/23/2011 01:14 PM, Salman Aljammaz wrote:
> # HG changeset patch
> # User aljamms8 at cs.man.ac.uk
> # Date 1306104988 0
> # Node ID 1a5767c4bdaddffeb39d58b592fe3d1627589268
> # Parent  e948f92964b50679eac300c2842980d4364de9bb
> Use 9p VirtFS for /home and /mnt/host
> 
> diff -r e948f92964b5 -r 1a5767c4bdad sources/baseconfig-linux
> --- a/sources/baseconfig-linux	Wed May 04 02:04:17 2011 -0500
> +++ b/sources/baseconfig-linux	Sun May 22 22:56:28 2011 +0000
> @@ -40,3 +40,13 @@
>  CONFIG_SQUASHFS=y
>  CONFIG_MAGIC_SYSRQ=y
>  CONFIG_DEVTMPFS=y
> +
> +CONFIG_VIRTIO=y
> +CONFIG_VIRTIO_PCI=y
> +CONFIG_VIRTIO_NET=y
> +CONFIG_NET_9P=y
> +CONFIG_NET_9P_VIRTIO=y
> +CONFIG_9P_FS=y
> +CONFIG_9P_FS_POSIX_ACL=y
> +CONFIG_PARAVIRT_GUEST=y
> +CONFIG_VIRTUALIZATION=y

Hmmm, my .config just has:

--- a/sources/baseconfig-linux  Tue May 24 02:00:52 2011 -0500
+++ b/sources/baseconfig-linux  Tue May 24 02:00:56 2011 -0500
@@ -34,9 +34,15 @@
 CONFIG_EXT3_FS=y
 CONFIG_TMPFS=y
 CONFIG_MISC_FILESYSTEMS=y
-CONFIG_NETWORK_FILESYSTEMS=y
-CONFIG_NFS_FS=y
-CONFIG_NFS_V3=y
 CONFIG_SQUASHFS=y
 CONFIG_MAGIC_SYSRQ=y
 CONFIG_DEVTMPFS=y
+
+CONFIG_NETWORK_FILESYSTEMS=y
+CONFIG_NET_9P=y
+CONFIG_VIRTUALIZATION=y
+CONFIG_VIRTIO_PCI=y
+CONFIG_NET_9P_VIRTIO=y
+CONFIG_VIRTIO_NET=y
+CONFIG_9P_FS=y
+CONFIG_9P_FS_POSIX_ACL=y

Let's see...

CONFIG_VIRTIO is an internal symbol, it has no prompt but is instead
selected by other symbols.

CONFIG_PARAVIRT_GUEST=y enables optimizations for running under KVM.
(Ok I suppose, but not useful off an x86 host, or under qemu.  In the
circumstances where it's actually useful, so is chroot.)

I must admit your symbol order is a lot prettier than mine. :)

> diff -r e948f92964b5 -r 1a5767c4bdad sources/root-filesystem/sbin/init.sh
> --- a/sources/root-filesystem/sbin/init.sh	Wed May 04 02:04:17 2011 -0500
> +++ b/sources/root-filesystem/sbin/init.sh	Sun May 22 22:56:28 2011 +0000
> @@ -37,12 +37,19 @@
>    [ "$(date +%s)" -lt 1000 ] && rdate 10.0.2.2 # or time-b.nist.gov
>  
>    mount -t tmpfs /tmp /tmp
> +  mount -t tmpfs /mnt /mnt
>  
> -  # If there's a /dev/hdb or /dev/sdb, mount it on home
> +  # if there's a 9p virtual filesystem, mount it on home, otherwise
> +  # check for /dev/hdb or /dev/sdb
>  
>    [ -b /dev/hdb ] && HOMEDEV=/dev/hdb
>    [ -b /dev/sdb ] && HOMEDEV=/dev/sdb
> -  if [ ! -z "$HOMEDEV" ]
> +  if [ -d /sys/bus/virtio/drivers/9pnet_virtio/virtio0 ]
> +  then
> +    mkdir /mnt/host
> +    mount -t 9p -o trans=virtio host /mnt/host
> +    mount -t 9p -o trans=virtio home /home
> +  elif [ ! -z "$HOMEDEV" ]

Hmmm, seems a bit inflexible.

If you mount the host's / somewhere you can then bind mount /home out of
it.  You don't need two virtfs exports.

Specifying where HOME lives is the kind of thing I'd normally use an
environment variable for.  (You can both export them for run-emulator.sh
and feed them to init.sh via QEMU_EXTRA.  If it's going to live in
perhaps system-image-$ARCH/home directory on the host then
dev-environment.sh can trivially add it to QEMU_EXTRA, modulo there
being spaces in the path to get there, but maybe qemu could take a
relative path so that wasn't an issue...)

The real problem is that virtio isn't available on all targets.  This
can't make hdb.img go away. :(

By the way, i've had some discussions on the p9 mailing list about
redoing the mount user interface a bit, so it can autodetect the
transport type and such.  The thread is behind this horrible (and
wordwrapped) URL:

http://sourceforge.net/mailarchive/forum.php?thread_name=4DB08F2B.6070004%40parallels.com&forum_name=v9fs-developer

The meat of it is sort of here:

  http://sourceforge.net/mailarchive/message.php?msg_id=27389405

If I got something like that in, we could specify "10.0.2.2:/path" or
similar...

>    then
>      mount -o noatime $HOMEDEV /home
>    else
> @@ -50,13 +57,14 @@
>      touch /.temp 2>/dev/null
>      [ $? -ne 0 ] && mount -t tmpfs /home /home || rm /.temp
>    fi
> +
>    cd /home
> -
>    [ -b /dev/hdc ] && MNTDEV=/dev/hdc
>    [ -b /dev/sdc ] && MNTDEV=/dev/sdc
>    if [ ! -z "$MNTDEV" ]
>    then
> -    mount -o ro $MNTDEV /mnt
> +    mkdir /mnt/c
> +    mount -o ro $MNTDEV /mnt/c
>    fi

Breaks the existing control images.  (Doable, but annoying.)

>    [ -z "$CONSOLE" ] &&
> diff -r e948f92964b5 -r 1a5767c4bdad system-image.sh
> --- a/system-image.sh	Wed May 04 02:04:17 2011 -0500
> +++ b/system-image.sh	Sun May 22 22:56:28 2011 +0000
> @@ -30,6 +30,8 @@
>  {
>    echo -n "-nographic -no-reboot -kernel $KERNEL \$WITH_HDC \$WITH_HDB"
>    [ "$SYSIMAGE_TYPE" != "initramfs" ] && echo -n " -hda $IMAGE"
> +  echo -n " -virtfs local,path=/,security_model=none,mount_tag=host"
> +  echo -n " -virtfs local,path=\$HOME,security_model=none,mount_tag=home"
>    echo -n " -append \"$(kernel_cmdline)\" \$QEMU_EXTRA"
>  }

Have you tested this on any target _other_ than x86?

Also, it means that a qemu that doesn't support -virtfs will fail to
launch, and most distro qemus don't have it yet...

Rob

 1306222481.0

From rob at landley.net  Tue May 24 08:09:50 2011
From: rob at landley.net (Rob Landley)
Date: Tue, 24 May 2011 03:09:50 -0500
Subject: [Aboriginal] 9p VirtFS for /home
In-Reply-To: <BANLkTik_poOdTTg745QHqipKMC7LS3uz0w@mail.gmail.com>
References: <BANLkTik_poOdTTg745QHqipKMC7LS3uz0w@mail.gmail.com>
Message-ID: <4DDB67CE.4030506@landley.net>

On 05/23/2011 01:14 PM, Salman Aljammaz wrote:
>    [ "$SYSIMAGE_TYPE" != "initramfs" ] && echo -n " -hda $IMAGE"
> +  echo -n " -virtfs local,path=/,security_model=none,mount_tag=host"
> +  echo -n " -virtfs local,path=\$HOME,security_model=none,mount_tag=home"
>    echo -n " -append \"$(kernel_cmdline)\" \$QEMU_EXTRA"

Also, you probably want security_model=mapped unless you're running
qemu/kvm as root (which I try not to do: nothing Aboriginal does should
require root on the host).

Rob

 1306224590.0

From rob at landley.net  Wed May 25 07:40:09 2011
From: rob at landley.net (Rob Landley)
Date: Wed, 25 May 2011 02:40:09 -0500
Subject: [Aboriginal] Mips bug...
Message-ID: <4DDCB259.80803@landley.net>

My bad, the mips bug is actually:

af3a1f6f4813907e143f87030cde67a9971db533 is the first bad commit
commit af3a1f6f4813907e143f87030cde67a9971db533
Author: Ralf Baechle <ralf at linux-mips.org>
Date:   Tue Mar 29 11:43:19 2011 +0200

    MIPS: Malta: Fix GCC 4.6.0 build error

      CC      arch/mips/mti-malta/malta-init.o
    arch/mips/mti-malta/malta-init.c: In function 'prom_init':
    arch/mips/mti-malta/malta-init.c:196:6: error: variable 'result' set
but not used [-Werror=unused-but-set-variable]
    cc1: all warnings being treated as errors

    Signed-off-by: Ralf Baechle <ralf at linux-mips.org>

:040000 040000 58f11c3479ae15f2c4d0a3e7486c7aa4e1ca3e96
33ad31b666926e7090b5165b79773eee38b58229 M      arch

Reversing that patch fixes the error, but I've pinged Ralf to see if he
knows what's up.  (That's a small enough patch I might be able to work
out what's wrong myself, but let's see what he says first...)

Rob

 1306309209.0

From niklas.brunback at gmail.com  Wed May 25 08:57:09 2011
From: niklas.brunback at gmail.com (=?ISO-8859-15?Q?Niklas_Brunb=E4ck?=)
Date: Wed, 25 May 2011 10:57:09 +0200 (CEST)
Subject: [Aboriginal] 9p VirtFS for /home
In-Reply-To: <BANLkTik_poOdTTg745QHqipKMC7LS3uz0w@mail.gmail.com>
References: <BANLkTik_poOdTTg745QHqipKMC7LS3uz0w@mail.gmail.com>
Message-ID: <alpine.DEB.2.00.1105251042130.2596@bender>

On Mon, 23 May 2011, Salman Aljammaz wrote:

>
> Caveat: Because this uses VitrIO, this currently only works for x86
> targets.  I believe there was an effort to make that work with ARM as
> well [2] but I don't know what's happened with that.  Meanwhile we
> could just run a real 9p server (inferno/npfs) and mount it over the
> network.  I wonder why qemu doesn't do 9p with its user mode network,
> like cifs...  I should look into that.
>
I'm currently using unfsd (http://unfs3.sourceforge.net/) to mount stuff 
in qemu. It works really well, but you have to do a "cp -rs 
/nfsmount/path/to/source /path/to/some/local/fs" and build in 
/path/to/some/local/fs. I'm also exporting the toolchain to the target via 
NFS.

It should work with most arches and it does not require root privileges 
but you need to specify mountport=, port= and mountvers=3.

It wants to link to libfl. I'm building it statically with the cross 
compiler just in case I need to export something from the target.

Niklas

 1306313829.0

From rob at landley.net  Wed May 25 12:46:37 2011
From: rob at landley.net (Rob Landley)
Date: Wed, 25 May 2011 07:46:37 -0500
Subject: [Aboriginal] 9p VirtFS for /home
In-Reply-To: <alpine.DEB.2.00.1105251042130.2596@bender>
References: <BANLkTik_poOdTTg745QHqipKMC7LS3uz0w@mail.gmail.com>
	<alpine.DEB.2.00.1105251042130.2596@bender>
Message-ID: <4DDCFA2D.2020308@landley.net>

On 05/25/2011 03:57 AM, Niklas Brunb?ck wrote:
> On Mon, 23 May 2011, Salman Aljammaz wrote:
> 
>>
>> Caveat: Because this uses VitrIO, this currently only works for x86
>> targets.  I believe there was an effort to make that work with ARM as
>> well [2] but I don't know what's happened with that.  Meanwhile we
>> could just run a real 9p server (inferno/npfs) and mount it over the
>> network.  I wonder why qemu doesn't do 9p with its user mode network,
>> like cifs...  I should look into that.
>>
> I'm currently using unfsd (http://unfs3.sourceforge.net/) to mount stuff
> in qemu. It works really well, but you have to do a "cp -rs
> /nfsmount/path/to/source /path/to/some/local/fs" and build in
> /path/to/some/local/fs. I'm also exporting the toolchain to the target
> via NFS.

The control images are squashfs (read only) mounts on /mnt, so they also
havve to cp -s into writeable space in order to build.  (That's a
marvelous trick, isn't it?)

So far 9p is in fact capable of being built in.  (I'm playing with
crosstool in a qemu debian image that's only got a 1 gig filesystem and
debian takes up over half of that, so I've got /mnt/diod with more space
to hg clone crosstool into...)

I am very interested in automating this, but I'd also like to get the
infrastructure right...

> It should work with most arches and it does not require root privileges
> but you need to specify mountport=, port= and mountvers=3.

The diod server can also do the same thing for 9p via tcp/ip.  The
advantage of virtfs is that it's built into qemu.

9p is a nice protocol that can in theory work through any arbitrary
serial connection, it needs one connection per mount.  For virtfs it's
using virtio to provide that connection, for diod it's using tcp/ip for
that connection.  In theory, qemu could fake up a TCP/IP connection (it
would just require a bit more emulation to break it down into packets
and then stitch them back together, right now the -net user stuff other
than masquerading is packet based rather than stream based.  The virtual
DNS server, virtual dhcp server, etc...)

So the _ideal_ solution would be to be able to have a qemu option that
could fake up a 9p server on 10.0.2.4 the way samba works now (iana gave
it port 564), so we wouldn't even need to run diod on the host's
loopback but just go "-v9fs security_model=mapped,path=/dir/to/export"
and then mount it in the target system from 10.0.2.4.

> It wants to link to libfl. I'm building it statically with the cross
> compiler just in case I need to export something from the target.
> 
> Niklas

I'm having some problem where building qemu myself, it's not including
virtfs support.  I have no idea why, it did last time but I've
reinstalled my laptop since and am probably missing some unmentioned
prerequisite library.  Sigh...

Rob

 1306327597.0

From onefang at gmail.com  Wed May 25 12:57:36 2011
From: onefang at gmail.com (David Seikel)
Date: Wed, 25 May 2011 22:57:36 +1000
Subject: [Aboriginal] The hw- target stuff is probably bit-rotted.
In-Reply-To: <4DACE184.9030907@parallels.com>
References: <4DACD933.2010807@landley.net>
	<20110419104842.4d91a04f@U64-desktop>
	<4DACE184.9030907@parallels.com>
Message-ID: <20110525225736.3e6d76b4@U64-desktop>

On Mon, 18 Apr 2011 20:12:36 -0500 Rob Landley <rlandley at parallels.com>
wrote:

> On 04/18/2011 07:48 PM, David Seikel wrote:
> > On Mon, 18 Apr 2011 19:37:07 -0500 Rob Landley <rob at landley.net>
> > wrote:
> > 
> > Just wasted a day beating up grub legacy. Think I got it in shape
> > now. The patches supplied with the version used in the last LFS
> > that used grub legacy don't actually apply, no matter which patch
> > program you use.  The advice to set the compiler flags is just
> > plain wrong.  No one ever actually tested the --disable-nls
> > configure option.  #if statements refer to symbols that are not
> > defined, instead of using #ifdef.  I'm sure there was more I can't
> > recall right now.
> 
> Yeah, that's the FSF.  As with many packages, it used to work, then it
> was contributed to the FSF and it gradually bloated and became
> incoherent.
> 
> > I seriously think that since that was the last grub legacy that FSF
> > published, that they went to the effort of breaking it.  But, never
> > ascribe to malice what can be accounted for with stupidity.
> 
> So back up a few versions.

Actually, the problem was that the LFS I was using included a later
grub version that was overwriting the source of the grub version I was
trying to install.  This happens when the LFS included source tarballs
are unpacked at the end.  I added in a line to remove the internal grub
tarball before unpacking the rest of LFS.

That at least got rid of the --disable-nls problem, the patches still
did not apply.

The rest of my problems where - when building a disk image from
scratch, it pays to sync often.  And some shitty hardware issues.

Right now I'm happy to finally see the system and demo app booting and
running on actual hardware.  Yay!

-- 
A big old stinking pile of genius that no one wants
coz there are too many silver coated monkeys in the world.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL: <http://lists.landley.net/pipermail/aboriginal/attachments/20110525/405bc082/attachment.sig>

From rob at landley.net  Thu May 26 06:39:27 2011
From: rob at landley.net (Rob Landley)
Date: Thu, 26 May 2011 01:39:27 -0500
Subject: [Aboriginal] The hw- target stuff is probably bit-rotted.
In-Reply-To: <20110525225736.3e6d76b4@U64-desktop>
References: <4DACD933.2010807@landley.net>	<20110419104842.4d91a04f@U64-desktop>	<4DACE184.9030907@parallels.com>
	<20110525225736.3e6d76b4@U64-desktop>
Message-ID: <4DDDF59F.50607@landley.net>

On 05/25/2011 07:57 AM, David Seikel wrote:
> On Mon, 18 Apr 2011 20:12:36 -0500 Rob Landley <rlandley at parallels.com>
> wrote:
>>> I seriously think that since that was the last grub legacy that FSF
>>> published, that they went to the effort of breaking it.  But, never
>>> ascribe to malice what can be accounted for with stupidity.
>>
>> So back up a few versions.
> 
> Actually, the problem was that the LFS I was using included a later
> grub version that was overwriting the source of the grub version I was
> trying to install.  This happens when the LFS included source tarballs
> are unpacked at the end.  I added in a line to remove the internal grub
> tarball before unpacking the rest of LFS.

You mean while running make-control-image.sh?  Or are you extracting a
tarball at native build time?  (I dunno how closely what you're doing is
based on my lfs-bootstrap... or not.)

> That at least got rid of the --disable-nls problem, the patches still
> did not apply.
> 
> The rest of my problems where - when building a disk image from
> scratch, it pays to sync often.  And some shitty hardware issues.

I tend to make scripts that can be re-run to rebuild everything, and
then do lots of unnecessary rebuilds which I write off as "regression
testing".  I've been in the situation of tweaking a system I can't
reproduce, and "restore from backup" isn't an option if the problem is
an old software package got silently corrupted 18 months ago and
nobody's noticed up until now, and the build recipe that would allow you
to replace it has to be worked out fromm scratch again, and nobody even
remembers what it's used for...

Erring on the side of "rebuild into a fresh directory, time for lunch"
is much more comfortable for me.  (Then again, almost all my builds are
"build all".  I even put a "make clean" step in my git bisects.  Well,
actually I put a "git clean -fdx && git checkout -f" in there, because
distclean can have version skew. :P )

> Right now I'm happy to finally see the system and demo app booting and
> running on actual hardware.  Yay!

Woot!  Congratulations.

Rob

 1306391967.0

From onefang at gmail.com  Thu May 26 07:09:30 2011
From: onefang at gmail.com (David Seikel)
Date: Thu, 26 May 2011 17:09:30 +1000
Subject: [Aboriginal] The hw- target stuff is probably bit-rotted.
In-Reply-To: <4DDDF59F.50607@landley.net>
References: <4DACD933.2010807@landley.net>
	<20110419104842.4d91a04f@U64-desktop>
	<4DACE184.9030907@parallels.com>
	<20110525225736.3e6d76b4@U64-desktop> <4DDDF59F.50607@landley.net>
Message-ID: <20110526170930.647e76c4@U64-desktop>

On Thu, 26 May 2011 01:39:27 -0500 Rob Landley <rob at landley.net> wrote:

> On 05/25/2011 07:57 AM, David Seikel wrote:
> > On Mon, 18 Apr 2011 20:12:36 -0500 Rob Landley
> > <rlandley at parallels.com> wrote:
> >>> I seriously think that since that was the last grub legacy that
> >>> FSF published, that they went to the effort of breaking it.  But,
> >>> never ascribe to malice what can be accounted for with stupidity.
> >>
> >> So back up a few versions.
> > 
> > Actually, the problem was that the LFS I was using included a later
> > grub version that was overwriting the source of the grub version I
> > was trying to install.  This happens when the LFS included source
> > tarballs are unpacked at the end.  I added in a line to remove the
> > internal grub tarball before unpacking the rest of LFS.
> 
> You mean while running make-control-image.sh?  Or are you extracting a
> tarball at native build time?  (I dunno how closely what you're doing
> is based on my lfs-bootstrap... or not.)

Yep, make-control-image.sh.  What I'm doing is based on lfs-bootstrap,
with a heap of the packages commented out of package-list, and a bunch
more tacked on the end.  With suitable build scripts added, though some
of them are just links to generic-check.sh.  The extra packages are
added to download.sh, where the above mentioned change was made.

> > That at least got rid of the --disable-nls problem, the patches
> > still did not apply.
> > 
> > The rest of my problems where - when building a disk image from
> > scratch, it pays to sync often.  And some shitty hardware issues.
> 
> I tend to make scripts that can be re-run to rebuild everything, and
> then do lots of unnecessary rebuilds which I write off as "regression
> testing".  I've been in the situation of tweaking a system I can't
> reproduce, and "restore from backup" isn't an option if the problem is
> an old software package got silently corrupted 18 months ago and
> nobody's noticed up until now, and the build recipe that would allow
> you to replace it has to be worked out fromm scratch again, and
> nobody even remembers what it's used for...
> 
> Erring on the side of "rebuild into a fresh directory, time for lunch"
> is much more comfortable for me.  (Then again, almost all my builds
> are "build all".  I even put a "make clean" step in my git bisects.
> Well, actually I put a "git clean -fdx && git checkout -f" in there,
> because distclean can have version skew. :P )

I have a tendency to do that to.  For similar reasons, I tend to reboot
when a system update, or my own work, messes with anything that's used
for the boot up sequence.  Something I'd rather know got broken when it
breaks, rather than months later when I will have less clue, and likely
a dire need for the system to just boot NOW dammit.

Plus, what better way to exercise the legendary laziness of a good
programmer than to start a long compile, then wonder to the other side
of my bedroom / office, and just relax on my bed for half an hour?  B-)

-- 
A big old stinking pile of genius that no one wants
coz there are too many silver coated monkeys in the world.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL: <http://lists.landley.net/pipermail/aboriginal/attachments/20110526/a70c73cc/attachment.sig>

From rob at landley.net  Fri May 27 16:15:37 2011
From: rob at landley.net (Rob Landley)
Date: Fri, 27 May 2011 11:15:37 -0500
Subject: [Aboriginal] 9p VirtFS for /home
In-Reply-To: <BANLkTik_poOdTTg745QHqipKMC7LS3uz0w@mail.gmail.com>
References: <BANLkTik_poOdTTg745QHqipKMC7LS3uz0w@mail.gmail.com>
Message-ID: <4DDFCE29.6040708@landley.net>

Ah, the fix to build qemu with virtfs support is to first install
libattr (in Ubuntu, that's package libattr1-dev).

That was non-obvious.  Ok, I should be able to test this some more this
weekend...

Rob

 1306512937.0