User creation causes installation to have an "unknown error"

The 1000+ installations successfully happen, but upon creating a user, it throws a “unknown error” and has me either debug/report, or quit.

Versions I have tried: 4.0.4-rc2, 4.0.4-rc1, 4.0.3

I would like to end with 4.0.3, but wanted to see if either of the other versions would work.
I have verified the download files, and just to try, even though I know after verifying the files this makes no logical sense, I have tried downloading via other mirrors.

I have tried flashing with Rufus and Etcher, I have used 4 different usbs, of which 2 are different brands, and 3 are different models. All are 64gb. only one is a 3.0, however they all attempt to boot, so I don’t think that is an issue. 3/4 of the flash drives are SanDisk, so I don’t believe it is a brand issue. If it was, I would think the install on the hard drive or SSD would work.

I have tried with a 256gb hard drive, and a 128gb SSD. I have tried with 2 different laptops, one of which is a Dell Latitude E6230, which the HCL says is completely compatible. I have insured all virtualization settings are turned on. I have tried using legacy boot, UEFI, and all combinations of one of those, neither, or both.

I read through all the documentation on trouble shooting, and while I do not understand it all, I do not see a single mention on the user creation causing an error. I also could not find anything related on github or reddit. For all 3 versions, the install works perfectly until I need to create the Qubes user. all 1000+ installations work, and it says to complete USER CREATION. after creating a user, it says an unknown error forces me to close or report the issue. I have tried waiting until all the downloads complete then creating the user, and I have tried create the user while the downloads download.

Just as another piece of info, I am attempting these installs offline. The documentation says this is fine, but just wanted to give all info I could.

This is the only thing that looks odd to me when attempting to install qubes.(4.0.4-RC2 was used for this test run, for me to get all the text that seemed like it could be helpful.)
when it first boots it shows these two lines:

[   14.814201] racut-pre-udev[461]: rpc.idmap: conf_reinit: open ("(null)",0_
RONLY) failed
``[   14.417355] racut-pre-udev[461]: rpc.idmap: conf_reinit: open ("(null)",0_
RONLY) failed

