| View previous topic :: View next topic |
| Author |
Message |
pjp
Administrator
Joined: 16 Apr 2002
Posts: 20067
|
 Posted: Sun Oct 08, 2017 3:50 am Post subject: openSUSE kernel sources |
 |
|
This may be all wrong.
Consider yourself informed.
Status: - The ebuild currently installs (for me) and can be selected via eselect.
- I have browsed the configuration using make menuconfig but have not yet had a chance to configure a kernel.
Items of note: - openSUSE kernel versions are hyphenated (4.4.87-18.29.1), which isn't something Portage likes, so the the ebuild replaces the - with a .
- The sources provided are named non-descriptively as "kernel-sources". For identification, I've renamed them during download.
Source: kernel-source-4.4.87-18.29.1.src.rpm
Downloaded: opensuse-sources-4.4.87-18.29.1.src.rpm
- When installed into /usr/src, the directory includes an opensuse suffix for clarity.
linux-4.4.87.18.29.1-opensuse
- src_prepare uses the patching methodology as described in the kernel package.
When extracted, this can be found in work/README.SUSE under the section PATCH SELECTION MECHANISM
- pkg_preinst renames the unhelpful default target directory from linux-4.4 to linux-4.4.87.18.29.1-opensuse.
This was mainly to match other kernels I've seen which use the 3rd version number, plus the clarifying suffix.
- pkg_postinst as another reminder that this is unsupported, except for maybe interested people in this thread.
- Most details found other ebuilds. Thanks for their efforts.
If anything went wrong here, it wasn't their fault. See my opening warning ;)
- Inspiration from the inquiry by mx_ in hardened-sources going forward
opensuse-sources/opensuse-sources-4.4.87.25.1.ebuild -- MY_LEAPV="42.3"
opensuse-sources/opensuse-sources-4.4.87.18.29.1.ebuild -- MY_LEAPV="42.2"
Note: MY_LEAPV in the ebuild below should reflect the newest version listed above.
For older versions, be sure to set MY_LEAPV as indicated above. | Code: | # Copyright 1999-2012 Gentoo Foundation
# Distributed under the terms of the GNU General Public License v2
EAPI="6"
ETYPE="sources"
inherit eutils flag-o-matic kernel-2 rpm versionator
detect_version
detect_arch
# Revision of the RPM. Shouldn't affect us, as we're just grabbing the source
# tarball out of it
RPMREV="1"
MY_PV=$(replace_version_separator 3 '-')
MY_LEAPV="42.3"
DESCRIPTION="openSUSE Kernel Sources"
HOMEPAGE="https://software.opensuse.org/package/kernel-source"
SRC_URI="https://download.opensuse.org/repositories/openSUSE:/Leap:/${MY_LEAPV}:/Update/standard/src/kernel-source-${MY_PV}.src.rpm -> ${PN}-${MY_PV}.src.rpm"
LICENSE="GPL-2"
KEYWORDS="~amd64 ~x86"
IUSE=""
RDEPEND=""
DEPEND="${RDEPEND}"
S="${WORKDIR}/${MY_P}"
src_unpack() {
rpm_src_unpack ${A}
}
src_prepare() {
for p in $(./guards < series.conf); do
patch -d linux-4.4 -p1 < $p || break;
done
eapply_user
}
pkg_preinst() {
L=linux-
MY_TARGET_DIR=${L}${PV}-${PN%-sources}
mv "${D}/usr/src/${L}${KV_MAJOR}.${KV_MINOR}" "${D}/usr/src/${MY_TARGET_DIR}"
}
pkg_postinst() {
kernel-2_pkg_postinst
ewarn
ewarn "${PN} are *not* supported!"
ewarn "Do *NOT* open bugs in Gentoo's bugzilla or with openSUSE."
ewarn "Do *NOT* contact either the Gentoo Kernel Project or openSUSE for "
ewarn "support."
ewarn
elog
elog "For community support, you may check the following thread in the "
elog "Unsupported Software forum on forums.gentoo.org: "
elog "https://forums.gentoo.org/viewtopic-t-1070182.html"
elog
} |
Changelog: - Added MY_LEAPV to reference the version of LEAP associated with the kernel.
Version bump
- Removed SLOT="0" which was preventing multiple kernel versions from being installed simultaneously.
_________________
Quis separabit? Quo animo?
Last edited by pjp on Mon Oct 09, 2017 4:53 am; edited 2 times in total |
|
| Back to top |
|
 |
