mintupgrade should respect boot parameters

[d-albrecht]

A week ago I upgraded my LMDE 4 install to LMDE 5 and with this update the boot splash screen returned and I'm unable to get rid of it again. Running an upgrading script should not change/reset system settings that don't need to be changed (for example I understand that the theme settings are affected now that dark mode is handled differently).

On LMDE 4 I explicitly disabled the splash screen (because I like the output and one time I had messed up my boot a bit and that was the point where I decided that I not only liked the output but needed it to detect any problems way easier and faster). I'm pretty sure I changed this with grub-customizer. Now after the upgrade the splash screen is visible again upon boot and I cannot find a way to disable it permanently. Because both the grub-customizer and /etc/default/grub tell me that the splash screen SHOULD NOT be visible. I can't turn off something that is turned off already, when in reality I know that it isn't off. And that's not a setting that the upgrader had to change/touch anyways (as far as I know) in order to upgrade to LMDE 5.

Therefore, I would appreciate if the upgrader could respect these system settings in the future. (And if someone could point me to a way to again disable the splash screen.)

PS: This might not be an issue with the upgrader itself but its usage for specific updates, but I didn't know where to put this otherwise. Please move to an appropriate place if necessary/applicable,

[d-albrecht]

Okay, so. I managed to disable the splash screen again. There isn't just /etc/default/grub but a whole /etc/default/grub.d folder that also gets parsed and in there was a config file to enable the splash screen. The problem with the splash screen is that ii is triggered by present parameters. So, the absence of the splash screen can only be assured if all config files don't specify the required parameters. If any do, the splash screen is visible (there is no "no-splash-screen" parameter that overwrites any other flags). So, the default value for this setting as well as the default state in which LMDE ships can easily cause the splash screen to reappear, if someone misses this change at one point or another (but that's a general Linux problem, not a Mint problem). Now, I don't know for sure if the upgrade did something in this folder, but I do know that on LMDE 4 I didn't have a splash screen for me, on LMDE 5 I did. So, something must have happened while the upgrade did its things. I will keep the issue open, but I'm totally fine if you decide to just close this because the issue for me seems resolved. Still, I would blame mintupgrader here for affecting some stuff it shouldn't have.

[Jeremy7701]

If you read the comments in /etc/default/grub.d/50_lmde.cfg, this explains why LMDE need to over-ride Debian's actions. Additionally, Mint make the assumption everyone wants a splash screen. (I'm assuming the reference to LMDE4 should be LMDE5).

[d-albrecht]

To be fair, I've never read all the comments in this file, partially because I found the solution kind of in a hurry and was also sort of debugging a different side-effect of the upgrading process at the same time, so, I hope you can understand that I don't spend extra time on a solved problem, when there are other problems as well. That said, and given that I now have read and understood the reasoning, it's hard for me to really be mad at the upgrader or claim that the upgrade process should be implemented in a smarter way. Because let's face it, if the boot parameters are distributed among these files and locations, and if some grub-packages just outright ignore / delete some config files or expect the config somewhere different, then it's overkill to expect the upgrader to parse that all and only create the new file (which I agree probably meant to say LMDE 5 and not 4) if the system prior was configured to show the splash screen.

It still holds true, that if there was a "no-splash-screen" flag or "splash-screen=-1" option that would overwrite any other flags that target this class of behavior, that this parameter would be saver to handle. (I know, not the scope of mint.)

BUT; Should this then perhaps be treated as an issue with grub-customizer? Sure, I know that this isn't mint's responsibility as well. But while I don't think the upgrader should have parsed all the potential files that might have something to do with booting, this exactly is the use case for grub-customizer. I only today checked the files directly because some other user pointed me vaguely in the direction of the config files and I just looked whether there might be other files with boot parameters. I had checked grub-customizer before and at first trusted its displayed values. But what is the value of a tool that only reflects parts of the boot parameters? Well, I will leave this as an open question and close this issue. Because I'm not the right person to decide whether grub-customizer does enough to operate well. As well as the (rather rhetorical) question, why we might want to support SecureBoot at all (if this means that all Linux distros have to beg MS to sign certain cryptographic keys or that the users have to tamper with the motherboard's key chain). But, I might just not get the security threat this is preventing (like I don't get AMD's PSB). Other than that Win 11 requires SecureBoot (and some users might want to dual-boot) and no antitrust division has stopped MS from overstepping their boundaries here.