And is there a way to change kernels or add kernel parameters if issues arise?
What about if there are other OS’s and the user wants to boot these?
And is there a way to change kernels or add kernel parameters if issues arise?
I think @philm has answered these questions:
- press Shift or Esc or F8 at boot to show the menu
- if there are other OS installed it will magically appear at every boot
I don’t need
grub-quiet, but I understand why Manjaro team wants to use it.
I’m waiting for a response about filesystem
fsck at boot.
Yeah, but all these are not working yet.
We test it out again if there are new developments.
Of course it will be, that’s why it is packaged. I share your legit concern for data integrity and it has been taken care of. The issue was originally raised and answered about a month ago here:
Please be more precise what doesn’t work. On my end it works. I’ve two Manjaro instances and I always see the grub menu. Only when I set it to value 2 it is hidden. Also when there was an error it shows the menu.
We have two values: boot_indeterminate and boot_success. Additionally menu_show_once. found_other_os thru os-prober adds the value to show the menu when another OS is installed. After two minutes working OS it gets marked as successful which hides the menu at next boot. Please also study this patch on how we determinate a successful bootup. As an alternative we also have grub-fedora with all working patches ported from Fedora.
I’m glad for any help with this. In 2019 we most likely will add these patches to grub and drop other versions of grub packages from the repos. It passed our QA on Manjaro focused hardware we use for our Hardware projects, however we can’t test other hardware which is out there.
Yes, systemd-fsck-silent was planned to be default when using the new grub package.
Well, if it still matters, I’m for it. I have no desire to see boot messages unless there’s a reason to see them—which is when there’s an error. I think this is a good move on the part of @philm and Manjaro, and brings the distro into parity with desktop experiences users likely already have.
Some might not know how the automatic hiding of the grub menu actually works. So let’s take a look the the following patch.
On single-os systems we do not want to show the menu, unless something went wrong with the previous boot, in which case the user may need the menu to debug/fix the problem.
Since auto-hiding the menu requires detecting the previous boot was ok, we get fastboot support (where we don’t check for a key at all) for free so this commit also adds support for this.
The new config-file code uses the following variables:
- menu_auto_hide: Set this to “1” to activate the new auto-hide feature. Set this to “2” to auto-hide the menu even when multiple operating systems are installed. Note the menu will still auto show after booting an other os as that won’t set boot_success.
- menu_show_once: Set this to “1” to force showing the menu once.
- boot_success: The OS sets this to “1” to indicate a successful boot.
- boot_indeterminate: The OS increments this integer when rebooting after e.g. installing updates or a selinux relabel.
- fastboot: If set to “1” and the conditions for auto-hiding the menu are met, the menu is not shown and all checks for keypresses are skipped, booting the default immediately.
The systemd timer script will set boot_success to 1 after two minutes in a successful booted system. We reset boot_indeterminate after a successful boot. We also reset menu_show_once when it was used. The menu will be shown for 60s btw. with this option. When using fastboot we set grub_timeout to zero as grub_timeout_style=menu and grub_timeout=0 avoids the countdown code keypress check.
For a successful boot we set grub_timeout_style=hidden and grub_timeout=1. Else we have grub_timeout_style=menu and grub_timeout=5 or grub_timeout=60.
A quick question before I try testing again.
All my computers (each disk) have lots of OS’s + other distros.
Does that mean I cannot test grub-quiet (meaningfully)?
Or that even if I can use it, the menu will always appear?
And can I just install grub-quiet to an existing os and test it? ( that’s what I did too after installing a test os. It booted straight into Os and I could not get into menu.
Perhaps that’s before the patches. I did not see any menu-autohide lines to select.
With grub-fedora you can set as normal user. See FAQ.
sudo grub-editenv - set menu_auto_hide=1
This will enable it for a single OS setup.
sudo grub-editenv - set menu_auto_hide=2
Same, but for multiple OS setup. Pressing either ESC or F8 will unhide it. Also holding SHIFT.
To unset use
sudo grub-editenv - unset menu_auto_hide.
Always perform a
sudo update-grub after changes. To check, please see
/boot/grub/grubenv for set values. The boot_success grub_env flag gets set when you login as a normal user and your session lasts at least 2 minutes. Calamares will set
grub-editenv - set menu_auto_hide=1 boot_success=1.
I always recommend to reinstall grub to MBR.
sudo grub-install --target=x86_64-efi --efi-directory=/boot/efi --bootloader-id=manjaro --recheck
sudo grub-install --recheck /dev/sd[x]
Prepare for any breakage if you reinstall grub on MBR. Most likely it is optional, but better to have it similar to a fresh install.
Remember: Don’t getting the vendor logo has nothing to do with the grub-quiet package. It only hides the menu and won’t display extra text messages. Configure it with quiet and setup udev not to display messages as needed. linux419 provides the magic to hold back the cached logo, when no text gets displayed. More about flickerfree bootup here. An explanation for deferred console takeover can be found here. The needed patch is also added to linux418 series. Also I’ve to say: we started to support Intel’s i915 driver and will update the approach so AMD and Nvidia will work too.
Guys one more thing to test is the behaviour of this logo thing when using encryption - I mean when a user enters a password during the boot if he has more than one partition encrypted and no keyfiles are added as slots. Does this logo thing let you enter the password? Or does it fall back to console prompt?
Ah… so… it is a different package ‘grub-fedora’ not ‘grub-quiet’.
So I’m still correct that grub-quiet ‘does not work’.
I remember that on a single OS, Ubuntu default installation hides the grub menu too (press ‘shift’ to make menu appear) Not sure if that is still the case.
As said, I personally do not want to use ‘hidden grub’ but I am just trying to help out by testing (and provide feedback - good or bad). My personal opinion is that the present grub is sufficient to handle hidden grub without much hassle (manufacturer logo not withstanding). I repeat my opinion that the present ‘grub-quiet’ package is …not good.
As for testing ‘grub-fedora’, I’ll be sitting this one out for the moment until the ‘dust settles’ and if we decide that Manjaro will be adopting it as the default grub, which at this point, appears to me (without testing) to be ‘trifling’ for the amount of work to be done.
Good luck. Cheers.
OK, what is not working? Were the needed settings set in grubenv? Be more specific. What did you test so far with grub-quiet and/or grub-fedora. Seems I’ve to do more QA on this one.
The main and sufficient thing (I thought I had pointed this out) is that we cannot get to the grub menu (not shift or esc key) if timeout=0; and we are instructed to have timeout=0 to have grub-quiet working.
2nd point (to me not that important)
testing timeout=(non-zero), it is the same as as having the normal grub with grub=hidden.
Manufacturer logo still not appear (same as normal grub) whether in uefi or bios-legacy, In Dell labtop, logo appears at start of computer, just the same as in grub or grub-quiet, no difference.
ps: I repeat I have not tested grub-fedora
[EDIT] - I also repeat that for a hidden grub menu, I think it is imperative there must be some way to make the menu appear. Imperative because there will be a need to amend kernel parameters or boot a different kernel whenever there are some problems booting. If the user cannot do this, it is quite difficult for the user to fix the problem booting up (except by chroot or livecd boots).
Where do you read anything about timeout=0? This will disenable to press any key. It will only passed when fastboot is enabled. Did you check the last changes made in git? Default settings are timeout=5 and style=menu.
We will then set timeout=1 and style=hidden for hiding on successful boot. Else we may have timeout=60 and style=menu for showing it once.
Seems we are in a constant loop here.
From your posts here, yup, before
before… grub-add-auto-hide-menu-support.patch (from grub-fedora i presume)
I add there is something more about ‘fastboot’ ?
So I’ll be sitting out out the testing until we decide if we want any ‘new-grub’ (instead of the present) to be the default.
Perhaps I might be testing ‘new-grub’ even if it is not the default but when the dust settles.
Too many loops going around.
Ladies and gentlemen!
Come on guys - this thread has deteriorated to making no sense - repeating for every other post the same issue over and over.
Data integrity makes sense and is accommodated for with systemd-fsck-silent package.
I understand - to a degree - that, the absense of the logo on a lot of hardware gives the impression that the boot hangs.
I don’t mind the scrolling of text - it gives me assurance that the system is booting as expected. It sometimes gives me cues to something I need to have a look at. Like
gssproxy.service taking a long time starting.
But it is nothing that is so vital to me that it is worth the crusade like this thread.
It sounds more like the die-hard init fanclub - now the die-hard grub scrolling fanclub.
All measures are in place - when needed - to make the grub screen/menu visible.
I know that over the years, dual-booting has been so much up-voted that everybody thinks it is the next standard and a must have. No - dual-boot is not a must have.
I feel like dual-booting has become the holy grail of GNU/Linux - and it shouldn’t be.
I think that dual booting should be avoided since it is the mother of a lot of booting issues. That goes for dual booting different versions of Manjaro and different versions of Linux .
People which absolute needs dual-boot can easily adapt the system after installation.
As mentioned earlier in this thread - when something is bothering us - as users - we tweak the system.
I don’t think Manjaro deserves the storm which has been raised in the thread so please calm down ladies and gentlemen.
OK, I’ll patch normal grub later today, and drop grub-quiet. Then defacto grub-quiet will be default on all systems. Calamares will autohide the menu by default. To see the menu you can issue display once, disable the feature or set it to hiding, even if you have a dual boot setup.
I really have simply enough of this nonsense.
Is Manjaro going towards Gnome/Apple road?