32bit: kernel 4.16 fails to boot

English Install/Boot/Login
#1

hi,

just for info

when trying the latest kernel, logon does not proceed beyond grub,
stays with black screen and cursor blinking in top left had corner

no problems with, and still using, prior kernel-default-4.15.13-2.4.i586

waiting for the next update

cheers

info:
2018-04-10 05:56:43 CET+1
kernel-default-4.16.0-1.5.i586 bits: 32 Desktop: KDE Plasma 5.12.4
openSUSE Tumbleweed 20180406
Device: laptop System: TOSHIBA product: Satellite M60 v: PSM60E-0C801GGR serial: N/A
Mobo: TOSHIBA model: EBQ10 v: Null serial: N/A BIOS: TOSHIBA v: V1.60 date: 03/16/2006
CPU: Single core Intel Pentium M (-UP-) cache: 2048 KB speed: 1867 MHz (max)
Graphics: Advanced Micro Devices [AMD/ATI] RV410/M26 [Mobility Radeon X700]

#2

I assume that despite you say “logon”, you mean “boot”. When it stucks just after Grub there is way to go before even a logon prompt (CLI) or screen (GUI) appears.

Nothing to see when you press Esc key a.s.a.p. after Grub starts booting?

#3

I re-read your post. It seems that while you post in the help forum, you do not want help. Is that correct?

#4

Correct, post was advisory

If others have the 32bit 4.16 kernel up and running it would be of interest.

There’s not a boot problem with kernel 4.15

#5

Well, chances are that it’s not a general 32bit problem, but rather specific to certain hardware.

Although, Tumbleweed 32bit is completely untested since a long time and only provided as best-effort.

Anyway, I would recommend to file a bug report at bugzilla.opensuse.org with details about your hardware.

Trying some kernel parameters may be a good idea as well, e.g. “nomodeset” or “noacpi”.
And/or try kernel-vanilla to see whether it is an upstream problem or caused by some (open)SUSE specific patch.

#6

hi wolfi323,

on a normal boot the following is seen,

Loading Linux 4.16.0-1 default …
Loadig initial ramdisk …
_

and that how it stays until manual reboot. (That’s today)

Odd but recovery mode boots without a problem, using it now.
Tried regenerating grub and get the same result.

If any progress is made, it will be posted or a bug raised.

cheers

#7

Not odd at all, IMHO.
The point of recovery mode is to use failsafer settings so the system possibly still boots in case of driver problems.

I would try all additional kernel options from recovery mode to see which one may help.

But in principle I would try with “nomodeset” or “noacpi” first, as mentioned.

Finding a kernel option that helps would probably be good information for a bug report as well, as it narrows down the possible causes a bit.

#8

Hi, I am facing the same problem. However, in m case CLI appears, asking me to log in. And I just a beginner in Linux so I don’t know what to do next.

https://i.stack.imgur.com/nHU7C.jpg

#9

That’s not the same problem though, is it? :wink:
(especially as you boot kernel 4.15.3 on that picture)

In your case, it definitely looks like XOrg fails to start.
Are you using nvidia?
The current drivers do not work with kernel 4.16 (except the latest 396.xx beta, but that’s not available for 32bit anymore).

Although, the driver in the nvidia repo is patched to work since a few days.

And I just a beginner in Linux so I don’t know what to do next.

As a first step, try to select a “recovery mode” option in “Advanced Options” in the boot menu.
That should give you a working system at least.

Then open a new thread specific to your problem, with more information.
In particular what graphics card and driver you are using, and the file /var/log/Xorg.0.log.old.

There already have been a couple of threads about nvidia and kernel 4.16 already though, so you might also try to search the forum instead if you do use nvidia.

#10

Thank you very much for the reply…

#11

hi wolfi232,

when trying to disable drivers at the grub command line the result is always as follows,

Booting a command list
error: can’t find command ‘esetparams’
Press any key to continue…_

on a key press, the os is dumped back to the grub menu

No idea why ‘esetparams’ is being looked for

Any suggests appreciated.

Cheers

#12

‘esetparams’ looks like a typo. You probably want setparams.

I’m running kernel 4.16 on a hardware very similar to yours:
Fujitsu-Siemens Celsius H230
Pentium M 730 (32 bit only),
ATI Mobility FireGL V5000 (M26 chip)
and the rest of the first Centrino platform.

Hendrik

#13

hi Hendrik,

yes, the edit key obviously hit twice putting an ‘e’ at the start of the grub.cfg file

cheers

#14

hi wolfi323,

tried “nomodeset” and “noacpi”, but they had no effect
where are other kernel boot options to be found?

the boot is ok when the resume=/dev/sda3 is removed from the command line,
but its guessed this is basically booting recovery mode

cheers

#15

E.g. here: https://www.kernel.org/doc/html/v4.16/admin-guide/kernel-parameters.html

the boot is ok when the resume=/dev/sda3 is removed from the command line,
but its guessed this is basically booting recovery mode

Not at all.
Recovery Mode disables a lot more than just resume.

That finding means that trying to resume from /dev/sda3 causes your problem.
Maybe try to wipe out /dev/sda3 and see if it helps.

Do you actually use hibernate, or is this after a normal shutdown?
If the latter, I’d suggest to just hibernate once, that should overwrite the partition and remove possibly “corrupted” data.

#16

hi wolfi323,

thanks for the info and reference

with YaST- partitioner the swap file was deleted and then added, and the message occurred,

“MBR gap size is not enough to correctly to install bootloader”

The continue button was pressed anyway and the situation remains the some,
boots ok without resume with the new kernel,
boots ok with resume with the old kernel,

Is a bios update required?

No, neither hibernate or suspend have ever worked on this laptop. So its after a normal shutdown.

cheers

#17

I have an old acer emachine 32 bit laptop and there is no problem with the 4.16 kernel, however my machine only uses the pae kernel. However sddm does not work and I have to use another desktop manager (kdm, xdm, etc all work OK). So from my point of view there is nothing wrong with the 32 bit kernel itself.
Cheers
Uli

#18

Swap file, or swap *partition? :wink:

I didn’t mean that you should delete it, just wipe out the partion (with dd e.g. or mkswap).

Or as I wrote, do a hibernate, which would overwrite everything anyway, and see if that helps.

and the message occurred,

“MBR gap size is not enough to correctly to install bootloader”

The continue button was pressed anyway and the situation remains the some,
boots ok without resume with the new kernel,
boots ok with resume with the old kernel,

Is a bios update required?

This has nothing to do with the BIOS.

There’s not enough space before the 1st partition (MBR gap) to install the bootloader there.
This is the case if you use the old Windows partition scheme that created the first partition at block 63, which is not enough for current grub2 and bad for performance on modern drives anyway.
You’d need to repartition your hard disk.

Although, it normally should be possible to install grub2 (ist core.img) to the root partition instead, which should actually be done automatically in this case, but that needs to be supported by the filesystem.

No, neither hibernate or suspend have ever worked on this laptop. So its after a normal shutdown.

Then just remove the “resume=” parameter if it helps. In that case it’s pointless anyway.