User talk:Eschwartz/Grub

Status

Intent to merge into GRUB: discussion: Talk:GRUB#Manually generate grub.cfg

• The custom grub.cfg has been implemented and is I think done.

• Examples have been merged up, and are universally applicable to both generated and handwritten grub.cfg.

• Filesystem specificity like LVM, RAID, encrypted boot now has its own section.

Currently focusing on rework of the surrounding sections to ensure all necessary information is exposed soon enough that people will not need to dig through mkconfig sections when they are writing their handwritten grub.cfg.

Removing grub.cfg examples

Copied from [1]

Must everything in GRUB#Custom grub.cfg be removed? Can't the examples from GRUB#Boot menu entries be integrated in User:Eschwartz/Grub#Examples? I find them useful. -- nl6720 (talk) 15:41, 8 January 2019 (UTC)

I'm open to expanding the examples section, but I think many of them are needlessly ornate. It's redundant to, for example, include multiple full copy-paste definitions of menuentries to execute halt/reboot (which I don't see as particularly useful), or to chainload the specific .efi executable used for the UEFI Shell. I'm unsure how much Windows stuff might be valuable to merge, but I'm highly suspicious that most of it could be made smaller at least. Like, I have no idea why this stuff checks $grub_platform per default. -- Eschwartz (talk) 15:54, 8 January 2019 (UTC)

I don't really see a problem with having a lot of detailed examples, working examples should make it easier for the reader to understand the syntax.

The $grub_platform check in the Windows entries is most likely useless since AFAIK for Windows changing the boot mode is not that simple and I don't think it supports both at the same time. -- nl6720 (talk) 16:11, 8 January 2019 (UTC)

I'm myself looking at the expansion template in [2], which end the new part. What I would do in that subsection is move and link the windows examples to the later detached examples section, replacing them with a very typical Linux one. For example, one with systemd hook boot parameters and one which crosslinks how to derive the correct lvm uuid. I agree it is still necessary to sieve the other existing examples, perhaps add a bullet list linking the most important ones. --Indigo (talk) 18:37, 13 January 2019 (UTC)

General examples section merged out of the grub-mkconfig subsection and linked in my examples section. Looking at options for further streamlining, suggestions welcome! -- Eschwartz (talk) 20:13, 13 January 2019 (UTC)

Refactoring intermingled grub-mkconfig and custom instructions

Copied from [3]

Hi, first, the intro you wrote for the manual section is super, very clear already and enhances the upstream doc. IMO it would be totally helpful to merge in as a drop-in replacement for GRUB#Custom grub.cfg right away. At this point I'm not convinced it should prepend the GRUB#Generated grub.cfg as the first GRUB#Configuration section though. Let me give two examples: Look at User:Eschwartz/Grub#RAID, it's inside the grub-mkconfig but actually describes grub-install and grub modules as well. I.e. the grub-mkconfig section mixes in the parts relevant for a first install. All this would have to be dis-entangled and crosslinked between both config sections first. What I am getting it is: Yes, a custom.cfg can be a slick three lines, but all that magic making them a working 50+ lines is shipped with supported defaults ([4] [5]), because the major GRUB configuration task is to (1) install the boot loader image correctly to the disk and (2) have a initramfs with matching boot options for the machine setup based on configured defaults. Just one more example for this: nowhere in the article there is an explicit mention of an "-fallback" menu entry. --> Because the /etc/grub.d/ script handles it, sourcing /etc/default/grub <-- variables in that file are a lot explanation to cover for any meaningful manual examples... or not? So, to pre-pend the manual method as the first configuration section, there should first be a plan how to proceed with the more complex rest. My suggestion is to

1. drop-in your new part to start existing "3.2 GRUB#Custom grub.cfg,
2. Separate the dispensable menuentry{} examples into a new top-level "Examples" section (IMO ideally below current "4. GRUB#Using the command shell", because your new explanation is super helpful to lead over for command shell too), and remove/move/merge menuentries as appropriate (btw, I assume ordering User:Eschwartz/Grub#Multiple entries ff into "Encryption" is simply a glitch.). Meanwhile,
3. work-out where the "configuration from scratch" should end/what of the not-straight-forward three-line .cfg's are covered in which section.

What do you think? --Indigo (talk) 12:29, 13 January 2019 (UTC)

First off, my rewrite and the main page have diverted a bit and I did not merge changes. I've now merged the current main page as-is with my rewrite dropped in where I suggested; this means there are now two sections for generating the custom grub.cfg, the latter of which is a boatload of custom.cfg things for grub-mkconfig to do like shutdown entries and stuff. Also, it is now much easier to grok the high-level organization of the page at a glance.

On the topic of things like RAID, would this be sufficient to include as references to how to write a filesystem path? I have no practical experience with RAID. Maybe we should merge this section into its own section as a child of User:Eschwartz/Grub#Configuration.

If it doesn't provide a suitable explanation linked to writing your own grub.cfg, I'm hesitant to merge as-is, because it shouldn't depend on grub-mkconfig docs whether listed before or after. On an unrelated note, I really don't want to relegate this to second, because I want people to see what I believe the superior method first. :p I guess that could be fixed later, true...-- Eschwartz (talk) 15:05, 13 January 2019 (UTC)

Yes, please don't start to merge as-is. If options are presented neutral, the order is secondary, exactly. --Indigo (talk) 18:37, 13 January 2019 (UTC)

I'm wondering if the best option would be to simply drop it altogether. The handwritten cfg already describes the need to insmod the drivers for additional partitions, and this includes both grub and lvm. Make a new toplevel section #4, "Filesystem-specific issues", in between GRUB#Configuration and GRUB#Using the command shell, which describes issues specific to installation in some given situation, and describe 1) the need to grub-install twice for RAID and 2) move GRUB#Encrypted /boot under that header.

Maybe expand the mkconfig section to specify how to preload a module -- though I'm unsure why it doesn't autodetect the need, what is this huge script even useful for? :p -- Eschwartz (talk) 00:04, 15 January 2019 (UTC)

Luckily I still kept my VMs with dm-crypt/Encrypting an entire system#Encrypted boot partition (GRUB) and a slightly modified dm-crypt/Encrypting an entire system#LUKS on software RAID. Adding modules to GRUB_PRELOAD_MODULES is not needed, grub-mkconfig detects them and puts them in grub.cfg where needed. -- nl6720 (talk) 09:55, 15 January 2019 (UTC)

I've implemented this in my rewrite as Special:Diff/563411, do you agree with this? EDIT: reworked it several more times -- Eschwartz (talk) 17:22, 15 January 2019 (UTC)

I don't think that is what nl6720 (pls correct if wrong) implied: Unfortunately, not that simple. grub-mkconfig will detect its required modules according to what's running, but that does not mean you can leave the user alone with the determination. LUKS is likely worst case (~5 out of a 22 gcry_*.mod). --Indigo (talk) 23:34, 15 January 2019 (UTC)

It's not exactly what I had in mind, but until custom grub.cfg is merged, it's good enough. To properly solve this would require quite a big reorganization of the installation sections. We need a common section for both BIOS & UEFI installation to place warnings and notes. Only workable solution I see it to split package and boot loader installation and make BIOS & UEFI a subsection of boot loader installation. That might also involve revisiting Talk:GRUB#De-duplication of section header.

I really would like to see custom grub.cfg before any of this happens, otherwise I can see this becoming a permanent draft and a never ending rewrite. -- nl6720 (talk) 11:19, 16 January 2019 (UTC)

To the first point: yes, good point we need to revisit that one later. That apart, in general I think Eschwartz' chosen method of adding an extra User:Eschwartz/Grub#Filesystem-specific_installation_issues subsection is a good solution. Just that the subsection, plus the BIOS, UEFI section should be ordered into a User:Eschwartz/Grub#Installation]]. What's your opinion on that? --Indigo (talk) 20:22, 16 January 2019 (UTC)

To the second: I agree and see that risk as well, but at the same time the greenfield approach chosen for the draft has advantages too. @Eschwartz: that brings me one additional organizational point I feel obliged to mention. Fact is, the more exiting section are touched (moved around, partly rewritten) in the greenfield approach - the more of a job will it become to cleanly merge it to mainspace. That was something else I had in mind with my suggestion (1) above. The key point is that we want/need the commit history to show what happens to the article. While shuffling in greenfield is super to grok what works/what not, a good shuffle-structured result is not an ideal starting point to merge. (For example, we'd have to recheck your roll forward from last week, etc.)

In my view the efficient way to handle your contributions is to continue towards agreement on a final new custom grub.cfg section to move/merge to the existing, and continue to work on a workable target structure in the draft that can be a blueprint for editing the main article step-by-step - but not investing too much time in rewriting/adjusting existing in the rest of the content. Hope this makes sense? --Indigo (talk) 20:22, 16 January 2019 (UTC)

Making BIOS/UEFI/filesystem specificity as children of Installation sounds reasonable. And I've only just recently gotten ready to do a big rewrite, so we have time to try implementing a cohesive facelift for the page, before deciding it is dragging on too long. So I'd like to give a stab at figuring out how to make this look really good, and then we can start implementing stages in the main article as they seem useful.

So what I'm focusing on at the moment is figuring out what I'd like the article to look like, and then ultimately I'd break down the changes into logical chunks and reimplement them on the main page. -- Eschwartz (talk) 21:23, 16 January 2019 (UTC)

Ok, terrific. If in doubt on the course, please address it anytime. --Indigo (talk) 22:00, 16 January 2019 (UTC)

I want to add another point: As intended, User:Eschwartz/Grub#Write the configuration from scratch instructs how to go about creating a fully custom /boot/grub/grub.cfg. Until now the article explains how to create a /boot/grub/custom.cfg instead - the regular custom.cfg proposed by the GRUB doc (quoted by Alad and Chazza top of the orig talk item).

Difference is: if a user creates a grub.cfg from scratch any erroneous call of grub-mkconfig will overwrite it, i.e. going unnoticed it will wreck the next boot. In my view the straight-forward measure is to switch it back custom.cfg plus an initial placeholder grub.cfg (empty; I have not tried yet, but that should still work). This way the worst that should happen is a messed-up menu, with the custom.cfg entries at the end.

--Indigo (talk) 20:48, 16 January 2019 (UTC)

I've not been considering this an issue as my assumption is people doing this will prefer to entirely avoid grub-mkconfig. It's not exactly something you can do without realizing, unless you're using some highly questionable pacman hook from the AUR... -- Eschwartz (talk) 21:03, 16 January 2019 (UTC)

True for a lot of users, but too much to assume generally IMO (boot loader, new Arch users, BG gone, upstream ...). Have a general search how often grub-mkconfig is mentioned in this wiki's articles alone. --Indigo (talk) 22:00, 16 January 2019 (UTC)

Maybe we could add a Tip for this? ("To prevent against accidentally running grub-mkconfig and overwriting the cfg, you can load it from a separate file using: ___") The grub.cfg would then be (taken from /etc/grub.d/41_custom):

if [ -f  ${prefix}/custom.cfg ]; then
  source ${prefix}/custom.cfg
fi

Then any unwise grub-mkconfig invocations will not overwrite the handwritten cfg, and also, it can be shared between a generated and custom cfg (ignoring the duplication issues).

For example, yes. And another tip to write-protect it, alternatively. (You know more options than me.) And again (sorry to be repetitive on it): the last grub package finally removed a shipped default grub.cfg. Why now add instructions to recreate it, when there is a standard path to customize everything. IMHO your new instructions lose nothing in clarity if you switch them to /boot/grub/custom.cfg, but it would make integration much simpler. --Indigo (talk) 15:19, 19 January 2019 (UTC)

Write protecting how? It is already owned by root, there is nothing you could do to stop grub-mkconfig (a root process) from running other than to mark the file as immutable (which would stop you from editing it by hand as well). It might be nice if grub-mkconfig had a flag for /etc/default/grub to indicate that mkconfig should immediately abort with "warning: grub.cfg was written by hand, not overwriting", but it does not. (Maybe this would be a good upstream bug report, since the generated version will anyways have very recognizable header comments. If it does not detect those, then it should at least ask before overwriting...)

As for removing the packaged grub.cfg, I am the one who filed FS#57949. :D I'm not sure what you mean by "why now add instructions to recreate it" -- it must exist somehow, the bug was only ever about removing the one which was incorrect on a technological level even as a default.

Anyway, I've already agreed to the tip, it harms nobody and reduces a potential source of great confusion to inexperienced users. -- Eschwartz (talk) 02:33, 20 January 2019 (UTC)

Ah, good job with FS#57949. I meant setting it immutable, yes. Hackish, but not a big deal when editing manually anyway. Regarding the tip, of course glad you agree, I am not 100% sure yet how it pans out. I'll come back to it, when it is in place.

Good idea with asking upstream about a safety-check for grub-mkconfig to check for its header and warn. I skimmed across the savannah and did not see any related one. --Indigo (talk) 18:04, 21 January 2019 (UTC)

use grub-script-check to verify the validity of grub.cfg

Another suggestion I want to carry over from the other talk is to add grub-script-check to the instructions to manually create a configuration. Given the peculiarities of GRUB's script syntax, it's easy to make errors. --Indigo (talk) 15:19, 19 January 2019 (UTC)

I have tried this command on /tmp/example.cfg with the single-line contents sdfsdfsf and it silently returned successfully. If I replace it with if sdfsdfsf then the command will return failure and tell me that there is a syntax error. Other things it can detect: unterminated quotes, unterminated {. The exact error message seems to be always the same: "error: out of memory. error: syntax error. error: Incorrect command. error: syntax error. Syntax error at line $x" (where the only thing that ever changes is the line number). Its abilities seem quite primitive, if it cannot tell when nonsensical commands are used but only when the control flow for keywords like "if" are broken. Given this trial run, I would personally not rely on it to tell me if I can use it to successfully boot, especially as I avoid such control loops. I'm unsure if there is a better way.... -- Eschwartz (talk) 02:46, 20 January 2019 (UTC)

Good you tested it. Yes, I was aware somewhat it has limitations, but still consider it better than nothing. Actually, I only ran across the script-check because grub-mkconfig calls it. I'm not sure right away if grub-mkconfig itself spits out other configuration errors (e.g. wrong device/UUID). If yes, it may be useful to add a tip how to use that, i.e. let it run over manual.cfg with STDOUT. --Indigo (talk) 17:50, 21 January 2019 (UTC)