I’m new to the opensuse community, and thought I would give Tumbleweed a shot. I first installed it, and everything worked perfectly. After the first reboot, however, I have been unable to boot my machine reliably. Only successfully launches OpenSUSE a fraction of the time, and has never once successfully booted twice in a row. I’ve posted the output below, however it’s only ever the same three unhelpful lines.
So far, I’ve tried removing the ‘quiet’ parameters from the linuxefi line in GRUB (in hopes of getting some kind of error), changing from the default btrfs to ext4 when installing, updating BIOS, toggling secure boot, and changing the boot order. So far, nothing has produced a reliable change from this behavior.
I have also redownloaded the iso file twice, verified the checksum each time, as well as checked its integrity when installing. I’m pretty sure I’m installing a legitimate copy of Tumbleweed. I’m also fairly confident in my hardware, since it can install and run Ubuntu and CentOS perfectly well. It seems to be a problem specific to the installer or the current image of Tumbleweed I’m installing.
[HR][/HR]Output:
Booting `openSUSE Tumbleweed’
Loading Linux 5.0.5-1-default …
Loading initial ramdisk…
[HR][/HR]**Hardware:
**Laptop: ASUS Q32FA-BI7T13
CPU: Intel i7-8565U
[HR][/HR]I’ve tried to research possible fixes, but so far I truthfully don’t even know where to start. Any help I could get would be much appreciated! From what (little) I’ve seen openSUSE is a great distro, and I really want to give it a shot.
Remove the “splash=silent” to get more output. Or just hit ESC during boot.
If you were able to install, then the kernel was able to boot the installer.
Maybe edit the boot line by removing “splash=silent” and then append " 3" (without quotes) to the end of that line. That will check whether you can boot to a command line.
Thanks for the quick reply, I really appreciate the help.
I tried removing all instances of ‘splash=silent’ from the boot line (there were three, I’m not experienced in grub, so I’m not sure if that’s normal), but I didn’t receive any additional output after waiting for about 5 minutes.
I rebooted and tried both removing ‘splash=silent’ and appending 3 to the line, and still nothing.
Finally, I tried again, just appending 3 to the line, and it booted successfully, and gave me an error. I obviously can’t really copy paste it, and I’m not able to attach pictures from mobile (that I can see), so I’ll copy it by hand the best I can:
ACPI BIOS Error (Bug): Failure creating _SB.PCI0.XHC.RHUB.SS04._UPC], AE_ALREADY_EXISTS (20181213/dswload2-324)
ACPI Error: AE_ALREADY_EXISTS, During name lookup/catalog (20181213/psobject-221)
(This repeats for a few lines, finally ending with)
Couldn’t get size: 0x800000000000000e
Like I said earlier, I’m not super familiar with bios or grub, so I’m not sure if this is the source of the issue or not. Any additional feedback would definitely be welcome, in the meantime I’ll look into this error and see if I can start to boot Tumbleweed more reliably.
Hit ‘e’ on the boot menu (with the boot line you are going to use). That should bring up an edit window.
Scroll down to the first line beginning “linux” or “linuxefi”. Scroll right to remove “splash=silent” and append 3.
CTRL-X to continue booting.
Finally, I tried again, just appending 3 to the line, and it booted successfully, and gave me an error. I obviously can’t really copy paste it, and I’m not able to attach pictures from mobile (that I can see), so I’ll copy it by hand the best I can:
ACPI BIOS Error (Bug): Failure creating _SB.PCI0.XHC.RHUB.SS04._UPC], AE_ALREADY_EXISTS (20181213/dswload2-324)
ACPI Error: AE_ALREADY_EXISTS, During name lookup/catalog (20181213/psobject-221)
Those are probably not serious issues. There’s something that the kernel didn’t like, but it managed to ignore it after giving some messages. That’s quite common.
Couldn’t get size: 0x800000000000000e
Again, not a problem. That’s still fairly early in the boot, but after loading the kernel. It’s a new message with 5.x kernels, and I think you only get that on a UEFI machine where you have disabled secure-boot. It seems safe to ignore.
If you were able to boot to a command line, then you might have a graphics issue. Try appending “nomodeset” to the end of the boot line (instead of that “3”), and see what happens. It might give you a graphic session, but with inferior graphics. But that’s better than no graphics, and will be easier than the command line session.
I gave it a shot, and it didn’t boot. I also tried booting when appending just “3” to the boot line once again, and it didn’t actually boot then either, so my guess is when it booted the first time it was just lucky.
I’ve noticed that my laptop becomes incredibly hot when it fails to boot, like it’s being overclocked for some reason. Is that a normal part of the openSUSE boot process?
Sorry, my earlier reply was deleted, so I’ll recreate it.
I appended the no modesty option, and it failed to boot, same as before. Just for reference, I tried appending “3” again to see if it works consistently, and it also failed to boot. My guess is when it booted earlier, it was just lucky.
I’ve noticed some excessive heating when it fails to boot, and was wondering if this was a normal part of the openSUSE boot procedure? It seems to be fairly extreme heating, to the point where if it’s left in that state too long, it actually hurts to touch parts of the computer.
PS: thanks for the tips about the bios errors, at least that’s good news!
My replies keep getting deleted (editing in mobile is not the greatest), so I apologize if this is repeated several times in the thread:
I appended the “nomodeset” option, and it still failed to boot. As a test, I tried appending “3” again, to see if it boots consistently with that option, and it failed to boot then too, so it was likely just lucky the first time around.
I’ve also noticed excessive heating when it fails to boot, and was wondering if heavy CPU usage is a normal part of the openSUSE boot procedure? Its fairly extreme, to the point where it hurts to touch parts of the computer after being left in that state too long.
One thing that I originally forgot to mention, too, was some strange behavior with USB sticks. When I attempted to re-image my machine previously, the USB stick I was using originally showed five partitions, two unnamed, one called partition 1 and two called partition 2. Only the partition named “partition 1” actually contained installation media, which is fine, except that every time the computer rebooted it added two additional unnamed partitions. At one point, it claimed that there were around 18 partitions on one USB, without me changing anything. The partition count resets only after the USB device is physically removed and reinserted.
I’m not sure that it’s at all related, but its definitely something I found strange… (for the record, this has never happened to me with any other installation media, only OpenSUSE)
PS: Thanks for your tips about the BIOS errors, you probably saved me several hours of research!
System startup does consume resources. It will keep the cpu and hard drive busy. It most starting services. Too hot to touch is not necessarily a problem. Usually there is a fan that kicks in as the temperature rises.
I have never seen the behavior that you describe for USB sticks. It might be an oddity of the particular UEFI firmware.
Ok, that’s good to know. I’ve left it running for several hours trying to boot, and occasionally the fan doesn’t kick on, but everything still seems to be working as it should, so I won’t worry about it.
As for the USB, I thought it was funny, but it’s still functional, so it doesn’t really matter either.
Is there a clue to be found in the UEFI boot menu? On my newest Asus, it’s the F8 key as POST proceeds. Are there multiple openSUSE entries? Are CentOS and/or Ubuntu still in it?
Was Tumbleweed an addition to CentOS and/or Ubuntu rather than a replacement?
If a replacement, was TW installed in the same mode, UEFI vs. BIOS? If not, try another in matching mode.
Possibly stale boot entries need to be purged from NVRAM?
Tumbleweed was meant as a replacement, and no other OS is listed in the UEFI menu, however there are two openSUSE entries: ‘opensuse’ and ‘opensuse-secureboot’. I’ve tried both and they have the same issues, but it makes me wonder if the secureboot settings could be the cause? I have secureboot disabled in BIOS, because it seems like it requires a key from the OS or something to function, but secureboot support in tumbleweed was enabled by default. Maybe its expecting secureboot, and just not booting because it’s disabled or something?
I believe when I installed Tumbleweed, it was in UEFI mode, same as Ubuntu/CentOs before it. I can try changing the modes, and see if that makes a difference.
As for the NVRAM option, do you know how I could purge it? I tried resetting my BIOS once already, which, based on a single Google search, seems similar, but might not be exactly what you have in mind.
It should not make any difference which of those you choose, because you have secure-boot disabled.
It still looks to me as if you are having a graphics driver problem.
What desktop environment did you install (Gnome, KDE, XFCE, something else)?
Is your system configured for automatic login (that’s the default)?
What graphics card are you using?
I don’t believe a BIOS “reset” empties boot selections. AFAICT, entries not wanted must be manually deleted, either via BIOS setup, or using efibootmgr.
I installed KDE, and disabled automatic login. My graphics card is the default Integrated Intel UHD 620 graphics card. I haven’t had too many issues with it before, I can try to update it. Is there a specific method in openSUSE I should use?
Ok, I can look into that. However, I think I specified that those partitions be overwritten, does that not clear those boot entries from BIOS?
I found an old boot entry for Windows 10, which I deleted. Unfortunately, that didn’t seem to have any effect as TW still cannot boot reliably.
On a slightly different note, does it matter if ‘opensuse’ and ‘opensuse-secureboot’ are not consecutive entries in the UEFI flash table? Strangely enough, opensuse is listed as 0000 and opensuse-secureboot as 0002.