Hi,

This bug was filed against cauldron, but we do not have cauldron at the moment.

Please report whether this bug is still valid for Mageia 2.

Thanks :)

Cheers,
marja

Keywords: (none) => NEEDINFO

@ Luc

This bug was filed agains old cauldron, from before Mageia 2 release

Is this bug still valid for Mageia 2 and/or for *current* cauldron.

Please tell us within two weeks from now. If you don't reply again, we'll have to close this bug as old.

CC: (none) => marja11

Hi,

The inittab installed by default has not been fixed.
This bug affects only mga2's users who still use sysvinit (iniscripts) instead of systemd (which is the default init system for mga2).
It's not valid for current cauldron as we will support only systemd for mga3.

regards,
Luc

Keywords: NEEDINFO => (none)
Version: Cauldron => 2

The proposed fix makes sense, so I've committed a fix for this to SVN, but haven't cut an RPM yet or tested it (I don't run sysvinit on my mga2 machine). I imagine the following simple test procedure should work to verify it:

1) Install sysvinit-legacy with 'sudo urpmi sysvinit-legacy'
2) Reboot.
3) System should boot into X11 as before. Hit Ctrl-Alt-F2 and you should see a text login console. Hit Ctrl-Alt-F1 and you should be back at the X11 login window.

CC: (none) => dan
Assignee: bugsquad => dan

I've verified the test case in comment #4. The failing case caused the keyboard to lock up after selecting Ctrl-Alt-F1, preventing further access to the system. The expected behaviour in this case is to switch to X11 after Ctrl-Alt-F1. This is such a serious issue that it's clear to me that few people would have consciously switched to sysvinit on Mga2.

Whiteboard: (none) => has_procedure

Cleaning up after testing consists of:

sudo urpmi systemd-sysvinit

