Ubiquity not using password provided by UI

[Adam Szewczyk]

System: Skywave Linux Flashback Release: 4.3.0 - this is a Focal Remix live-cd based on Ubuntu 20.04.4 (https://skywavelinux.com/)

Ubiquity Version: 20.04.15.19

I want to install this live distro on VM (standalone HVM on Qubes OS - but I think this not make any difference). I installed ubiquity, ubiquity-casper, ubiquity-casper, ubiquity-frontend-gtk,ubiquity-frontend-gtk-panel and ubiquity-slideshow-ubuntu via apt after 'sudo apt-get update'. I also mounted booted iso as cdrom (using: 'sudo mount /dev/loop0 /media/cdrom' and 'sudo ls -s /media/cdrom /cdrom')

Then poceded installation as normal. When it comes to "Who are you?" page all fields without password was filed by some garbage/error "10 passwd/user-fulname-casper-backup doesn't exist".
I changed it to values desired by me and chose some simple password.

Instalaltion crashed on user-setup. After some dbugging I found out that $PASSWD variable that is used by setpassword() in user-setup-apply script file is set to "10 passwd/user-fulname-casper-backup doesn't exist" despite I was trying to set a new password via UI.

I also add question about that behavior to find some workaround (https://answers.launchpad.net/ubuntu/+source/ubiquity/+question/701995).
---
ProblemType: Bug
ApportVersion: 2.20.11-0ubuntu27.24
Architecture: amd64
CasperMD5CheckResult: skip
CurrentDesktop: GNOME-Flashback:GNOME
DistroRelease: Skywave Linux Flashback 4.3.0
InstallCmdLine: BOOT_IMAGE=/casper/vmlinuz boot=casper live-media-path=/casper initrd=/casper/initrd fsck.mode=skip threadirqs clocksource=tsc tsc=reliable elevator=mq-deadline ---
Package: ubiquity 20.04.15.19 [origin: Ubuntu]
PackageArchitecture: amd64
ProcEnviron:
 TERM=alacritty
 PATH=(custom, no user)
 XDG_RUNTIME_DIR=<set>
 LANG=en_US.UTF-8
 SHELL=/bin/bash
Tags: focal third-party-packages ubiquity-20.04.15.19
Uname: Linux 5.15.14-rt27-xanmod1 x86_64
UnreportableReason: This is not an official Skywave package. Please remove any third party package and try again.
UpgradeStatus: No upgrade log present (probably fresh install)
UserGroups: adm audio cdrom dialout dip lpadmin plugdev pulse-access sambashare sudo video
_MarkForUpload: True

[Chris Guiver (guiverc)]

Thank you for taking the time to report this bug and helping to make Ubuntu better. Please execute the following command only once, as it will automatically gather debugging information, in a terminal:

apport-collect 1976177

When reporting bugs in the future please use apport by using 'ubuntu-bug' and the name of the package affected. You can learn more about this functionality at https://wiki.ubuntu.com/ReportingBugs.

Please note, if this is not Ubuntu official media, the report will likely be closed as invalid, as it should be filed with the creator of the non-Ubuntu media.

[Adam Szewczyk (szewiec)]

apport information

[Adam Szewczyk (szewiec)]

apport information

[Adam Szewczyk (szewiec)]

apport information

[Adam Szewczyk (szewiec)]

apport information

[Adam Szewczyk (szewiec)]

apport information

[Adam Szewczyk (szewiec)]

apport information

[Adam Szewczyk (szewiec)]

I know that it is the problem with other Ubuntu based OS, but thing I address is bug with error handling in ubiquity itself. I think it should throw and error at the beginning when it got error when trying to preseed (I guess) the 'passwd/user-fullname' or in best case use password I chose in frontend. And now the behavior is that it try to use error string as a parameter for usermode and fails due the space character after '10'.

Other thing is that I can't find any presseed file on that ISO - there is preseed directory but it is empty. Also I'm not see any 'file=' parameters in boot menu. So what is the source of all those preseeded values?

[Adam Szewczyk (szewiec)]

Ok, I read the logs once more. The error string for usermod was in fact "10 passwd/user-password-crypted-casper-backup doesn't exist" so it is the other field that I provide from frontend which was "passwd/user-password". So the filed is in fact missing? But error handling here still can be handy.

[Ubuntu Foundations Team Bug Bot (crichton)]

Thank you for taking the time to report this bug and helping to make Ubuntu better. Reviewing your log files attached to this bug report it seems that there is a problem with the disk to which you are trying to install Ubuntu. I'd recommend performing a back up of your existing operating system and then investigating the situation. Measures you might take include checking cable connections for your disks and using software tools to investigate the health of your hardware. In the event that is is not in fact an error with your hardware please set the bug's status back to New. Thanks and good luck!

[This is an automated message. I apologize if it reached you inappropriately; please just reply to this message indicating so.]

[Adam Szewczyk (szewiec)]

This is a virtual drive. And I was able to install focal and jammy on the same setup normally.

[Adam Szewczyk (szewiec)]

Once again, steps that I performed:

1.) boot VM from skywavelinux-4.3.0-flashback.iso
2.) setup internet connection manually
3.) sudo apt-get update
4.) sudo apt-get install ubiquity ubiquity-frontend-gtk ubiquity-frontend-gtk-panel ubiquity-slideshow-ubuntu ubiquity-casper
5.) sudo mount /dev/loop0 /media/cdrom
6.) sudo ls -s /media/cdrom /cdrom
7.) ubiquity -d gtk_ui
8.) Try to perform normal graphical installation (with erase and install option)

I mount loop0 since without that there was an error with adding cdrom to apt.

When I comment out usermode command from user-setup-apply Ubiquity report successful installation.

[Adam Szewczyk (szewiec)]

Check once again. I can install jammy on that VM without touching anything in the VM settings. Just boot, proceed all unnecessary for normal Ubuntu steps from my case, and start ubiquity the same way. Installation was successful but in logs there are all that access denied messages. I can upload that logs if that can help. Jammy booted from virtual drive and seems to work.

[Chris Guiver (guiverc)]

The media used is not a Ubuntu ISO.

For this bug to be explored, an official Ubuntu ISO (eg. 20.04.4) would need to be used, to rule out issues created by the unsupported (by Ubuntu) third party ISO used in the initial filing.

I've marked this bug report invalid. If you believe this is a ubiquity bug, please use a Ubuntu ISO to confirm the issue occurs there, and file another bug report using `ubuntu-bug ubiquity` if the problem occurs. You can provide a link to this report so additional details noted here can also be used in locating & providing a fix.

Thank you for taking the time to report this bug and helping to make Ubuntu better.

[Adam Szewczyk (szewiec)]

Ok, don't know which package produce that value in debconf passwd/user-password-crypted but when I reset it using debconf-communicate, installation was completed. Unfortunately system not booted successfully, so I will dig deeper in the future. Maybe it's not a bug then, but maybe some validation of passwd/user-password-crypted can make ubiquity more robust.