On Wed, Jun 20, 2018 at 2:11 PM Dimitri John Ledkov 🌈 <[email protected]> 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/postrm.d/zz-update-grub skips updating grub if 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://archive.ubuntu.com/ubuntu bionic-updates/main amd64 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_2.4.29-1ubuntu4.1_amd64.deb ... 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/system, I'm confused as to why the lsb-hook on ubuntu > 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/removal/upgrade anyway. 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://bugs.launchpad.net/bugs/1774120 > > Title: > ebtables cannot be upgraded from 2.0.10.4-3.5ubuntu2 to > 2.0.10.4-3.5ubuntu2.18.04.1 on WSL > > 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_2.0.10.4-3.5ubuntu2.18.04.1_amd64.deb ... > 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/apt/archives/ebtables_2.0.10.4-3.5ubuntu2.18.04.1_amd64.deb > (--unpack): > 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/apt/archives/ebtables_2.0.10.4-3.5ubuntu2.18.04.1_amd64.deb > > See https://github.com/Microsoft/WSL/issues/1761 > > To manage notifications about this bug go to: > https://bugs.launchpad.net/ubuntu/+source/ebtables/+bug/1774120/+subscriptions -- Balint Reczey Ubuntu & Debian Developer -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1774120 Title: ebtables cannot be upgraded from 2.0.10.4-3.5ubuntu2 to 2.0.10.4-3.5ubuntu2.18.04.1 on WSL To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/ebtables/+bug/1774120/+subscriptions -- ubuntu-bugs mailing list [email protected] https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
