freeze during boot after blank disk install

English Install/Boot/Login
#1

On an older Toshiba notebook (Satellite A-665, Intel i5, KDE) deleted all partitions and created new when installing oS 15.2. Several installation attempts failed when “unable to resolve download.opensuse.org”. Machine has wired Ethernet and Wi-Fi. Up to that point I had installed repositories when first prompted early in the process, after the LAN connection was detected. When I did not add repositories when prompted the install succeeded – once.
Then Yast installed the many updates, including 5 or 6 kernel patches.
Now the boot freezes and the underline cursor stops blinking after “[OK] Started Locale Service”. Same freeze in “safe Mode” from the grub menu. Have booted at least 6 times. Machine is unresponsive except that pressing a key will turn on the screen after it goes dark (screensaver). What is visible on screen is the boot activity.
Ran 15.1 on this machine for many months. Is 15.2 so different that this hardware no longer supports openSuse?
I am reluctant to migrate my other computers from 15.1 to 15.2 until this machine works well. How critical is the need to update BIOS before installing 15.2, as stated in the release notes? Have not updated the Toshiba BIOS recently. Have been unable to update the BIOS on an HP Omen because it lacks Windows, like all my computers.

#2

I’m in FL and often find download.opensuse.org for repo configuration infuriating. I sometimes avoid issues like you describe by specifying a specific mirror instead of d.o.o. These are all worth a try for Leap (but not necessarily for Tumbleweed):

I’ve usually been using gwdg.de lately, even though it’s in Europe. The rest are in North America AFAICT.

Failure to resolve may have nothing to do with download.opensuse.org. I would disable your router’s wifi, plug in an ethernet cable and try again before assuming it’s a mirror problem, and turn router wifi back on only after a successful installation.

Considering your success with prior versions, need for a BIOS update is suspect.

I have a Satellite older than yours. IIRC I managed a BIOS update without any help from windows 11 months ago, but have already forgotten all the details. I do see on my server the downloaded BIOS .EXE file has been extracted into a directory. I probably copied those files to some device the laptop could access while booted to MS-DOS in order to do the update. I always have something I can boot DOS from even in a laptop, though the need has been declining in recent years.

You seem to have successfully gotten a basic 15.2 installation complete and only need to find out how to eradicate the black screen hangup. Have you tried using any of Grub’s “Advanced Options”? What were the results?

Did you choose automatic user login during installation? That’s a bit of a can of worms when boot problems arise.

Disabling boot bling can sometimes resolve black screen trouble. At the Grub menu, strike the E key, then at the end of the line that begins linu, which usually wraps, append the string plymouth=0 before proceeding to boot. Does it help at all? If it does, you can make it permanent via /etc/default/grub, or just uninstall plymouth.

Exactly which Intel graphics you have, and its configuration, should be useful for further diagnosis. Please paste here if able input and output from

inxi -Ga

using [b]code tags ( # ] above input window) around your paste.

#3

No, I never use the auto login.

~> inxi -Ga
Graphics:
  Device-1: Intel Core Processor Integrated Graphics vendor: Toshiba driver: i915 
  v: kernel bus ID: 00:02.0 chip ID: 8086:0046 
  Device-2: Chicony CNF9055 Toshiba Webcam type: USB driver: uvcvideo 
  bus ID: 1-1.4:3 chip ID: 04f2:b1d6 
  Display: x11 server: X.Org 1.20.3 compositor: kwin_x11 driver: modesetting 
  unloaded: fbdev,vesa alternate: intel display ID: :0 screens: 1 
  Screen-1: 0 s-res: 1366x768 s-dpi: 96 s-size: 361x203mm (14.2x8.0") 
  s-diag: 414mm (16.3") 
  Monitor-1: LVDS-1 res: 1366x768 hz: 60 dpi: 101 size: 344x194mm (13.5x7.6") 
  diag: 395mm (15.5") 
  OpenGL: renderer: Mesa DRI Intel Ironlake Mobile v: 2.1 Mesa 19.3.4 
  direct render: Yes
#4

I sense a kernel regression due to the presence of the webcam. I remember seeing these webcams in 10-12 year old laptops causing trouble, but it’s been quite a while.

It’s not clear to me when your laptop’s unresponsiveness begins. Is it after logging into a Plasma session? Which Plasma session are you running? If Wayland, switch to Xorg, or vice versa. Wayland seems to cause people more trouble than Xorg, as if Wayland isn’t actually ready for official release.

Next thing I would try is opening an IceWM session to see if the problem is with KDE/Plasma rather than kernel or X itself. If you have any session types besides Plasma and IceWM to choose in your login manager, try those too.

Another thing to try is disable the webcam. Above output indicates it’s using a USB driver, which if the Chicony is a USB device, unplug it. If it’s internal, IIRC, in order to disable we also need to see output from:

xrandr --listproviders

and then follow the instruction in this kernel document. Does it make any difference if you totally block the camera lens from input?

Something I would try in any event is switching the X DDX driver. Give this primer a read and make the switch from modesetting to intel to see if it helps. If it doesn’t, I’d definitely report a bug as described here and indicate it’s a regression, with the older kernel still working as expected. Note which kernel version works and which does not. You’ll probably be asked for Xorg.0.log from either /var/log/ or ~/.local/share/xorg/ from both a working kernel and a non-working kernel, so go ahead and attach those to the bug. While waiting for feedback on the bug report, do some searching for laptop Intel graphics webcam to see if you can find a solution or other indications that you’re not the first to encounter this.

Before doing any more updating that might include another new kernel you should modify /etc/zypp/zypp.conf the line beginning “multiversion.kernels = latest,latest-1,running” to expressly exclude from removal the working kernel as instructed in the comments preceding that line.