I have confirmed that Fedora-Workstation-Live-x86_64-39-20230824.n.0.iso installs successfully without `inst.sdboot`.

Original title: WebUI: Installation of the system failed: Configuring storage org.fedoraproject.Anaconda.Error: [Errno 17] File exists: '/proc/self/mounts' -> '/mnt/sysroot/etc/mtab'

Created attachment 1985199 [details]
gtk interface anaconda error log with `inst.sdboot` enabled

(In reply to Jonathan Steffan from comment #3)
> Created attachment 1985199 [details]
> gtk interface anaconda error log with `inst.sdboot` enabled

This was created with Fedora-Workstation-Live-39-20230823.n.0 and `inst.sdboot`. The same image without `inst.sdboot` works as expected.

So it seems that we are calling a tool which is not yet packaged in Fedora :(

The error from the logs:
```
Aug 24 23:56:38 localhost-live org.fedoraproject.Anaconda.Modules.Storage[2902]: During handling of the above exception, another exception occurred:
Aug 24 23:56:38 localhost-live org.fedoraproject.Anaconda.Modules.Storage[2902]: Traceback (most recent call last):
Aug 24 23:56:38 localhost-live org.fedoraproject.Anaconda.Modules.Storage[2902]:   File "/usr/lib/python3.12/site-packages/dasbus/server/handler.py", line 455, in _method_callback
Aug 24 23:56:38 localhost-live org.fedoraproject.Anaconda.Modules.Storage[2902]:     result = self._handle_call(
Aug 24 23:56:38 localhost-live org.fedoraproject.Anaconda.Modules.Storage[2902]:              ^^^^^^^^^^^^^^^^^^
Aug 24 23:56:38 localhost-live org.fedoraproject.Anaconda.Modules.Storage[2902]:   File "/usr/lib/python3.12/site-packages/dasbus/server/handler.py", line 265, in _handle_call
Aug 24 23:56:38 localhost-live org.fedoraproject.Anaconda.Modules.Storage[2902]:     return handler(*parameters, **additional_args)
Aug 24 23:56:38 localhost-live org.fedoraproject.Anaconda.Modules.Storage[2902]:            ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Aug 24 23:56:38 localhost-live org.fedoraproject.Anaconda.Modules.Storage[2902]:   File "/usr/lib64/python3.12/site-packages/pyanaconda/modules/common/task/task_interface.py", line 114, in Finish
Aug 24 23:56:38 localhost-live org.fedoraproject.Anaconda.Modules.Storage[2902]:     self.implementation.finish()
Aug 24 23:56:38 localhost-live org.fedoraproject.Anaconda.Modules.Storage[2902]:   File "/usr/lib64/python3.12/site-packages/pyanaconda/modules/common/task/task.py", line 173, in finish
Aug 24 23:56:38 localhost-live org.fedoraproject.Anaconda.Modules.Storage[2902]:     thread_manager.raise_if_error(self._thread_name)
Aug 24 23:56:38 localhost-live org.fedoraproject.Anaconda.Modules.Storage[2902]:   File "/usr/lib64/python3.12/site-packages/pyanaconda/core/threads.py", line 171, in raise_if_error
Aug 24 23:56:38 localhost-live org.fedoraproject.Anaconda.Modules.Storage[2902]:     raise exc_info[1]
Aug 24 23:56:38 localhost-live org.fedoraproject.Anaconda.Modules.Storage[2902]:   File "/usr/lib64/python3.12/site-packages/pyanaconda/core/threads.py", line 280, in run
Aug 24 23:56:38 localhost-live org.fedoraproject.Anaconda.Modules.Storage[2902]:     threading.Thread.run(self)
Aug 24 23:56:38 localhost-live org.fedoraproject.Anaconda.Modules.Storage[2902]:   File "/usr/lib64/python3.12/threading.py", line 989, in run
Aug 24 23:56:38 localhost-live org.fedoraproject.Anaconda.Modules.Storage[2902]:     self._target(*self._args, **self._kwargs)
Aug 24 23:56:38 localhost-live org.fedoraproject.Anaconda.Modules.Storage[2902]:   File "/usr/lib64/python3.12/site-packages/pyanaconda/modules/common/task/task.py", line 94, in _thread_run_callback
Aug 24 23:56:38 localhost-live org.fedoraproject.Anaconda.Modules.Storage[2902]:     self._task_run_callback()
Aug 24 23:56:38 localhost-live org.fedoraproject.Anaconda.Modules.Storage[2902]:   File "/usr/lib64/python3.12/site-packages/pyanaconda/modules/common/task/task.py", line 107, in _task_run_callback
Aug 24 23:56:38 localhost-live org.fedoraproject.Anaconda.Modules.Storage[2902]:     self._set_result(self.run())
Aug 24 23:56:38 localhost-live org.fedoraproject.Anaconda.Modules.Storage[2902]:                      ^^^^^^^^^^
Aug 24 23:56:38 localhost-live org.fedoraproject.Anaconda.Modules.Storage[2902]:   File "/usr/lib64/python3.12/site-packages/pyanaconda/modules/storage/bootloader/installation.py", line 139, in run
Aug 24 23:56:38 localhost-live org.fedoraproject.Anaconda.Modules.Storage[2902]:     install_boot_loader(storage=self._storage)
Aug 24 23:56:38 localhost-live org.fedoraproject.Anaconda.Modules.Storage[2902]:   File "/usr/lib64/python3.12/site-packages/pyanaconda/modules/storage/bootloader/utils.py", line 215, in install_boot_loader
Aug 24 23:56:38 localhost-live org.fedoraproject.Anaconda.Modules.Storage[2902]:     storage.bootloader.write()
Aug 24 23:56:38 localhost-live org.fedoraproject.Anaconda.Modules.Storage[2902]:   File "/usr/lib64/python3.12/site-packages/pyanaconda/modules/storage/bootloader/efi.py", line 136, in write
Aug 24 23:56:38 localhost-live org.fedoraproject.Anaconda.Modules.Storage[2902]:     self.write_config()  # pylint: disable=no-member
Aug 24 23:56:38 localhost-live org.fedoraproject.Anaconda.Modules.Storage[2902]:     ^^^^^^^^^^^^^^^^^^^
Aug 24 23:56:38 localhost-live org.fedoraproject.Anaconda.Modules.Storage[2902]:   File "/usr/lib64/python3.12/site-packages/pyanaconda/modules/storage/bootloader/efi.py", line 234, in write_config
Aug 24 23:56:38 localhost-live org.fedoraproject.Anaconda.Modules.Storage[2902]:     super().write_config()
Aug 24 23:56:38 localhost-live org.fedoraproject.Anaconda.Modules.Storage[2902]:   File "/usr/lib64/python3.12/site-packages/pyanaconda/modules/storage/bootloader/systemd.py", line 121, in write_config
Aug 24 23:56:38 localhost-live org.fedoraproject.Anaconda.Modules.Storage[2902]:     rc = util.execWithRedirect(
Aug 24 23:56:38 localhost-live org.fedoraproject.Anaconda.Modules.Storage[2902]:          ^^^^^^^^^^^^^^^^^^^^^^
Aug 24 23:56:38 localhost-live org.fedoraproject.Anaconda.Modules.Storage[2902]:   File "/usr/lib64/python3.12/site-packages/pyanaconda/core/util.py", line 353, in execWithRedirect
Aug 24 23:56:38 localhost-live org.fedoraproject.Anaconda.Modules.Storage[2902]:     return _run_program(argv, stdin=stdin, stdout=stdout, root=root, env_prune=env_prune,
Aug 24 23:56:38 localhost-live org.fedoraproject.Anaconda.Modules.Storage[2902]:            ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Aug 24 23:56:38 localhost-live org.fedoraproject.Anaconda.Modules.Storage[2902]:   File "/usr/lib64/python3.12/site-packages/pyanaconda/core/util.py", line 290, in _run_program
Aug 24 23:56:38 localhost-live org.fedoraproject.Anaconda.Modules.Storage[2902]:     proc = startProgram(argv, root=root, stdin=stdin, stdout=subprocess.PIPE, stderr=stderr,
Aug 24 23:56:38 localhost-live org.fedoraproject.Anaconda.Modules.Storage[2902]:            ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Aug 24 23:56:38 localhost-live org.fedoraproject.Anaconda.Modules.Storage[2902]:   File "/usr/lib64/python3.12/site-packages/pyanaconda/core/util.py", line 165, in startProgram
Aug 24 23:56:38 localhost-live org.fedoraproject.Anaconda.Modules.Storage[2902]:     return partsubp(preexec_fn=preexec)
Aug 24 23:56:38 localhost-live org.fedoraproject.Anaconda.Modules.Storage[2902]:            ^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Aug 24 23:56:38 localhost-live org.fedoraproject.Anaconda.Modules.Storage[2902]:   File "/usr/lib64/python3.12/subprocess.py", line 1026, in __init__
Aug 24 23:56:38 localhost-live org.fedoraproject.Anaconda.Modules.Storage[2902]:     self._execute_child(args, executable, preexec_fn, close_fds,
Aug 24 23:56:38 localhost-live org.fedoraproject.Anaconda.Modules.Storage[2902]:   File "/usr/lib64/python3.12/subprocess.py", line 1950, in _execute_child
Aug 24 23:56:38 localhost-live org.fedoraproject.Anaconda.Modules.Storage[2902]:     raise child_exception_type(errno_num, err_msg, err_filename)
Aug 24 23:56:38 localhost-live org.fedoraproject.Anaconda.Modules.Storage[2902]: FileNotFoundError: [Errno 2] No such file or directory: '/usr/sbin/updateloaderentries'
```

Based on discussion on PR: https://github.com/rhinstaller/anaconda/pull/4368/files#r1089774874 which points to bug 2134972 which is still in POST for the package review.

I wonder Jeremy, should we revert this feature until the package is in the distribution?

Proposing as a Beta FE. It's not particuarly important as inst.sdboot is pretty hidden, but it would be *good* if it didn't just crash, and fixing this should be fairly isolated so safe.

+3 in https://pagure.io/fedora-qa/blocker-review/issue/1205 , marking accepted.

I guess its me at this point, because at the sdubby package was approved last week. I've opened the branch creation, so it should be in the works RSN.

https://bodhi.fedoraproject.org/updates/FEDORA-2023-3b6fc9579c

But it needs that freeze exception, and that won't fix the workstation install (AFAIK) without the comps/anaconda update.

Hmmm Did I mess that up by using the original BZ in the update request rather than this one that has the freeze exception?

You can list as many bugs as you like. Yes, please add this one, or else I have no idea that there's an update that addresses it, when processing blockers.

When you say "the comps/anaconda update", what do you mean? A change to pull sdubby into the installer environment?

FEDORA-2023-3b6fc9579c has been submitted as an update to Fedora 39. https://bodhi.fedoraproject.org/updates/FEDORA-2023-3b6fc9579c

Yes, there is also this, https://pagure.io/fedora-comps/pull-request/883 which is the missing bits from the earlier PR that moved grubby to the anaconda required list. That PR assures that sdubby is in the repo anaconda is using as an install source. Otherwise, the only install source that works is the everything repo.

FEDORA-2023-3b6fc9579c has been pushed to the Fedora 39 stable repository.
If problem still persists, please make note of it in this bug report.

I'm not sure the comps change here is a good idea. See https://pagure.io/fedora-comps/pull-request/883#comment-192000 . I'm rather worried it would break the world.

As an alternative, perhaps anaconda should disregard the parameter (and maybe warn about it?) if the sdubby package is not available for install (so it would only work on netinst images, as the Change page describes)?

Re-opening to consider this tricky angle.

I guess i'm confused why the live images are installing packages from that list onto the live image, rather than the packages listed as anaconda dependencies, and then just making them available during a live install.

Because there is no way to "make packages available" for a live install other than to *actually install them*. The live install mechanism is just a dump of the live system image itself onto the target filesystem(s). There is no mechanism to install additional packages. So, all the packages in that comps group are installed into live images.

But then the mistake is installing the anaconda comps section at all, no? I thought the live image package lists were coming from the kickstarts, but i'm willing to admit ignorance here.

Yah, so this really shouldn't be there: 

https://pagure.io/fedora-kickstarts/blob/main/f/fedora-live-base.ks#_37

Because the "tools" should be part of the anaconda dependencies covered by the previous two lines.

No, it's not a mistake. Anything the installer might want to "deploy" to the installed system has to just be preinstalled on the live images, because there is no way for the installer to actually "deploy" additional packages to the installed system when installing from a live image.

The things in anaconda-tools are not "dependencies" of anaconda, in that anaconda itself does not require them to *work*. They're things that anaconda might want to *install into the system it is deploying*. That's the distinction between direct dependencies of the anaconda packages, and things that are in the anaconda-tools comps group. Nothing is wrong here except the pull request. The fact that live installs work this way is an unfortunate limitation, but it's not a *new* one, and it's well understood.

? But the when the kickstart is run, anaconda picks what it needs to install to the live media, that list is just to assure that those are available in the source repos.

I guess the point is that according to the comment (and my understand of how this should work) the sdubby package should be in that section, but the live media should _NOT_ have it installed anywhere because anaconda chooses to pick grubby/etc for the live image.

This comment: https://pagure.io/fedora-comps/blob/main/f/comps-f39.xml.in#_36

I guess maybe the solution (although probably way to late for F39) is to actually have a list of "anaconda might" packages and a list of "needs to be on the live media" and split the existing anaconda-tools section?

No, that's still not right.

Strictly speaking, there is no distinction there. *Everything* in anaconda-tools should be on the live media, unless the installer is somehow nerfed on all the live media to not have the capability that would require that package to be deployed to the installed system.

In this case we have a problem that cannot be fully satisfactorily resolved. As you say, if the installer has the capability to deploy sdubby, sdubby should be in anaconda-tools - and because the installer has that capability on the live image, it should also be installed on the live image. But both sdubby and grubby *can't* be installed on the live image. There is no 100% perfect way to square this circle. We have to do something slightly imperfect.

What I'm suggesting is, effectively, that we nerf anaconda: make it *not* capable of systemd-boot installation if sdubby is not available to it. That way you will only be able to do a systemd-boot install from network install media, but at least you won't be able to make the live images or Server DVD crash by trying it.

Another possible choice is to add sdubby to the anaconda-tools group but exclude it in fedora-live-base.ks . We do something similar to this already for a couple of cases (only one of which is 'live'): the Workstation and Budgie kickstarts exclude the gfs2-utils and reiserfs-utils packages that are/were listed in anaconda-tools , to save space. The reiserfs-utils exclusion is not 'live' because that package has already been retired and is no longer in anaconda-tools (so we could cut the exclusion from the kickstarts). The gfs2-utils exclusion is 'live', though. The effect of this is that you can't create gfs2 filesystems from the Workstation or Budgie live installers. Since this is a fairly exotic filesystem intended for use cases you certainly wouldn't deploy via a Workstation live image, that seems like a sensible choice. In this case, the 'nerfing' is done by blivet: blivet has checks to hide filesystems for which the required tools aren't available, so on a Workstation live install it just won't show gfs2 as an option.

The only practical benefit of doing this, though, would be that you could also do a systemd-boot install from the Server DVD, as well as the netinsts. If that's a big enough benefit, I guess we could look at it.

In any case, "actually have a list of "anaconda might" packages and a list of "needs to be on the live media" and split the existing anaconda-tools section" doesn't really make sense to me. We already have both of those conceptually - anaconda-tools is the "anaconda might" group, and the kickstarts define the "needs to be on live media" lists. In *practice*, with limited exceptions as discussed above, anaconda-tools always has to be in the "must be on live media" group; for the limited exceptions, we already have a mechanism - kickstart exclusions - as explained above.

Right, its an incomplete solution to the "exists in the repo" vs "is runnable from the live image". Its sorta related/similar to this x13s problem with pd-mapper/etc where you would want it available in the live image, but you don't really want it installed everywhere because its not going to work on machines that aren't Qualcomm based. So ideally anaconda adds it to the installed image if it detects a QC machine during install, but that doesn't solve the problem of needing it "live".

I've sorta assumed that things like the server dvd would be able to use the option with the set of DVD packages, although offhand i'm not sure in anaconda how to disable the option if a package isn't available since the package resolution/etc happens pretty late.

And AFAIK anaconda doesn't even realize the package isn't available until the install is progressing right now, one would assume that it would notice and refuse the install rather than popping up a we can't find this package message during the install (which is usually what I see when i'm testing this). The fact that there is a message in this BZ about using updateloader entries, means that part of the install actually finished installing the packages before it threw that message trying to cleanup the installed BLS entries, which is just about the last thing it does before rebooting the machine.

Oh, right scratch that, the error comes from the live meda, which of course doesn't have the updateloaderentries, nor a package list to check.

"I've sorta assumed that things like the server dvd would be able to use the option with the set of DVD packages"

It probably won't right now. In order for the package to show up in the repo on the server DVD, it needs to be in anaconda-tools. That's one of the points of anaconda-tools. :D Unless it's getting pulled in by some other kind of dep chain, it currently will not be there.

"although offhand i'm not sure in anaconda how to disable the option if a package isn't available since the package resolution/etc happens pretty late...The fact that there is a message in this BZ about using updateloader entries, means that part of the install actually finished installing the packages before it threw that message trying to cleanup the installed BLS entries, which is just about the last thing it does before rebooting the machine."

Yes, what actually happens currently is that we reach bootloader configuration, then try and run `updateloaderentries` *in the installed system root* (not the installer environment) and it fails. But we would want to detect the situation sooner than that for a clean solution. On the path where we actually *do* deploy packages to the installed system, I think it should be possible to check if that actually worked. On the live path, I guess we would just have to check whether the binary is present in the live environment, as a proxy for whether it would be available in the deployed system environment. I've no idea off the top of my head how difficult writing checks like this would be, the anaconda devs would know better.

We could also do an uglier but simpler hack and simply disregard the kernel parameter when booting a live image; the installer knows very early on when it's a live installer. I don't think that approach should be too difficult.

Oh, the anaconda drippings know if its a live install, right? So its not going to work in that case no matter what because there are already grub drippings everywhere and they don't really co-exist without manual intervention.

So, the option could just then be killed for live images, leaving the problem of how to get it onto the server/etc dvd if its not in anaconda-tools.

(yah you basically just said the same thing about the live image)

There is a provides_liveuser() method which can be used in the BootLoaderSection.type to flip back to "DEFAULT" if its set. Although, I've been curious for a while how these anaconda extlinux options are working because its the same problem (you get failures in some cases).

Which is where I point out the anaconda sdboot documentation, which says it may not work... :)

