Kernel Sources in the SDK / Adding new ebuild

[Jared White]

Apologies to all for being a newb at this.  This is continued work along the lines of including my own packages (a couple of kernel modules) within an internal distribution of CoreOS.  

The third party module that I would like to add requires kernel sources.  I can't seem to find those contained within the chroot when I drop into cros_sdk. 

    Question 1:  Does anyone know where these kernel sources are?  Surely they are accessible somehow?

 

Additionally, I'm completely new to ebuild and am trying to add my package to be built when I run build_packages.  I have added my package ("foo/bar") to the RDEPEND list inside of third_party/coreos-overlay/coreos-base/coreos/coreos-0.0.1.ebuild

    Question 2:  is this the correct location to specify this dependency so that it gets built when I invoke build_packages?

I have done the following:

    1) added my package ("foo/bar") under ~/trunk/src/third_party/foo/bar

    2) added a "bar.ebuild" file under this folder.  All this does at the moment is some boilerplate ebuild declarations and echo things to the console.

    3) For good measure, I re-ran "./setup_board --default --board=amd64-usr --force" as well.  

What occurs when I invoke build_packages follows:

emerge: there are no ebuilds to satisfy "foo/bar" for /build/amd64-usr/.

(dependency required by "coreos-base/coreos-0.0.1-r269::coreos" [installed])

(dependency required by "coreos-devel/board-packages-0.0.1-r5::coreos" [installed])

(dependency required by "coreos-devel/board-packages" [argument])

    Question 3:  What am I missing here?  Do I have to register my ebuild elsewhere?  

Thanks in advance. 

[Brandon Philips]

Hey Jared-

Would something like this help you from maintaining a custom build?

http://blog.clarifai.com/how-to-simplify-building-nvidia-gpu-drivers-on-coreos/

Cheers,

Brandon

[Jared White]

Hi Brandon -

Yes and no.  I've gone through the effort previously to use the developer image to build the kernel modules and driver that I need.  I've taken a step back to rethink my options.

Initially I took the slice & dice approach by doing the following:

  1) build my kernel driver, modules and userland libraries/executables inside the developer image

  2) package all of the relevant files together 

  3) take the published PXE image from a given stable release, unpack the usr.squashfs file system from it, and patch it with the new files

    - note that I include userland files because I want to test this both inside of pure CoreOS and inside of Docker/rkt

  4) PXE boot from this image

That all works fine (with some caveats) but I would ideally like a solution that is more organic than this.

Next, I thought to add the build process to the SDK and have things built along with the base CoreOS packages.  With that being said, I'm not sure if things like running depmod inside the context of the build process is even an option.  Surely that gets run at *some* point, but when?  

What are your thoughts?

-Jared

[Geoff Levand]

On Fri, 2016-09-16 at 15:34 -0700, Jared White wrote:
> What occurs when I invoke build_packages follows:
>
> emerge: there are no ebuilds to satisfy "foo/bar" for /build/amd64-
> usr/.

Put your kernel patch in

  src/third_party/coreos-overlay/sys-kernel/coreos-sources/files/4.X/

Then add the patch to the UNIPATCH_LIST in:

  src/third_party/coreos-overlay/sys-kernel/coreos-sources/coreossources-4.X.Y.ebuild

Increment the ebuild's Y version, then enable the module's config in

  src/third_party/coreos-overlay/sys-kernel/coreos-modules/files/commonconfig-4.X

Then run build_packages.

[Alan Zheng]

Hi,
Should I commit them to git and note the hash of the commit. and replace the hash value in coreos/.repo/manifests/default.xml ?

Geoff Levand於 2016年9月21日星期三 UTC+8上午8時17分54秒寫道：

[Alan Zheng]

coreos version is 1153 

kernel version is 4.7.1

I modify the file name of src/third_party/coreos-overlay/sys-kernel/coreos-sources/coreos-sources-4.7.1.ebuild to coreos-sources-4.7.2.ebuild

in coreos sdk

$cd ~/trunk/src/scripts

$./build_packerage

I went on following your instructions, but during the ./build_package step I get the following message: 

============

...

These are the packages that would be merged, in order:

Calculating dependencies... done!

[ebuild  NS    ] sys-kernel/coreos-sources-4.7.2:4.7.2::coreos [4.7.1:4.7.1::coreos] to /build/amd64-usr/ USE="symlink -build" 0 KiB

Total: 1 package (1 in new slot), Size of downloads: 0 KiB

>>> Verifying ebuild manifests

>>> Emerging (1 of 1) sys-kernel/coreos-sources-4.7.2::coreos for /build/amd64-usr/

>>> Failed to emerge sys-kernel/coreos-sources-4.7.2 for /build/amd64-usr/, Log file:

>>>  '/build/amd64-usr/var/log/portage/sys-kernel:coreos-sources-4.7.2:20160929-063934.log'

>>> Jobs: 0 of 1 complete, 1 failed                 Load avg: 1.48, 1.18, 0.97

!!! Fetched file: patch-4.7.2.xz VERIFY FAILED!

!!! Reason: Insufficient data for checksum verification

!!! Got:      

!!! Expected: MD5 RMD160 SHA1 SHA256 SHA512 WHIRLPOOL

 * Fetch failed for 'sys-kernel/coreos-sources-4.7.2', Log file:

 *  '/build/amd64-usr/var/log/portage/sys-kernel:coreos-sources-4.7.2:20160929-063934.log'

 * Messages for package sys-kernel/coreos-sources-4.7.2 merged to /build/amd64-usr/:

 * Fetch failed for 'sys-kernel/coreos-sources-4.7.2', Log file:

 *  '/build/amd64-usr/var/log/portage/sys-kernel:coreos-sources-4.7.2:20160929-063934.log'

ERROR   build_packages: script called: build_packages (args unknown, no debug available)

ERROR   build_packages: Backtrace:  (most recent call is last)

ERROR   build_packages:   file build_packages, line 235, called: die_err_trap 'sudo -E "${EMERGE_CMD[@]}" "${EMERGE_FLAGS[@]}" "$@"' '1'

ERROR   build_packages: 

ERROR   build_packages: Command failed:

ERROR   build_packages:   Command 'sudo -E "${EMERGE_CMD[@]}" "${EMERGE_FLAGS[@]}" "$@"' exited with nonzero code: 1

============

Do I miss something?

Geoff Levand於 2016年9月21日星期三 UTC+8上午8時17分54秒寫道：

[Alex Crawford]

On 09/28, Alan Zheng wrote:
> Should I commit them to git and note the hash of the commit. and replace
> the hash value in coreos/.repo/manifests/default.xml ?

No need. That is automatically done as part of our release process.

-Alex

[Alan Zheng]

Hi Alex

I see, thank you~

Alex Crawford於 2016年9月30日星期五 UTC+8下午11時49分34秒寫道：