Wrong initramfs filename with gentoo-sources-4.0.5 and genkernel-next-63

[sxprophet]

The latest stable gentoo-sources-4.0.5 and genkernel-next-63 generates initramfs-genkernel-x86_64-4.0.5-gentoo-gnu. Please append a -gnu in the INITRAMFSNAME variable.

*         >> Finalizing cpio...

* WARNING... WARNING... WARNING...
* Additional kernel cmdline arguments that *may* be required to boot properly...
* add "dolvm" for lvm support
* With support for several ext* filesystems available, it may be needed to
* add "rootfstype=ext3" or "rootfstype=ext4" to the list of boot parameters.

* Do NOT report kernel bugs as genkernel bugs unless your bug
* is about the default genkernel configuration...
*
* Make sure you have the latest ~arch genkernel before reporting bugs.
cp: cannot stat ‘/boot/initramfs-genkernel-x86_64-4.0.5-gentoo’: No such file or directory

[sakaki-]

Hi, thanks for the report.

Are you by any chance deblobbing your kernel?

On 29/06/15 04:47, Sinclair Sun wrote:

The latest stable |gentoo-sources-4.0.5| and |genkernel-next-63| generates |initramfs-genkernel-x86_64-4.0.5-gentoo-gnu|. Please append a |-gnu| in the |INITRAMFSNAME| variable.

|* >> Finalizing cpio...

• WARNING... WARNING... WARNING...
• Additional kernel cmdline arguments that may be required to boot properly...
• add "dolvm" for lvm support
• With support for several ext* filesystems available, it may be needed to
• add "rootfstype=ext3" or "rootfstype=ext4" to the list of boot parameters.
• Do NOT report kernel bugs as genkernel bugs unless your bug
• is about the default genkernel configuration... *
• Make sure you have the latest ~arch genkernel before reporting bugs. cp: cannot stat ‘/boot/initramfs-genkernel-x86_64-4.0.5-gentoo’: No such file or directory |

— Reply to this email directly or view it on GitHub https://github.com/sakaki-/sakaki-tools/issues/1.

sakaki@deciban.com

[sxprophet]

Hi, I've deblobed my kernel last time and it failed to buildkernel. This time I've disabled deblobbing kernel and it worked.

Thanks for your hints.

[tomegathericon]

@sakaki- @sxprophet - Having the same issue build Linux 4.10-rc8, however I do not know how to disable kernel deblobbing.

Any help will be appreciated.

[sakaki-]

Hi, you are probably not deblobbing - to do this you need to have the deblob USE flag set on gentoo-sources (it will not be on by default). What error message are you getting (cp: cannot stat...?) Are you using gentoo-sources or have you downloaded the kernel directly?

[tomegathericon]

cp cannot stat /boot/initramfs-genkernel-x86_64-4.10.0-rc8

Downloaded kernel directly from Github

[sakaki-]

If you look in the EFI partition (/boot, which you may need to mount), what is the filename of the initramfs file present there?

[tomegathericon]

initramfs-genkernel-x86_64-4.9.6.-gentoo-r1 initramfs-genkernel-x86_64-4.10.0-rc8

Both are present

[sakaki-]

Strange - the pathnames appear to match exactly. I was expecting some trailing-suffix oddness. What do you get if you run ls -l /boot/initramfs-genkernel-x86_64-4.10.0-rc8 ?

[tomegathericon]

@sakaki-

Here you go -

tomegathericon@IBS-LAP-026 % ll /boot ~ total 1.1G -rw-r--r-- 1 root root 121K Feb 10 14:43 config-4.10.0-rc7+ -rw-r--r-- 1 root root 121K Feb 10 14:30 config-4.10.0-rc7+.old -rw-r--r-- 1 root root 121K Feb 13 14:18 config-4.10.0-rc8+ -rw-r--r-- 1 root root 119K Feb 13 14:31 config-4.9.6-gentoo-r1 -rw-r--r-- 1 root root 119K Feb 13 14:26 config-4.9.6-gentoo-r1.old drwxr-xr-x 2 root root 6 Feb 7 00:51 efi drwxr-xr-x 15 root root 192 Feb 13 14:27 initramfs -rw-r--r-- 1 root root 239M Feb 13 14:27 initramfs.cpio -rw-r--r-- 1 root root 237M Feb 10 14:43 initramfs-genkernel-x86_64-4.10.0-rc7+ -rw-r--r-- 1 root root 237M Feb 13 14:19 initramfs-genkernel-x86_64-4.10.0-rc8+ -rw-r--r-- 1 root root 239M Feb 13 14:27 initramfs-genkernel-x86_64-4.9.6-gentoo-r1 -rw-r--r-- 1 root root 3.0M Feb 10 14:43 System.map-4.10.0-rc7+ -rw-r--r-- 1 root root 3.0M Feb 10 14:30 System.map-4.10.0-rc7+.old -rw-r--r-- 1 root root 3.0M Feb 13 14:18 System.map-4.10.0-rc8+ -rw-r--r-- 1 root root 3.3M Feb 13 14:31 System.map-4.9.6-gentoo-r1 -rw-r--r-- 1 root root 3.3M Feb 13 14:26 System.map-4.9.6-gentoo-r1.old -rw-r--r-- 1 root root 4.5M Feb 10 14:43 vmlinuz-4.10.0-rc7+ -rw-r--r-- 1 root root 4.5M Feb 10 14:30 vmlinuz-4.10.0-rc7+.old -rw-r--r-- 1 root root 4.5M Feb 13 14:18 vmlinuz-4.10.0-rc8+ -rw-r--r-- 1 root root 114M Feb 13 14:31 vmlinuz-4.9.6-gentoo-r1 -rw-r--r-- 1 root root 4.4M Feb 13 14:26 vmlinuz-4.9.6-gentoo-r1.old tomegathericon@IBS-LAP-026 % cd /boot ~ tomegathericon@IBS-LAP-026 % ll initramfs-genkernel-x86_64-4.10.0-rc8+ /boot -rw-r--r-- 1 root root 237M Feb 13 14:19 initramfs-genkernel-x86_64-4.10.0-rc8+ tomegathericon@IBS-LAP-026 %

