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

grub boot success services fails, because there is no grub dir #83

Open
Cyborgscode opened this issue Dec 13, 2020 · 7 comments
Open

grub boot success services fails, because there is no grub dir #83

Cyborgscode opened this issue Dec 13, 2020 · 7 comments

Comments

@Cyborgscode
Copy link

I think it's enabled in base by default, you may wanne remove it:

/usr/lib/systemd/user/grub-boot-success.service

root # /usr/sbin/grub2-set-bootflag boot_success
Error canonicalizing /boot/grub2/grubenv filename: No such file or directory

@Cyborgscode Cyborgscode changed the title grub boot success services fails, because there is no grub grub boot success services fails, because there is no grub dir Dec 13, 2020
@Cyborgscode
Copy link
Author

so funny...

systemctl disable grub-boot-success

Failed to disable unit: Unit file grub-boot-success.service does not exist.

ls -la /usr/lib/systemd/user/grub-boot-success.service

-rw-r--r--. 1 root root 119 31. Aug 14:29 /usr/lib/systemd/user/grub-boot-success.service

@pcfe
Copy link

pcfe commented Jan 8, 2021

Please note the TriggeredBy: ● grub-boot-success.timer when you do [pine@pinephone ~]$ systemctl --user status grub-boot-success.service

Also please note this is user not system wide.

You can view the user timers with

[pine@pinephone ~]$ systemctl --user list-timers
NEXT                        LEFT          LAST                        PASSED   UNIT                         ACTIVATES                     
Fri 2021-01-08 11:32:36 CET 2min 46s left n/a                         n/a      systemd-tmpfiles-clean.timer systemd-tmpfiles-clean.service
n/a                         n/a           Fri 2021-01-08 11:29:49 CET 10ms ago grub-boot-success.timer      grub-boot-success.service     

2 timers listed.
Pass --all to see loaded but inactive timers, too.

I had no success when trying to disable it with [pine@pinephone ~]$ systemctl --user disable grub-boot-success.timer, it still triggered at next boot and did not bother digging further as there is a plan B for that case

So, like any .service or .timer that's a bit reluctant to be disabled, I masked it

[pine@pinephone ~]$ systemctl --user mask grub-boot-success.timer
Created symlink /home/pine/.config/systemd/user/grub-boot-success.timer → /dev/null.
[pine@pinephone ~]$ sudo reboot
[sudo] password for pine: 

Checking after the phone rebooted, once shorly after boot and then again about 5 minutes later

[pine@guest47 ~]$ uptime
 11:41:49 up 1 min,  2 users,  load average: 1.74, 1.01, 0.39
[pine@guest47 ~]$ systemctl --user list-timers
NEXT                        LEFT          LAST PASSED UNIT                         ACTIVATES                     
Fri 2021-01-08 11:45:17 CET 3min 18s left n/a  n/a    systemd-tmpfiles-clean.timer systemd-tmpfiles-clean.service

1 timers listed.
Pass --all to see loaded but inactive timers, too.
[pine@guest47 ~]$ systemctl --user --failed
  UNIT LOAD ACTIVE SUB DESCRIPTION
0 loaded units listed.
[pine@guest47 ~]$ sleep 300 ; systemctl --user --failed
  UNIT LOAD ACTIVE SUB DESCRIPTION
0 loaded units listed.

@Cyborgscode
Copy link
Author

Who sets a user depending timer to acknowledge a successful boot in the first place? If the user session fails, the boot itself could still be successful.

In the light of a phone, which will have ( but is not restricted to ) only one user account, I have some acceptance for it, but it's still wrong IMHO, as a user session fail will result in booting an older kernel ( in the normal grub boot process on fedora ) which will not fix the issue with userspace issues in allmost all cases.

@Cyborgscode
Copy link
Author

Update: grub2-efi aarch64 package from fedora 34 does not get installed with a symlink error:

https://bugzilla.redhat.com/show_bug.cgi?id=1919907

Solution: touch /boot/grub2/grubenv

and than updating the system with dnf as usual :D

@alh61
Copy link

alh61 commented Apr 6, 2021

This is basicly a duplicate of #24 - that all grub2 code should be removed

@Cyborgscode
Copy link
Author

Grub itself is not needed, but removing it takes some other packages with it, which may be required.

@alh61
Copy link

alh61 commented Apr 6, 2021

I don't think so. I remove everything related to Grub2 and EFI on all my nightly images. I see no reason, why it can't be removed from this image too.

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

3 participants