[WARNING] Watch the initscripts 2009.07 upgrade

skottish · 2009-07-18 16:46:16

The initscripts upgrade, particularly in /etc/inittab, changed the behavior of how Arch boots on my system. If necessary, make sure that you update inittab before you reboot. This is the change (from diff /etc/inittab /etc/inittab.pacnew):

< c1:2345:respawn:/sbin/agetty -8 38400 tty1 linux
< c2:2345:respawn:/sbin/agetty -8 38400 tty2 linux
< c3:2345:respawn:/sbin/agetty -8 38400 tty3 linux
< c4:2345:respawn:/sbin/agetty -8 38400 tty4 linux
< c5:2345:respawn:/sbin/agetty -8 38400 tty5 linux
< c6:2345:respawn:/sbin/agetty -8 38400 tty6 linux
---
> c1:2345:respawn:/sbin/agetty -8 38400 vc/1 linux
> c2:2345:respawn:/sbin/agetty -8 38400 vc/2 linux
> c3:2345:respawn:/sbin/agetty -8 38400 vc/3 linux
> c4:2345:respawn:/sbin/agetty -8 38400 vc/4 linux
> c5:2345:respawn:/sbin/agetty -8 38400 vc/5 linux
> c6:2345:respawn:/sbin/agetty -8 38400 vc/6 linux

It only seems to have happened on my 64 bit install. Hmmm? Does anyone have any idea why my 32 bit install is one way and my 64 bit install is the other?

whoops · 2009-07-18 17:20:10

[WARNING] Watch the initscripts 2009.07 upgrade

Too late I guess, but thanks for the warning I should have read!

Hope this is related:

I don't really know much about that "boot stuff", so all I can say is that my arch64 doesn't boot with testing ATM. Says something like "spawning too fast, spawning to fast, spawning too fas bla bla something runlevel 3 something [finished|done|ſomething_I_forgot]"... takes about 10 minutes for the messages to appear, nothing else happens (hangs after/at boot). Setting runlevels by editing grub doesn't seem to work ATM either, but single user works.