But 99% of why I put the comps change there, was to get it to appear on the server install dvd.. :)

"Although, I've been curious for a while how these anaconda extlinux options are working because its the same problem (you get failures in some cases)"

It's entirely possible it doesn't work, on live images. We don't formally test it, or any other 'hidden' options like this one that aren't part of the release criteria. If they're broken and nobody complains...

this one only came to my attention through the FE list.

Ok, just to followup, I think my plan at the moment requires three patches, the existing comps one, an additional one to exclude sdubby from the live kickstarts as is done with fcoe and device-mapper-multipath, and an anaconda tweak to disable inst.sdboot/etc on live media.

That will fix the install DVD images so that inst.sdboot works using the DVD packages.
It will correct the build break caused by the anaconda-tools conflict on live media
It will correct the error at the top of this bug, by keeping users from using inst.sdboot on live media which is already partially setup to use grub.

yes, that's broadly the approach I would suggest.

I would suggest landing the excludes in the kickstarts *before* landing the comps change. "Invalid" excludes don't cause any problems, and this way there won't be a window where we may get compose failures.

Just a note, it seems that sdboot is broken also for ostree based images because ostree is messing up with bootloader:

https://github.com/rhinstaller/anaconda/blob/master/pyanaconda/modules/payloads/payload/rpm_ostree/installation.py#L483