mx_
n00b
Joined: 29 Sep 2017
Posts: 8
|
| Posted: Sun Oct 08, 2017 8:59 am Post subject: |
|
|
Nice. I did not install it yet but here are suggestions you can use:
As Leap 42.3 is out it may make more sense to start with Leap 42.3 instead of 42.2.
Here is the link to the original Leap 42.2 package in Open Build Service (OBS) so you can see the original files used to build the source rpm:
https://build.opensuse.org/package/show/openSUSE%3ALeap%3A42.2/kernel-source
and to make it a bit confusing, here is the link to the current patch update (Update is an additional repository added to the SuSE systems, they keep the original files as is while changes are applied to Updates repo only; so this is where the latest kernel will come from)
https://build.opensuse.org/package/show/openSUSE:Leap:42.2:Update/kernel-default
From all the .spec files included in the build service, the kernel-default.spec is used to build the kernel package. Whatever happens there should be mapped to the ebuild.
Here is the OBS build log for this package:
https://build.opensuse.org/public/build/openSUSE:Leap:42.2/standard/x86_64/kernel-default/_log
and
https://build.opensuse.org/public/build/openSUSE:Leap:42.2:Update/standard/x86_64/kernel-default.7271/_log
for the update resulting in release 18.29.1
I think I saw a .config file or something like that included in the package. While technically everyone should be able to compile the sources by themselves, I would say that in this case the .config file from SuSE should be deployed and used to directly build a kernel+initrd exactly matching the one from SuSE (because porting/duplicating their kernel completely was the original intention for hardened gentoo).
At least it should be hinted how to copy this file into the source path if someone wants to rebuild with SuSE settings.
Regarding the version number...
Short info about SuSE rpm packaging (I assume this is foreign to most gentoo users):
Each package has a version number and a release number, specified in the .spec file used to create the package. In this case the file would contain the lines
---
name: kernel-sources
version: 4.4.87
release: 18.29.1
---
resulting in a package named "kernel-sources-4.4.87-18.29.1.x86_64.rpm".
(If for whatever reason you are going to parse the file name, you must do it backwards btw: "rpm" "." $arch "." $release "-" $version "-" $name)
The opensuse build service (OBS) replaces whatever is written in the release line during each build. A rebuild can be triggered through rpm build dependencies watched by OBS (unlikely for the kernel) or manually (also unlikely here) or by changing the packaged files.
You can see it happen in the build log:
| Code: | [ 43s] -----------------------------------------------------------------
[ 43s] I have the following modifications for kernel-default.spec:
[ 43s] 63c63
[ 43s] < Release: <RELEASE>.g3e35b20
[ 43s] ---
[ 43s] > Release: 18.29.1.g3e35b20
[ 43s] 65c65
[ 43s] < Release: 0
[ 43s] ---
[ 43s] > Release: 18.29.1
[ 43s] ----------------------------------------------------------------- |
The developers will only increase the version string if they move to another upstream kernel.
If they backport a patch they add the patch to the sources and include+apply it in the spec file. After committing these changes, the sources are rebuilt automatically (which increases the release number as said before).
From what I saw, they will branch the package for every change (see https://build.opensuse.org/project/show/openSUSE:Leap:42.2:Update and type "kernel-default" into the search field to filter the results).
-> Name the ebuild opensuse-sources-7271.ebuild and internally map that correctly to the download location in OBS (parse https://build.opensuse.org/public/build/openSUSE:Leap:42.2:Update/standard/x86_64/kernel-default.7271/_log for "> Release: 18.29.1" and map to http://download.opensuse.org/update/leap/42.2/oss//src/kernel-source-4.4.87-18.29.1.src.rpm - doing this automatically requires internet access; this must be hard coded if this is against some gentoo policy) |
|
| Back to top |
|
|
Marlo
Veteran
Joined: 26 Jul 2003
Posts: 1591
|
| Posted: Sun Oct 08, 2017 9:12 am Post subject: |
|
|
thx pjp!
| Code: | | Startup finished in 6.299s (kernel) + 1.789s (userspace) = 8.088s |
with my own .config without an initramfs.
| emerge --info: |
Portage 2.3.8 (python 3.4.5-final-0, default/linux/amd64/13.0/desktop/gnome/systemd, gcc-7.2.0, glibc-2.25-r7, 4.4.87suse x86_64)
=================================================================
System uname: Linux-4.4.87suse-x86_64-AMD_Phenom-tm-_II_X6_1090T_Processor-with-gentoo-2.4.1
KiB Mem: 8152088 total, 5874244 free
KiB Swap: 15335420 total, 15335420 free
Head commit of repository gentoo: fa156bc7255f384731084f0d0d52944dd59ea871
sh bash 4.3_p48-r1
ld GNU ld (Gentoo 2.29.1 p1.0) 2.29.1
app-shells/bash: 4.3_p48-r1::gentoo
dev-java/java-config: 2.2.0-r3::gentoo
dev-lang/perl: 5.24.1-r2::gentoo
dev-lang/python: 2.7.12::gentoo, 3.4.5::gentoo
dev-util/cmake: 3.7.2::gentoo
dev-util/pkgconfig: 0.28-r2::gentoo
sys-apps/baselayout: 2.4.1-r2::gentoo
sys-apps/openrc: 0.28::gentoo
sys-apps/sandbox: 2.12::gentoo
sys-devel/autoconf: 2.13::gentoo, 2.69::gentoo
sys-devel/automake: 1.11.6-r2::gentoo, 1.15.1-r1::gentoo
sys-devel/binutils: 2.29.1::gentoo
sys-devel/gcc: 6.4.0::gentoo, 7.2.0::gentoo
sys-devel/gcc-config: 1.9.0::gentoo
sys-devel/libtool: 2.4.6-r4::gentoo
sys-devel/make: 4.2.1-r1::gentoo
sys-kernel/linux-headers: 4.13::gentoo (virtual/os-headers)
sys-libs/glibc: 2.25-r7::gentoo
|
[Moderator edit: changed [quote] tags to [code] tags to preserve output layout. -Hu]
_________________
------------------------------------------------------------------
http://radio.garden/ |
|
| Back to top |
|
|
Marlo
Veteran
Joined: 26 Jul 2003
Posts: 1591
|
|
| Back to top |
|
|
pjp
Administrator
Joined: 16 Apr 2002
Posts: 20067
|
| Posted: Sun Oct 08, 2017 10:34 pm Post subject: |
|
|
| mx_ wrote: | | As Leap 42.3 is out it may make more sense to start with Leap 42.3 instead of 42.2. |
For whatever reason, 42.2 appears to b the default. 42.3 isn't visible until after clicking 'show other versions." In theory, the ebuild would hopefully not need much to change for 42.3.
I'm not sure what you're referencing here. I understand about using those files to make the RPM, but if the ebuld uses the RPM, isn't that passed the point of needing those files?
| mx_ wrote: | I think I saw a .config file or something like that included in the package. While technically everyone should be able to compile the sources by themselves, I would say that in this case the .config file from SuSE should be deployed and used to directly build a kernel+initrd exactly matching the one from SuSE (because porting/duplicating their kernel completely was the original intention for hardened gentoo).
At least it should be hinted how to copy this file into the source path if someone wants to rebuild with SuSE settings. |
I think it sounds reasonable that a person wanting to use an openSUSE kernel would likely expect their configuration. I don't think that'd be too difficult to achieve, depending on how reliably it is located.
| mx_ wrote: | Regarding the version number...
Short info about SuSE rpm packaging (I assume this is foreign to most gentoo users):
Each package has a version number and a release number, specified in the .spec file used to create the package. In this case the file would contain the lines
---
name: kernel-sources
version: 4.4.87
release: 18.29.1
---
resulting in a package named "kernel-sources-4.4.87-18.29.1.x86_64.rpm".
(If for whatever reason you are going to parse the file name, you must do it backwards btw: "rpm" "." $arch "." $release "-" $version "-" $name) |
Thanks, I didn't find much to explain that, but it is mostly what I guessed. 4.4 was pretty clearly the kernel version, and the 18 number was some version associated with the kernel team's versioning. Unfortunately, that doesn't work with Portage, so the closest match of the openSUSE versioning and Portage versioning appears to be replacing the - with a .
That may not make a lot of sense. I came across the Leap version and of course the version/release of the kernel, but I didn't notice references like "7271." To me, this doesn't appear to map to a version someone would expect to see. What does "7271" represent?
EDIT: Fixed quote tag error.
_________________
Quis separabit? Quo animo?
Last edited by pjp on Mon Oct 09, 2017 12:28 am; edited 1 time in total |
|
| Back to top |
|
|
pjp
Administrator
Joined: 16 Apr 2002
Posts: 20067
|
| Posted: Sun Oct 08, 2017 10:47 pm Post subject: |
|
|
You're welcome. Hopefully it is meaningfully useful.
I'm going to look into using the .config as suggested by mx_. Maybe it ought to be tied to a USE flag.
_________________
Quis separabit? Quo animo? |
|
| Back to top |
|
|
pjp
Administrator
Joined: 16 Apr 2002
Posts: 20067
|
| Posted: Sun Oct 08, 2017 11:38 pm Post subject: |
|
|
I've tested and emerged the newer version for LEAP 42.3 / 4.4.87.25.1.
It emerged correctly. Unfortunately for me, emerge uninstalled the older version. I generally leave them installed for a while.
EDIT: The above issue has been resolved and the ebuild corrected. (Removed SLOT="0").
_________________
Quis separabit? Quo animo?
Last edited by pjp on Mon Oct 09, 2017 4:59 am; edited 1 time in total |
|
| Back to top |
|
|
mx_
n00b
Joined: 29 Sep 2017
Posts: 8
|
| Posted: Mon Oct 09, 2017 12:10 am Post subject: |
|
|
| Quote: | | I'm not sure what you're referencing here. I understand about using those files to make the RPM, but if the ebuld uses the RPM, isn't that passed the point of needing those files? |
right, these files are not required for the ebuild, only for us to see what the srpm contains during the ebuild development. e.g. if the kernel source package does not contain the patches from the tarballs 100-121 which are mentioned in the spec file but only the tarballs themselves then we currently skip most patches (compare the %prep section in the spec file with the source preparation in the ebuild)
| Quote: | | That may not make a lot of sense. I came across the Leap version and of course the version/release of the kernel, but I didn't notice references like "7271." To me, this doesn't appear to map to a version someone would expect to see. What does "7271" represent? |
The number is a patch number which is referenced in the mailing list, patch download site and is also a package name in OBS which leads to the srpm.
Here is an example where such a number is used: https://download.suse.com/Download?buildid=GemQ_k8lnEI~
But this number may only be useful for searching the matching build in OBS and matching the patch information from SuSE to the ebuild. Thinking about it I am undecided which version I like better, it would work either way. |
|
| Back to top |
|
|
pjp
Administrator
Joined: 16 Apr 2002
Posts: 20067
|
| Posted: Mon Oct 09, 2017 12:52 am Post subject: |
|
|
Ah, OK. Now I understand about the files in the RPMs. Hopefully it won't be needed. I may need to make a note about that as a reminder.
When manually applying the patches, it appears to do a lot of work. I capture the output for reference here. With some cursory grep'ing, I didn't notice any errors. Though I can't say if everything got done that could have been done (the tarballs you mentioned in the source files).
My main preference for the ebuild version in its current format is only to match the upstream download. The Leap version and 7271 patch version don't appear to translate to the ebuild. If the ebuild ends up being used enough, maybe there will be a better solution eventually.
As for the configs, they appear to be included in the RPM, which is a nice convenience. However, they don't appear to get installed. Determining how to take advantage of them is another issue.
| Code: | config/x86_64/vanilla
config/x86_64/default
config/x86_64/debug
config/s390x/zfcpdump
config/s390x/vanilla
config/s390x/default
config/ppc64le/vanilla
config/ppc64le/default
config/ppc64le/debug
config/armv7hl/vanilla
config/armv7hl/lpae
config/armv7hl/default
config/arm64/vanilla
config/arm64/default |
_________________
Quis separabit? Quo animo? |
|
| Back to top |
|
|
pjp
Administrator
Joined: 16 Apr 2002
Posts: 20067
|
| Posted: Mon Oct 09, 2017 1:00 am Post subject: |
|
|
Thanks. This one at least matches the version for Leap 42.3. Where did you find it? I'm curious if it is in the RPM or if it needs to be sourced separately.
Unfortunately its md5sum doesn't match the ones I found listed in my last post which come with the RPM.
_________________
Quis separabit? Quo animo? |
|
| Back to top |
|
|
Marlo
Veteran
Joined: 26 Jul 2003
Posts: 1591
|
| Posted: Mon Oct 09, 2017 7:57 am Post subject: |
|
|
| pjp wrote: | | Where did you find it?. |
I quickly downloaded Suse and installed in a Virtualbox openSUSE-Leap-42.3-DVD-x86_64.iso. After a kernelupdate both configs were found in /boot.
This config is from the opensuse-sources-4.4.87-18.29.1.src.rpm downloaded with your ebuild.
_________________
------------------------------------------------------------------
http://radio.garden/ |
|
| Back to top |
|
|
pjp
Administrator
Joined: 16 Apr 2002
Posts: 20067
|
| Posted: Mon Oct 09, 2017 3:51 pm Post subject: |
|
|
Strange. I'm not finding a match in either the /usr/src/ directory or the unpacked ebuild work area in /var/tmp/portage.
Downloading the config you linked to via the raw output:
| Code: | $ wget -qO marlo-config https://paste.pound-python.org/raw/B1B0wJo7o6VKUhTwAOi8/
$ head -5 marlo-config
#
# Automatically generated file; DO NOT EDIT.
# Linux/x86_64 4.4.62 Kernel Configuration
#
CONFIG_64BIT=y
$ md5sum marlo-config
214d26f1cf606b6583e3e85ea29a823f marlo-config
$ pwd
/usr/src/linux-4.4.87.18.29.1-opensuse
$ find . -type f -name "*config*" -exec md5sum {} \+ |grep -ic "^214d2"
0
$
$ pwd
/var/tmp/portage/sys-kernel/opensuse-sources-4.4.87.18.29.1/work
$ find . -type f -name "*config*" -exec md5sum {} \+ |grep -ic "^214d2"
0
$ |
_________________
Quis separabit? Quo animo? |
|
| Back to top |
|
|
Marlo
Veteran
Joined: 26 Jul 2003
Posts: 1591
|
| Posted: Mon Oct 09, 2017 5:26 pm Post subject: |
|
|
I have done this as root:
cd /usr/portage/distfiles /
cp opensuse-sources-4.4.87 - ** /home/marlo
cd /home/marlo
chown marlo: marlo opensuse- *
And then I opened the rpm with Nautilus (Gnome) as user (I know I'm lazy).
This includes a config.tar.bz2. A click and include is a folder "config" with additional folders for:
arm64, armv7hl, ppc64le, s390x and x86_64.
Each contains 3 configs. For debug, default and vanilla. The file "default" comes as renamed .config to /usr/src/Opensusekernel
That's it.
_________________
------------------------------------------------------------------
http://radio.garden/ |
|
| Back to top |
|
|
mx_
n00b
Joined: 29 Sep 2017
Posts: 8
|
| Posted: Wed Nov 01, 2017 10:17 am Post subject: |
|
|
have a look at the kernel-default.spec file: In the %setup section they unpack the config.tar.bz2, patch the sources (by executing an apply-patches script [provided by the srpm] with arguments) and copy the file config/$arch as .config to the build directory:
| Code: |
if ! grep -q CONFIG_MMU= "%my_builddir/config/%cpu_arch_flavor"; then
cp "%my_builddir/config/%cpu_arch/$vanilla_base" .config
../scripts/kconfig/merge_config.sh -m .config \
%my_builddir/config/%cpu_arch_flavor
else
cp %my_builddir/config/%cpu_arch_flavor .config
fi
|
In our case this is config/x86_64/default.
The next step: if a config.addon subdirectory exists (which currently does not exist), then they merge the config file from there with the main config file.
Then they execute make prepare, make scripts, make clean with some arguments they constructed before (e.g. appending --output-sync under certain conditions, adding make flags for -j (via %{_smp_mflags} macro)).
Then the actual %build section starts; they source a build environment file, create symref files (I have never heard about before), do some magic with module signing and finally they execute make all.
The %install section is even larger because the OBS builds for several architectures at once. Basically they install vmlinux to /, compress it if compression was enabled. Then the bzImage is copied to /boot (as vmlinuz-$release-default), then they copy the certificates to /etc/uefi/certs (in DER format).
Then they patch several scripts (for pre-installation, post-installation steps and so on) with version/image/package information.
Then they create the initrd file by preparing a config file, zeroing the file and dumping stuff from /boot, /etc, /lib(modules|firmware) and the kernel inside.
This is why I pointed to the files they use. I suspect that the ebuild simply installs the kernel as is without all this stuff. |
|
| Back to top |
|
|
pjp
Administrator
Joined: 16 Apr 2002
Posts: 20067
|
| Posted: Sun Nov 05, 2017 5:24 am Post subject: |
|
|
The config files appear to be there when the ebuild is unpacks (this post).
Unfortunately, in the post immediately following that one, there is no checksum match (though I confess now that I don't recall what I was trying to match -- it made sense then).
These files seem to confirm the code fragment you posted is being run. | Code: | -rw-r--r-- 1 portage portage 179978 Sep 4 23:05 default
-rw-r--r-- 1 portage portage 451 Sep 4 23:05 vanilla |
Presumably that means the default config is being created partly from the vanilla kernel.
I think the question still to be answered is how to verify if the config files which appear to be created when the ebuild is unpacked are the correct config files to install. I checked README.SUSE, README.PATCH-POLICY.SUSE and README.KSYMS and didn't see anything related to those config files.
To be honest, I haven't looked at this since my last post in early October. I don't change my kernel more often than necessary and don't know when or if I'll get back to trying to "prove" this is a comparably configured kernel to an actual openSUSE kernel.
In the meantime, anyone interested is welcome to improve the posted ebuild.
_________________
Quis separabit? Quo animo? |
|
| Back to top |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
Unsupported Software
