• Status Closed
  • Percent Complete
  • Task Type Feature Request
  • Category Core
  • Assigned To No-one
  • Operating System All
  • Severity Medium
  • Priority Very Low
  • Reported Version 1.0
  • Due in Version Undecided
  • Due Date Undecided
  • Votes
  • Private
Attached to Project: BDisk
Opened by Anonymous Submitter - 04.01.2018
Last edited by brent s. - 14.01.2018

FS#35 - variablize kernel name in build.ini

Make the name of the kernel a variable in build.ini. This allows for custom kernels.
related patch from Ninja OS:

Closed by  brent s.
14.01.2018 08:46
Reason for closing:  Won't implement
Additional comments about closing:  will break future changes planned for cross-distro guest support
GI Jack: All American zero commented on 04.01.2018 21:37
in you can now change

#bootfiles['kernel'] = ['vmlinuz-linux-' + bdisk['name'], '{0}.{1}.kern'.format(bdisk['uxname'], bitness)]


#bootfiles['kernel'] = ['vmlinuz-linux-' + bdisk['kernel'], '{0}.{1}.kern'.format(bdisk['uxname'], bitness)] perhaps add if bdisk['kernel'] is not "linux":

brent s. commented on 04.01.2018 22:17

i'm unclear as to what benefit this serves to implement this in-code. you should use a overlay file if you have custom changes you need to make.

GI Jack: All American zero commented on 05.01.2018 20:38

The benefit would be able to specify a custom kernel package instead of using linux which is now the hard coded default.


Me personally, it allows me to roll my own kernel, and select my own compile time options, and I can pick and chose what kernel verison I want.
Another big use case scenarion is users can use linux-lts and linux-hardened packages instead of the vanilla -ARCH kernel.

Its actually a pretty big benefit.

GI Jack: All American zero commented on 05.01.2018 20:39

More use cases: someone needs a kernel with a custom patch or driver to make it run on a system, or type of system.


also, kernel name is also specified in

brent s. commented on 05.01.2018 20:46

"you should use a overlay file if you have custom changes you need to make."

install/build the kernel in pre-build, move it to the specified kernel filename/path then. problem solved.

GI Jack: All American zero commented on 06.01.2018 02:09
there is also a line that copies the kernel in Its another one of those "It'd be nice to have". Like the request for a groups= in the user tab.
GI Jack: All American zero commented on 06.01.2018 03:07
also, thats not nearly as maintainable. automation with jinja profiles is the new norm, in increases reliability, decreases errors, and increases reproducability.

"edit" can also be problematic, because there is no guarantee with forward compatibility. side note: you might want to investigate using a for user additions and source it.

brent s. commented on 06.01.2018 05:21

well, jinja2 isn't the way to go here, because we aren't generating something static, like a configuration file, from dynamic content. the purpose of the script, be it BDisk-supplied or user-modified, is to complete further actions *inside the chroot* to *customize the ennvironment*. like replacing the default kernel. see here for more information.

this will, however, be a little more clean in the rewrite, as i need to re-do a majority of how that whole thing behaves anyways for support for building different distro guests.

brent s. commented on 06.01.2018 05:25

(which is also why i can't provide a custom kernel name moving forward; different distros prefer different names for the kernel and it's simply far too much work with far too little payoff to modify each and every distro to support that.)

the pseudo-support for programmatic names is even actually a carryover from needing to use AUFS, but since OverlayFS is now in-mainline kernel (and honestly, superior to AUFS for these types of applications), i use that and just use the stock Arch kernel. makes it pretty predictive, which is handy.

so anyways, point being that's going to go away because i'm not making a dependency for Arch guests/builds a requirement in the future so it'd be even more pointless to implement this.

GI Jack: All American zero commented on 07.01.2018 15:10
You shouldn't provide a custom kernel. You should provide as close to a stock Arch experience which is the Arch Way, and then let users use bdisk as a tool to create the Live OS they way. Upstream, Arch ships as much of a basic vanilla GNU/Linux system and lets the user choose software they want. Kernel included. It would also work for systems

It should be an option for users who wish to provide their own custom kernels. I plan on doing so.

It should also be noted that upstream, Arch supports three kernels. Linux, Linux-lts, and Linux-hardened. There is good reason that various people might want to use any of them. But that is up to the user. Its also noted that "This is Arch Linux", and custom kernels are more popular than you think. It would be nice also for people who use linux-ck and linux-pf from AUR, the more popular patch sets.

I plan on shipping my live os with a custom compile with small compile time tweaks, and perhaps holding versions as I see fit.

Implementing this is not that hard. adding a jinja variable, that gets processed with VARS.txt. the extension can be derived from bdisk['kernel'].split('-')[1] in python, and cut -d "-" -f2 <<< $KERNEL in bash. for a default kernel it requires a simple if statement to use no name extension for logic with vmlinuz and the like.

like this in


Available keyboard shortcuts


Task Details

Task Editing