Bug 5336 - 'init' command does not work as intended
Summary: 'init' command does not work as intended
Status: RESOLVED FIXED
Alias: None
Product: General Runtime
Classification: Runtime
Component: General Runtime (show other bugs)
Version: 1.5
Hardware: x86 Multiple
: Medium normal
Target Milestone: 1.8 M4
Assignee: Aníbal Limón
QA Contact:
URL:
Whiteboard:
Depends on:
Blocks:
 
Reported: 2013-10-10 14:40 UTC by Stoicescu Cornel
Modified: 2015-03-23 16:13 UTC (History)
3 users (show)

See Also:
OS type for building Yocto: ---
Type of Regression: ---
Verified:
Documentation change: No (bug/feature does not impact docs)

Attachments
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Stoicescu Cornel 2013-10-10 14:40:54 UTC 
When in runlevel X and issuing command 'init Y', the system should cleanly migrate to runlevel Y. This behaviour does not happen in most cases using Yocto images.

Some examples of bad behavior:
1) In any image(testes core-image-sato, core-image-lsb-sdk) issuing command 'init 1' will result in a technical hang

2) In core-image-lsb-sdk images, from the default runlevel 5, issuing the sequence of commands: 'init 3' 'init 5' 'init 3' 'init 5' will result in an oprofile-server:1054 error(could not bind to the server. Address already in use).

3) In core-image-sato-sdk images issuing 'init 3' command from the GUI terminal is completely ignored.


NOTE: 'init 0' and 'init 6' commands correctlr shutdown and restart the system(during my tests)
Comment 1 Saul Wold 2014-05-12 17:49:30 UTC 
Is this still an issue and if so, can you verify if it's just a real HW (which 
machines) and/or Qemu?
Comment 2 Stoicescu Cornel 2014-05-27 07:15:34 UTC 
We will test this on meta-intel HW targets today. Core BSPs will be tested in the next few days as well and QEMU targets on the first weekly test. I will get as much feedback and post the results here.
Comment 3 Stoicescu Cornel 2014-06-04 09:40:56 UTC 
Verified on meta-intel 1.6 release candidates and issues happen as described.
Comment 4 Stephen K Jolley 2014-06-18 17:24:03 UTC 
Info Supplied, moved back out of NEEDINFO per RP.
Comment 5 Stoicescu Cornel 2014-07-16 10:08:43 UTC 
Also tested qemux86-64 with poky master:a5531a2b8983318b99c119a87b78a92cf84160bb and the issue is the same.
Comment 6 Aníbal Limón 2014-11-04 20:51:39 UTC 
Stoicescu,

I'm doing some debugging with qemux86-64/core-image-sato using master branch, i have some concerns.

1) core-image-sato init 1, i reproduce this but it seems that not hang only didn't display shell in the monitor output, i used serial and vm it's running.

$ runqemu qemux86-64 core-image-sato serial

This is the issue?

2) core-image-lsb sdk init 3 - init 5, i can't reproduce the problem do you have another information?

3) core-image-sato-sdk init 3, gives me the same problem that 1).
Comment 7 Stoicescu Cornel 2014-11-11 08:34:44 UTC 
Lucian, can you please help investigate the current status of the issues presented in this bug? Try to reproduce steps 1, 2, 3 from the first post.
Comment 8 Lucian Musat 2014-12-17 11:48:44 UTC 
Tried to reproduce this on 1.8 M1 (b813bdebb36501500e86fea5f7e15b4b15ea0902) Lenovo X220 laptop genericx86-64 and this is what happened:

1. Core-image-sato-sdk image hangs on init 1, 3 and 5. Works for init 0 and 6.
2. Core-image-lsb-sdk ignores init 3 and 5. Actually it tries the first time but fails with: 
"INIT: Switching to runlevel 3
cups: started scheduler
umount: /mnt/.psplash: not mounted"
and returns to console. After that init 3 and 5 are ignored.
Init 1 hangs at "INIT: no more processes left in this runlevel"
Init 0 and 6 works.