11:26 a.m.
Repo: git://git.baserock.org/baserock/baserock/definitions.git
Ref: baserock/richardmaw/S10786-finer-splitting
SHA1: 817a4a98e5fdb14283e1e809a3ba28f884f79292
Land: origin/master
This also includes an update to zlib.
The changes to gcc and eglibc will also be sent to the list for review.
No patch series for zlib will be included, since there are no morph
related changes involved in updating its version.
Richard Maw (1):
Define a minimal x86_32 system
base-system-x86_32-generic.morph | 2 +-
build-essential.morph | 22 +++++++++++++++++++---
minimal-system-x86_32-generic.morph | 15 +++++++++++++++
3 files changed, 35 insertions(+), 4 deletions(-)
create mode 100644 minimal-system-x86_32-generic.morph
--
1.8.5.rc2
11:26 a.m.
New subject: [PATCH] Define a minimal x86_32 system
This minimal system is smaller than base, consisting of little more than
busybox, its dependent libraries and a kernel built with tools that
don't make it into the final system.
---
base-system-x86_32-generic.morph | 2 +-
build-essential.morph | 22 +++++++++++++++++++---
minimal-system-x86_32-generic.morph | 15 +++++++++++++++
3 files changed, 35 insertions(+), 4 deletions(-)
create mode 100644 minimal-system-x86_32-generic.morph
diff --git a/base-system-x86_32-generic.morph b/base-system-x86_32-generic.morph
index a1eff55..e53b2d9 100644
--- a/base-system-x86_32-generic.morph
+++ b/base-system-x86_32-generic.morph
@@ -5,7 +5,7 @@ configuration-extensions:
- simple-network
- nfsboot
- install-files
-description: The set of strata required to have a minimal system for a 32-bit x86
+description: The set of strata required to have a basic system for a 32-bit x86
system.
kind: system
name: base-system-x86_32-generic
diff --git a/build-essential.morph b/build-essential.morph
index 387f2b8..eefec3a 100644
--- a/build-essential.morph
+++ b/build-essential.morph
@@ -31,6 +31,11 @@ description: |
stage2-fhs-dirs.morph for details. Basically, /bin is a symlink to
/tools/bin during stage 2 but in stage 3 it becomes a real directory
again.
+products:
+- artifact: build-essential-minimal
+ include:
+ - fhs-dirs-.*
+ - busybox-.*
chunks:
- name: stage1-binutils
repo: upstream:binutils-redhat
@@ -165,7 +170,8 @@ chunks:
prefix: /usr
- name: eglibc
repo: upstream:eglibc2
- ref: baserock/2.15-build-essential
+ ref: baserock/richardmaw/S10786-finer-splitting
+ unpetrify-ref: baserock/2.15-build-essential
build-depends:
- stage2-binutils
- stage2-busybox
@@ -178,10 +184,15 @@ chunks:
- stage2-reset-specs
- linux-api-headers
build-mode: staging
+ artifacts:
+ eglibc-gconv: build-essential-runtime
+ eglibc-libs: build-essential-minimal
+ eglibc-nss: build-essential-runtime
prefix: /usr
- name: zlib
repo: upstream:zlib
- ref: baserock/build-essential
+ ref: baserock/richardmaw/S10786-finer-splitting
+ unpetrify-ref: baserock/build-essential
build-depends:
- stage2-binutils
- stage2-busybox
@@ -194,6 +205,8 @@ chunks:
- stage2-reset-specs
- eglibc
build-mode: staging
+ artifacts:
+ zlib-libs: build-essential-minimal
prefix: /usr
- name: binutils
repo: upstream:binutils-redhat
@@ -246,7 +259,8 @@ chunks:
prefix: /usr
- name: gcc
repo: upstream:gcc-tarball
- ref: baserock/build-essential
+ ref: baserock/richardmaw/S10786-finer-splitting
+ unpetrify-ref: baserock/build-essential
build-depends:
- stage2-binutils
- stage2-busybox
@@ -260,6 +274,8 @@ chunks:
- eglibc
- zlib
build-mode: staging
+ artifacts:
+ gcc-libs: build-essential-minimal
prefix: /usr
- name: make
repo: upstream:make
diff --git a/minimal-system-x86_32-generic.morph b/minimal-system-x86_32-generic.morph
new file mode 100644
index 0000000..f8e5d19
--- /dev/null
+++ b/minimal-system-x86_32-generic.morph
@@ -0,0 +1,15 @@
+arch: x86_32
+configuration-extensions:
+- set-hostname
+- simple-network
+- nfsboot
+- install-files
+description: The set of strata required to have a minimal system for a 32-bit x86
+ system.
+kind: system
+name: minimal-system-x86_32-generic
+strata:
+- morph: build-essential
+ artifacts:
+ - build-essential-minimal
+- morph: bsp-x86_32-generic
--
1.8.5.rc2
11:27 a.m.
New subject: [PATCH] Define splitting rules for gcc
Repo: git://git.baserock.org/delta/gcc-tarball.git
Ref: baserock/richardmaw/S10786-finer-splitting
SHA1: 088b7ab28fe53b198ec5c4eaba0f54176c4c35a0
Land: origin/baserock/build-essential
Richard Maw (1):
gcc.morph: Define splitting rules
gcc.morph | 16 ++++++++++++++++
1 file changed, 16 insertions(+)
--
1.8.5.rc2
11:27 a.m.
New subject: [PATCH] gcc.morph: Define splitting rules
---
gcc.morph | 16 ++++++++++++++++
1 file changed, 16 insertions(+)
diff --git a/gcc.morph b/gcc.morph
index 498a60b..86d42fc 100644
--- a/gcc.morph
+++ b/gcc.morph
@@ -1,6 +1,22 @@
name: gcc
kind: chunk
+products:
+- artifact: gcc-libs
+ include:
+ - (usr/)lib/lib.*\.so(\.\d+)*$
+- artifact: gcc-doc
+ include:
+ - (usr/)?share/doc/.*
+ - (usr/)?share/man/.*
+ - (usr/)?share/info/.*
+- artifact: gcc-devel
+ # devel includes everything which isn't documentation or libs, since
+ # everything else gcc produces is required for compiling
+ # this is the -devel artifact instead of -misc, since it goes in -devel
+ # stratum artifacts by default
+ include: [ .* ]
+
configure-commands:
- mkdir o
--
1.8.5.rc2
11:27 a.m.
New subject: [PATCH] Define splitting rules for eglibc
Repo: git://git.baserock.org/delta/eglibc2
Ref: baserock/richardmaw/S10786-finer-splitting
SHA1: 2c8b27a3da500b9cd8a31e78baa81e578b145728
Land: origin/baserock/2.15-build-essential
Richard Maw (1):
eglibc.morph: Define splitting rules
eglibc.morph | 39 +++++++++++++++++++++++++++++++++++++++
1 file changed, 39 insertions(+)
--
1.8.5.rc2
11:27 a.m.
New subject: [PATCH] eglibc.morph: Define splitting rules
---
eglibc.morph | 39 +++++++++++++++++++++++++++++++++++++++
1 file changed, 39 insertions(+)
diff --git a/eglibc.morph b/eglibc.morph
index 4efd311..7dbbdd4 100644
--- a/eglibc.morph
+++ b/eglibc.morph
@@ -1,6 +1,45 @@
name: eglibc
kind: chunk
+products:
+- artifact: eglibc-nss
+ include:
+ - (usr/)?lib/libnss.*
+- artifact: eglibc-gconv
+ include:
+ - (usr/)?lib/gconv/.*
+- artifact: eglibc-gconv
+ include:
+ - (usr/)?lib/libnss.*
+- artifact: eglibc-libs
+ include:
+ - sbin/ldconfig
+ - lib/ld-.*
+ - (usr/)?lib(exec)?/pt_chown
+- artifact: eglibc-bins
+ include:
+ - (usr/)?s?bin/.*
+ - (usr/)?libexec/getconf/.* # support libs for getconf
+ - (usr/)?lib/libSegFault\.so(\.\d+)*$ # support lib for catchsegv
+- artifact: eglibc-libs
+ include:
+ # This is processed after bins, so bins can take libSegFault.so
+ - (usr/)?lib(32|64)?/lib[^/]*\.so(\.\d+)*$
+- artifact: eglibc-devel
+ include:
+ - (usr/)?include/.*
+ - (usr/)?lib(32|64)?/lib.*\.a
+ - (usr/)?lib(32|64)?/lib.*\.la
+ - (usr/)?(lib(32|64)?|share)/pkgconfig/.*\.pc
+ - (usr/)?lib(32|64)?/.*\.o
+- artifact: eglibc-locale
+ include:
+ - (usr/)?share/locale/.*
+ - (usr/)?share/i18n/.*
+ - (usr/)?share/zoneinfo/.*
+- artifact: eglibc-misc
+ include: [ .* ]
+
configure-commands:
- mkdir o
--
1.8.5.rc2
11:45 a.m.
On 26/03/14 16:26, Richard Maw wrote:
Repo: git://git.baserock.org/baserock/baserock/definitions.git
Ref: baserock/richardmaw/S10786-finer-splitting
SHA1: 817a4a98e5fdb14283e1e809a3ba28f884f79292
Land: origin/master
This also includes an update to zlib.
The changes to gcc and eglibc will also be sent to the list for review.
No patch series for zlib will be included, since there are no morph
related changes involved in updating its version.
Looks good, but would it be worth making these changes to the
base-system instead of introducing a minimal-system? As I understand it
this branch removes the toolchain from the final system, which surely is
wanted in the base system too?
Sam
--
Sam Thursfield, Codethink Ltd.
Office telephone: +44 161 236 5575
11:49 a.m.
On Wed, Mar 26, 2014 at 04:45:49PM +0000, Sam Thursfield wrote:
Looks good, but would it be worth making these changes to the
base-system instead of introducing a minimal-system?
minimal's aim is to be as tiny as possible to get anything booting,
so it needs to be configured to use busybox's init.
base's aim is to be a useful baseline system, so it has a proper init
system in it and anything we'd consider to be core libraries.
devel is kitchen sink.
The difference between minimal and base is sufficient enough that I
don't think it makes sense to have minimal take the place of base.
As I understand it this branch removes the toolchain from the final
system, which surely is wanted in the base system too?
Yes, but there's also a bunch more work to do for that to be considered
complete, and it was my goal to have a really tiny system available,
rather than make base smaller.
11:55 a.m.
On Wed, Mar 26, 2014 at 16:26:40 +0000, Richard Maw wrote:
Repo: git://git.baserock.org/baserock/baserock/definitions.git
Ref: baserock/richardmaw/S10786-finer-splitting
SHA1: 817a4a98e5fdb14283e1e809a3ba28f884f79292
Land: origin/master
Unfortunately Richard started this before the petrified master happened.
Richard: Can you re-base your work on the petrified master and ensure your
proposed merge doesn't unpetrify anything?
D.
--
Daniel Silverstone http://www.codethink.co.uk/
Lead Architect GPG 4096/R Key Id: 3CCE BABE 206C 3B69
12:03 p.m.
On Wed, Mar 26, 2014 at 04:55:45PM +0000, Daniel Silverstone wrote:
On Wed, Mar 26, 2014 at 16:26:40 +0000, Richard Maw wrote:
> Repo: git://git.baserock.org/baserock/baserock/definitions.git
> Ref: baserock/richardmaw/S10786-finer-splitting
> SHA1: 817a4a98e5fdb14283e1e809a3ba28f884f79292
> Land: origin/master
Unfortunately Richard started this before the petrified master happened.
Richard: Can you re-base your work on the petrified master and ensure your
proposed merge doesn't unpetrify anything?
I'll need to fix up the refs post-merge anyway, but I'll give it a go,
since it may be easier for people to try out when it's petrified.
12:27 p.m.
On Wed, Mar 26, 2014 at 05:03:33PM +0000, Richard Maw wrote:
I'll need to fix up the refs post-merge anyway, but I'll give
it a go,
since it may be easier for people to try out when it's petrified.
Git's merge got less confused than I expected it to, so this was pretty easy.
I won't bother re-sending the diff, since the logical changes are
correctly shown in the previous version.
Ref: baserock/richardmaw/S10786-finer-splitting-rebase
SHA1: e7ee5df7f5b3297a31e9814bde46ede032f98bf2
6:19 p.m.
On 26/03/2014 17:27, Richard Maw wrote:
On Wed, Mar 26, 2014 at 05:03:33PM +0000, Richard Maw wrote:
> I'll need to fix up the refs post-merge anyway, but I'll give it a go,
> since it may be easier for people to try out when it's petrified.
Git's merge got less confused than I expected it to, so this was pretty easy.
I won't bother re-sending the diff, since the logical changes are
correctly shown in the previous version.
Ref: baserock/richardmaw/S10786-finer-splitting-rebase
SHA1: e7ee5df7f5b3297a31e9814bde46ede032f98bf2
I tried building this (after fudging) for x86_64. The build completed
ok, 50.572MB for rootfs, which is apparently rather bigger than expected?
But the result failed to boot - 'kernel panic - no init found'
is that expected behaviour?
4:27 a.m.
On Wed, Mar 26, 2014 at 23:19:38 +0000, Paul Sherwood wrote:
> Ref: baserock/richardmaw/S10786-finer-splitting-rebase
> SHA1: e7ee5df7f5b3297a31e9814bde46ede032f98bf2
I tried building this (after fudging) for x86_64. The build completed
ok, 50.572MB for rootfs, which is apparently rather bigger than expected?
the size difference could be to do with either debug symbols or that different
architectures may result in additional split rules.
But the result failed to boot - 'kernel panic - no init
found'
Minimal uses busybox init, we may need a configuration extension to reinstate
busybox init if systemd is missing.
is that expected behaviour?
I'd say "not unexpected" but once we're okay for 32 bit we should look
into
what it'll take to sort out 64bit and other platforms minimal systems.
D.
--
Daniel Silverstone http://www.codethink.co.uk/
Lead Architect GPG 4096/R Key Id: 3CCE BABE 206C 3B69
5:16 a.m.
On Wed, Mar 26, 2014 at 11:19:38PM +0000, Paul Sherwood wrote:
I tried building this (after fudging) for x86_64. The build
completed
ok, 50.572MB for rootfs, which is apparently rather bigger than expected?
This is because I put the kernel chunk back in, so it would be possible
to boot. I'm surprised that it increased the size by that much, but I
also didn't do any splitting to prevent the BSP including the kernel
headers in the final system.
But the result failed to boot - 'kernel panic - no init
found'
is that expected behaviour?
This is because we don't install the /sbin/init -> /bin/busybox symlink
in the busybox chunk, since we generally expect systemd.
In general, it's just missing a bit more configuration to be usable as a
rootfs though. If you would prefer it work out of the box I'll happily
prepare some updated patches.
I just didn't do it to start with since my goal for this patch was to
have a more unusual system for Richard Ipsum's distbuild patches to try.
10:10 a.m.
On Wed, Mar 26, 2014 at 11:19:38PM +0000, Paul Sherwood wrote:
I tried building this (after fudging) for x86_64. The build
completed
ok, 50.572MB for rootfs, which is apparently rather bigger than expected?
But the result failed to boot - 'kernel panic - no init found'
is that expected behaviour?
I've prepared an updated version now at ref
baserock/richardmaw/S10786-finer-splitting-v2
This has removed the kernel headers from the final system, but the
addition of the kernel and syslinux has doubled the size.
There is now a configuration extension that will add busybox config if
INIT_SYSTEM=busybox is set in the environment, since if you were using
this system as a chroot for example, you wouldn't want to add the extra
init config.
I also added an example deployment as minimal-system-deploy.morph
If you want to try it again with x86_64, you need to ensure that
busybox-init is listed in the configuration extensions.
7:25 p.m.
On 2014-03-27 15:10, Richard Maw wrote:
I've prepared an updated version now at ref
baserock/richardmaw/S10786-finer-splitting-v2
This has removed the kernel headers from the final system, but the
addition of the kernel and syslinux has doubled the size.
There is now a configuration extension that will add busybox config
if
INIT_SYSTEM=busybox is set in the environment, since if you were
using
this system as a chroot for example, you wouldn't want to add the
extra
init config.
I also added an example deployment as minimal-system-deploy.morph
If you want to try it again with x86_64, you need to ensure that
busybox-init is listed in the configuration extensions.
Thanks, Richard.
I built your baserock/richardmaw/S10786-finer-splitting-v2 branch fine
- this rootfs is now 22.9MB
Unfortunately even with the busybox configure it still panics for me...
i guess it's something i'm missing?
http://postimg.org/image/us5e3qw67/
br
Paul
4:17 a.m.
On Fri, Mar 28, 2014 at 00:25:43 +0000, Paul Sherwood wrote:
I built your baserock/richardmaw/S10786-finer-splitting-v2 branch
fine - this rootfs is now 22.9MB
Unfortunately even with the busybox configure it still panics for
me... i guess it's something i'm missing?
http://postimg.org/image/us5e3qw67/
Can you post the system morphology and the deployment cluster morphology to
this thread?
D.
--
Daniel Silverstone http://www.codethink.co.uk/
Lead Architect GPG 4096/R Key Id: 3CCE BABE 206C 3B69
8:10 a.m.
On 28/03/2014 09:17, Daniel Silverstone wrote:
On Fri, Mar 28, 2014 at 00:25:43 +0000, Paul Sherwood wrote:
> I built your baserock/richardmaw/S10786-finer-splitting-v2 branch
> fine - this rootfs is now 22.9MB
> Unfortunately even with the busybox configure it still panics for
> me... i guess it's something i'm missing?
> http://postimg.org/image/us5e3qw67/
Can you post the system morphology and the deployment cluster morphology to
this thread?
http://git.baserock.org/cgi-bin/cgit.cgi/baserock/baserock/definitions.gi...
9:05 a.m.
On Fri, Mar 28, 2014 at 13:10:13 +0000, Paul Sherwood wrote:
> Can you post the system morphology and the deployment cluster
morphology to
> this thread?
http://git.baserock.org/cgi-bin/cgit.cgi/baserock/baserock/definitions.gi...
Unfortunately there's nothing I can spot easily there :-( I'm afraid you may
need to wait for Richard Maw to check it on Monday.
D.
--
Daniel Silverstone http://www.codethink.co.uk/
Lead Architect GPG 4096/R Key Id: 3CCE BABE 206C 3B69
9:33 a.m.
On Fri, Mar 28, 2014 at 02:05:38PM +0000, Daniel Silverstone wrote:
On Fri, Mar 28, 2014 at 13:10:13 +0000, Paul Sherwood wrote:
> > Can you post the system morphology and the deployment cluster morphology to
> > this thread?
>
http://git.baserock.org/cgi-bin/cgit.cgi/baserock/baserock/definitions.gi...
Unfortunately there's nothing I can spot easily there :-( I'm afraid you may
need to wait for Richard Maw to check it on Monday.
It turns out to be a flaw in the splitting rules. On 32-bit the linker
is in /lib/ld-linux-*; but on 64-bit it's in /lib64/ld-linux-*, so the
linker didn't make it into the -libs chunk artifact, so it didn't make
it into the system, so no dynamically linked binaries are runnable.
I'll fix the match rules and update the branch, I'll report the results
after I've rebuilt and re-tested.
12:19 p.m.
On Mon, Mar 31, 2014 at 03:33:33PM +0100, Richard Maw wrote:
I'll fix the match rules and update the branch, I'll report
the results
after I've rebuilt and re-tested.
Updating the splitting rules worked for me. The
baserock/richardmaw/S10786-finer-splitting-v2 branch has been updated
to include this fix.
5:42 p.m.
On 2014-03-31 18:19, Richard Maw wrote:
On Mon, Mar 31, 2014 at 03:33:33PM +0100, Richard Maw wrote:
> I'll fix the match rules and update the branch, I'll report the
> results
> after I've rebuilt and re-tested.
Updating the splitting rules worked for me. The
baserock/richardmaw/S10786-finer-splitting-v2 branch has been updated
to include this fix.
I've built and booted this :-)
fwiw...
- rootfs now 23MB
- lots of stuff got rebuilt, so morph build took 76m in total (is that
right?)
- should this really include core.morph? it includes stuff that doesn't
seem to be available in the actual result (e.g. nano)
- seems to take longer to boot than a
- a few errors on boot, including
- can't access tty: job control turned off
- can't run /etc/init.d/rcS: No such file or directory
- do we need to include the deploy script?
3:15 a.m.
On Mon, Mar 31, 2014 at 11:42:32PM +0100, Paul Sherwood wrote:
On 2014-03-31 18:19, Richard Maw wrote:
>On Mon, Mar 31, 2014 at 03:33:33PM +0100, Richard Maw wrote:
>>I'll fix the match rules and update the branch, I'll report the
>>results
>>after I've rebuilt and re-tested.
>
>Updating the splitting rules worked for me. The
>baserock/richardmaw/S10786-finer-splitting-v2 branch has been updated
>to include this fix.
I've built and booted this :-)
fwiw...
- rootfs now 23MB
- lots of stuff got rebuilt, so morph build took 76m in total (is
that right?)
The cache keys are partly derived from the splitting rules, so changing
the splitting rules for eglibc implies needing to rebuild anything that
depends on it, which is pretty much everything.
- should this really include core.morph? it includes stuff that
doesn't seem to be available in the actual result (e.g. nano)
It wouldn't be 23MB if we included core.morph; it rebuilds that, since
it's a dependency of the bsp stratum, since the kernel uses a lot of
perl in its build system, and perl is in core.
Build-time only dependencies do get rebuilt if the things they depend
on change, but they don't have to be included in the final system.
- seems to take longer to boot than a
Busybox init requires a lot of scripts, so a lot of things that could
be done in parallel in a systemd based system, can't.
- a few errors on boot, including
- can't access tty: job control turned off
This is from the shell, it's something to do with spawning a shell
directly on the console, when the shells usually expect the getty
processes to spawn them.
It's pretty harmless, so I mostly ignore it, though the cttyhack program
from busybox is supposed to fix this.
- can't run /etc/init.d/rcS: No such file or directory
This is because we don't have any services that need to be started on
boot in the minimal systems.
- do we need to include the deploy script?
If by that you mean the busybox-init.configure script, strictly: no,
we could put all this busybox config in the busybox chunk and rely on
systemd to replace the /sbin/init symlink itself, but Emmet convinced
me that this _is_ just configuration, and we may want to deploy a system
to init differently, even if it has got busybox available.
4:32 a.m.
On 01/04/2014 09:15, Richard Maw wrote:
> - do we need to include the deploy script?
If by that you mean the busybox-init.configure script, strictly: no,
Sorry, I should have said 'did you mean to include the
minimal-system-deploy.morph?' - we don't have any other deploy examples.
I'm not against it, but it might be better to put it/them in a separate
subdirectory.
4:46 a.m.
Richard,
On 01/04/2014 10:32, Paul Sherwood wrote:
On 01/04/2014 09:15, Richard Maw wrote:
>> - do we need to include the deploy script?
>
> If by that you mean the busybox-init.configure script, strictly: no,
Sorry, I should have said 'did you mean to include the
minimal-system-deploy.morph?' - we don't have any other deploy examples.
I'm not against it, but it might be better to put it/them in a separate
subdirectory.
+1 for the minimal-system morphs, your call on the deploy.morph
3:53 a.m.
On Mon, Mar 31, 2014 at 11:42:32PM +0100, Paul Sherwood wrote:
- rootfs now 23MB
That sounds about right, now that the linker is included. It is about
1MB in size since it has to be a statically linked executable.
FWIW: musl manages significant size savings here by making libc, libm,
librt and ld-linux all be the same ELF binary.
This is possible since if you compile it right, it can be both executable
and a library.
It manages the space savings by not having a copy of the libc in both
the linker and the shared object.
11:14 a.m.
On Wed, Mar 26, 2014 at 04:26:40PM +0000, Richard Maw wrote:
Repo: git://git.baserock.org/baserock/baserock/definitions.git
Ref: baserock/richardmaw/S10786-finer-splitting
SHA1: 817a4a98e5fdb14283e1e809a3ba28f884f79292
Land: origin/master
This also includes an update to zlib.
The changes to gcc and eglibc will also be sent to the list for review.
No patch series for zlib will be included, since there are no morph
related changes involved in updating its version.
I've pushed the -v2 version of this branch to definitions master,
having reviewed and test built this.
--
http://www.codethink.co.uk/ http://wiki.baserock.org/ http://www.baserock.com/
3272
days inactive
3285
days old
26 comments
5 participants
participants (5)
-
Daniel Silverstone -
Lars Wirzenius -
Paul Sherwood -
Richard Maw -
Sam Thursfield