On 12/8/18 7:45 AM, mar77i via arch-general wrote:

For the kernel we run mkinitcpio. So there shouldn't be a real reason why we shouldn't run grub-mkconfig >/${main_grub_dir}/grub.cfg for grub. That being said, the path is /boot/grub.cfg for me, so I'm not sure how we'd get the installfile to figure out where to output its output.

As you have just pointed out, there is no way to possibly know where a user's grub.cfg is, or even whether they have one rather than using some external boot disk, or using the grub package exclusively to modify the grub.efi on some externally mounted system, or or or or.

One key difference is that the output of mkinitcpio are binary files, whereas grub.cfg is a text file, and maybe operators would like to modify that file after it's generated? So one could make a case that the install file should in fact keep its hands off grub.cfg entirely.

Well, yes. In fact, I consider the mere existence of the grub-mkconfig command to be a harsh sin. :p I would fork the grub package and roll my own if it were to erase my lovingly handwritten grub.cfg with some autogenerated nonsense that all too often doesn't even work. I'd also submit an annoyed bug report... ... It boggles my mind that a distribution that prides itself on: - DIY, - KISS, - understanding how things work, and - the avoidance of crutch-like tools meant to abstract into nonexistence the job of maintaining your system still discourages all these things with respect to the grub bootloader. I am in the gradual process of hopefully fixing all this via rewriting the wiki page for grub. My current progress towards this end can be seen at https://wiki.archlinux.org/index.php/User:Eschwartz/Grub#Configuration -- Eli Schwartz Bug Wrangler and Trusted User

On 12/9/18 2:14 AM, Amish via arch-general wrote:

Simple is to use a tool in this case. Hand writing a full conf file is no way simple.

Are you sure about that? Here's your handwritten 'full conf file'... menuentry "Linux" { linux /boot/vmlinuz-linux root=... rw initrd /boot/intel-ucode.img /boot/initramfs-linux.img } Yes, that's all. Please don't spread FUD -- Rob (coderobe) O< ascii ribbon campaign - stop html mail - www.asciiribbon.org

On Sun, 9 Dec 2018 07:56:29 +0530, Amish via arch-general wrote:

Thats because you have assumed that people will install only Linux. And that too plain Linux.

Chainloading e.g. FreeBSD, Windows or whatsoever is even simpler.

And that too no grub modules. No fancy stuff.

That too no failsafe stuff. Or LTS stuff. etc. etc.

You could add all of this, but you only need to do it one time, not after each upgrade of a kernel.

Now if you have to hand write grub.cfg considering all of the above, I dont think its as easy as 4 lines above.

It still is, just a few additional lines are needed.

And I bet if you recommend above 4 lines to a normal user, he is going to make spelling mistake even in above 4 lines that you have given.

If this happens to me, I simply correct the spelling mistake.

Or forget starting or ending braces some where or forget new line.

And then have a broken system in the end.

This doesn't happen often and if it happens, it could be easily fixed with an editor.

I am not saying dont write grub.conf on your own. I am saying that recommend tools first because tools are well tested and probes things much better.

If above 4 lines sufficed everyone and all cases - then yes its easy. But from user manual point of view you can not recommend hand written grub first.

You don't mention all the failures of that os-prober and the other thingies. Some people don't want any fancy stuff at all, but a menu order that fits to their needs, so they would have to edit the configs for all those auto-crap. On my machine I've seen auto-generated menus with entries for installs that don't exist, after waiting several minutes to generate a grub.cfg, that could be edited manually in a few seconds, without this kind of mistakes.

On Sun, 9 Dec 2018 07:56:29 +0530, Amish via arch-general wrote:

But from user manual point of view you can not recommend hand written grub first.

I don't have a grub.cfg at hand, but you could add boot options for just one kernel of one install in a similar way to grub.cfg as you could do for syslinux.cfg. [rocketmouse@archlinux ~]$ grep LABEL=s3.archlinux /boot/syslinux/syslinux.cfg | head -3 APPEND root=LABEL=s3.archlinux ro threadirqs APPEND root=LABEL=s3.archlinux ro threadirqs nopti APPEND root=LABEL=s3.archlinux ro If you don't edit grub.cfg manually, you need to configure the auto-thingy configs to add three entries instead of doing it by editing grub.cfg directly. This makes it more complicated and harder to find even a simple spelling mistake.

On 12/8/18 8:14 PM, Amish via arch-general wrote:

