Using username 'qubes' causes installer to hang

[anoadragon453]

Qubes OS version (e.g., R3.2):

R3.2

---

Expected behavior:

• With a new installation providing 'qubes' as the user name should produce a new install with 'qubes' as my username

Actual behavior:

• The installer hangs at the end with a message similar to can't create user. user already exists.

Steps to reproduce the behavior:

• New Qubes R3.2 install
• At portion where you can set your username, enter 'qubes'
• Installer will go til the end until it hangs, making install impossible

General notes:

• The user should not be able to set 'qubes' as the username
• Perhaps instead we should show a warning/error message if qubes is entered into the username box, and advise the user to change it

[rustybird]

It probably breaks if any username that's already in /etc/passwd or /etc/group (adm audio avahi-autoipd bin cdrom cgred daemon dbus dialout dip disk floppy ftp games geoclue halt input kmem lightdm lock lp mail man mem nobody operator polkitd pulse pulse-access pulse-rt qubes root rtkit saslauth shutdown slocate ssh_keys sync sys systemd-bus-proxy systemd-journal systemd-network systemd-resolve systemd-timesync tape tty unbound user users utempter utmp video wheel yumex) is entered?

Maybe the dom0 username should just be hardcoded to user, which would be consistent with VMs and get rid of a bit of friction in the installer. (I also find it aesthetically pleasing, somehow.)

[rustybird]

It probably breaks if any username that's already in /etc/passwd or /etc/group (adm audio avahi-autoipd bin cdrom cgred daemon dbus dialout dip disk floppy ftp games geoclue halt input kmem lightdm lock lp mail man mem nobody operator polkitd pulse pulse-access pulse-rt qubes root rtkit saslauth shutdown slocate ssh_keys sync sys systemd-bus-proxy systemd-journal systemd-network systemd-resolve systemd-timesync tape tty unbound user users utempter utmp video wheel yumex) is entered?

Maybe the dom0 username should just be hardcoded to user, which would be consistent with VMs and get rid of a bit of friction in the installer. (I also find it aesthetically pleasing, somehow.)

[anoadragon453]

I too enjoy and currently use 'user' as the username as it makes scrubbing logs much less hassle.

…

On 05/06/2017 08:58 AM, Rusty Bird wrote: It probably breaks if any username that's already in |/etc/passwd| (adm avahi-autoipd bin daemon dbus ftp games geoclue halt lightdm lp mail nobody operator polkitd pulse root rtkit saslauth shutdown sync systemd-bus-proxy systemd-network systemd-resolve systemd-timesync unbound) is entered? Maybe the dom0 username should just be hardcoded to |user|, which would be consistent with VMs and get rid of a bit of friction in the installer. (I also find it aesthetically pleasing, somehow.) — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#2793 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ABR7mLfipDaOIrhWMrpl2DTf98reeqSWks5r3JiVgaJpZM4NSnpw>.

[anoadragon453]

I too enjoy and currently use 'user' as the username as it makes scrubbing logs much less hassle.

…

On 05/06/2017 08:58 AM, Rusty Bird wrote: It probably breaks if any username that's already in |/etc/passwd| (adm avahi-autoipd bin daemon dbus ftp games geoclue halt lightdm lp mail nobody operator polkitd pulse root rtkit saslauth shutdown sync systemd-bus-proxy systemd-network systemd-resolve systemd-timesync unbound) is entered? Maybe the dom0 username should just be hardcoded to |user|, which would be consistent with VMs and get rid of a bit of friction in the installer. (I also find it aesthetically pleasing, somehow.) — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#2793 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ABR7mLfipDaOIrhWMrpl2DTf98reeqSWks5r3JiVgaJpZM4NSnpw>.

[eduncan911]

Hello! I originally reported this here:

https://groups.google.com/forum/#!msg/qubes-users/HH2rK1Yt9Jc/0fO-ujP7BQAJ

And thanks to @anoadragon453, he brought it over to this git issue. 👍

--

Basically, two options on Expected Behavior:

A) With a new installation providing 'qubes' as the user name should produce a new install with 'qubes' as my username. (dom0 would use a user account instead).

or B) Installer should have Validation to not allow qubes on the username input.

Thanks!

[eduncan911]

Hello! I originally reported this here:

https://groups.google.com/forum/#!msg/qubes-users/HH2rK1Yt9Jc/0fO-ujP7BQAJ

And thanks to @anoadragon453, he brought it over to this git issue. 👍

--

Basically, two options on Expected Behavior:

A) With a new installation providing 'qubes' as the user name should produce a new install with 'qubes' as my username. (dom0 would use a user account instead).

or B) Installer should have Validation to not allow qubes on the username input.

Thanks!