Not sure if we already have a bug. I just discussed this on a chat.

This is probably going to have to be the same as the live images for the time being unless/until some kind of "remove grub, add systemd-boot" option is provided.

Partial PR for this, https://github.com/rhinstaller/anaconda/pull/5172

But will depend on the webUI handling bootloader exceptions like the old UI.

Hi Adam, we have missed the freeze exception here. What is the current approach, F39 final exception or rather F40?

We can propose it for Final. I think it's a sensible change to make if we can. As a reminder, Final freeze does not kick in until October 3rd, and as far as the project's procedures go, you can land anything that's acceptable under the updates policy between now and then. I know anaconda as a matter of its *own* policy tries to only land changes to fix accepted FEs or blockers, but because that's not a project-wide policy, there isn't really a project wide "process" for handling this aspect of it.

btw, a thought occurs: I think we also should hide this for ostree installer images, right? (Silverblue, Kinoite etc.) We cannot include sdubby in the base ostrees for those images so we cannot have an install-time option to turn it on.

in fact, we probably also need to check that adding sdubby to comps doesn't cause problems for the ostree installer images.

Yes, the ostree images have similar issues to the live ones. Which I started looking at, and have another hacky patch to disable, but i've sorta been distracted because in theory we should be able to create a live-workstation-systemd image which puts systemd-boot on the image itself, but that has turned out to be a bit of a rabbit hole.

