Today I upgraded my second computer to Leap15.3 (no problems with the first one). This is an old Dell Edge server with 2 GB Ram and XGI Technology Inc. (eXtreme Graphicc Innovation Z7/Z9 (XG20 core). Install ran without any problems but with the first boot I got the following error messages [192.973364] blk_update_request: I/O error, dev fd0, sector 0 op 0x0: (READ) flags 0x0 phys_seg 1 prio class 0 .
(The number in the square bracket change each time that message comes).
Then the screen stays black with the text “login:” I loged in as root and did a zypper up and got the following message:
patch SUSE-2021-1526-1.noarch problems conflicts with readline-doc < 7.0-19.3.1 provided by readline-doc-7.0-17.83.noarch
As root I tried the startx command and the computer went into the GUI. So the graphics support there looked OK. I logged off again and typed this on my Tumbleweed computer. Any support is appreciated.
Cheers
Uli
I edited the GRUB menu - added nomodeset and the computer booted into the GUI. There I received the message “Software update You have 1 new update” When I started the update I got: “Software update patch:SUSE-2021-1526-1.noarch conflicts with readline-doc”.
at the root command line for updating. Other ways of updating are being confused by patches which seem to be intended for SLE only and not for openSUSE.
I have a Gigabyte server motherboard with this IGP:
0a:03.0 VGA compatible controller: XGI Technology Inc. (eXtreme Graphics Innovation) Z7/Z9 (XG20 core) (prog-if 00 [VGA controller])
Subsystem: Gigabyte Technology Co., Ltd Device 0020
Flags: 66MHz, medium devsel
BIST result: 00
Memory at dc000000 (32-bit, prefetchable) [size=32]
Memory at de000000 (32-bit, non-prefetchable) [size=256]
I/O ports at 6400 [size=128]
Expansion ROM at <unassigned> [disabled]
Capabilities: [40] Power Management version 2
Kernel modules: xgifb
I installed an accessory graphics card in it years ago because there was no satisfactory Linux driver support for the XGI regardless of distro. This is a common situation with GPUs not made by AMD, Intel or NVidia. IIRC the only way to run Xorg on it was with the VESA or FBDEV Xorg driver. Both these two drivers are unaccelerated and limited in support for resolutions above 1024x768. Whether optimal configuration requires nomodeset or not I cannot recall. It’s been quite some years since I tried to use it.[/size][/size][/size]
Thank you, mrmazda, I know the graphics card is hopeless. But this computer has little use, mainly for scanning and if I ever need Windows it still has an old WinXP system there which I haven’t used for years. The error message I wrote in my first post here comes from the old floppy drive and I disabled the floppy now in the BIOS. For now I have added the nomodeset and now I have enough for today. Tomorrow I will try to see if the VESA or FBDEV drivers are present. May be someone has a bright idea by then…
Thanks, arvidjaar, I didn’t know to which driver it will revert back with the nomodeset command - all I understand is that it will refer back to a generic driver… But if it worked somehow reasonably before with LEAP15.2 right down to version 9.2 (I have this computer since 2004) why doesn’t it work after the upgrade?
How should we know without any information? You said you were able to start GUI after logging in in text terminal, so apparently this part works, just it is not started on boot. The obvious first thing to check -
thanks, arvidjaar, I have already supplied the result of systemctl get-default in my second post. And I only could get into the GUI as root with startx and I went out of it quickly because I don’t like running a computer with a GUI as root. The command systemctl enable graphical.target as normal user did not work. However I have now added nomodeset permanently to the booting line in GRUB and I think I have to replace this 17 year old computer at some stage.
In the meantime I have upgraded all 4 of my Leap computers to 15.3 without problems with the other computers. I followed nrickert’s advice and disabled the packagekit updater in system tray and will once a week update with zypper up. Where will be a notification when this problem is solved that we can enable this update function again, will this be in the community news?
Thank you, arvidjaar, here is the journalctl file: https://susepaste.org/17631694
and here is the Xorg.0.log file: https://susepaste.org/51057922
Both files are after a boot-up without nomodeset when it only boots in text mode. To be sure I made the same text files with the nomodeset command when it boots into the GUI. Let me know please if you need that too. To me these files are long and I hardly understand anything.
Actually they look OK. Xorg is started and it selects FBDEV as driver and kernel is also using vesafb as console driver. SDDM is also started.
To be sure I made the same text files with the nomodeset command when it boots into the GUI. Let me know please if you need that too.
Yes, please, it certainly would be useful to compare the difference.
But pragmatic answer is - if it works for you with “nomodeset”, just add “nomodeset” to kernel command line. You may consider opening bug report if it was not needed in 15.2.
Thank you, arvidjaar, here is the journalctl file with nomodeset: https://susepaste.org/91936347
and here is the Xorg.0.log file with nomodeset: https://susepaste.org/91176206
I had the impression that the computer struggles a bit before the GUI finally comes on with those settings but at least it comes on and the computer can be used as before.
I will leave the nomodeset option in the GRUB booting line until I find out what causes the sudden problems with the booting. As I wrote before I have this computer since 2004 and it is always running openSUSE and with all the upgrades I had never problems with the GUI. WIth newer computers running better and faster this computer was used less and now it is mainly used to scan in documents and it does this quite well.
If you find something which improves this GUI coming on that is fine but there is no hurry. I very much appreciate your attempts to help me.
Thank you
Uli
Several hours ago I pulled the NVidia card from mine and, after a zypper dup session, booted TW20210605 with and without nomodeset. Then I did the same with 15.2 and 15.3. Plymouth is installed on none of the three. I’m at a loss to recognize any difference among them. All are on FBDEV @1024x768 on a 1680x1050 display connected via VGA, with or without using nomodeset.
Yes, that was useful. Xorg logs are identical, there is no difference, so this is not graphical card issue.
I had never problems with the GUI.
It is not a GUI problem.
Booting without nomodeset, SDDM stops at
Jun 08 11:19:44 fft sddm[2040]: Starting...
Jun 08 11:19:44 fft sddm[2040]: Logind interface found
while booting with nomodeset it continues
Jun 08 11:31:42 fft sddm[1965]: Starting...
Jun 08 11:31:42 fft sddm[1965]: Logind interface found
Jun 08 11:31:42 fft sddm[1965]: Adding new display on vt 7 ...
Educated guess is - without nomodeset systemd (logind) expects KMS capable graphical device and so waits for it to appear; and SDDM waits for logind to allocate suitable device and hand it over.
I am not sure right now how exactly logind does it, but this just confirms that nomodeset is the right workaroud here (you get exactly the same Xorg setup in both cases anyway).
SDDM queries logind whether there are graphical devices suitable for display. Logind answer is based on whether there are devices with master-of-seat tag. This tag is assigned by udev rules to either KMS capable device or to framebuffer device if nomodeset is present on kernel command line. I am not sure how it worked for you in the past. Something must have changed. Did you use SDDM too?
but this just confirms that nomodeset is the right workaroud here
It is not workaround - it is actually the only correct fix given current state of affairs.