Bugzilla – Bug 1161620
New purge-kernels asks to confirm purge, at boot time
Last modified: 2021-11-03 20:46:55 UTC
dracut-049+git118.a6090e2f-1.1.x86_64 (no longer has purge-kernels.service)
Ref: Bug 1159289 OP Michal Suchanek (2019-12-16), Dracut needs to drop
purge-kernels.service execs "zypper purge-kernels" on boot if
/boot/do_purge_kernels is present. Zypper synthesizes a command line
zypper remove kernel-default-(vers) kernel-default-devel-(vers)...
It then asks the human operator to confirm this operation, which of
course is impossible at boot time. Output is attached from
systemctl status purge-kernels.service .
I think purge-kernels.service needs to give --non-interactive to zypper.
In a session with a normal ptty I tried "zypper purge-kernels" with and
without --non-interactive. Without, the removal instance asked for
confirmation, but with --non-interactive. it simulated a 'y' and went on
to remove the unwanted kernel instance(s). This is correct behavior.
Last night I tried the same test on a different machine and with
--non-interactive and (I think) '</dev/null'; even so it tried to read
the tty, failing. But it was late and I could have done something
different from what I'm describing.
I added --non-interactive in /etc/systemd/system/purge-kernels.service
and started it (after "touch /boot/do_purge_kernels"). It removed the
unwanted kernels and kernel-default-devel's.
Created attachment 828102 [details]
Output of systemctl status purge-kernels (when failing)
I can confirm the problem.
But there is an addition problem. Somehow, the purge-kernels service does not exist. Yet it has been working successfully for years.
It seems that there is a purge-kernels-service package that must be installed. This is going to result in Tumbleweed user's disks filling up.
So I added the package, but it does not work (as this bug reports).
Marking bug as confirmed.
(In reply to Neil Rickert from comment #2)
> I can confirm the problem.
> But there is an addition problem. Somehow, the purge-kernels service does
> not exist. Yet it has been working successfully for years.
> It seems that there is a purge-kernels-service package that must be
> installed. This is going to result in Tumbleweed user's disks filling up.
> So I added the package, but it does not work (as this bug reports).
I can confirm your observations:
i) After the removal of the purge-kernels scripts and service with dracut 049+git117.d3206e79 there is an additional package called 'purge-kernels-service', which has to be installed manually.
ii) The "new" purge-kernels.service fails at boot with the above-mentioned error.
Can confirm this issue and also the purge-kernels-service that has never been installed and that I add to install manually.
Passing -n (non-interactive) to 'zypper purge-kernels' does indeed fixes the problem at boot.
Thanks for the report. The service is indeed not installed because the dependency is commented out in patterns-base.
The -n parameter is needed for unattended run.
FYI: The above-mentioned issues also apply to Leap 15.2.
This should be addressed on 15.2 as well. The packages are submitted.