You are here
Mcgiwer - Wed, 2023/10/11 - 16:37
Hello. I would like to propose improving the documentation by expanding it and adding (among others) informations about the boot parameters, customizing, etc.
Currently, there is no info about the boot parameters that can be given and I see that some doesn't look like the standard Debian ones
Forum:
Hi there, our docs could certainly do with improvement
Hi there.
I certainly agree that our docs could do with improvement. Unfortunately, we're a small, overworked and underpaid team and there are only so many hours in the day. So often docs are the last thing we get to. Whilst they are important, we usually have a long backlog of higher priorities, so the docs often miss out.
Whilst our docs are far from perfect (gaps in documentation and often outdated), if you could be more specific on what you want info on and/or can't find in our existing docs? I'm fairly sure that a significant part of the issue is curse of knowledge. I'll explicitly address boot parameters below, but it would be good to understand what other specific info you are after. Perhaps there is already some documentation on what you are after that you haven't found? Or perhaps the existing docs are outdated and/or incomplete and I can update them easily OTTOMH? Or perhaps you are totally on the money and you've found a truck sized gap in our docs - that needs to be addressed ASAP?
Whilst there is some customisations, under the hood TurnKey is Debian. Debian default config is generally pretty sane, but we do make a few modifications, mostly security hardening, but also some for user convenience. We provide some of our own custom tools to achieve our ends, but much of the value we try to add is purely via pre-installation, configuration and integration of software components (Debian, upstream and/or custom TurnKey - as required and relevant for each appliance).
As for your specific query on boot parameters, IIRC the only non-standard boot parameters we use are for di-live (our minimalist live installer - that uses code from the standard debian-installer) and inithooks (our custom tool that drives our firstboot scripts). We don't make any other changes to the system (at least not intentionally) that would affect any standard boot params - so any that work with vanilla Debian should also "just work" on TurnKey. Any that don't, probably require additional software and/or configuration.
If you have any other specific questions and/or specific things you would like documentation on please elaborate.
Hello. I meant that when
Hello. I meant that when clicking the "e" in grub while startup, there a bunch of either not documented or not well docummented boot parameters.
Debian itself has a quite modest documentation in this matter and it seem to be quite outdated (it isn't not beeing updaged with the kernel version).
The current kernel cmd params can be seen in /proc/cmdline
The current kernel command line parameters can be seen in /proc/cmdline. I.e. on a local TKLDev v18.0 I have running locally:
The first bit ('BOOT_IMAGE=/boot/vmlinuz-6.1.0-12-amd64') is the kernel to load, then the next is the root device to load at boot ('root=/dev/mapper/turnkey-root' - I installed with LVM - if you installed with vanilla ext, then it'd likely be '/dev/sda1' or similar). 'ro' means that the kernel is initially loaded read only. The last 2 are added by us; 'net.ifnames=0' disables "predictable network interface names" (and uses the legacy defaults; i.e. 'eth0', etc) and 'consoleblank=0' ensures that the terminal never sleeps. As I mentioned in my previous post, we also have some kernel cmd params that are used by inithooks and di-live, but they aren't included in the installed system (i.e. relate to running live and/or installation from the ISO).
All available (kernel specific) options are well documented via the 'kernel-command-line' man page. As per what we do, kernel options can be used for other purposes too (as we do with di-live and inithooks). To access the local docs relevant to your specific system run this:
Or that same info can be viewed online via the relevant Debian man page for the relevant Debian release. E.g. TKL v16.x / Debian 10/Buster, TKL v17.x / Debian 11/Bullseye and/or TKL v18.x / Debian 12/Bookworm.
Beyond that, the relevant upstream kernel docs (select the relevant kernel version, then browse to 'Admin guide' >> 'Kernel parameters' - e.g. for kernel v6.1 (as per v18.x / Debian 12/Bookworm). Whilst Debian do apply their own patchset, the bulk of the kernel is consistent with mainline so it should remain mostly relevant. Alternatively, you could view the 'kernel-parameters.txt' file within the kernel source - to get the correct version, be sure to change to the relevant kernel version tag.
FYI, as you're perhaps already aware, another way for these options to be included is at compile time (so they don't show up in /proc/cmdline). Obviously those are Debian specific, but you can view the enabled compile time options for your current kernel like this:
If you wish to change the compiled in options, then you'll need to download the source and recompile with the relevant options you want. Here's a link to a page that notes the options with details. The Debian wiki kernel package page is likely also worth a look (Debian wiki pages tend to contain outdated info, although they usually contain enough hints to still be of value).
You may also find the Debian Kernel Handbook of interest (or alternatively, install the 'debian-kernel-handbook' package to a system with a desktop and point your local web browser at /usr/share/doc/debian-kernel-handbook/kernel-handbook.html/). Probably the most relevant page is Chapter 4. Common kernel-related tasks.
I hope that helps.
Hello and thanks for the info
Hello and thanks for the info.
It is strange, but I had left the "net.ifnames=0" and the interfaces weren't having the legacy naming convencion (eth0, wlan0, usb0, etc.) but (as example) enp3s0, etc. 🤔
Such "non-legacy" interface naming is troublesome in cases if their named become quite long.
There is no info where to change them back to the legacy ones
That is strange!?
That is strange!? We only add 'net.ifnames=0' and it "just works" for me (I mostly use KVM via Proxmox for testing, but also test in VirtualBox and VMWare Player - it works for me in all of those). What platform are you using when you experience this?
The Debian NetworkInterfaceNames wiki page has a fair bit of info which might be worth consulting? Beyond that, a bit of googling suggests that these days "biosdevname=0" (i.e. "net.ifnames=0 biosdevname=0") might also be required? Please test that and see how you go? If that fixes it for you, please let me know and I'll test that on my end too. So long as there is limited risk of it causing a regression, I'd be happy to add that by default too.
If that doesn't work, another alternate path to achieve the same ends should be available via systemd.link. By my brief scan of that page, I think that this approach essentially creates a "dummy" eth0 (etc) device(s) that points towards the "real" (new "predictable") interface name - essentially a symlink.
I'd be really interested to hear how you go.
Add new comment