This will ask to remove sysvinit-legacy, which you should say Y to. Installing sysvinit-legacy (comment #4) asks something similar about systemd-sysvinit, which should also be replied to with Y. Note that this assumes that the system under test is running with systemd, of course.

initscripts-9.34-20.1.mga2 is in updates_testing and available to test.

after this update is run, the inittab changes to not have X11 on tty1... but at the same time, the default runlevel goes back to 3, thus breaking X11 in the first place.

please revert this update!

the real fix would be to allow the component that does the change to 5 (i presume something in installer or XFdrake) to also remove the getty on tty1.

to fix an annoyance, you're breaking X11...

i'd rather have this as wont_fix rather than fixed like this

CC: (none) => alien

Unfortunately, this fix didn't get through the QA process before another fix was pushed and dragged this one with it. I didn't have any troubles with it, but I'm only one data point.

It's not clear to me what the issue is. Are you saying that the issue is that the default runlevel is now 3 when it used to be 5? That's the case for the base initscripts-9.34.tar.bz2 package as well as the Mageia package. I don't know how long it's been that way, but we've been on 9.34 for two years so I imagine it's been that way for at least that long.

due to the change of inittab wrt to tty1 having no getty... (which is bad due to the default runlevel being 3 in the first place)

This means the inittab is updating and thus changes the runlevel back to default.

i believe that during installation runlevel is modified to have 5?


the effect is that if you have a default installation (runlevel 3), you don't have a getty on tty1... which is bad.

the other effect is that if you have a regular installation with graphic (runlevel 5), after update, you get back to runlevel3. (and since there's no getty on tty1... not good).

in any case, please revert the change immediately, so that people who install mga2 and then get all the updates, won't have a broken system.

allthough maybe the update needs to be removed from mirrors and redone in a higher version. (without modifying inittab)

(In reply to AL13N from comment #10)
> 
> This means the inittab is updating and thus changes the runlevel back to
> default.
> 
[...]
> 
> the other effect is that if you have a regular installation with graphic
> (runlevel 5), after update, you get back to runlevel3. (and since there's no
> getty on tty1... not good).
> 

nope
/etc/inittab is installed with %config(noreplace) (initscripts.spec line 428), so on update, an inittab with runlevel 5 is not updated. The new inittab is installed as /etc/inittab.rpmnew.

(In reply to AL13N from comment #10)
> due to the change of inittab wrt to tty1 having no getty... (which is bad
> due to the default runlevel being 3 in the first place)
> 
> This means the inittab is updating and thus changes the runlevel back to
> default.
> 
> i believe that during installation runlevel is modified to have 5?

Yeah a graphical install will tweak inittab to be runlevel 5.

It should really also comment out the tty1 getty and it be reinstated, but frankly this is something that would need fixed in the installer which is not going to happen as an update.

> the effect is that if you have a default installation (runlevel 3), you
> don't have a getty on tty1... which is bad.

Well, the "default" installation is to use systemd and thus inittab contents are completely irrelevant, but if you customise your install to install sysvinit, not systemd, then yes, this problem occurs.
 
> the other effect is that if you have a regular installation with graphic
> (runlevel 5), after update, you get back to runlevel3. (and since there's no
> getty on tty1... not good).

Again, this wouldn't be a "regular" installation, but a customised one.

> in any case, please revert the change immediately, so that people who
> install mga2 and then get all the updates, won't have a broken system.
> 
> allthough maybe the update needs to be removed from mirrors and redone in a
> higher version. (without modifying inittab)

Being honest, this probably affects a very small number of installs. 

That said the line *should* just be specified as:

1:23:respawn:/sbin/mingetty tty1
  rather than the original
1:2345:respawn:/sbin/mingetty tty1

i.e. only show the getty at runlevels 2 and 3 and not in runelevels 4 and 5.

and yet it still proposed the question to me... which normal users would have likely said: ok

the point is that the default shipping now has runlevel 3, but no getty. which is not good.

and the other point is that this bug should've not be solved by having no getty on tty1, but fixing the in XFdrake.

and the 3rd point is that stuff that wasn't QA'd shouldn't have been pushed through anyway...

(In reply to Colin Guthrie from comment #12)
> (In reply to AL13N from comment #10)
> > due to the change of inittab wrt to tty1 having no getty... (which is bad
> > due to the default runlevel being 3 in the first place)
> > 
> > This means the inittab is updating and thus changes the runlevel back to
> > default.
> > 
> > i believe that during installation runlevel is modified to have 5?
> 
> Yeah a graphical install will tweak inittab to be runlevel 5.
> 
> It should really also comment out the tty1 getty and it be reinstated, but
> frankly this is something that would need fixed in the installer which is
> not going to happen as an update.

that's what i said... i'd rather have WONFIX for this bug than to this "fix" which doesn't even work... i definately don't have the problem stated above. which is not something you have if you have a "default installation anyway"

> > the effect is that if you have a default installation (runlevel 3), you
> > don't have a getty on tty1... which is bad.
> 
> Well, the "default" installation is to use systemd and thus inittab contents
> are completely irrelevant, but if you customise your install to install
> sysvinit, not systemd, then yes, this problem occurs.

of course... unless this is an mga1 upgrade, such as in my case...

> > the other effect is that if you have a regular installation with graphic
> > (runlevel 5), after update, you get back to runlevel3. (and since there's no
> > getty on tty1... not good).
> 
> Again, this wouldn't be a "regular" installation, but a customised one.

or an mga1 upgrade

> > in any case, please revert the change immediately, so that people who
> > install mga2 and then get all the updates, won't have a broken system.
> > 
> > allthough maybe the update needs to be removed from mirrors and redone in a
> > higher version. (without modifying inittab)
> 
> Being honest, this probably affects a very small number of installs. 

and all the mga1 upgrades....

> That said the line *should* just be specified as:
> 
> 1:23:respawn:/sbin/mingetty tty1
>   rather than the original
> 1:2345:respawn:/sbin/mingetty tty1
> 
> i.e. only show the getty at runlevels 2 and 3 and not in runelevels 4 and 5.

still, this "bugfix" bypassed QA, and caused issues...

i'd like it to be removed from mirrors and a new one issued that doesn't contain this "bugfix" but does contain the later bugfixes. and preferably have a higher version release than the one issued.

(In reply to AL13N from comment #14)
> i'd like it to be removed from mirrors and a new one issued that doesn't
> contain this "bugfix" but does contain the later bugfixes. and preferably
> have a higher version release than the one issued.

Which is basically just another update. There is no need to make this sound over-dramatic by talking about "removing it from the mirrors" etc. We just need to issue another update and everything happens automatically.

If you can fix this and issue such and update that's great, otherwise perhaps Dan can and finally, failing that, I will do it next week.

Actually I've just submitted a new build to updates_testing for this.

Please let me know and we can ask QA/Secteam to push it through.

(In reply to Colin Guthrie from comment #15)
> (In reply to AL13N from comment #14)
> > i'd like it to be removed from mirrors and a new one issued that doesn't
> > contain this "bugfix" but does contain the later bugfixes. and preferably
> > have a higher version release than the one issued.
> 
> Which is basically just another update. There is no need to make this sound
> over-dramatic by talking about "removing it from the mirrors" etc. We just
> need to issue another update and everything happens automatically.

i thought that changing inittab again, might trigger it again?

the idea for me was that if people would be installing an mga2 and then applying all updates, that they don't break X11.

if this is another update that modifies inittab back, won't it just trigger the same problem?

(In reply to AL13N from comment #17)
> (In reply to Colin Guthrie from comment #15)
> > (In reply to AL13N from comment #14)
> > > i'd like it to be removed from mirrors and a new one issued that doesn't
> > > contain this "bugfix" but does contain the later bugfixes. and preferably
> > > have a higher version release than the one issued.
> > 
> > Which is basically just another update. There is no need to make this sound
> > over-dramatic by talking about "removing it from the mirrors" etc. We just
> > need to issue another update and everything happens automatically.
> 
> i thought that changing inittab again, might trigger it again?

Well a new inittab should just result in an inittab.rpmnew file. If the user has consolidated the previous update, then they will also have to consolidate this one.

> the idea for me was that if people would be installing an mga2 and then
> applying all updates, that they don't break X11.

I'm not sure I follow the problem specifically. If they install and then apply updates they will get an inittab.rpmnew. If they install from online sources, then they will not get an rpmnew.
 
> if this is another update that modifies inittab back, won't it just trigger
> the same problem?

It'll put a .rpmnew file, but the only circumstance where this is problematic is when someone has installed a new mga2 with online media. In that case the user will have the "bad" inittab, but will get a .rpmnew file.

I really don't think it's worth while doing anything more advanced than that although if you want to add a %post check on the file for the comment and then apply some sed magic you are more than welcome to make that change. Personally I don't think it's worth it.

(In reply to Colin Guthrie from comment #18)
> (In reply to AL13N from comment #17)
> > (In reply to Colin Guthrie from comment #15)
> > > (In reply to AL13N from comment #14)
> > > > i'd like it to be removed from mirrors and a new one issued that doesn't
> > > > contain this "bugfix" but does contain the later bugfixes. and preferably
> > > > have a higher version release than the one issued.
> > > 
> > > Which is basically just another update. There is no need to make this sound
> > > over-dramatic by talking about "removing it from the mirrors" etc. We just
> > > need to issue another update and everything happens automatically.
> > 
> > i thought that changing inittab again, might trigger it again?
[...]

That's not what i mean...

the problem is really that if you have a mga1 upgraded to mga2, and update graphically, that you end up with a popup window that says: you need to inspect inittab. there you get 2 choices, stick with the old or get the new one.

the new one will have runlevel 3, thus choosing the new, (what people who don't know any better will do) you will end up without X11 (and no getty on tty1 either)


after this fix is validated,

if people upgrade or have upgraded to mga2 and now apply updates graphically... 

with the fixed package now shipped, will they also get a popup telling us to inspect inittab? or will they not get it? if they don't get a popup telling to inspect inittab since there's only a local change, that would be good, otherwise they would wind up without X11 too.

(In reply to AL13N from comment #19)
> (In reply to Colin Guthrie from comment #18)
> > (In reply to AL13N from comment #17)
> > > (In reply to Colin Guthrie from comment #15)
> > > > (In reply to AL13N from comment #14)
> > > > > i'd like it to be removed from mirrors and a new one issued that doesn't
> > > > > contain this "bugfix" but does contain the later bugfixes. and preferably
> > > > > have a higher version release than the one issued.
> > > > 
> > > > Which is basically just another update. There is no need to make this sound
> > > > over-dramatic by talking about "removing it from the mirrors" etc. We just
> > > > need to issue another update and everything happens automatically.
> > > 
> > > i thought that changing inittab again, might trigger it again?
> [...]
> 
> That's not what i mean...
> 
> the problem is really that if you have a mga1 upgraded to mga2, and update
> graphically, that you end up with a popup window that says: you need to
> inspect inittab. there you get 2 choices, stick with the old or get the new
> one.
> 
> the new one will have runlevel 3, thus choosing the new, (what people who
> don't know any better will do) you will end up without X11 (and no getty on
> tty1 either)

OK, so that's always been a problem (replacing a rl5 inittab with a rl3 one, not the no getty on tty1) as the initab of any graphical install is "modified", this .rpmnew dialog should always show up.

> after this fix is validated,
> 
> if people upgrade or have upgraded to mga2 and now apply updates
> graphically... 
> 
> with the fixed package now shipped, will they also get a popup telling us to
> inspect inittab? or will they not get it? if they don't get a popup telling
> to inspect inittab since there's only a local change, that would be good,
> otherwise they would wind up without X11 too.

Yes they will end up with the same problem again, but I'm still struggling to see this as something new... AFAICT, a .rpmnew and a popup has always occurred since forever.

And keep in mind that any upgrades to mga2 should default to systemd anyway (the sysvinit package was renamed to legacy-sysvinit so we could replace it with systemd-sysvinit automatically), so this problem should be affecting only a very small subset of users who have gone out of their way to avoid systemd. That being the case, a little inittab modification shouldn't be beyond them - they are after all specifically choosing to use an inittab-based system.

i had hoped that since the new inittab would be identical to the original one except with only a local modification that it wouldn't trigger the dialog. and keep the modifications, since the merge would be painless.

anyway, the fact that after this change you don't even have getty on tty1 is the new problematic part.

i'm pretty sure i did from mga1 to mga2 an urpmi upgrade and didn't change anything... thought i must admit not to be very sure...

let's hope the validation goes nicely then.

This message is a reminder that Mageia 2 is nearing its end of life.
Approximately one month from now Mageia will stop maintaining and issuing updates for Mageia 2. At that time this bug will be closed as WONTFIX (EOL) if it remains open with a Mageia 'version' of '2'.

Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Mageia version prior to Mageia 2's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Mageia 2 is end of life.  If you would still like to see this bug fixed and are able to reproduce it against a later version of Mageia, you are encouraged to click on "Version" and change it against that version of Mageia.

Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Mageia release includes newer upstream software that fixes bugs or makes them obsolete.

-- 
The Mageia Bugsquad

Mageia 2 changed to end-of-life (EOL) status on ''22 November''. Mageia 2 is no
longer maintained, which means that it will not receive any further security or
bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of Mageia
please feel free to click on "Version" change it against that version of Mageia
and reopen this bug.

Thank you for reporting this bug and we are sorry it could not be fixed.

--
The Mageia Bugsquad

Status: NEW => RESOLVED
Resolution: (none) => OLD