Update loops, fails with no X

I’m trying to update a machine from 12.2 to 13.1 (because that’s what the latest CUDA version requires. I’m using the net install from a USB stick (I successfully did a fresh install from it, after switching to an SSD in this machine). The install begins, walks through several screens, then begins loading a couple of GBytes of upgrade files. This continues for some time, apparently normally judging from occasional looks at the screen. However, at some point it apparently loops back to the beginning, because I get the initial license screen again. It then appears to go through the whole update process again, downloading another couple of GBytes (probably the same ones), then at some point loops back to the license screen to begin the update AGAIN.

After a couple of cycles of this, it apparently got tired and decided to do a full install, as after the license screen it went to the timezone setting screen. Here I aborted it, and tried to boot the system, but it boots to a console, no X or FVWM2 window manager.

So is there any way I can get it to complete the update, and get back to a working system without the hassle of re-installing a lot of stuff (like the window manager) by hand?

On 2014-09-11 02:56, jamesqf wrote:
>
> I’m trying to update a machine from 12.2 to 13.1 (because that’s what
> the latest CUDA version requires. I’m using the net install from a USB
> stick (I successfully did a fresh install from it, after switching to an
> SSD in this machine).

So, you already have installed 13.1 in this machine? It is done then,
you do not need to ugrade, then, nor install?

Or are you saying that you did another install using that stick, and now
you are going to install or upgrade this system? That is, two systems in
the same machine?

> The install begins, walks through several
> screens, then begins loading a couple of GBytes of upgrade files.

Then you are choosing the “upgrade” option in the netinstall CD?
(CD “burned” to a usb stick, no matter)

> This
> continues for some time, apparently normally judging from occasional
> looks at the screen. However, at some point it apparently loops back to
> the beginning, because I get the initial license screen again. It then
> appears to go through the whole update process again, downloading
> another couple of GBytes (probably the same ones), then at some point
> loops back to the license screen to begin the update AGAIN.
>
> After a couple of cycles of this, it apparently got tired and decided to
> do a full install, as after the license screen it went to the timezone
> setting screen. Here I aborted it, and tried to boot the system, but it
> boots to a console, no X or FVWM2 window manager.
>
> So is there any way I can get it to complete the update, and get back to
> a working system without the hassle of re-installing a lot of stuff
> (like the window manager) by hand?

It is not clear to me what you are doing. However, if it loops
downloading, I would then switch to the full DVD instead, running
locally, no downloads from internet.


Cheers / Saludos,

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

No, I see that what I wrote wasn’t clear. I used the USB stick to do a successful fresh install in another machine after switching to an SSD. That machine has been working fine for a couple of months now, so the stick & install can be presumed to be good.

Or are you saying that you did another install using that stick, and now
you are going to install or upgrade this system? That is, two systems in
the same machine?

No, same stick, but the upgrade is to a second machine (mostly used as a CUDA/compute machine). I had hoped that by upgrading I could avoid the couple of days of futzing around with window manager, host names, ssh permissions, and the rest.

Then you are choosing the “upgrade” option in the netinstall CD?
(CD “burned” to a usb stick, no matter)

Yes

It is not clear to me what you are doing. However, if it loops
downloading, I would then switch to the full DVD instead, running
locally, no downloads from internet.

It acts as if it has finished the upgrade, then has automatically rebooted the machine, which boots from the stick again. Which shouldn’t happen: first, the install/upgrade should wait for user confirmation, and second, the boot-from-USB is (per the BIOS docs) supposed to be a one-time thing that only happens when you press F-12 during startup.

It does seem to have done at least some of the upgrade, as the boot screen & console both say it’s 13.1. I even have shell history saved from before starting the upgrade, just no X :frowning:

DVD install is not an option, unless I go out and buy the hardware.

Do you get a grub menu? If so have you tried advanced - rescue?

You probably need the propritary NVIDIA driver. That is not installed in a distro upgrade

On 2014-09-11 23:16, jamesqf wrote:
>
> robin_listas;2663980 Wrote:

> No, I see that what I wrote wasn’t clear. I used the USB stick to do a
> successful fresh install in another machine after switching to an SSD
> (the one I’m using now), so the stick & install can be presumed to be
> good.

Ah, ok. That’s good.

>
>> Or are you saying that you did another install using that stick, and now
>> you are going to install or upgrade this system? That is, two systems in
>> the same machine?
>
> No, same stick, but the upgrade is to a second machine (mostly used as a
> CUDA/compute machine). I had hoped that by upgrading I could avoid the
> couple of days of futzing around with window manager, host names, ssh
> permissions, and the rest.

Yes, I do the same :slight_smile:

>> Then you are choosing the “upgrade” option in the netinstall CD?
>> (CD “burned” to a usb stick, no matter)
>
> Yes

Ok.

>> It is not clear to me what you are doing. However, if it loops
>> downloading, I would then switch to the full DVD instead, running
>> locally, no downloads from internet.
>
> It acts as if it has finished the upgrade, then has automatically
> rebooted the machine, which boots from the stick again. Which shouldn’t
> happen: first, the install/upgrade should wait for user confirmation,
> and second, the boot-from-USB is (per the BIOS docs) supposed to be a
> one-time thing that only happens when you press F-12 during startup.

I think, from memory, that the upgrade boots automatically at the end of
the process. On a normal install, it does a boot from kexec, not a
/real/ boot, in order to complete the initial setup after the installation.

But this I think does not happen on an upgrade. If it does (sorry, I
don’t have all the details of the process on my biological memory), it
could redirect the boot to happen from other media.

Or there is an entry in grub to boot from the stick…

…and even if the stick boots automatically, it should not do an
install/upgrade attempt on its own.

> It does seem to have done at least some of the upgrade, as the boot
> screen & console both say it’s 13.1. I even have shell history saved
> from before starting the upgrade, just no X :frowning:

If you remove the stick, does the system “boot”? If it does, and the
console does say 13.1, I can guide you on the next steps. It looks good,
actually :slight_smile:


Cheers / Saludos,

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

On 2014-09-12 00:06, gogalthorp wrote:
>
> Do you get a grub menu? If so have you tried advanced - rescue?
>
> You probably need the propritary NVIDIA driver. That is not installed in
> a distro upgrade

True.

Let me see, he is using the Netinstall media, not the DVD, so the
typical DVD upgrade problem he should not have: the DVD, because of the
size, can not contain all the needed packages.

Copied from my notes:

…so on a dvd upgrade, you need to run after the initial boot,


zypper dup
zypper up
zypper patch

Make sure you only have the 4 official repos active before running that.
Then, verify:

Upgrading rpm query


rpm -q -a --queryformat "%{INSTALLTIME};%{INSTALLTIME:day}; \
%{BUILDTIME:day}; %{NAME};%{VERSION}-%-7{RELEASE};%{arch}; \
%{VENDOR};%{PACKAGER};%{DISTRIBUTION};%{DISTTAG}
" \
| sort | cut --fields="2-" --delimiter=\; \
| tee rpmlist.csv | less -S

or

rpm -q -a --queryformat "%{INSTALLTIME}	%{INSTALLTIME:day} \
%{BUILDTIME:day} %-30{NAME}	%15{VERSION}-%-7{RELEASE}	%{arch} \
%25{VENDOR}%25{PACKAGER} == %{DISTRIBUTION} %{DISTTAG}
" \
| sort | cut --fields="2-" | tee rpmlist | less -S

or


rpm -q -a --queryformat "%{INSTALLTIME}	%{INSTALLTIME:day} \
%{BUILDTIME:day} %-30{NAME}	%15{VERSION}-%-7{RELEASE}	%{arch} \
%25{VENDOR}%25{PACKAGER} == %{DISTRIBUTION} %{DISTTAG}
" \
| sort | cut --fields="2-" | tee rpmlist \
| egrep -v "openSUSE.13\.1" | less -S

(not containing 13.1)

With that query, you find listed at the top old packages that may have
to be upgraded manually, because they belong to the previous release, or
perhaps came from extra repositories and no equivalent was found in the
active repos. In that case you have to start at this phase to add the
needed extra repositories and update those packages.

Many of them show in red in YaST,

rcrpmconfigcheck

And after that, run “rcrpmconfigcheck” and verify the resulting list of
config files. I suggest backing up both the active and the old/new file
somewhere, and then edit both with “meld”. Choose what to keep or not of
the config.

More info here: Offline upgrade method


Cheers / Saludos,

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

You nailed it: the upgrade apparently installed a newer version of X which needed a newer driver, but didn’t install the needed driver - which caused a boot to console as though X itself was missing (sigh). Seems to work pretty much normally now - thanks for the help, everyone.

And yes, apparently the looping was just the install/upgrade program somehow rebooting from the stick again. Kind of confusing not to have it wait for the user to respond to a prompt before doing that.

Well, the nvidia driver is not included in the distribution (for legal reasons), so it cannot be updated during the upgrade of course.

You should probably remove it before the upgrade, or boot to “recovery mode” to update it manually afterwards.

If you do not have an /etc/xorg.conf that forces Xorg to load the nvidia driver, you should get to a graphical system even when the nvidia driver does not work though (unless you use GNOME… :wink: ).

On 2014-09-12 08:46, wolfi323 wrote:
>
> jamesqf;2664149 Wrote:

>> You nailed it: the upgrade apparently installed a newer version of X
>> which needed a newer driver, but didn’t install the needed driver -
>> which caused a boot to console as though X itself was missing (sigh).
>> Seems to work pretty much normally now - thanks for the help, everyone.

> Well, the nvidia driver is not included in the distribution (for legal
> reasons), so it cannot be updated during the upgrade of course.

It can, though, but you have to know how, and that you have to do
“something” yourself :wink:

He was using the netinstall image, which does not contain anything
locally except the local live image. Meaning, it has to connect to
online repos. I’m not that familiar with the netinstall disk, because my
internet is too slow, I use the full DVD instead. But in the DVD you can
choose to pull from online repos, and can customize the list of repos:
thus the trick is to add the nvidia repo to the list. And you need to
know the URL, AFAIR you can not simply “select” a repo, you have to type
it. I guess that the netinstall media will work very similarly.

I can’t vouch for this procedure, though, never used it myself with the
nvidia repo (or I don’t remember using it). I believe it should work.
Me, I usually prefer to upgrade using the native nouveau driver - but I
see that this also failed. The upgrade should have left this one
working. It is possible that a configuration file was left disabled
(check rcrpmconfigcheck output).

Unless the OP has one of those cards that simply fail with nouveau… :-?


Cheers / Saludos,

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

Right, but that’s not automatic any more then.
You can just as well update it manually afterwards… :wink:

He was using the netinstall image, which does not contain anything
locally except the local live image. Meaning, it has to connect to
online repos. I’m not that familiar with the netinstall disk, because my
internet is too slow, I use the full DVD instead. But in the DVD you can
choose to pull from online repos, and can customize the list of repos:
thus the trick is to add the nvidia repo to the list. And you need to
know the URL, AFAIR you can not simply “select” a repo, you have to type
it. I guess that the netinstall media will work very similarly.

You probably would have to do that using zypper in text mode though.
I am not aware of any option in the Netinstall CD to add any additional repos.

Me, I usually prefer to upgrade using the native nouveau driver - but I
see that this also failed. The upgrade should have left this one
working. It is possible that a configuration file was left disabled
(check rcrpmconfigcheck output).

If the nvidia driver is installed, nouveau won’t work. That’s to be expected, as the nvidia driver blacklists nouveau.
But without an xorg.conf the system would at least be able to fall back to fbdev or vesa.

On 2014-09-12 16:36, wolfi323 wrote:

>> It can, though, but you have to know how, and that you have to do
>> “something” yourself :wink:
> Right, but that’s not automatic any more then.
> You can just as well update it manually afterwards… :wink:

No, not automatic. But once the repo is added, the upgrade itself should
be automatic.

>> thus the trick is to add the nvidia repo to the list. And you need to
>> know the URL, AFAIR you can not simply “select” a repo, you have to type
>> it. I guess that the netinstall media will work very similarly.
> You probably would have to do that using zypper in text mode though.
> I am not aware of any option in the Netinstall CD to add any additional
> repos.

I’m surprised about that. The full DVD certainly has it, and as far as I
know, both are the same, but with/without the rpm tree locally.

>> Me, I usually prefer to upgrade using the native nouveau driver - but I
>> see that this also failed. The upgrade should have left this one
>> working. It is possible that a configuration file was left disabled
>> (check rcrpmconfigcheck output).

> If the nvidia driver is installed, nouveau won’t work. That’s to be
> expected, as the nvidia driver blacklists nouveau.
> But without an xorg.conf the system would at least be able to fall back
> to fbdev or vesa.

No, I mean that the upgrade should have left the nouveau driver
correctly configured to work, and removed the stale nvidia driver, and
things running.

It simply did nothing. It did not offer to add nvidia repo and upgrade
it, nor did it remove it, nor did it configure nouveau to work, knowing
that the old nvidia rpm will not work in any case.

And this could have been caused by the correct xorg.conf being named
xorg.conf.rpmnew or something of the kind.

…which can be detected by running “rcrpmconfigcheck”.


Cheers / Saludos,

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

No idea, I never used the full DVD.

But I do know that the Netinstall CD does not offer any option to add/change/remove repos in the graphical installer.
(unless it is very well hidden… :wink: )

You can specify the URL of the online repo though, but this won’t help much in this particular case, unless you create your own repo that includes the nvidia packages…

No, I mean that the upgrade should have left the nouveau driver
correctly configured to work, and removed the stale nvidia driver, and
things running.

The upgrade does/did not change anything regarding the Xorg configuration.
The user created an xorg.conf (probably, we do not really know this), so the upgrade should not remove it anyway.

And the upgrade should not remove packages that are not part of the official repos either, just because it cannot upgrade them.
The installer cannot know why they have been installed in the first place, and it cannot know that they might cause problems after the upgrade, unless there are dependency errors/conflicts of course. In that case they most likely would be removed of course.

It simply did nothing. It did not offer to add nvidia repo and upgrade
it, nor did it remove it, nor did it configure nouveau to work, knowing
that the old nvidia rpm will not work in any case.

Why should the installer have any special knowledge about the nvidia driver or the nvidia repo?

And this could have been caused by the correct xorg.conf being named
xorg.conf.rpmnew or something of the kind.

No.
xorg.conf is not contained by any package, so it will not be renamed to xorg.conf.rpmnew or simething similar.

…which can be detected by running “rcrpmconfigcheck”.

Well, it could be detected if xorg.conf was part of any RPM package. But it isn’t.

As robin_listas notes, it was the netinstall update, so it should be able to pull the necessary driver from NVidia’s site. Or if I’d known in advance, I could have specified the repository, but I didn’t see that mentioned anywhere in the various update instructions I read beforehand.

You should probably remove it before the upgrade, or boot to “recovery mode” to update it manually afterwards.

Simply doing the manual update afterwards seems to work just fine.

If you do not have an /etc/xorg.conf that forces Xorg to load the nvidia driver, you should get to a graphical system even when the nvidia driver does not work though (unless you use GNOME… :wink: ).

I haven’t gotten to where I really understand the new Xorg configuration stuff - as so often seems the case, I no sooner get a handle on something than the developers decide to change it :frowning: But I would be quite happy to have the display on this maching always run through the onboard Intel graphics. The GPU is used as a compute device, so most of time I don’t even have a connected display or keyboard, just ssh to it.

No. It only uses the standard OSS repo for the upgrade.

Or if I’d known in advance, I could have specified the repository, but I didn’t see that mentioned anywhere in the various update instructions I read beforehand.

As I wrote, this is not easily possible.

Simply doing the manual update afterwards seems to work just fine.

Then it’s ok, isn’t it?

I haven’t gotten to where I really understand the new Xorg configuration stuff - as so often seems the case, I no sooner get a handle on something than the developers decide to change it :frowning:

An old-style xorg.conf is still used if present.
The new-style config in /etc/X11/xorg.conf.d/ is nothing else than the xorg.conf split out into several files (one file per section e.g.).
See also “man xorg.conf”. :wink:

But I would be quite happy to have the display on this maching always run through the onboard Intel graphics.

???
Is this an Optimus system? Or a standard one with intel onboard graphics and an additional nvidia card?
If it’s the latter I’m not sure it would be possible to use the intel graphics.

But especially in this case you should remove an xorg.conf that specifies the nvidia driver to be loaded, if there is one.

And if you install all nvidia packages, the intel driver won’t even work fully, in particular OpenGL will not!
You have to remove nvidia-glG03, i.e. the OpenGL part of the nvidia driver.
You should still be able to use it for CUDA then. That’s the main reason why the driver is split up in so many packages.

Although if you only use it via SSH, you might not care about the intel driver anyway.

On 2014-09-12 20:26, wolfi323 wrote:
>
> robin_listas;2664226 Wrote:
>> I’m surprised about that. The full DVD certainly has it, and as far as I
>> know, both are the same, but with/without the rpm tree locally.
> No idea, I never used the full DVD.
>
> But I do know that the Netinstall CD does not offer any option to
> add/change/remove repos in the graphical installer.
> (unless it is very well hidden… :wink: )

I’ll show you.

I downloaded the CD, which took me a full hour. Then I started it on a
vmware machine that has 12.3, to test the upgrade (but not performed, I
only wanted a look). During boot, it first downloads the 6 “installation
systems” from internet, they are not apparently on the CD. This took me
a long time to download, as my internet is slow.

At the screen where you select install of upgrade:

http://susepaste.org/27826898

…notice that there is a tick for “add online repositories before
installation”. If you select it, after a bit you reach this other screen:

http://susepaste.org/71471885

where you get the old repository list you had for the previous system.
If you had the nvidia 12.3 repo, it will be there. Just edit it to point
to the 13.1 version, and toggle it active. Then just continue to the
next screen.

No need need to activate any of the default repos shown in my photo,
because those are for 12.3, and the ones for 13.1 are automatically
activated a bit later. I have the photo for that, but I don’t think it
is needed.

my photo does not have a line for nvidia, of course, as that is a
virtual setup. But believe me, any repo you had active on the previous
version that you are upgrading from, in my example, will be in that
list. So, the nvidia repo will be there, but deactivated, an pointing to
the old release.

Quod erat demonstrandum (QED) :-))

