I suddenly got the same problem in /efi/loader/entries all conf files reverted to previous uuid (first post ). To change uuid I just edited all conf files with the correct uuid for root.

I don’t know if manually changing was correct or if I should use some sort command.

Bootctl status

UUID in status is wrong.

I have no idea what is reverting UUID back to the wrong one after updating system.

I could just reinstall but if possible I would like to try to fix this and learn.

Edit: Problem was that in /etc/kernel/cmdline had wrong UUID. Changed it to correct one and dracut-rebuild uses correct UUID.

  • krnl386@lemmy.ca
    2·
    1 year ago

    Legacy API and app behaviour support. Ironically replacing the registry with something more straightforward would be relatively easy, unlike adding support for storing home directories on a drive other than C. Technically you can mount a different filesystem under c:/users to achieve this, but AFAIK that’s neither supported nor trivial to do.

    I tried doing it, and gave up. Sure, most software will respect the path changes in the user’s registry hive, however, every once in a while a program will just assume that your home dir lives under c:\documents and settings$username - and that’s when it all goes south. Really frustrating this lack of consistency.

    All in all, the OS is riddled with hacks and “supports” for legacy runtimes and behaviours. Heck, my username is poking fun at the fact that Windows 7 had support for the 386 (yes, Intel’s 80386 processor from the late 80’s) enhanced API. Windows 7…. My username is a “tribute” to a file called krnl386.exe that implemented a bunch of legacy API calls like how much RAM a system has or whether or not the OS is running in “386 enhanced mode” that were relevant back in Windows 3.x days… and still supported in Windows 7. That pretty much sums up why Windows is, and always will be, a hot mess.