Unattended installation ended with error

[serock]

I tried an unattended installation of Leap 16.0 using the agama-installer.x86_64-10.0.0-openSUSE-Build27.7.iso in VirtualBox 7.0.18 on Leap 15.6. At the end of the installation, an error was displayed:

The effective profile.json is attached with the user and password info omitted.

The end of the agama.out.log had:

Nov 08 09:08:01 agama agamactl[3007]: [INFO]: software: Commit result [688, [], [], [], []]
Nov 08 09:08:01 agama agamactl[2991]: [INFO]: manager: Configure the system (3/3)
Nov 08 09:08:02 agama agamactl[39077]: /mnt: /etc/locale.conf written.
Nov 08 09:08:02 agama agamactl[39077]: /mnt: /etc/vconsole.conf written.
Nov 08 09:08:02 agama agamactl[39077]: /mnt: /etc/localtime written
Nov 08 09:08:15 agama agamactl[2989]: Loading mocked module /usr/lib64/ruby/gems/3.3.0/gems/agama-yast-10.devel407/lib/agama/dbus/y2dir/modules/InstFunctions.rb
Nov 08 09:08:20 agama agamactl[2991]: [INFO]: manager: Install phase done

The installation of Leap 16.0 seemed to be successful; I was able to reboot the virtual machine and login to Leap 16.0.

[imobachgs]

Thanks for the report. The installation was finished successfully, but the web UI crashed. We will try to reproduce the problem.

[imobachgs]

I was able to reproduce the problem using bug.json. It seems to related to the storage layer, as I see two failing requests to api/storage/proposal/settings and api/storage/proposal/actions.

I am attaching some debugging information:

• Agama logs
• Browser console logs

[imobachgs]

Actually, if you remove the encryption password from bug.json and try to import that profile (from the CLI), the storage proposal will fail and the UI won't handle it properly.

[joseivanlopez]

I haven't checked this yet. BTW, removing the encryption password should report an error because the password is required by the schema. Is Agama validating the schema while importing the profile?

[imobachgs]

Sorry, I did not explain it well. It is not removing but setting the password to an empty string (which is "valid"). However, in my latest test I was unable to reproduce that problem.

However, the original issue still applies.

[teclator]

Should be fixed by #1793, thanks for the report!