You could even reuse one of those entries to add a totally different
repository. You can fully edit the existing entries, just not add new
ones, apparently. But nothing forbids you from making a 12.3 debug repo
point to packman instead, even if the name is wrong :wink:


Cheers / Saludos,

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

On 2014-09-12 21:36, wolfi323 wrote:
>
> jamesqf;2664259 Wrote:
>> As robin_listas notes, it was the netinstall update, so it should be
>> able to pull the necessary driver from NVidia’s site.
> No. It only uses the standard OSS repo for the upgrade.
>
>> Or if I’d known in advance, I could have specified the repository, but I
>> didn’t see that mentioned anywhere in the various update instructions I
>> read beforehand.
> As I wrote, this is not easily possible.

See my recent post where I show how to do it :wink:


Cheers / Saludos,

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

The photos I posted do not display on the forum. Perhaps too big.
Redoing as URL.

On 2014-09-13 02:53, Carlos E. R. wrote:
> At the screen where you select install of upgrade:
>
> http://susepaste.org/27826898

http://susepaste.org/images/27826898.jpg

http://susepaste.org/27826898

> …notice that there is a tick for “add online repositories before
> installation”. If you select it, after a bit you reach this other screen:
>
> http://susepaste.org/71471885

http://susepaste.org/71471885.jpg

