4 ms·

How do those background images scale on different monitors/resolutions? Btw, how does grub figure out in what resolution to draw the interface?

mshockwave 1y ago
judging from some of these repos, I think the answer is: they don't. It seems like you have to manually pick images with the correct resolution
shmerl 1y ago
You can set the resolution explicitly, otherwise it will render at resolution UEFI started the boot with.
- cosmic_cheese 1y ago
  This is a significant peeve of mine. The need to explicitly specify resolution in boot managers is annoying for both laptops and machines that aren’t always used with the same monitor, because no matter what it’s going to end up in fallback with an ugly stretched resolution some portion of the time, rendering beautification with themes somewhat moot. This limit made sense 20+ years ago but today it feels highly anachronistic, kind of like finding a corded rotary phone mounted on a wall in the kitchen of an otherwise cutting edge home. Surely it’s something that could be fixed?
  - shmerl 1y ago
    May be, but this is so minor in general, that I barely care as long as it boots properly. Way bigger annoyance is that grub still doesn't support luks2 and uses some gimped variant of libcrypto without proper hardware acceleration that decrypts boot volumes for almost a minute. That is way more serious than boot resolution annoyances.
    - nextaccountic 1y ago
      That's also a peeve of mine. Is there a way at all for grub to use hardware acceleration there? Or maybe the bootloader isn't allowed to do such things
      - shmerl 1y ago
        Yes - use newer libcrypto. They are in the process of switching, but it just takes very long. I don't see why bootloader won't be allowed to use the CPU features that accelerate decryption.
        nextaccountic 1y ago
        > They are in the process of switching, Nice! Do you have a link with the progress of this? Maybe in a mailing list or something. I can't manage to find it Also, do you know whether grub plans to support luks2? And maybe even veracrypt - ok this one is unlikely. (cryptsetup can read veracrypt just fine and the Linux kernel copes with it, maybe it's a matter of porting this code to grub? One issue is that grub would need to embed the number of iterations of the key derivation function somehow - the thing veracrypt calls PIM - because unlike luks, veracrypt doesn't store it in a header that can be read before unencrypting)
        shmerl 1y ago
        The main bug is here: https://savannah.gnu.org/bugs/?55093 https://savannah.gnu.org/bugs/?55093 But I do recall some other post which went into more details and was saying that switching was taking time due to lack of stable API and other issues. Try searching for grub 2 + libgcrypt. Some links are also in that bug.
    - bobmcnamara 1y ago
      What can I say? Feels weird to include a JSON library in a bootloader.
      - 1y ago
  - rsaxvc 1y ago
    My pet peeve is that grub repartitions windows disks on chain load, so if it ever boots with the disks remapped, there's a chance it'll plow apart the partition table of whatever poor disk got mapped to that hd#.

mshockwave 1y ago

judging from some of these repos, I think the answer is: they don't. It seems like you have to manually pick images with the correct resolution

shmerl 1y ago

You can set the resolution explicitly, otherwise it will render at resolution UEFI started the boot with.

cosmic_cheese 1y ago
This is a significant peeve of mine. The need to explicitly specify resolution in boot managers is annoying for both laptops and machines that aren’t always used with the same monitor, because no matter what it’s going to end up in fallback with an ugly stretched resolution some portion of the time, rendering beautification with themes somewhat moot. This limit made sense 20+ years ago but today it feels highly anachronistic, kind of like finding a corded rotary phone mounted on a wall in the kitchen of an otherwise cutting edge home. Surely it’s something that could be fixed?
- shmerl 1y ago
  May be, but this is so minor in general, that I barely care as long as it boots properly. Way bigger annoyance is that grub still doesn't support luks2 and uses some gimped variant of libcrypto without proper hardware acceleration that decrypts boot volumes for almost a minute. That is way more serious than boot resolution annoyances.
  - nextaccountic 1y ago
    That's also a peeve of mine. Is there a way at all for grub to use hardware acceleration there? Or maybe the bootloader isn't allowed to do such things
    - shmerl 1y ago
      Yes - use newer libcrypto. They are in the process of switching, but it just takes very long. I don't see why bootloader won't be allowed to use the CPU features that accelerate decryption.
      - nextaccountic 1y ago
        > They are in the process of switching, Nice! Do you have a link with the progress of this? Maybe in a mailing list or something. I can't manage to find it Also, do you know whether grub plans to support luks2? And maybe even veracrypt - ok this one is unlikely. (cryptsetup can read veracrypt just fine and the Linux kernel copes with it, maybe it's a matter of porting this code to grub? One issue is that grub would need to embed the number of iterations of the key derivation function somehow - the thing veracrypt calls PIM - because unlike luks, veracrypt doesn't store it in a header that can be read before unencrypting)
        shmerl 1y ago
        The main bug is here: https://savannah.gnu.org/bugs/?55093 https://savannah.gnu.org/bugs/?55093 But I do recall some other post which went into more details and was saying that switching was taking time due to lack of stable API and other issues. Try searching for grub 2 + libgcrypt. Some links are also in that bug.
  - bobmcnamara 1y ago
    What can I say? Feels weird to include a JSON library in a bootloader.
    - 1y ago
- rsaxvc 1y ago
  My pet peeve is that grub repartitions windows disks on chain load, so if it ever boots with the disks remapped, there's a chance it'll plow apart the partition table of whatever poor disk got mapped to that hd#.