(Also I just noticed, that I don't have any other means of writing something down than my computer - and maybe ketchup but I haven't been desperate enough for that - available here and my memory is crappy - which is why so is my error message citation. And I really start to wonder how I manage to constantly break & fix my system without gaining some sort of knowledge - it's astounding)

Last edited by whoops (2009-07-18 17:22:00)

skottish · 2009-07-18 17:25:58

If you can get into your system at all, which it sounds like you can, the fix is simple. Log in as root:

mv /etc/inittab /etc/inittab~
mv /etc/inittab.pacnew /etc/inittab

You can now boot into run level 3. With a little bit of editing, you can get back into 5 as the default.

foutrelis · 2009-07-18 18:15:52

skottish wrote:

It only seems to have happened on my 64 bit install. Hmmm? Does anyone have any idea why my 32 bit install is one way and my 64 bit install is the other?

If you hadn't made any changes to /etc/inittab on your 32bit install, the new file would simply replace the old one. Otherwise, a .pacnew file is created and you're expected to merge in any changes between the two.

skottish · 2009-07-18 18:27:56

foutrelis wrote:

skottish wrote:
It only seems to have happened on my 64 bit install. Hmmm? Does anyone have any idea why my 32 bit install is one way and my 64 bit install is the other?
If you hadn't made any changes to /etc/inittab on your 32bit install, the new file would simply replace the old one. Otherwise, a .pacnew file is created and you're expected to merge in any changes between the two.

That makes sense. Although, there should be some warning for those that have a modified inittab that their install is about to break. Off to Flyspray...

foutrelis · 2009-07-18 18:46:28

skottish wrote:

That makes sense. Although, there should be some warning for those that have a modified inittab that their install is about to break. Off to Flyspray...

It's always advisable to take note of the .pacnew warnings printed during upgrades (also written to /var/log/pacman.log) and apply the required changes afterwards. Maybe most of the time the .pacnew files can be ignored without this having any immediate consequences, but it's times like this that remind us to clean up after them.

Due to the possibility of having a lot of users breaking their system when the new initscripts package moves to [core], I think an announcement on the front page would help prevent many breakages and frustrated people.

skottish · 2009-07-18 18:53:50

foutrelis wrote:

skottish wrote:
That makes sense. Although, there should be some warning for those that have a modified inittab that their install is about to break. Off to Flyspray...
It's always advisable to take note of the .pacnew warnings printed during upgrades (also written to /var/log/pacman.log) and apply the required changes afterwards. Maybe most of the time the .pacnew files can be ignored without this having any immediate consequences, but it's times like this that remind us to clean up after them.
Due to the possibility of having a lot of users breaking their system when the new initscripts package moves to [core], I think an announcement on the front page would help prevent many breakages and frustrated people.

Normally I'm more careful with what I'm doing. What happened was the I could no longer mount any external devices. dmesg was clearly showing that the devices were being seen and no de-registration was happening, but there was no way to mount anything. At the same time udev was upgraded and wrongly figured that it just needed to be restarted. I closed my computer out and did other things, came back, and no more logging in.

Allan · 2009-07-19 01:26:29

I am going to adjust the initscripts package so that it automatically seds the relevant parts of your config file so hopefully this will keep people from getting themselves into trouble. The transition from vc/* to tty* was obviously not as smooth as I hoped...

pyther · 2009-07-19 01:45:54

Just how dumb do people need to be??? This is a really sad day. All I can say is I'm shocked.

Last edited by pyther (2009-07-19 01:51:17)

louipc · 2009-07-19 02:05:15

Allan wrote:

I am going to adjust the initscripts package so that it automatically seds the relevant parts of your config file so hopefully this will keep people from getting themselves into trouble. The transition from vc/* to tty* was obviously not as smooth as I hoped...

I am vehemently against this. Editing configuration files behind the user's back is against fundamental Arch principles. You are taking the control out of my hands by automatically editing that file. Provide a notice, a message, a pacnew file, or the sed line as an example command to run, but don't make the decision to edit the file.

brisbin33 · 2009-07-19 02:09:59

much agreed. "pacman never touches your config files". this is what attracted me to arch linux. do what you can to improve things; but IMHO don't break that philosophy.

Allan · 2009-07-19 02:19:05

I am against adjusting config files. However, the number of complaints I will receive for doing the sed is much, much less that the number of complaints I will get not doing it. And given I get pissed off with complaints and I would prefer to be less pissed off...

skottish · 2009-07-19 02:30:29

From my point of view this is a great topic. There's no argument that I should have been more diligent about this and this was preventable from me paying closer attention. But, it will serve as a public reminder that even though most .pacnew files will have little to no immediate relevance to most systems, it's still very important to take a few seconds and diff them.

keenerd · 2009-07-19 03:07:59

It would be pretty nifty if there were some way a package could contain simple tests. Something along the lines of "if (coming_from_version < a.b.c) then echo 'Critical update, important pacnew' ".

It might be possible to add this into the .PKG_INFO file, but parsing it could be a real PITA.

Allan · 2009-07-19 03:09:32

It is possible with a combination of install files and vercmp.

Ranguvar · 2009-07-19 03:16:45

It's close, but I'd favor going with sed, if only because the change from vc/* to tty* is AFAIK highly unlikely to interfere with user changes. Otherwise, I think the .pacnew approach is better.

Any info on why this change was made, though?

djgera · 2009-07-19 03:23:32

Ranguvar wrote:

Any info on why this change was made, though?

/dev/vc/ are from the age of devfs (linux-2.4), this not only apply to virtual consoles, also for others devices.

http://bugs.archlinux.org/task/11352

Last edited by djgera (2009-07-19 03:24:03)

LeoSolaris · 2009-07-19 17:39:55

I should have read this first as well. I looked at the .pacnew, and swapped my inittab... or so I thought. I think I hit S rather than R and suppressed the .pacnew rather than replacing it. C'est la vie.

Long live the Arch install disc! It is the best repair tool in my arsenal. Did y'all know that chroot'ing into an Arch install with even the newest Ubuntu disc will not work? It gave me an error on the chroot command. (I had to dig for the Arch disc, the Ubuntu disc was close at hand.)

brisbin33 · 2009-07-20 11:23:56

just an FYI:

so far, i've helped one user on irc and another on the forums. based on the forum post, it seems that if one neglects the /etc/inittab.pacnew file before rebooting, runlevel 1 does still work. Thus, a liveCD is not necessarily required.

hopefully this info makes someone's day a little easier

Allan · 2009-07-20 11:30:28

There is an updated package in [testing] that will copy the original /etc/inittab to inittab.pacsave and do the required sed line to keep the system booting. A big message is posted saying what has been done so the user can check everything went OK before rebooting.

u_no_hu · 2009-07-20 13:23:47

@Allan
It's always your choice... but i want to assure you that there are plenty of new users like me who like the arch way of doing things. We remain silent most of the time, so you are hearing only the new users who complain. Please don't take the slippery slope of making it easier/dumber because people complain about things breaking. Just publish a news item with complete details( and even a sed script for those who are too lazy ) and ignore the rest. If people who run a rolling release system can't even subscribe to a news feed, then i don't think you should bother about them.

Last edited by u_no_hu (2009-07-20 13:24:20)

Allan · 2009-07-20 13:33:57

I assure you that this decision was not taken lightly. The automatic editing of the config file was only done in this case as the breakage caused by not doing it could was very, very big while the actual fix is very, very simple and we can easily back up the original so there is no risk of damaging peoples configuration. Definitely do not take this as an indication that this is the path we are taking in the future. In fact, I would not expect to see a config file automatically changed again, ever.

LeoSolaris · 2009-07-20 19:44:33

Allan wrote:

In fact, I would not expect to see a config file automatically changed again, ever.

It was a minor change in config wording. The autochange keeps people from locking themselves out of their system. Seems like a no-brainer to me.

Just remember it's the exception that proves the rule. Being wise enough to know when to bend the rules is one of the things that I like about Arch's Dev team.

@brisbin33: I wish I had known that before going to all of the trouble of digging my install disc out of it's hole.

sfabius · 2009-10-21 00:28:44

I'm resurrecting this because I'm having the respawning problem (x64), but the inittab.pacnew is the same as initttab, and has:

c1:2345:respawn:/sbin/agetty -8 38400 tty1 linux
c2:2345:respawn:/sbin/agetty -8 38400 tty2 linux
c3:2345:respawn:/sbin/agetty -8 38400 tty3 linux
c4:2345:respawn:/sbin/agetty -8 38400 tty4 linux
c5:2345:respawn:/sbin/agetty -8 38400 tty5 linux
c6:2345:respawn:/sbin/agetty -8 38400 tty6 linux

I'll try changing to vc/*

skottish · 2009-10-21 00:58:07

sfabius wrote:

I'm resurrecting this because I'm having the respawning problem (x64), but the inittab.pacnew is the same as initttab, and has:
c1:2345:respawn:/sbin/agetty -8 38400 tty1 linux
c2:2345:respawn:/sbin/agetty -8 38400 tty2 linux
c3:2345:respawn:/sbin/agetty -8 38400 tty3 linux
c4:2345:respawn:/sbin/agetty -8 38400 tty4 linux
c5:2345:respawn:/sbin/agetty -8 38400 tty5 linux
c6:2345:respawn:/sbin/agetty -8 38400 tty6 linux
I'll try changing to vc/*

You may want to start another thread on this. The respawning too fast messages can also come up from other problems from within inittab.

Arch Linux

#1 2009-07-18 16:46:16

[WARNING] Watch the initscripts 2009.07 upgrade

#2 2009-07-18 17:20:10

Re: [WARNING] Watch the initscripts 2009.07 upgrade

#3 2009-07-18 17:25:58

Re: [WARNING] Watch the initscripts 2009.07 upgrade

#4 2009-07-18 18:15:52

Re: [WARNING] Watch the initscripts 2009.07 upgrade

#5 2009-07-18 18:27:56

Re: [WARNING] Watch the initscripts 2009.07 upgrade

#6 2009-07-18 18:46:28

Re: [WARNING] Watch the initscripts 2009.07 upgrade

#7 2009-07-18 18:53:50

Re: [WARNING] Watch the initscripts 2009.07 upgrade

#8 2009-07-19 01:26:29

Re: [WARNING] Watch the initscripts 2009.07 upgrade

#9 2009-07-19 01:45:54

Re: [WARNING] Watch the initscripts 2009.07 upgrade

#10 2009-07-19 02:05:15

Re: [WARNING] Watch the initscripts 2009.07 upgrade

#11 2009-07-19 02:09:59

Re: [WARNING] Watch the initscripts 2009.07 upgrade

#12 2009-07-19 02:19:05

Re: [WARNING] Watch the initscripts 2009.07 upgrade

#13 2009-07-19 02:30:29

Re: [WARNING] Watch the initscripts 2009.07 upgrade

#14 2009-07-19 03:07:59

Re: [WARNING] Watch the initscripts 2009.07 upgrade

#15 2009-07-19 03:09:32

Re: [WARNING] Watch the initscripts 2009.07 upgrade

#16 2009-07-19 03:16:45

Re: [WARNING] Watch the initscripts 2009.07 upgrade

#17 2009-07-19 03:23:32

Re: [WARNING] Watch the initscripts 2009.07 upgrade

#18 2009-07-19 17:39:55

Re: [WARNING] Watch the initscripts 2009.07 upgrade

#19 2009-07-20 11:23:56

Re: [WARNING] Watch the initscripts 2009.07 upgrade

#20 2009-07-20 11:30:28

Re: [WARNING] Watch the initscripts 2009.07 upgrade

#21 2009-07-20 13:23:47

Re: [WARNING] Watch the initscripts 2009.07 upgrade

#22 2009-07-20 13:33:57

Re: [WARNING] Watch the initscripts 2009.07 upgrade

#23 2009-07-20 19:44:33

Re: [WARNING] Watch the initscripts 2009.07 upgrade

#24 2009-10-21 00:28:44

Re: [WARNING] Watch the initscripts 2009.07 upgrade

#25 2009-10-21 00:58:07

Re: [WARNING] Watch the initscripts 2009.07 upgrade

Board footer