Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Default systemd-boot entry not working #29

Open
eoli3n opened this issue Nov 17, 2020 · 11 comments
Open

Default systemd-boot entry not working #29

eoli3n opened this issue Nov 17, 2020 · 11 comments

Comments

@eoli3n
Copy link

eoli3n commented Nov 17, 2020

This is not a zectl issue : systemd/systemd#15068

But as it is an important feature for zectl, i'm wondering if you workedaround it ?
If you reboot without beeing in front of your screen and without speedly select (and remember) the right boot env, so you get the last created boot env booted. It could be really painful if you didn't notice it...

I still don't get why i need to "activate" a bootenv after booted it ? As we select a bootenv in systemd-boot at boot, it sound like making the work twice, and being more complex without beeing useful. If i want to revert, i reboot to the previous boot env, so why activate mechanism offers more ?

@zhimsel
Copy link
Collaborator

zhimsel commented Nov 17, 2020

Activating a boot env marks it as the default entry in the boot loader and promotes the dataset clone.

@eoli3n
Copy link
Author

eoli3n commented Nov 17, 2020

Ok thanks. Why not making auto-default+promote at startup ? and using activate to "revert" if needed ?
I don't even know if you need activate, this seems to me a more logic workflow:

  1. Create a boot env "before install x"
  2. Something is wrong, lets reboot and select the boot env "before install x"
  3. At startup, it become the default boot env. Then two cases:
    a. I'm ok with this: nothing to do
    b. I'm not ok, lets reboot on another bootenv, then goto 3 :)

@zhimsel do you face the issue of systemd-boot not correctly boot defaultly set entry ?

@zhimsel
Copy link
Collaborator

zhimsel commented Nov 17, 2020 via email

@eoli3n
Copy link
Author

eoli3n commented Nov 20, 2020

@zhimsel can you try and tell me if its working please ?

@zhimsel
Copy link
Collaborator

zhimsel commented Nov 20, 2020 via email

@zhimsel
Copy link
Collaborator

zhimsel commented Nov 20, 2020

@eoli3n So I just tested what I think was the issue, and it didn't occur for me. My test procedure (while booted into the default boot env):

  • zectl create test
  • zectl activate test
  • Confirm that loader.conf had test as the default BE
  • Reboot, verify that test was the actively selected bootloader entry (i.e. the default)
  • Select and boot into default instead
  • Confirm that loader.conf still had test as the default
  • Reboot again and verify again that test was still selected in the bootloader by default.

So it seems to have been fixed. I vaguely remember seeing it as a bug that was fixed in systemd-bootloader's bug tracker.

For reference:

  • zectl version: 0.1.2
  • systemd version: 246.6-1

¯\_(ツ)_/¯

@eoli3n
Copy link
Author

eoli3n commented Nov 20, 2020

Thanks for testing, I will try to understand what's going on here.

@johnramsden
Copy link
Owner

I also attempted @zhimsel 's test and cannot reproduce

bootctl version: systemd 246 (246.6-1-arch)

@eoli3n
Copy link
Author

eoli3n commented Nov 25, 2020

I think that my bootenv names are problematic:

pacmanhook-20200523T162905  NR      /                 2020-05-23 16:29  
pacmanhook-20201121T114946          -                 2020-11-21 11:49  

I will test @zhimsel procedure when i have time
@johnramsden what do you think of #29 (comment) ?

@schmitmd
Copy link

schmitmd commented Jan 9, 2022

related to 4d9139e and #7 ? I'm running into this same problem on a fresh install for a new laptop. Tried loader.conf with org.zectl-default.conf and org.zectl-default, no change in behavior with systemdboot efi default entry when I zectl activate foo. :/

@eoli3n
Copy link
Author

eoli3n commented Jan 10, 2022

I'm still running that bug, which is pretty annoying.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants