serial consoles not properly migrated from inittab to event.d

[Kyle McMartin]

Binary package hint: upstart

Entries in /etc/inittab, created by d-i, for ttyS0 on my zx6000 were not correctly migrated to /etc/event.d. Symptom is that I never get a tty on ttyS0.

The problem seems to be that upstart/debian/migrate-inittab.pl is producing lines "start on runlevel-2" which appear to be invalid. They should be "start on runlevel 2".

Debdiff attached.

[Kyle McMartin (kyle)]

In Progress (will wait for Scott's sign-off...) and severity set to medium, since if the user hadn't installed sshd, they'd be S.O.L. for logging in.

[Scott James Remnant (Canonical) (canonical-scott)]

We should probably check for existing jobs in /etc/event.d that have "runlevel-X" syntax which was used in edgy, and convert that to "runlevel X" as used in feisty.

[Kyle McMartin (kyle)]

Debdiff for checking existing jobs for your rubber stamping...

[Fabio Massimo Di Nitto (fabbione)]

Target for beta.

[Tollef Fog Heen (tfheen)]

Bringing milestone forward

[Scott James Remnant (Canonical) (canonical-scott)]

There's a few changes that need to be migrated, including the respawn/exec one; I think that a quick perl script like migrate-inittab is in order

[Colin Watson (cjwatson)]

Moving milestone forward now that this clearly isn't going to make Feisty.

[Jose Castillo (jcastill)]

I checked and there's no file named "ttyS0" so I checked the differences between our working Ultra 60 and the nonworking Sunblade150. I did found some differences, on the respawn.

Mainly the Sunblade150 (non working) reads:
respawn
/sbin/getty 38400 tty1exec /sbin/getty 38400 tty1

While the Ultra 60 (working) reads:
respawn
exec /sbit/getty 38400 tty1

So my idea is that someway the update readded the file without checking it was already there. (as to add the exec)

Finally, we have a working Sunblade150 on Feisty.

All this was made using video card not console.

[Daniel Hahler (blueyed)]

I can confirm what Jose reported. I have e.g.
  respawn
  /sbin/getty 38400 tty2exec /sbin/getty 38400 tty2
in my server's /etc/init.d/tty2.

I'll attach the used /etc/inittab file.

This seems to be reported in bug 95210 (dupe) originally.

[Onno Benschop (onno-itmaze)]

Based what I learnt and documented in bug #104038, I suspect that this is the problem line:

File: /usr/lib/upstart/migrate-inittab.pl (which I've attached so we can all look at the same file - mine comes from Feisty)

Likely faulty line 94:
     $job[$idx] =~ s/^(\s*respawn\s+).*/$1$process/;

I'm only able to deduce this (not being a native Perl speaker) based on the following argument:

Line 56 starts a foreach, which contains an if-then-else on line 60.

If the code was going through the else on line 100, the faulty tty lines would contain the phrase "stop on shutdown", which the examples available to me do not have.

That means the code is going through the top half of the if-then-else. (Which started on line 60).

The code comes to the if-then-else on line 93.

If it were to take the else on line 95, then there would be no issue because the 'exec' would be at the start of the line - which it isn't.

That means it is going through line 94 which I'm postulating contains some black magic Perl, which I do no yet understand - yay Perl Regex - :(

[Colin Watson (cjwatson)]

This bug is really about a different issue, not the respawn/exec migration breakage. See bug 95210 for the latter.

[Scott James Remnant (Canonical) (canonical-scott)]

I think we pretty much missed the boat on this one. dapper didn't have Upstart, and everything between dapper and hardy is now EOL. dapper->hardy will migrate properly anyway, and anyone bitten by this bug fixed their scripts by hand years ago.

What should learn from this? Don't promote engineers to managers? :p