efibootmgr stopped printing:
erlangen:~ # efibootmgr
BootCurrent: 0000
Timeout: 1 seconds
BootOrder: 0000,0002,0001,0009,000A
Boot0000* opensuse
Boot0001* Fedora
Boot0002* ubuntu
Boot0009* ubuntu
Boot000A* opensuse
erlangen:~ # efibootmgr -v
BootCurrent: 0000
Timeout: 1 seconds
BootOrder: 0000,0002,0001,0009,000A
Boot0000* opensuseCould not parse device path: Invalid argument
erlangen:~ #
Any idea?
Report a bug. Happens to me in TW20190226.
On Fri 01 Mar 2019 08:06:03 AM CST, karlmistelberger wrote:
efibootmgr stopped printing:
Boot0000* opensuseCould not parse device path: Invalid argument
Hi
As indicated, bug report time, one wonders if due to the age/version of
the efibootmgr program.
–
Cheers Malcolm °¿° SUSE Knowledge Partner (Linux Counter #276890)
SLES 15 | GNOME Shell 3.26.2 | 4.12.14-25.28-default
If you find this post helpful and are logged into the web interface,
please show your appreciation and click on the star below… Thanks!
It is more likely that the latest update to “libefivar1” broke something.
I have reported this as Bug 1127544 - efibootmgr is broken
This same bug makes it impossible to install Tumbleweed (with EFI booting) with the latest install image and there are no copies of older images for some reason, so… it’s really rather important.
I have not tried a recent EFI install of Tumbleweed. But I did wonder whether that would be a problem with this bug.
It does appear to be the update of “libefivar1” that caused the problem. I blocked that update on one system, and “efibootmgr” is working fine on that system.
Perhaps you should add a note about your install experience to the bug report.
Snapshots 20190301 and 20190304 passed openQA EFI install tests.
Then the OpenQA is completely screwed up. Right now it’s IMPOSSIBLE to install Tumbleweed from any of the March ISOs, as confirmed in another post here and on Reddit from various users trying and failing. You can pop it into VirtualBox and try it yourself. There seem to be a host of bugs that crept into the March installer.
Ah, I finally got a screenshot of what the installer complains about when you try to update online repositories:
**Tumbleweed is down!
[video]https://youtu.be/TSyiZ61BspU[/video]
**
Really?
Right now it’s IMPOSSIBLE to install Tumbleweed from any of the March ISOs
It is of course possible as confirmed by openQA. It is of course possible that openQA does not test exact conditions that trigger this bug. This does not make it “screwed up”, just incomplete.
You can pop it into VirtualBox and try it yourself.
So you come here shouting “Tumbleweed down!” and demand that I must do debugging for you? I have not seen as much as your comment on the bug mentioned earlier. That shows you are not really interested in fixing this bug but simply to use it as occasion to bash around.
Tumbleweed is down!
Sure. It is much easier than comparing what is different between openQA and other systems where it fails and submitting bug report with explanation what is missing in openQA tests.
I tried a test install of 20190305 today. And it went fine. But this was a fairly simple install, so perhaps it did not hit whatever problems some people might be having.
It’s not possible, as confirmed by me and everyone else reporting the problem. There are missing files on the ISOs/repositories, as specified in the error message screenshots I displayed.
So you come here shouting “Tumbleweed down!” and demand that I must do debugging for you?
I didn’t demand anyone do anything. I simply pointed out that the problem is reproducible.
That shows you are not really interested in fixing this bug but simply to use it as occasion to bash around.
Is that why I went through the trouble of obtaining screenshots of the error message the installer spits out before it drops into the generic error screen? As far as I know, I’m the first/only person who managed to get the error message; it doesn’t display before dropping into the error screen. I tried switching to different consoles today on a hunch and found the error message on one of the screens and then grabbed the shot.
Did you enable online repositories? If you’ve got time, try the net install and see if it even starts. With the efibootmgr install message, it seems to make a difference whether the install drive is already partitioned or not.
I just tried the net install again and this time it wanted to download a new file before starting; maybe there’s a bugfix already? Nope; it just crashed again when updating online repositories.
You never stated explicitly what you are trying to install! Please post the URL of the object you are talking about.
Tumbleweed. The installer is broken on two levels. The efibootmgr bug that this thread is about affects the installation on UEFI systems if the installer needs to delete partitions (I’ve since figured this out, which is why the poster above reported they didn’t have a problem). If they run through the install a second time and this time select the option to remove partitions even if not needed, they’ll run into the bug.
There is apparently a second, unrelated bug that occurs if you opt to update online repositories (or use the net installer). Files are reported as not being found. This may be on the server end, and it frustratingly seems to occasionally work, so I don’t know what’s going on on that end. But what this means is that usually the net installer completely fails and the DVD install will fail if you select update online repositories.
I’ll update the efibootmgr but report and see if anyone on bugzilla can assist me with reporting the missing files bug since I’m still not sure on which end the problem lies. All the missing files the error message reports about are in the “/var/adm/mount” directory. On the DVD it’ll say “couldn’t open file” and on the NET install it’ll be the same files, but this time 404 file not found. It’s still doing it as of the latest March 7 ISO image.
Actually, I found another person reporting the same problem now since February:
Downloaded openSUSE-Tumbleweed-NET-x86_64-Snapshot20190307-Media.iso and installed. Expert partitioner > Delete partition failed. But Edit partition worked.As a result the installer readily deleted a swap partition and created an ext4 system partition.
Just in case you need to delete a partition boot from a rescue or a live iso and have a try with expert partitioner. In case of failure use gdisk.
Thank you.
I have now tested that, and I confirm that deleting a partition fails. And it failed on deleting “/dev/sda5” which was not even the EFI partition, though I had set it to delete all partitions.
Then I tried again, and this time I set it to create a new partition table. And, again, it wanted to delete partitions first with the same failure.
However, I could use: CTRL-ALT-F2
to get a command line, and use “fdisk” to delete partitions. That way the installer wouldn’t actually know about it.
So apparently openQA is not testing for deleting partitions – or it would have caught this.
A similar problem occurred in the past. How to add this to openQA?
I presume you can start here: GitHub - os-autoinst/os-autoinst-distri-opensuse: os-autoinst test cases for openSUSE
There is link to Contributing Guide directly on this page.
