Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
(Installation media) Bootloader artwork refresh #33686
Instructions for testing this PR by making a disk image: #33686 (comment)
See PR #26 of nixos-artwork
Motivation for this change
The current artwork is old, wait that's not an issue, but it does use the older NixOS snowflake logo!
This PR is more of a technical workout of the details needed to review bootloader artwork. I am not an artist, this is why this is a sober refresh, using existing bits.
This PR is geared towards the installation media, I don't intend to change defaults or prevent choices for the end-user installation.
ISOLINUX setup is a given, I don't think there's anything to review really. I have upgraded the default resolution to 800x600. ISOLINUX will fallback to text mode if it cannot change to 800x600.
On a technical note, I have chosen to keep to 4:3 aspect ratio since this will probably be much less frequently used on real hardware with 16:9 aspect ratio. The appearance targets mainly the VirtualBox use-case. Furthermore, seeing stretched 4:3 on 16:9 will be par-for-the-course for the users that will see it on real hardware.
2. systemd-boot (or lack thereof)
This is why there are the next points
3. New UEFI bootloader for the installer image
This is something that will need to be evaluated with great care. Here are the solutions I know of.
@andir has a good point, we can't move to a bootloader that can't support serial. It should support serial, but it seems the author isn't making it a priority to ensure it works.
I think this means that grub is a necessity for this purpose.
rEFInd from systemd-boot?
This is redundant for 99% of the installer image users, but this might help some users with buggy EFI implementations. I know I would have loved it in two separate occasions last year.
The specific scenario I know of is that some buggy EFI implementation can lose their configuration. I have two separate computers with distinct EFI implementation that have this flaw, (exhibited in different ways). In both cases, it is made worse in not being able to manually add a path to the EFI boot options from the firmware interface. With the default NixOS setup, it makes both those computers unbootable from the existing volumes. (Both implementation will boot the default
Total cost of adding rEFInd:
Looks like there is or there was a suite of tests for the minimal iso.
Grub theme has been made. There is also support into the module to not use the theme and instead use a simpler background and text menu, as is currently used by default when using grub2.
The grub2 theme engine cannot render with subpixels, which is why the text is... not that great. Though the text rendering isn't the best, having the ability to render bigger text is a great help for Higher DPI devices.
Hardware testing has been conclusive. It works on all of my UEFI devices. (Not all are pictured.)
I have re-worked the grub menuentry generation to allow building new options while not repeating the code. This makes it possible to add a submenu with entries. I have added two demo entries that add
I have updated this PR with tested and working serial for grub.
This has been tested only on qemu, as I do not have the hardware to test.
This has been tested with these qemu options:
In all cases, when it made sense, serial worked, graphics worked.
Fun fact, the serial and graphics menus are synchronised! This means that selecting an option in the serial console will be visible on the screen, and selecting an option in the screen will be visible on the console.
Additionally, a new option in the Quirks menu has been added for serial. This, too, has been tested with qemu, and it works.
Nothing much really, though I'd love it if people could test on real-world hardware especially if they have picky hardware.
Here's a list of things that may be good to check:
Both checking how GRUB looks, and the hidpi helper options in the accessibility menus.
Though, I don't really have any hopes to see them all tested, I mean, I'd like to have a head count of everyone that booted it on real hardware, then a head count for those that booted it on MBR and then UEFI virtual machines.
So, it's probably good to be merged, if the code quality here is fine.
I merged my nixos-artwork PR, made the review as needed for the grub2 theme. This is ready. I also freshly rebased ans squashed into more logical commits.
I don't want to have to press the merge button myself, would love to have someone else validate the iso works for them too.!
I don't think it was worth the effort to split the big grub2 commit into smaller parts; it's all interconnected.
A bit of testing was done by two members of the community
The first end-user tests hit a couple bumps from the later changes:
This wasn't considered at first, because it worked here, but turns out grub sees serial interfaces on my test hardware devices, and sees one with the default qemu settings! You can use
This has been fixed.
The other main pain point would be how the menu can look on really-low resolutions, like some towers/workstations can show. This has been fixed by reducing the padding (in the last PR to nixos-artwork).
The changes don't need this to be merged before this one, I'm keeping it open until this is merged, in case there are other changes; the release tarball for the theme is already fixed to serve the right files.
With the newly-done user-testing, and having had an actual refresh of its state by fixing those small issues, I'd say LGTM.
Leaving this note here if anyone needs it.
Building the image
Checkout this branch, then at the root of nixpkgs
@samueldr I get both on the minimal and the graphical ISOs on my early-EFI Nvidia notebook:
error: no suitable video mode found. Booting in blind mode
It doesn't go away.
Oh, thanks for testing!
A quick note: for both isos, the behaviour is supposed to be the same as there is no distinction as far as the bootloader is concerned.
I am really glad you tested this as otherwise this would have left our users in a dire situation!
@ilyaigpetrov quick question: can you confirm that this is after successfully using grub or is the error happening before being able to select a boot option? (This changes how I will approach the issue.)
EDIT: and could you confirm that this is the same behaviour as observed in #5829; that the computer on which "Booting in blind mode" is the one which went to a blank screen; and that the other computer worked on both. I mainly want to ensure there's no actual regression...
added a commit
this pull request
Aug 24, 2018
I have, nonetheless, applied what I think is the appropriate fix; that is, if I understand the issue correctly, and the gotchas link applies for your situation.
A quick overview of the change:
I have doubts that adding
I can see that loading
I, though, have hope that loading the two modules that way could change the results.
Thanks again for testing, waiting for feedback (both using with the changes, and the questions asked in the previous comment),
I am able to successfully select an option from the list or edit boot parameters before the boot, after this I get the error. That's all I know.
Yes, the problematic notebook is the same as in #5829, the other notebook works both with the grub and the old boot loader.
I have tried your new commits -- unfortunately they don't solve the issue.
P.S. Other linux distros (Lubuntu) on the problematic notebook show the same "error: no suitable video mode found" but after some seconds boot an X11 server or a terminal in high resolution (if I remember it correctly).
Thanks for testing again @ilyaigpetrov! This 99% confirms my suspicions: To fix such issues, the installer image needs to use KMS (kernel modesetting) in your situation.
That's why you see no output, and then a high resolution terminal.
Since there is no regression, it doesn't block this from merging (
I'm now curious, @ilyaigpetrov, your other comment I just now read brings this to 99.99% certainty. Does using one of the resolution option under "HiDPI, Quirks and Accessibility" → "Suggests resolution @ ____", then selecting the default installer option work? It may start up without output, but after a couple seconds it could end-up showing stuff. The parameter it adds is supposed to force a resolutoin at the KMS driver level.
Here is the flow for you, @samueldr :
error: no suitable video mode found. Press any key to continue
→I press a key and select 720p
error: no suitable video mode found. Booting in blind mode
→The error doesn't go away.
P.S. The ISO image may be not of the last commit where you tried to apply arch wiki gotchats, but the previous.
No worries, the gotchas commit shouldn't affect the outcome since this is strictly something Linux manages.
Seeing the errors every time is... an annoying misfeature of grub; long explanation cut short: every sub-menu has to be re-initialized the same way the main menu has to be, which shows any errors while the main menu doesn't 🤷.
Improvements to do noted in #5829 could help those in the same situation in the future, though won't be part of this PR as they would be orthogonal.
I have dropped the lesser-tested last commit, in case it caused issues wherever else the other state of this PR was tested. The commit is available as a patch here for testing purposes. Anyway, AFAICT, the way grub works made most of those changes no-ops.
referenced this pull request
Aug 27, 2018
Building I get this output:
wonder the impacts of that.
Regarding the error message I found:
this is already true in 18.09's build of the install image:
however it is not in the 18.03 image build:
We may want to see why we increased by 3k sectors and try to keep it small. However, to find out if this was a blocker, I did some research in to what this vague warning actually means.
Thanks to rcf in ##linux on Freenode, I learned this is going to be a non-issue for any system newer than MSDOS basically:
and for more information: https://en.wikipedia.org/wiki/INT_13H#EDD
However, rcf noted some boot firmware vendors suck and still don't support EDD for USB disks. This means if a user has a problem with booting the graphical disk, they should try the non-graphical disk.
Overall, I would be honored to press the merge button.
Aug 29, 2018
8 checks passed
This broke generating i686 image: https://nix-cache.s3.amazonaws.com/log/0z6fqv1dmxbngw2r65r53y0qw20h0qkp-efi-directory.drv (I know very little about EFI).