The comps change is now merged for Rawhide, not yet for F39.

Discussed during the 2023-09-25 blocker review meeting: [0]

The decision to classify this bug as an "AcceptedFreezeException (Final)" was made as it would be good to have this change working in all environments where it can (netinsts and the Server DVD) and disabled in environments where it can't (lives, ostrees?).

[0] https://meetbot.fedoraproject.org/fedora-blocker-review/2023-09-25/f39-blocker-review.2023-09-25-16.02.txt

Turns out the ostrees don't pull in anaconda-tools at all, though they probably should. Filed https://gitlab.com/fedora/ostree/sig/-/issues/5 on that, but in practice, it means merging this won't make things any worse for them...:D

*** Bug 2233759 has been marked as a duplicate of this bug. ***

installation with inst.sdboot parameter passed to grub, fedora 39 beta iso.

hdd setup is 3 partitions
1gb - /boot/efi with label boot-efi
1gb - /boot with label boot
18gb - / with label root


cmdline:        /usr/bin/python3  /sbin/anaconda --liveinst --graphical
hashmarkername: anaconda
product:        Fedora
package:        anaconda-core-39.32.2-1.fc39.x86_64
reason:         pyanaconda.modules.common.errors.general.AnacondaError: [Errno 2] No such file or directory: '/usr/sbin/updateloaderentries'
release_type:   pre-release
release:        Fedora release 39 (Thirty Nine)
cmdline_file:   BOOT_IMAGE=/images/pxeboot/vmlinuz root=live:CDLABEL=Fedora-WS-Live-39_B-1-1 rd.live.image inst.sdboot rhgb
addons:         com_redhat_kdump
kernel:         6.5.2-301.fc39.x86_64
version:        39
other involved packages: python3-dasbus-1.7-4.fc39.noarch, anaconda-gui-39.32.2-1.fc39.x86_64, python3-libs-3.12.0~rc1-1.fc39.x86_64

