Upgraded tumbleweed, won't boot

Ok, first I tried updating my openSUSE 13.2 KDE (Plasma5) installation to Tumbleweed following the instructions here : https://en.opensuse.org/openSUSE:Tumbleweed_installation#Upgrade It failed (could not finding a proper version of libstdc++) and then other libraries wouldn’t be found, run out of space, etc.

So I downloaded the Tumbleweed 64bit DVD ISO and threw it on a USB.

Using the USB I tried running the “upgrade” option which ran into a couple of sticky spots but I worked through them and got through the installation process without any errors or messages until it came time to install the bootloader. It would say there is an error, and doesn’t provide any further information.

So currently it starts up to the word “GRUB” in the screen (top left corner) and that’s it.

I don’t know why it failed, but I wonder if I can run the boot configuration process from the “repair” option of the DVD? If so, what command would I use?

Also, when I tried the “repair” option from the DVD ISO before, I was left at a prompt (possibly a login). I don’t know where to go from there.

If all else fails, my last resort is to do a full install overwriting the system files, and then re-install the applications I installed previously.

I tried updating Tumbleweed earlier today, and I got a lot of errors.

I tried the first two dependency dialogues, then gave up and cancelled out. They were all from packman.

I have the latest snapshot 20150612 running. At present, Tumbleweed is stalled at that point, until they get everything building with gcc 5. Evidently, packman repos have already been built to gcc 5, and updates complain about the missing libraries that we won’t have until the main repos update.

Using the USB I tried running the “upgrade” option which ran into a couple of sticky spots but I worked through them and got through the installation process without any errors or messages until it came time to install the bootloader. It would say there is an error, and doesn’t provide any further information.

In my experience, there is usually a box you can check for details. It’s a bit late for that now, though there are probably logs of the failure unless you aborted at that point.

So currently it starts up to the word “GRUB” in the screen (top left corner) and that’s it.

A bit hard to guess from that. This may be part of the previous grub.

Can you tell us a bit more about where grub is installed (in the MBR or in a partition). You can probably do a manual reinstall of grub if you can boot the system to the install media, mount needed file systems and chroot into the system.

Maybe also check disk space. Running out of disk space is one possible cause of problems – particularly the space under “/boot” to create the “initrd” files.

As already mentioned, that is Packman sourced and caused by delays in Factory build of a huge number of packages against GCC5 to be included as default in the next Tumbleweed snapshot. Read this week’s summary of Tumbleweed from Factory ML: http://lists.opensuse.org/opensuse-factory/2015-06/msg00375.html

I avoided the Packman conflict(s) by using “zypper up” whereas I normally “zypper dup”. You need to upgrade with “zypper dup”, so you could either wait until the GCC5 snapshot arrives, or disable Packman repos for this upgrade and proceed without them. The latter should allow your system to bed down while waiting for GCC5 which may see more problems than one normally gets on Tumbleweed.

Please, post all Tumbleweed questions/Problems in the Tumbleweed, Evergreen and Prerelease/Beta forum. That is the place where Tumbleweed users met.

On 2015-06-21 04:26, dragonbite wrote:
>
> Ok, first I tried updating my openSUSE 13.2 KDE (Plasma5) installation
> to Tumbleweed following the instructions here :

You should then ask in the tumbleweed forum.

> Also, when I tried the “repair” option from the DVD ISO before, I was
> left at a prompt (possibly a login). I don’t know where to go from
> there.

“Repair” is just a plain text only Linux system with just a very few
commands available. And of course, you need to know what is broken and
how to repair it, manually. There is no automatic repair.

You could instead use the XFCE or rescue openSUSE CD, better in a USB
stick. I don’t know if it is available for tumbleweed, though. You get
an XFCE desktop, but again, it is not automatic, you need to know what
to do.


Cheers / Saludos,

Carlos E. R.

(from 13.1 x86_64 “Bottle” (Minas Tirith))

Yes, it is. Each new published snapshot comes with a rescue CD iso (or two, one for 32-bit and one for 64-bit).

On 2015-06-21 17:46, nrickert wrote:
>
> robin_listas;2716188 Wrote:
>> You could instead use the XFCE or rescue openSUSE CD, better in a USB
>> stick. I don’t know if it is available for tumbleweed, though.
>
> Yes, it is. Each new published snapshot comes with a rescue CD iso (or
> two, one for 32-bit and one for 64-bit).

Nice :slight_smile:


Cheers / Saludos,

Carlos E. R.
(from 13.1 x86_64 “Bottle” at Telcontar)

Could you move the thread to the Tumbleweed thread?

The packman repository was already removed as the instructions listed only 6 tumbleweed repositories (oss, non-oss, debug, update, src-oss and src-non-oss). Unfortunately it did not like the non-oss repository.

