Opened 6 years ago

Closed 6 years ago

#780 closed defect (fixed)

Boot fails on Lenovo X250

Reported by: Jiri Svoboda Owned by: Jiri Svoboda
Priority: major Milestone: 0.8.0
Component: helenos/unspecified Version: mainline
Keywords: Cc:
Blocker for: Depends on:
See also:

Description

HelenOS (amd64) fails to boot bare metal on my Lenovo X250 laptop. Release 0.7.1 works fine and boots all the way up to GUI, with touchpad and keyboard working.

Release 0.7.2 fails to boot. It stops after printing a few lines of kernel boot messages. If I press a key, it prints out white question marks and produces more messages - with some servers starting and some error messages. Pressing more keys produces white question marks.

Error messages include:

ns: Unexpected clonable server
init: Error spawning /srv/tmpfs

The problem is still present in master/head.

Attachments (2)

01.jpg (195.8 KB ) - added by Jiri Svoboda 6 years ago.
Booting stops after a few lines of output
02.jpg (462.9 KB ) - added by Jiri Svoboda 6 years ago.
Error messages

Download all attachments as: .zip

Change History (6)

by Jiri Svoboda, 6 years ago

Attachment: 01.jpg added

Booting stops after a few lines of output

by Jiri Svoboda, 6 years ago

Attachment: 02.jpg added

Error messages

comment:1 by Jiri Svoboda, 6 years ago

Owner: set to Jiri Svoboda
Status: newaccepted

comment:2 by Jiri Svoboda, 6 years ago

I have a hunch this could be caused by the mirroring of the kernel console to the serial port, which was introduced in 0.7.2.

comment:3 by Jiri Svoboda, 6 years ago

It seems there are multiple problems. I focused on the main one, the boot failure.

Result of bisection: the problem manifests itself for me only after the changeset

commit 57d44dd9c17ddb49818d70775e58b45ccd3511fd
Author: Jiří Zárevúcky <jiri.zarevucky@nic.cz>
Date:   Tue Apr 10 20:51:14 2018 +0200

    Instead of using .interp section, determine loader by name.

The reason is that in my grub.cfg I set the command line to just the module name, e.g. 'loader' not '/boot/loader'. The problem was that resulting task name was '?' and the loader was not recognized.

The reason why the task name was garbage is a bug in multiboot parsing code. This is now fixed with commit b6d5e3137096b0cef6955a6398e292c7dc971d8a.

comment:4 by Jiri Svoboda, 6 years ago

Resolution: fixed
Status: acceptedclosed
Note: See TracTickets for help on using tickets.