User talk:Eschwartz/Grub

From ArchWiki
Jump to navigation Jump to search


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)