That's what it's doing for me. I've been multibooting for over 3 decades, accumulating many PCs over the years that I use for hardware support. I now have somewhat in excess of 40 that are kept up to date at least to some degree. Only two are laptops, both very old, and both used rarely, and with external keyboards.
Originally multiboot here was solely via IBM Boot Manager, then when I started with linux, I was quickly turned off of LILO and onto Grub. I was particularly enamored by SUSE's implementation of gfxboot that I very slightly customized. It was the only GNU bootloader I employed, a strong believer in the concept of one bootloader per PC is all that is needed, and used only it to boot everything GNU. I was turned off by Grub2 when it appeared, for various reasons, and have continued to use legacy Grub on all legacy BIOS PCs. Only several years after acquiring my first UEFI PC did I begin booting via UEFI, and only then did I begin using Grub2, naturally, in its EFI incarnation. And I got used to it by employing custom.cfg and copying 41_custom to 07_custom to place my stanzas at menu's top. I'm a touch typist. I'm also a former CPA, one of a significant group of people who learn to touch type at least on a adding machine/calculator, and thus on a 101-key style keyboard. Typing 6 or 8 numbers before realizing something turned off NUM is a highly annoying and recurring problem. One of the reasons I was attracted to openSUSE (as SuSE) more than two decades ago is it made keeping NUM enabled simple compared to most other distros that I had sampled. After a while I managed to get most to be cooperative, though at this point I remember none of what it took to make it happen in Fedora or Debian and derivatives. In part due to <https://www.linuxquestions.org/questions/linux-general-1/grub-legacy-delay-of-more-than-2-minutes-loading-initrd-from-ext4-filesystem-4175599620/>, last Wednesday I began a migration of one of the legacy PCs from a MBR SSD to GPT SSD, and thus, abandon legacy Grub for Grub2. Yesterday I finished to find roughly half the installations get NUM turned off by Grub's loading of their kernels and/or initrds. I double checked, and the stats are: Dist Ver Year GPT MBR MBRdelay openSUSE 13.1 2013 bad OK nil Tumbleweed - roll OK OK 2.5m Slowroll - roll OK OK lonnng openSUSE 15.6 2024 OK OK nil Debian 13 TBD bad OK nil Fedora 41 2024 bad OK 3.75m Ubuntu 24.04 2024 bad OK nil Mageia 9 2023 OK OK nil Debian 12 2023 bad OK 1.34m Fedora 40 2024 bad OK nil openSUSE 15.5 2023 OK OK nil Ubuntu 22.04 2022 bad OK 2m Fedora 39 2023 bad OK 1m Debian 11 2021 bad OK nil Ubuntu 20.04 2020 bad OK nil Mageia 8 2021 OK OK nil Mageia 7 2018 OK OK nil Mageia 6 2014 OK OK nil Mageia 4 2014 OK OK nil openSUSE 15.4 2022 OK OK nil openSUSE 15.3 2021 OK OK nil openSUSE 15.1 2019 OK OK nil openSUSE 42.3 2017 bad OK nil openSUSE 13.2 2014 bad OK nil openSUSE 12.3 2013 OK OK nil openSUSE 12.2 2013 OK OK nil openSUSE 12.1 2012 OK - - openSUSE 11.4 2011 OK OK nil antiX 16 2016 bad OK nil Key: Dist: Linux distribution Ver: distro version Year: distro release year GPT: NUM behavior booting the GPT SSD (OK means maintaining BIOS setting) MBR: NUM behavior booting the old MBR SSD MBRdelay: Extent to which kernel/initrd load time is excessive on MBR SSD I altered nothing on the migrated distros for the new SSD except their fstabs, plus on one key distro, Tumbleweed, Grub 2.12 was installed to take over boot duty from legacy Grub. I built /boot/grub2/custom.cfg from scratch on TW's boot filesystem to boot all 30 distros in manner equivalent to booting as they had been on the MBR SSD. Thus, it looks to me like Grub2, at least with Tumbleweed's version is a NUM kill trigger, and various distros themselves must be turning it back on as they have been here configured. In openSUSE, keeping NUM on is a simple setting in /etc/sysconfig/keyboard. How the OS makes use of it I have no clue. In Mageia, IIRC, numlockx is somehow used even for the vttys, which is normally where I routinely encounter the problem created. The DEs I use themselves have settings to turn NUM on, but for login/password, I've found nothing to make any DM turn NUM back on. I have multiple multiboot PCs UEFI booting. Grub2-efi AFAICT is not turning off NUM on any of them, respecting each's BIOS NUM ON setting. Questions: 1-Is it known that Grub2 for legacy/BIOS booting turns off NUM? 2-Is it intentional that Grub2 turns off NUM? 3-Is there a way I can get Grub2 to either flip NUM on instead of off, or just not touch it? -- Evolution as taught in public schools is, like religion, based on faith, not based on science. Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata
