[Lubuntu] "Install Lubuntu" fails with several commands not found and permission denied

[Leó Kolbeinsson]

Test Case:
1. Boot Lubuntu Desktop
2. On the boot menu select "Install Ubuntu"
3. In ubiquity proceed with the installation and keep the default settings

ProblemType: Bug
DistroRelease: Ubuntu 18.04
Package: ubiquity 18.04.3
ProcVersionSignature: Ubuntu 4.15.0-10.11-generic 4.15.3
Uname: Linux 4.15.0-10-generic x86_64
ApportVersion: 2.20.8-0ubuntu10
Architecture: amd64
CasperVersion: 1.389
Date: Wed Mar 7 21:42:12 2018
InstallCmdLine: file=/cdrom/preseed/lubuntu.seed boot=casper only-ubiquity initrd=/casper/initrd.lz quiet splash ---
JournalErrors:
 Error: command ['journalctl', '-b', '--priority=err', '--lines=1000'] failed with exit code 1: Hint: You are currently not seeing messages from other users and the system.
       Users in groups 'adm', 'systemd-journal' can see all messages.
       Pass -q to turn off this notice.
 No journal files were opened due to insufficient permissions.
LiveMediaBuild: Lubuntu 18.04 LTS "Bionic Beaver" - Alpha amd64 (20180306.1)
ProcEnviron:
 LANGUAGE=en_US.UTF-8
 PATH=(custom, no user)
 XDG_RUNTIME_DIR=<set>
 LANG=en_US.UTF-8
 LC_NUMERIC=C.UTF-8
SourcePackage: ubiquity
UpgradeStatus: No upgrade log present (probably fresh install)

[Ubuntu QA Website (ubuntuqa)]

This bug has been reported on the Ubuntu ISO testing tracker.

A list of all reports related to this bug can be found here:
http://iso.qa.ubuntu.com/qatracker/reports/bugs/1754174

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[Jean-Baptiste Lallement (jibel)]

Thanks for your report. I cannot reproduce this issue with latest Lubuntu or Ubuntu. Could you please describe the exact steps to reproduce it?

Thanks.

[Leó Kolbeinsson (leok)]

I just used the default install (English etc) . When the installer was
finished copying the files .. it crashed. Maybe I should download again
and retry.

regards Leo

On 8.3.2018 08:59, Jean-Baptiste Lallement wrote:
> Thanks for your report. I cannot reproduce this issue with latest
> Lubuntu or Ubuntu. Could you please describe the exact steps to
> reproduce it?
>
> Thanks.
>
> ** Changed in: ubiquity (Ubuntu)
> Status: Confirmed => Incomplete
>

[Leó Kolbeinsson (leok)]

same problem installing in Windows 10 Hyper-V virtual machine.

[Adam Conrad (adconrad)]

Reproduced in kvm/qemu by booting to the installer from the boot menu. Can't reproduce by booting to the desktop first and clicking the install icon.

The first obvious bug (assumption that py2 exists in the target when it doesn't) is glaringly obvious in the code. Not sure yet how that would cause all the errors that follow, but it just might be that one thing that needs fixing.

[ԜаӀtеr Ⅼарсһуnѕkі (wxl)]

Adam, I'm curious about your Python statement. This only fails when running Ubiquity directly from GRUB. Loading the live system and then running Ubiquity works fine. Also, Ubiquity fails to fail for any other flavours.

Things start going south in syslog here:

Mar 7 21:40:40 lubuntu ubiquity[1244]: switched to page partman
Mar 7 21:40:44 lubuntu ubiquity: /bin/autopartition: 292: /bin/autopartition:
Mar 7 21:40:44 lubuntu ubiquity: pvs: not found
Mar 7 21:40:44 lubuntu ubiquity:
Mar 7 21:40:47 lubuntu ubiquity[1244]: debconffilter_done: ubi-partman (current: ubi-partman)
Mar 7 21:40:47 lubuntu ubiquity[1244]: Step_before = stepPartAsk

On a successful install from the live system we find a little bit different behavior:

Mar 11 01:58:43 lubuntu ubiquity[2161]: switched to page partman
Mar 11 01:58:55 lubuntu ubiquity[2161]: debconffilter_done: ubi-partman (current: ubi-partman)
Mar 11 01:58:55 lubuntu ubiquity[2161]: Step_before = stepPartAsk

Noting that /bin/autopartition is a script, I went looking for line 292, but it wasn't there. It does, however source several other scripts in /lib/partman/lib. Looking for only files with a line number 292 that includes "pvs" in it, I found:

lib/lvm-base.sh: if $(pvs --noheadings --nosuffix -o pv_name | grep -q "$device"); then

Seems like pvs is a variable created from enumerating the partman devices and looking for ones with lvm method.

I'm not sure what this all means yet, but this sure is weird.

[sudodus (nio-wiklund)]

Testing on bare metal in my Toshiba laptop

http://www.toshiba.se/laptops/satellite-pro/c850/satellite-pro-c850-19w/

I can install Lubuntu via a USB live system cloned from the current bionic-desktop-amd64.iso file, if I select 'Try Lubuntu'.

But the installer fails, if I select 'Install Lubuntu' (go directly to the installer). I was kicked of the installer, and prompted to create a bug report, which I did not. Instead I selected 'affects me too' here.

So this bug does not only affect testing in virtual machines, but also bare metal in a computer that usually works well with Ubuntu based operating systems.

[Ron Mitchell (rm2892)]

Why am I getting these e-mails? I have not been part of the community for years

Please unsubscribe me.

Ron Mitchell
rm2892@gmail. com

Sent from my iPhone

> On Mar 11, 2018, at 4:15 AM, sudodus <email address hidden> wrote:
>
> Testing on bare metal in my Toshiba laptop
>
> http://www.toshiba.se/laptops/satellite-pro/c850/satellite-pro-c850-19w/
>
> I can install Lubuntu via a USB live system cloned from the current
> bionic-desktop-amd64.iso file, if I select 'Try Lubuntu'.
>
> But the installer fails, if I select 'Install Lubuntu' (go directly to
> the installer). I was kicked of the installer, and prompted to create a
> bug report, which I did not. Instead I selected 'affects me too' here.
>
> So this bug does not only affect testing in virtual machines, but also
> bare metal in a computer that usually works well with Ubuntu based
> operating systems.
>
> --
> You received this bug notification because you are a member of Lubuntu
> Packages Team, which is subscribed to the bug report.
> https://bugs.launchpad.net/bugs/1754174
>
> Title:
> [Lubuntu] "Install Lubuntu" fails with several commands not found and
> permission denied
>
> Status in ubiquity package in Ubuntu:
> Confirmed
>
> Bug description:
> Test Case:
> 1. Boot Lubuntu Desktop
> 2. On the boot menu select "Install Ubuntu"
> 3. In ubiquity proceed with the installation and keep the default settings
>
>
> ProblemType: Bug
> DistroRelease: Ubuntu 18.04
> Package: ubiquity 18.04.3
> ProcVersionSignature: Ubuntu 4.15.0-10.11-generic 4.15.3
> Uname: Linux 4.15.0-10-generic x86_64
> ApportVersion: 2.20.8-0ubuntu10
> Architecture: amd64
> CasperVersion: 1.389
> Date: Wed Mar 7 21:42:12 2018
> InstallCmdLine: file=/cdrom/preseed/lubuntu.seed boot=casper only-ubiquity initrd=/casper/initrd.lz quiet splash ---
> JournalErrors:
> Error: command ['journalctl', '-b', '--priority=err', '--lines=1000'] failed with exit code 1: Hint: You are currently not seeing messages from other users and the system.
> Users in groups 'adm', 'systemd-journal' can see all messages.
> Pass -q to turn off this notice.
> No journal files were opened due to insufficient permissions.
> LiveMediaBuild: Lubuntu 18.04 LTS "Bionic Beaver" - Alpha amd64 (20180306.1)
> ProcEnviron:
> LANGUAGE=en_US.UTF-8
> PATH=(custom, no user)
> XDG_RUNTIME_DIR=<set>
> LANG=en_US.UTF-8
> LC_NUMERIC=C.UTF-8
> SourcePackage: ubiquity
> UpgradeStatus: No upgrade log present (probably fresh install)
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/1754174/+subscriptions

[Adam Conrad (adconrad)]

Okay, so the inability to find lvm2 and python2 commands seems like a red herring (should probably be cleaned up for nicer logs, but probably not the issue here) as they also show up in a successful log. For some reason, though, it looks like we're dropping privs and can't do some things as root that we should be doing.

[Adam Conrad (adconrad)]

For reference, this is a log from a successful installation (done from the live session).

[Jb (jebsolutions)]

Lubuntu Bionic Desktop Daily 20180324 gets a bit farther.

Partitioning works (i.e. no pvs errors).

After this it crashes with various problems in the log.

Mar 24 17:04:27 lubuntu ubiquity: cannot create directory ‘/target/var’ Permission denied
- Note: may be a red herring as /target/var does exist

Mar 24 17:05:38 lubuntu ubiquity: failed to run command ‘pyversions’
- Note: no pyversions command installed in the live os, or in the chroot
- I tried to sudo apt-get install python-minimal in the live os but this didn't make a difference

Mar 24 17:05:38 lubuntu /plugininstall.py: log-output -t ubiquity chroot /target py3compile -p python3 /usr/share/python3/
Mar 24 17:05:39 lubuntu ubiquity: mount:
Mar 24 17:05:39 lubuntu ubiquity: only root can use "--types" option
Mar 24 17:05:39 lubuntu ubiquity:
Mar 24 17:05:39 lubuntu /plugininstall.py: log-output -t ubiquity chroot /target mount -t proc proc /proc
Mar 24 17:05:39 lubuntu ubiquity: mount:
Mar 24 17:05:39 lubuntu ubiquity: only root can use "--types" option

[Steve Langasek (vorlon)]

I don't understand why this bug is happening. Context:
- when run from the live session by clicking on the icon, ubiquity runs under sudo and runs entirely as root. this succeeds.
- when run from the "Install Ubuntu" option in the splash screen, ubiquity starts as root with PKEXEC_UID set in the environment telling it the uid to drop privileges to; and drops privileges to run as non-root most of the time.
- there is code in ubiquity which is supposed to raise privileges back to root before calling any operations that require root.
- the "Install Ubuntu" option works from both Ubuntu 18.04 beta2 and from Lubuntu 17.10.1. Only in Lubuntu 18.04 beta2 is it broken.
- several of the commands which are failing in the logs on Lubuntu due to permissions are operations that can only be run via 'chroot' which is a privileged operation - so the chroot succeeds, and then afterwards the commands lack permissions to operate on the target filesystem?!
- none of the changes to the ubiquity codebase since 17.10 seem to be relevant.
- the code around the point at which the install fails - basically when trying to run the first installer plugin (the language plugin) via scripts/plugininstall.py - doesn't include any privilege-handling code. So there seems to be an assumption that this code is running as root already. Clearly this assumption proves invalid, but I'm unclear where this is supposed to be happening.

[Steve Langasek (vorlon)]

Also, just confirmed that when running from the live session, PKEXEC_UID is not set (which makes sense, we don't execute under pkexec anymore, in Ubuntu 16.10 and later) and the installer therefore does not drop privileges. So it's altogether reasonable that we don't see any permissions problems in this install path.

The part that doesn't make sense is why 'Install Lubuntu' has permissions errors when 'Install Ubuntu' does not.

[Steve Langasek (vorlon)]

It appears the following one-liner patch fixes the permissions problem in Lubuntu, which is caused by /usr/share/ubiquity/plugininstall.py being called without elevated privileges.

=== modified file 'ubiquity/filteredcommand.py'
--- ubiquity/filteredcommand.py 2013-02-19 11:33:07 +0000
+++ ubiquity/filteredcommand.py 2018-04-05 22:14:08 +0000
@@ -193,6 +193,8 @@
                 # default action or else they won't notice if the
                 # debconffilter dies.
                 signal.signal(signal.SIGPIPE, signal.SIG_DFL)
+ # Regain root.
+ misc.regain_privileges()

             ret = subprocess.call(self.command, preexec_fn=subprocess_setup)
             if ret != 0:

It is not clear to me if this is correct, or why plugininstall.py is handled via this code path on Lubuntu when it evidently is not on other flavors (or alternatively: why this code is called with privileges already raised on all other flavors).

[Fritz Hudnut (este-el-paz)]

@Steve:

Just to add my "color commentary" . . . non-technical experience . . . in
my install of Lubuntu 18 . . . I got the "crash report" when it got to
around the grub-install . . . and the installer quit . . . but, because I
was multi-booting I already had a grub install and on reboot the grub
window opened and the Lubuntu choice was up top . . . and the Lubuntu
system booted up . . . . This was after the bug report process, etc.

In comparison, I did a U-MATE 18 install a few days after the Lu install .
. . and in U-MATE no errors or crash reports happened in the install, but
on reboot the log in window loads, but putting my password in, just cycles
to a black screen and then back to the log in window . . . . I'm thinking
there is something in "the installer" that doesn't seem to be getting
"everything" installed . . . ?? In the U-MATE I can log into a TTY and run
update/upgrade . . . think I've done 4 installs on it by now . . . problem
persists . . . . The "connection"?? Both are 18.04 distros . . . .

F

[lotuspsychje (lotuspsychje)]

confirming on lubuntu 32bit iso daily 18.04 @ 7/4/2018
ubiquity crashed on the end of setup

[Ming (mingpan)]

I can confirm that this bug still exists in the Final Beta. I have no problem re-installing Lubuntu 17.10.

[Colin Watson (cjwatson)]

I tried to reproduce this a couple of days ago with a current daily in order to debug it, and couldn't; furthermore, some developers who'd previously been able to reproduce this bug reported that it was now working fine for them. This is somewhat unsatisfactory since we don't know exactly what made the bug go away; but can anyone still reproduce this with a current daily build (20180418 or newer) of Lubuntu bionic?

[ԜаӀtеr Ⅼарсһуnѕkі (wxl)]

Confirmed on today's image. As if the bug wasn't strange enough, it's
even more strange that it just disappeared. This is not the kind of
thing that makes me sleep well at night. In any case, I'm inclined to
call this incomplete until it pops up again unless there is suggestion
otherwise.

[sudodus (nio-wiklund)]

I tested 'Install Lubuntu' with the current daily iso file

bionic-desktop-amd64.iso (dated April 20)

in my Toshiba laptop

http://www.toshiba.se/laptops/satellite-pro/c850/satellite-pro-c850-19w/

The installer worked all the way (I used 'Something else' and installed into an old partition.)

-o-

At the end I had to reboot with SysRq REISUB, but that is another problem (I think a race condition, that was gone for some year, but reappeared during the development of Bionic).

[jfath (jaf)]

Also gone on my system. 4/20 daily installed without error where last beta had consistently failed.

[Leó Kolbeinsson (leok)]

Same here. No longer a problem after 4/18 and 4/19 daily installs.