http://susepaste.org/71471885


Cheers / Saludos,

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

On 2014-09-13 03:15, Carlos E. R. wrote:
>
> The photos I posted do not display on the forum. Perhaps too big.
> Redoing as URL.

I think I got the trick. Should be right this time:

At the screen where you select install of upgrade:

http://susepaste.org/images/27826898.jpg

…notice that there is a tick for “add online repositories before
installation”. If you select it, after a bit you reach this other screen:

http://susepaste.org/images/71471885.jpg


Cheers / Saludos,

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

Yes, we agree that that’s what the current update program DOES. What I’m saying is that I see no technical reason why it could not use other repos as needed. For instance, if it detects a NVidia graphics card and an older driver than X requires, it could go to the NVidia site and get that driver, automatically. Or at the very least, it could warn the user that a new driver is needed, rather than fail silently.

As I wrote, this is not easily possible.

But as Robin notes, it is - at least if you know where to find the appropriate repository. Which I think could be included in the update howtos…

Then it’s ok, isn’t it?

Except for several hours of my time (and the time of you helpful people) wasted trying to figure out what the problem was, and a bit of unnecessary aggravation inserted into an otherwise tranquil life :slight_smile:

Is this an Optimus system? Or a standard one with intel onboard graphics and an additional nvidia card?
If it’s the latter I’m not sure it would be possible to use the intel graphics.