In my opinion DIY (Do it yourself) does not mean hand write everything from scratch.

KISS (Keep it simple) implies that if you can use a tool (grub-mkconfig in this case) then use it. Because handwriting the whole grub file is time consuming and as well as error prone. Simple is to use a tool in this case. Hand writing a full conf file is no way simple. Ofcourse, once created, its easy to edit the existing one. Hand writing becomes simple in such cases.

Writing your own grub.cfg is so simple my 3 year old brother can make one if someone first teaches him how to use a text editor. Using grub-mkconfig is time-consuming and error-prone, relies on external tools which aren't installed by default for OS detection, and has numerous embarrassing bugs: failure to boot with german locales?? https://bugs.archlinux.org/task/52763 heisenbug with path locations: https://bugs.archlinux.org/task/40029 totally borked with intel-ucode: https://bugs.archlinux.org/task/44288 somewhat borked with intel-ucode: https://bugs.archlinux.org/task/60999 https://bugs.archlinux.org/task/52910 generated menuentries are in the wrong order and default to LTS: https://bugs.archlinux.org/task/28081 generated config may try to boot the installation ISO: https://bugs.archlinux.org/task/51698 ... Did you *actually* read my wiki page, with its three-line grub.cfg? Supporting multiple kernels is nearly as easy, and the primary distinguishing factor between grub and systemd-boot, which people obsess over because of how "simple" the handwritten config file is as opposed to grub, is that instead of systemd-boot storing each one in a different file, grub uses one file, and stores each one inside of a pair of brackets after the word "menuentry".

Hence in my opinion, in your Wiki page, giving priority to writing a configuration from scratch (section 3.2) over using grub-mkconfig (section 3.3) isnt the right approach.

I hereby give you all my meh. You are the very example of the entire Arch Linux distribution being completely ignorant about how grub works due to the LIES of the grub developers who use scary language to make people think it's too hard for mere mortals to use. -- Eli Schwartz Bug Wrangler and Trusted User

Hi Eli,

...

Having spotted

warning: /boot/grub/grub.cfg saved as /boot/grub/grub.cfg.pacsave

during today's large package upgrade, I went to /boot/grub afterwards expecting work to do. grub.cfg.pacsave didn't exist. `pacman -Ql grub' showed grub doesn't own anything in /boot. Google led me to https://bbs.archlinux.org/viewtopic.php?id=242285 where Salkay had earlier started along the same path.

The warning has wasted our time, and the forum's conclusion is `ignore the warning'. Encouraging warnings to be ignored is a bad idea; I don't suppose some here are too happy when a user turns up with a problem and the answer was under their nose but they `ignored the warning'.

Can a better solution to this be engineered?

This is a one-time event where a package has removed a backup file from the package. ... See https://bugs.archlinux.org/task/57949 for more details.

Thanks, I've added to the forum's thread for anyone else that Google leads thither.

Nowhere in that thread you point to has anyone stated to "ignore pacsave warnings, they don't matter".

The conclusion from the forum was that the warning was to be expected, and that no action was required because of it. That conclusion to ignore this warning when *upgrading grub* was correct. The thread didn't suggest, to someone with my limited packaging knowledge, that the warning was a one-off so I thought that I, and others, would get it on future grub-package upgrades. A single warning that should be ignored is encouraging other warnings to be ignored too. I can conclude that without claiming it was the explicit advice from the forum's thread.

So just for the record, it is wise of you to ask what happened, because this update was indeed confusing and violates user expectations, albeit for a good cause.

It's much better to have an awkward fix than on-going wrongness, I agree.

(I'm less happy that you instantly decided we have instituted a distro-wide policy to ignore warnings.)

But I did not. Nowhere did I suggest it was a distro-wide policy. Even the subject spells out `Package grub'. I pointed out something I thought could be improved in package grub, but you took it as a criticism of a joint `we' decision by a group of Arch volunteers.

I would have added a message echoed in the post_upgrade:

"Performing one-time restore of user-generated grub.cfg due to removing it from the packaged files -- feel free to ignore the pacsave warning this once."

That would have been ideal.

Is it the end of the world that this was not done?

Nowhere did I suggest it was. If, as I wrongly thought, it were a recurring warning on all future grub-package upgrades then it would be something to consider improving. But the end of the world, no. Thanks for the explanation. -- Cheers, Ralph. https://plus.google.com/+RalphCorderoy