The stage4 root will boot using systemd as the default init process. We have found some performance issues with systemd on the model. This hasn't been fully investigated yet. To avoid wasting simulator cycles while building, the stage4 root also includes a means to boot with busybox as the init process. To do so, pass <code><nowiki>init=/etc/init</nowiki></code> on the kernel command line.}}

The stage4 root will boot using systemd as the default init process. We have found some performance issues with systemd on the model. This hasn't been fully investigated yet. To avoid wasting simulator cycles while building, the stage4 root also includes a means to boot with busybox as the init process. To do so, pass <code><nowiki>init=/etc/init</nowiki></code> on the kernel command line.}}

+

+

There are a several problems found in the existing stage3 RPMs which will be corrected by rebuilding in mock:

+

+

* Some packages were ''short-circuited'' and helped along with manual intervention. This causes rpm to create a fake '"Requires"' for '"rpmlib(ShortCircuited)"' which cannot normally be resolved. A temporary rpm patch is used to get around this.

+

+

* Some packages were built before some other package they require was built using rpm. That is, the required package was built and installed during stage2 before we used rpm. This leads to problems with implicit dependencies. For instance, glib2-devel was one such package and has a dependency on /bin/python. The python package provides /usr/bin/python. Even though they are the same file, /usr/bin/python does not satisfy the /bin/python. Such packages will need to have some dependencies manually installed in the mock chroot.

+

+

* The stage3 builds were performed using NFS roots. Some of the roots were erroneously mounted with sgid bit set and the sgid bit found its way into some directories in RPM packages. This led to some conflicting files (different file perms) when composing a rootfs with yum. A temporary rpm patch was used to ignore differences in file sgid bits.

+

+

All of these issues will be solved simply by rebuilding everything in mock which is going to be done in stage4 anyway.

Revision as of 18:52, 1 April 2013

AArch64 Bootstrap Stage4 Notes

A copy of the current stage4 rootfs can be found at http://fedorapeople.org/groups/armv8/stage4-rootfs.tar.xz. It is a fairly minimal root with enough in place to build packages with mock. Of course, a yum repository is also needed to feed the mock chroot. An initial repo based on stage3 packages can be found at http://fedorapeople.org/groups/armv8/stage4-repo.tar.xz. This repo is temporary and a live repo available over the network will be coming soon. For now, the mock and yum configs in the rootfs expect the repo to be mounted locally at /stage4-repo.

Booting The RootfsThe stage4 root will boot using systemd as the default init process. We have found some performance issues with systemd on the model. This hasn't been fully investigated yet. To avoid wasting simulator cycles while building, the stage4 root also includes a means to boot with busybox as the init process. To do so, pass init=/etc/init on the kernel command line.

There are a several problems found in the existing stage3 RPMs which will be corrected by rebuilding in mock:

Some packages were short-circuited and helped along with manual intervention. This causes rpm to create a fake '"Requires"' for '"rpmlib(ShortCircuited)"' which cannot normally be resolved. A temporary rpm patch is used to get around this.

Some packages were built before some other package they require was built using rpm. That is, the required package was built and installed during stage2 before we used rpm. This leads to problems with implicit dependencies. For instance, glib2-devel was one such package and has a dependency on /bin/python. The python package provides /usr/bin/python. Even though they are the same file, /usr/bin/python does not satisfy the /bin/python. Such packages will need to have some dependencies manually installed in the mock chroot.

The stage3 builds were performed using NFS roots. Some of the roots were erroneously mounted with sgid bit set and the sgid bit found its way into some directories in RPM packages. This led to some conflicting files (different file perms) when composing a rootfs with yum. A temporary rpm patch was used to ignore differences in file sgid bits.

All of these issues will be solved simply by rebuilding everything in mock which is going to be done in stage4 anyway.