`
while Qubes verifies the files, it shows:

[   14.814201] racut-pre-udev[461]: rpc.idmap: conf_reinit: open ("(null)",0_
RONLY) failed
[   14.417355] racut-pre-udev[461]: rpc.idmap: conf_reinit: open ("(null)",0_
RONLY) failed
[   17.417355] dracut-initqueue[639]: mount: /dev/sdb is write-protected, mounting read-only
/dev/sdb:   9c5d4f2b30030cb7b1eecc15a1178701
Fragment sums: e93e787cf1fb65ce35ddc9b428821586f61cf595dc7c120194d144b9d488
Fragment count: 20
Supported ISO: no
Checking:(goes up to 100%)

It finishes and everything says [ OK ]

This is what I see upon trying to run Qubes, which I do not expect to work due to it erroring out after trying to create a user:

[FAILED] Failed to start Load Kernel Modules.
See 'systemctl status systemd-modules-load.service' fo details.

Then everything else says [OK]
I enter passphrase
All [OK] until

(xfwm4:3505): GLib-CRITICAL **: g_str_has_prefix: assertion 'prefix! NULL' failed

(xfwm4:3505): xfwm4-WARNING **: the property '/general/double_click_distance' of type int is not supported

(xfwm4:3505): xfwm4-WARNING **: Another compositing manager is running on screen 0

(xfwm4:3505): xfwm4-WARNING **: Failed to connect to session manager: Failed to connect to the session manager: SESSION_MANAGER enviroment variable not defined
/bin/xinit: connection to X server lost

waiting for X server to shut down(II) Server terminated successfully (0). Closing log file.

Removed /etc/systemd/system/multi-user.target.wants/initial-setup.service.
removed /etc/systemd/graphical.target.wants/initial-setup.service.
[ OK ] started Initial setup configuration progam.
[FAILED] Failed to start Qubes OS daemon
See 'systemctl status qubesd.service for details.

It then continues to try to start the Qubes OS daemon over and over, and never works. If I hit debug, in response to it telling me to report or quit, it says:

(anacona:1344): Gtk-WARNING **: Allocating size to pyanaconda+ui+gui+MainWindow 0x647ae50442a0 without calling gtk_widget_get_preferred_width/height(). How does the code know the size to allocate?
(anacona:1344): Gtk-WARNING **: Allocating size to pyanaconda+ui+gui+MainWindow 0x647ae50442a0 without calling gtk_widget_get_preferred_width/height(). How does the code know the size to allocate?
(anacona:1344): Gtk-WARNING **: Allocating size to pyanaconda+ui+gui+MainWindow 0x647ae50442a0 without calling gtk_widget_get_preferred_width/height(). How does the code know the size to allocate?
(anacona:1344): Gtk-WARNING **: Allocating size to pyanaconda+ui+gui+MainWindow 0x647ae50442a0 without calling gtk_widget_get_preferred_width/height(). How does the code know the size to allocate?
(anacona:1344): Gtk-WARNING **: Allocating size to pyanaconda+ui+gui+MainWindow 0x647ae50442a0 without calling gtk_widget_get_preferred_width/height(). How does the code know the size to allocate?
(anaconda:1344): Gtk-WARNING **: Attempt to load unknown IM context type ''
(anaconda:1344): Gtk-WARNING **: Attempt to load unknown IM context type ''
(anaconda:1344): Gtk-WARNING **: Attempt to load unknown IM context type ''
(anaconda:1344): Gtk-WARNING **: Attempt to load unknown IM context type ''
Running in chroot, ignoring request.
BDB2053 Freeing read locks for locker 0x1: 2199/140530714089216
BDB2053 Freeing read locks for locker 0x3: 2199/140530714089216
BDB2053 Freeing read locks for locker 0x4: 2199/140530714089216
BDB2053 Freeing read locks for locker 0x5: 2199/140530714089216
BDB2053 Freeing read locks for locker 0x6: 2199/140530714089216
BDB2053 Freeing read locks for locker 0x7: 2199/140530714089216
BDB2053 Freeing read locks for locker 0x8: 2199/140530714089216
BDB2053 Freeing read locks for locker 0x9: 2199/140530714089216
BDB2053 Freeing read locks for locker 0xa: 2199/140530714089216
BDB2053 Freeing read locks for locker 0xb: 2199/140530714089216
BDB2053 Freeing read locks for locker 0xc: 2199/140530714089216
BDB2053 Freeing read locks for locker 0xd: 2199/140530714089216
BDB2053 Freeing read locks for locker 0xe: 2199/140530714089216
BDB2053 Freeing read locks for locker 0xf: 2199/140530714089216
BDB2053 Freeing read locks for locker 0x10: 2199/140530714089216
BDB2053 Freeing read locks for locker 0x11: 2199/140530714089216
BDB2053 Freeing read locks for locker 0x12: 2199/140530714089216
BDB2053 Freeing read locks for locker 0x13: 2199/140530714089216
BDB2053 Freeing read locks for locker 0x14: 2199/140530714089216

Entering debugger. . .
use 'continue' command to quit the debugger and get back to the main window
>/usr/lib64/python3.5/site-packages/pyanaconda/users.py(379)createUser()
->raise OSError("Unable to create user %s: status=%s" % (user_name, status))
(pdb)

I am new to this, so I will have to request any help be beginner friendly. Thank you in advance, let me know If I can provide any more help.

1 Like

FIXED. The solution is discussed here
In short, for whatever reason, my password being “1024” caused the issues. It was only 1024 for my test install, after which I would be using a diceware password. I switched to a diceware password and first try cleanly installed. If it would be of help I can try and replicate it. It did not work across various usernames with password “1024”.

1 Like

Hi @HelpQ202,

Just an idea, you shouldn’t choose a username which is already present in /etc/passwd or /etc/group. The installer doesn’t test all the cases. So root, adm, daemon, … will fail.

See this below issue with the rustybird’s comment:

Am I on the right way with this idea? Or not?

Edit: I answered too late, you already got the solution…

1 Like

I appreciate your time anyway, and hopefully the solution you proposed will help someone who stumbles upon this thread later!

1 Like

I suspect the problem is related to this, and it is can also be seen in 4.0.4 rc-2
https://bugzilla.redhat.com/show_bug.cgi?id=1491006