marav: My point is that if for example you update the kernel with huge kernel without removing the generic kernel, for some reason slackware actually installs both the generic and the huge kernel on inital setup/install. for me this caused my system to try to boot from the generic kernel. Although the system started, /boot/efi was not mounted, and could not be mounted because the kernel didn't support vfat, so I couldn't fix the problem in the efi partition without rebooting from the huge kernel on the install media (which obviously had a different kernel version).

luckycyborg: You can set the codepage as an option in the mount command, which over-rides the kernel default.https://www.kernel.org/doc/Documenta...stems/vfat.txt If you are using an automounter in a gui, then you would have to set the codepage in the automounter anyway. hopefully that will make the huge kernels more useful to you. I'm not sure on the rules regarding efi system partition codepages though, as that is loaded by the efi bios initially, so the bios has to understand the codepage used, and probably defaults to 437 the same as most distro's (ubuntu,arch,gentoo,lfs,fedora,debian etc.).

2 members found this post helpful.

An UEFI system doesn’t need the partition /boot/efi to be mounted
It just needs that it exists

My /etc/fstab:

2 members found this post helpful.

But of course!

However, some good people are misguided to use ancient boot technologies, which requires to have access to ESP partition again and again, for modifying files.

I for one, just like you I use modern boot technologies like GRUB2 which requires access to ESP partition only at system installation time or when the GRUB2 package is updated.

I do not know what others think, but I believe that's much simpler this way, the ESP filesystem is less prone for corruption and the system boot is much more robust. As bonus points, there is no need to learn a distinct bootloader and its configuration for the Legacy BIOS Boot - like LILO, as GRUB2 support also this mode, and it uses for Legacy BIOS Boot exactly the same configuration from /boot/grub/grub.cfg .

Yep, there is no need to fix the ESP mounting, but rather to not advertise antiquated and errors prone boot technologies.

1 members found this post helpful.

I don't think that you understood Petris reply and I don't think you understand what this means in a bash script:

So let me explain that when you write:

Your SOMEVARIABLE will get "defaultvalue" unless your environment already has set that variable to something else before the script is done.

A default value of -j$(expr $(nproc) + 1) is a rather good default value as it will be you number of cores + 1. If you prefer to have another value you can do something like:

You can set your default value in some file in /etc/profile.d or in some login file in your home directory.

regards Henrik

3 members found this post helpful.

FWIW
It's not a hardware requirement, or a Slackware requirement. Credit where it's due and all that.

No, I totally understand why he wants to indirectly break my system with bad advice.
Luckily, it's less work for me to rewrite all, than set that in ~profile and wait for builds like openssl to break at any point.
I'm certain he's aware of the consequences, just wants to have a laugh when my system starts to break apart because of what I did, according to his advice.
Forget about it. I didn't ask for solution, I just asked a bunch of questions regarding cause and effect.

Also any Linux distribution needs an ESP partition to boot in the UEFI mode.

AND, today NOT all the computers on sales has the ability to go Legacy BIOS mode, for the simple fact there is no CSM.

Also, no CSM usually means that there is no way to disable the Secure Boot, so today Slackware will not even boot on these computers.

I too set up my EFI Partition in /etc/fstab with the noauto option:
Q: is the 'defaults' option recommended for mounting vfat ?

I learned the hard way after a major Win11 Update last Fall when Windows wiped the files in the EFI Directory to keep a backup in /root/tmp/efi/

Now, if I could only make Win11 leave it the hell alone

-- kjh

p.s. The backed up Slackware files came in handy when I upgraded my INSYDE BIOS which also wiped out the EFI Directory

Usually, the 'defaults' option is what you write in /etc/fstab if you don't want to change any of the default values. In this case, as you have 'noauto' you don't need 'defaults' as noauto is not the default behaviour for a line in /etc/fstab.

In your quoted example there was 'defaults,noauto'. The 'defaults' option implies 'auto', but as the option 'noauto' is given after that it will override 'noauto'.

regards Henrik

1 members found this post helpful.

Thing with vfat defaults is it allows all users full access to files and makes everything an executable.

1 members found this post helpful.

Rather than changing the request for vfat support in generic kernel into "grub is better than elilo/lilo" which has it's points; we still have elilo and lilo for legacy reasons if nothing else. I actually use rEFInd for dualbooting with ms windows, but codepage aside, which is addressable in fstab if needed for those not in western europe or english speaking, it would still be nice to have vfat support in generic. There is support for ext2/3/4 and vfat is the most common (as mentioned re uefi system partition (and even installing via usb)) format not included. while slackware ships with elilo, and has a install from usb option, it is still useful.

luckycyborg: maybe you should request that the slackware installer gives an option to add codepage when it automatically adds /boot/efi mount point for the uefi system partition to fstab. That would be useful for both hugh and generic kernels. Also adding codepage support in automounter for the current locale, over-riding the kernel default would be also useful, based on what you have said.

The vfat file system support is similar to ext2/3/4 in generic:
You can add vfat in your mkinitrd command (-m ext4:vfat).

Or we could all just boot the kernel directly on UEFI and have no need of boot loader/ESP pissing contests every time the topic comes up...

glib-2.76.1
https://download.gnome.org/sources/g...-2.76.1.tar.xz

Suggestion to make makepkg warn about dangling symlinks:

2 members found this post helpful.