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)
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)