Comment 22 for bug 1774120
Revision history for this message
| Balint Reczey (rbalint) wrote Re: [Bug 1774120] Re: ebtables cannot be upgraded from 2.0.10.4-3.5ubuntu2 to 2.0.10.4-3.5ubuntu2.18.04.1 on WSL | #22 |
On Wed, Jun 20, 2018 at 2:11 PM Dimitri John Ledkov 🌈
<email address hidden> wrote:
>
> IMHO this is a class of issues on WSL. Given that systemd is not
> services should be attempted to be stopped, nor started.
I had the same idea for a little, but IMO trying to address the class
of potentially broken init scripts by masking them is not a good idea
in general and also would cause serious regression in Ubuntu on
Windows app's usability.
It is true that packages disable functionality when the functionality
is unlikely to be needed in a given environment like
/etc/kernel/
systemd-detect-virt identifies the system as a container environment
but in case of WSL the system features to be supported seems to be
open-ended. For example we now may think that managing services from
maintainer scripts should be skipped by short-cutting helpers, but
services can actually be run on WSL. Just try:
$ sudo apt install apache2
$ sudo service apache2 start
It runs, and it is even stopped when apache2 is reinstalled:
ubuntu@rbalint1:~$ sudo apt-get install --reinstall apache2
Reading package lists... Done
Building dependency tree
Reading state information... Done
0 upgraded, 0 newly installed, 1 reinstalled, 0 to remove and 0 not upgraded.
Need to get 95.1 kB of archives.
After this operation, 0 B of additional disk space will be used.
Get:1 http://
apache2 amd64 2.4.29-1ubuntu4.1 [95.1 kB]
Fetched 95.1 kB in 0s (1075 kB/s)
(Reading database ... 35177 files and directories currently installed.)
Preparing to unpack .../apache2_
invoke-rc.d: could not determine current runlevel
* Stopping Apache httpd web server apache2
Unpacking apache2 (2.4.29-1ubuntu4.1) over (2.4.29-1ubuntu4.1) ...
Processing triggers for ufw (0.35-5) ...
Setting up apache2 (2.4.29-1ubuntu4.1) ...
invoke-rc.d: could not determine current runlevel
invoke-rc.d: could not determine current runlevel
Processing triggers for ureadahead (0.100.0-20) ...
Processing triggers for systemd (237-3ubuntu10) ...
Processing triggers for man-db (2.8.3-2) ...
ubuntu@rbalint1:~$
It is not started again, though, but we are close to it. Rather than
disabling services I'd propose going forward with fixing starting and
stopping services and disabling the ones in the image which are
installed by default but which collide with Windows ones.
>
> systectl calls are guarded and check for presense of
> /run/systemd/
> doesn't have the same guard as well. Given that on ubuntu, we do not
> support anything by systemd init, and thus should not be attempting to
> neither start nor stop init.d scripts directly without systemctl/systemd
> rediction.
>
> If we were to fix lsb-hook, we would fix this class of issues not only
> for the ebtables package, but for all packages that ship init.d scripts
> only without systemd units.
Please note that despite Ubuntu does not officially support running
other init systems the byproduct of still having init.d script is a
lot of very happy users running services in WSL and disabling the
init.d scripts would gain much for anyone.
>
> about ebtables init.d script, imho it is fine for it to continue to fail
> as it does now. Given that init.d script should not have been executed
> in WSL at all during package install/
As I wrote earlier ebtables clearly mismaps an error code which is
coming from WSL properly and this is why its init.d script is failing.
I'm OK with patching the script instead and it is absolutely OK to
have debhelper-added maintainer scripts to restart ebtables even on
WSL.
> I'd rather fix this class of upgrade issues, rather than hunting down
> every single package, given that WSL platform is what it is.
Not starting services is not solving a class of upgrade issues but
breaking Ubuntu on Windows for many use cases. The way forward is
fixing service restarts and moving forward with supporting systemd
services, too.
Microsoft does a good work in providing the environment for Ubuntu and
running upgrade tests finds almost all the issues. I found this
particular one, too, before Bionic's release but it was already
reported since last year and with the default install there were no
other packages failing to reinstall.
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https:/
>
> Title:
> ebtables cannot be upgraded from 2.0.10.4-3.5ubuntu2 to
> 2.0.10.
>
> Status in ebtables package in Ubuntu:
> Fix Released
> Status in ebtables source package in Trusty:
> In Progress
> Status in ebtables source package in Xenial:
> In Progress
> Status in ebtables source package in Artful:
> In Progress
> Status in ebtables source package in Bionic:
> In Progress
> Status in ebtables source package in Cosmic:
> Fix Released
>
> Bug description:
> [impact]
>
> ebtables cannot be upgraded on Ubuntu 18.04 for WSL.
>
> [test case]
>
> on a WSL installation that already has ebtables installed (most
> installations do), try to upgrade the package with apt or dpkg; its
> prerm script will fail, and prevent the upgrade.
>
> [regression potential]
>
> the ebtables init script is changed to never return an error code when
> called as 'stop', so anything that depends on the script returning an
> error code when 'stop' fails will no longer work correctly. However,
> nothing appears to use the 'stop' return value, besides the package's
> prerm script, which is what is causing the upgrade failure.
> Additionally, the prerm script is updated to ignore 'failed-upgrade'
> failures, to allow upgrading over the previous version(s).
>
> Finally note that the rpm-specific ebtables.spec file that is included
> in the package specifically ignores the 'stop' return value, i.e.:
>
> /sbin/service ebtables stop &>/dev/null || :
>
> [other info]
>
> note that ebtables is effectively dead upstream, so it's extremely
> unlikely there will be many more package updates/srus, except to fix
> minor bugs such as this.
>
> [original description]
>
> ebtables cannot be upgraded on Ubuntu 18.04 for WSL.
>
> apt-get upgrade fails with the following error:
>
> Reading package lists...
> Building dependency tree...
> Reading state information...
> Calculating upgrade...
> The following packages will be upgraded:
> ebtables
> 1 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
> Need to get 0 B/79.9 kB of archives.
> After this operation, 0 B of additional disk space will be used.
> (Reading database ...
> (Reading database ... 5%
> (Reading database ... 10%
> (Reading database ... 15%
> (Reading database ... 20%
> (Reading database ... 25%
> (Reading database ... 30%
> (Reading database ... 35%
> (Reading database ... 40%
> (Reading database ... 45%
> (Reading database ... 50%
> (Reading database ... 55%
> (Reading database ... 60%
> (Reading database ... 65%
> (Reading database ... 70%
> (Reading database ... 75%
> (Reading database ... 80%
> (Reading database ... 85%
> (Reading database ... 90%
> (Reading database ... 95%
> (Reading database ... 100%
> (Reading database ... 47381 files and directories currently installed.)
> Preparing to unpack .../ebtables_
> invoke-rc.d: could not determine current runlevel
> [31m* [39;49m Error: insufficient privileges to access the ebtables rulesets.
> invoke-rc.d: initscript ebtables, action "stop" failed.
> dpkg: warning: old ebtables package pre-removal script subprocess returned error exit status 1
> dpkg: trying script from the new package instead ...
> invoke-rc.d: could not determine current runlevel
> [31m* [39;49m Error: insufficient privileges to access the ebtables rulesets.
> invoke-rc.d: initscript ebtables, action "stop" failed.
> dpkg: error processing archive /var/cache/
> new ebtables package pre-removal script subprocess returned error exit status 1
> update-rc.d: warning: start and stop actions are no longer supported; falling back to defaults
> invoke-rc.d: could not determine current runlevel
> Errors were encountered while processing:
> /var/cache/
>
> See https:/
>
> To manage notifications about this bug go to:
> https:/
--
Balint Reczey
Ubuntu & Debian Developer