Now that you mention there is + suffixed to the initramfs filename

[tomegathericon]

@sakaki-

With 4.9.6-gentoo-r1 that is not the case and buildkernel -av delivers fine

[tomegathericon]

@sakaki-

It went through. I had to rename the initramfs, System.map and vmlinuz to not have the suffixed+.

However, I would be interested to know why this would have happened.

Probably, bad menuconfig?

[sakaki-]

No, I think I have got to the bottom of this now. The issue is that you are building from a git archive that has been modified since checkout. See this link (section headed "Generating unique build version numbers"). According to that the KERNELRELEASE variable is generated as follows:

# Build the kernel release string
#
# The KERNELRELEASE value built here is stored in the file
# include/config/kernel.release, and is used when executing several
# make targets, such as "make install" or "make modules_install."
#
# The eventual kernel release string consists of the following fields,
# shown in a hierarchical format to show how smaller parts are concatenated
# to form the larger and final value, with values coming from places like
# the Makefile, kernel config options, make command line options and/or
# SCM tag information.
#
#       $(KERNELVERSION)
#         $(VERSION)                    eg, 2
#         $(PATCHLEVEL)                 eg, 6
#         $(SUBLEVEL)                   eg, 18
#         $(EXTRAVERSION)               eg, -rc6
#       $(localver-full)
#         $(localver)
#           localversion*               (files without backups, containing '~')
#           $(CONFIG_LOCALVERSION)      (from kernel config setting)
#         $(LOCALVERSION)               (from make command line, if provided)
#         $(localver-extra)
#           $(scm-identifier)           (unique SCM tag, if one exists)
#             ./scripts/setlocalversion (only with CONFIG_LOCALVERSION_AUTO)
#             .scmversion               (only with CONFIG_LOCALVERSION_AUTO)
#           +                           (only without CONFIG_LOCALVERSION_AUTO
#                                        and without LOCALVERSION= and
#                                        repository is at non-tagged commit)
#
# For kernels without CONFIG_LOCALVERSION_AUTO compiled from an SCM that has
# been revised beyond a tagged commit, `+' is appended to the version string
# when not overridden by using "make LOCALVERSION=".  This indicates that the
# kernel is not a vanilla release version and has been modified.

Now, buildkernel uses make -s kernelversion to work out the kernel name, but this will omit any of the $(localver-full) stuff. Per the above (last para), this includes a '+' sign when you have compiled "from an SCM that has been revised beyond a tagged commit". It won't affect builds from e.g. tarballs, as happens with gentoo-sources etc.

I think I can fix this by just having buildkernel run make -s kernelrelease to get the full kernel name. Would you mind trying the following in your kernel source directory:

# make -s kernelversion
# make -s kernelrelease

Thanks, sakaki

[tomegathericon]

@sakaki-

Here you go:

IBS-LAP-026➜ linux-4.10-rc7 : master ✘ :✖ ᐅ sudo make -s kernelversion 4.10.0-rc7 IBS-LAP-026➜ linux-4.10-rc7 : master ✘ :✖ ᐅ sudo make -s kernelrelease 4.10.0-rc7+

Thanks, tomegathericon

[sakaki-]

OK good. If you don't mind, would you try (with the 4.10.0-rc7 kernel selected as your current kernel):

$ sudo cp -a /usr/sbin/buildkernel /tmp/buildkernel
$ sudo sed -i 's/kernelversion/kernelrelease/g' /tmp/buildkernel
$ sudo /tmp/buildkernel <add any buildkernel options you normally set>

Does that go through OK for you? If so I will test further here and make a new release with that change applied. Thanks, sakaki

[tomegathericon]

All done without any hiccups.

Thanks @sakaki-

[sakaki-]

Pushed version 1.0.20 of buildkernel with the fix applied. Issue:

$ sudo emaint sync --repo=sakaki-tools
$ sudo emerge --regen && sudo eix-update # if you use eix
$ sudo emerge -avu buildkernel

to get it. Thanks for reporting the issue! Best, sakaki

[tomegathericon]

Thanks @sakaki-