It’s a standard system. I don’t see why it shouldn’t be possible, but I am far from an expert at this. Maybe it’s just that no one has ever tried, though there are plenty of instances of GPUs being used purely as compute devices - Amazon EC2’s GPU compute images, for example.

Ok, so it is there.
Thanks for explaining.

I didn’t see it the last time I tried.
Now I remember that I still didn’t try the upgrade to 13.1 in a 12.3 VM that I wanted to do to check this.
And my last real upgrade was in December, I might have missed it back then because I didn’t even care to add some repo. (although this actually was on a system with an nvidia card).

Sorry about this, and thanks for clearing it up…

You’re talking about the nvidia driver here. And what about dozens of other drivers that might exist?

Again, as long as the dependencies are correct, the installer has no way to know that something might get broken.

Or do you want to add special treatment to the installer/package manager depending on the package names?
That’s unmaintainable. And if there ever is a change to the nvidia packaging (which does happen), this would break completely.

Even if the packages would be removed during installation/upgrade, this wouldn’t help if you installed the driver the hard way though, of course.

Anyway, if you think there is a packaging problem with the nvidia driver regarding this (e.g. they should conflict with the newer Xorg or something), then please file a bug report at http://bugzilla.novell.com/.
And if you think the installer doesn’t do something it should do, you should file a bug report there as well.

The only sensible thing I can imagine right now, would be that the installer would offer to add repos from the Community repo list (this includplasma5-desktopes the nvidia repo e.g.) before installation/upgrade. But maybe it does anyway, I don’t know.

But as I mentioned already as well, the system should start just fine even with the old/incompatible nvidia driver (it should fall back to a different one), as long as there’s no xorg.conf that tells/forces X to load the nvidia driver. And there’s “recovery mode” that should work even if there is, as it uses a different config.
I don’t see a point in having an xorg.conf in your case though, as you do not want to use the nvidia driver for graphics display anyway.
(and even without an xorg.conf, the nvidia driver is preferred if installed)

It’s a standard system. I don’t see why it shouldn’t be possible, but I am far from an expert at this. Maybe it’s just that no one has ever tried, though there are plenty of instances of GPUs being used purely as compute devices - Amazon EC2’s GPU compute images, for example.

Well, it depends on whether the hardware/BIOS would allow this.
If the onboard graphics is switched off automatically when you add an additional card, there’s no way to use it any more obviously.

But I’m no expert on this either.

On an Optimus system this is definitely possible though, the system normally runs on the intel chip there anyway.