*** Bug 2244794 has been marked as a duplicate of this bug. ***

*** Bug 2248579 has been marked as a duplicate of this bug. ***

Anaconda Installer crashes when trying to install Fedora-Sway-x86_64-39-1.5 on a KVM VM with TianoCore as the UEFI firmware and inst.sdboot kernel boot parameter set.


comment:        Anaconda Installer crashes when trying to install Fedora-Sway-x86_64-39-1.5 on a KVM VM with TianoCore as the UEFI firmware and inst.sdboot kernel boot parameter set.
cmdline:        /usr/bin/python3  /sbin/anaconda --liveinst --graphical
hashmarkername: anaconda
product:        Fedora
package:        anaconda-core-39.32.6-2.fc39.x86_64
reason:         pyanaconda.modules.common.errors.general.AnacondaError: [Errno 2] No such file or directory: '/usr/sbin/updateloaderentries'
release:        Fedora release 39 (Thirty Nine)
cmdline_file:   BOOT_IMAGE=/images/pxeboot/vmlinuz root=live:CDLABEL=Fedora-Sway-Live-39-1-5 rd.live.image quiet rhgb inst.sdboot
addons:         com_redhat_kdump
kernel:         6.5.6-300.fc39.x86_64
version:        39
other involved packages: python3-libs-3.12.0-1.fc39.x86_64, python3-dasbus-1.7-4.fc39.noarch, anaconda-gui-39.32.6-2.fc39.x86_64