The last time I upgraded I told it to not use the previously set up repositories so that it would default to the DVD (on a USB) only. This went through the process the furthest without any issues.

However, the bootloader step fails, does not give me any information and I haven’t been able to get past that.

I was hoping that the repair option had a GRUB setup option but that would effect the USB stick, not the hard drive and I cannot get past the systems saying “GRUB” and a blinking cursor that doesn’t do anything.

I am able to chroot into the root directory, but now what? grub2-config reruns “command now found” so I’m not sure what I need to run (or how to run it) to have it try and configure grub so that I can view any messages that let me know why it is failing.

The system does not use EFI (or EUFI), it is a traditional bios and the boot partition is in /dev/sda8.

Thanks

Don’t you own a liveCD with a partitioner such as gparted onboard, to inspect the partition for boot flag setting for example?

Since you brought it up, I do have a Live USB (Fedora) and checked the partitions out for the boot flag and am surprised to find it missing. I settled that with gparted.

Still doesn’t boot, though.

OK I’ll move this. NNTP-ers don’t post for 10m

That’s done

There’s probably a “super grub disk” somewhere on the internet, that will boot you into your system. But I have no experience with that.e

I am able to chroot into the root directory, but now what? grub2-config reruns “command now found” so I’m not sure what I need to run (or how to run it) to have it try and configure grub so that I can view any messages that let me know why it is failing.

Make sure that you have --bind mounted “/dev”, “/proc” and “/sys” before you chroot.

Then, I think the command you need in the chroot session is:

# grub2-install --force /dev/sda8

You might also need:

# grub2-mkconfig -o /boot/grub2/grub.cfg

I installed Tumbleweed of 20150622 and had a boot problem too - no GRUB, nothing, just a blinking cursor. I used the rescue option and I’m sorry, I don’t remember all the choices I picked, but at one point it offered to boot from the first hard disk, and then offered me several different names for my boot (also root) partition (such as /dev/sda5, /dev/by-disk/<blah> <blah>). I selected the one /dev/by-uuid/… because I remember sometimes the device/partition names are a problem and the use of UUID is advised. Now it boots OK.

I’d love it if you could dust off your memory. I tried a clean install of Tumbleweed last night and when it rebooted it left me with the familiar “GRUB” and blinking cursor ( " _ " ). So even that didn’t work.

My backup plan is to re-install the non-Tumbleweed (13.2) and go from there… which would be a bummer.

Why would it be, other than extra work for you now. It’s how I installed my new Tumbleweed with a zypper dup from 13.2 (fresh installed from network CD). :wink:

Yeah, tried that which is the start of this whole thread (run zypper dup, try fixing, try upgrading, fresh instal back to 13.2, give up?) That’s the current story of my life here.

Another annoying piece is there is no information to supply if I wanted to file a bug.

I have not had that problem. I would guess that it is fixable.

Where did you install grub?

Is it possible that you installed grub in the MBR for some previous installation, and there are still remnants of that older grub that are causing problems?

The following have worked for me:

Install grub in the MBR of a legacy partitioned disk.

Create a BIOS BOOT partition (sometimes called a BIOS GRUB partition) on a GPT partitioned disk and install grub in the MBR of that disk.

Install grub on a primary partition of a legacy partitioned disk (install on “/” or “/boot”).

Install grub on a partition of a GPT partitioned disk, and have the installer put generic boot code into the MBR. This one was not perfect. The “/boot” partition (where I installed) was given the legacy_boot flag (correct), but was also given the boot flag (wrong) and that made it look like a EFI partition but using “ext2”. It did work, however, and I later used “gdisk” to fix the “EFI” partition problem.

Here’s the one that gave me problems. I wanted it to install grub (really grub2) on a logical drive ("/dev/sda5" as I recall) with legacy partitioning. And I wanted it to not install generic boot code, and to not set the active flag. It insisted on setting the active flag anyway, and it insisted on installing generic boot code anyway. Unfortunately, it set the active flag for the extended partition ("/dev/sda4" in this case). And that left me with an unbootable system. If it had left the active flag untouched, I could have booted into my 13.2 grub menu (already there), and used an entry in that menu to boot Tumbleweed. Or, if it had set the active flag only on the partition where I installed grub ("/dev/sda5"), that would actually have worked too, because the particular generic boot code that was installed is actually capable of booting a non-primary partition. I fixed the problem by changing the active flag back to where I had wanted it (booting from live media to do that). And I did file a bug report for this (bug 930341).

I re-did it on my (now working OK) system, but I’m unable to get to the point at which is gives me the different names for the root partition, maybe because there is no ambiguity now. But I just tried all the combinations from Rescue System and eventually ended up there.

Hmmm… after redoing the process, I can’t boot again! I can boot from the rescue system, however using YaST to reinstall the boot files ( I assume this calls grub2-config) doesn’t help. I’ll investigate further later.