Bug 1161620 - New purge-kernels asks to confirm purge, at boot time
New purge-kernels asks to confirm purge, at boot time
Status: RESOLVED FIXED
Classification: openSUSE
Product: openSUSE Tumbleweed
Classification: openSUSE
Component: Basesystem
Current
x86-64 openSUSE Factory
: P5 - None : Major (vote)
: ---
Assigned To: Michal Suchanek
E-mail List
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2020-01-23 05:48 UTC by James Carter
Modified: 2021-11-03 20:46 UTC (History)
7 users (show)

See Also:
Found By: ---
Services Priority:
Business Priority:
Blocker: ---
Marketing QA Status: ---
IT Deployment: ---


Attachments
Output of systemctl status purge-kernels (when failing) (1.31 KB, text/plain)
2020-01-23 05:53 UTC, James Carter
Details

Note You need to log in before you can comment on or make changes to this bug.
Description James Carter 2020-01-23 05:48:50 UTC
Versions:
purge-kernels-service-0-1.1.x86_64
zypper-1.14.33-1.2.x86_64
dracut-049+git118.a6090e2f-1.1.x86_64 (no longer has purge-kernels.service)
openSUSE-release-20200118-406.1.x86_64

Ref: Bug 1159289 OP Michal Suchanek (2019-12-16), Dracut needs to drop 
purge-kernels.service

purge-kernels.service execs "zypper purge-kernels" on boot if 
/boot/do_purge_kernels is present.  Zypper synthesizes a command line 
similar to:
    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.
Comment 1 James Carter 2020-01-23 05:53:34 UTC
Created attachment 828102 [details]
Output of systemctl status purge-kernels (when failing)
Comment 2 Neil Rickert 2020-01-23 19:43:17 UTC
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).
Comment 3 Neil Rickert 2020-01-23 19:45:08 UTC
Marking bug as confirmed.
Comment 4 Frank Krüger 2020-01-23 20:32:08 UTC
(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.
Comment 5 Michael Pujos 2020-01-24 13:11:29 UTC
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.
Comment 7 Michal Suchanek 2020-01-24 15:30:15 UTC
Thanks for the report. The service is indeed not installed because the dependency is commented out in patterns-base.

https://build.opensuse.org/request/show/766924

The -n parameter is needed for unattended run.

https://build.opensuse.org/request/show/766924
Comment 8 Michal Suchanek 2020-01-24 15:31:24 UTC
https://build.opensuse.org/request/show/766917
Comment 9 Frank Krüger 2020-01-24 21:14:23 UTC
FYI: The above-mentioned issues also apply to Leap 15.2.
Comment 10 Michal Suchanek 2020-01-30 19:14:58 UTC
This should be addressed on 15.2 as well. The packages are submitted.