Anaconda installer crashed when I passed inst.sdboot parameter.


comment:        Anaconda installer crashed when I passed inst.sdboot parameter.
cmdline:        /usr/bin/python3  /sbin/anaconda --liveinst --graphical
hashmarkername: anaconda
product:        Fedora
package:        anaconda-core-39.32.6-2.fc39.x86_64
reason:         pyanaconda.modules.common.errors.general.AnacondaError: [Errno 2] No such file or directory: '/usr/sbin/updateloaderentries'
release:        Fedora release 39 (Thirty Nine)
cmdline_file:   BOOT_IMAGE=/images/pxeboot/vmlinuz root=live:CDLABEL=Fedora-WS-Live-39-1-5 rd.live.image quiet rhgb inst.sdboot
addons:         com_redhat_kdump
kernel:         6.5.6-300.fc39.x86_64
version:        39
other involved packages: python3-libs-3.12.0-1.fc39.x86_64, anaconda-gui-39.32.6-2.fc39.x86_64, python3-dasbus-1.7-4.fc39.noarch

bhachech: I see "--liveinst" in your command line, so you were trying to run on a live image, I guess. This is normal. Due to <boring technical details about how our live images work>, it's pretty much impossible for this to work from a live image. It will only work when installing from a network install image, or the Server DVD image from Fedora 40 onwards.