Archlinux News: initscripts update - manual intervention required

[securitybreach]

Please manually delete /etc/profile.d/locale.sh before updating. If /etc/rc.conf fails in your login shell, please read the full announcement.Changes to locale handling:/etc/profile.d/locale.sh is now a static file that sources the correct config files in order to set your locale, rather than being generated at boot. The benefit of this is one less write to /etc, and it allows changes to the locale to take effect without rebooting (just relogin).We add support for /etc/locale.conf. The settings in this file takes precedence over /etc/rc.conf, and those who use shells that cannot source /etc/rc.conf are required to move to this new format. /etc/locale.conf contains a new-line separated list of variable assignments. The variables we support are LANG as well as the LC_* variables (with the exception of LC_ALL). The format is shared with systemd.

http://www.archlinux.org/news/initscripts-...ntion-required/I would suggest first backing up /etc/profile.d/locale.sh before deleting the file:

# cp /etc/profile.d/locale.sh /etc/profile.d/locale.sh.backup && rm /etc/profile.d/locale.sh

[V.T. Eric Layton]

Hmm... now I read this.

 

I did it a bit differently, but it seemed to work. I renamed locale.sh to locale.sh.old. I then updated the system. Afterwards, I deleted the newly created locale.sh and restored the locale.sh.old to locale.sh. I did NOT utilize the new rc.conf.pacnew, though. If I borked up, I guess I'll find out eventually. All seems OK for now.

 

I do NOT recommend doing it my way, as it is not the proper way to correct this issue.

[securitybreach]

The only line that changed in the rc.conf.pacnew was the LANG entry, well besides the obvious edits so you should not have a problem if you merge the files:

 

╔═ comhack@Cerberus 10:10 PM

╚═══ ~-> diff /etc/rc.conf /etc/rc.conf.pacnew

 

9a10

> # LANG in /etc/locale.conf takes precedence

26c27

---

> TIMEZONE="Canada/Pacific"

 

42c43

---

> MODULES=()

 

62c63

---

> HOSTNAME="myhost"

 

86,90c87,91

---

> interface=

> address=

> netmask=

> broadcast=

> gateway=

 

116,117c117,119

---

> # If you are sure nothing else touches your hardware clock (such as ntpd or

> # a dual-boot), you might want to enable 'hwclock'. Note that this will only

> # make a difference if the hwclock program has been calibrated correctly.

 

119c121,123

---

> # If you use a network filesystem you should enable 'netfs'.

> #

> DAEMONS=(syslog-ng network crond)

 

The locale.sh file is only needed if you are using non-bash terminal which I am pretty none of us are. This is the output when upgrading:

]If using non-bash-compatible shell, please set LANG in /etc/locale.conf,

as LOCALE in /etc/rc.conf no longer works.[/b]

 

Since the locale is already set by my /etc/rc.conf, I just deleted the file locale.sh after a reboot.

[V.T. Eric Layton]

Well, it's probably unrelated, but I can't seem to get my printer working in Arch. My CUPS daemon wasn't starting. Yet, it was in the daemons list in rc.conf. Weird. I'm tired. I'm back in Slack because I needed to print something. I'm heading to bed now. I'll troubleshoot the Arch printing issue tomorrow... and start a thread about it, if necessary.

 

Later...

[securitybreach]

Yeah I doubt that it is related. It is probably just a configuration change or something from an update. I do not presently have cups installed since I really dont have a a use for a printer anymore so I have not noticed anything. I would try restarting cups and checking the output:

rc.d restart cups

[V.T. Eric Layton]

I fixed it. Evidently, when I built this system, I forgot that I went from LPT1 (new mobo does not have legacy serial printer port) to USB for the printer. I must not have set it up in Arch at that time. Duh! I followed the Arch Wiki instructions for blacklisting usblp and then restarting/resetting-up CUPS and the printer. Works okee-dokee now.

[securitybreach]

Good deal

[amenditman]

Thanks for posting this Josh, I'm sure I would have never seen it in advance and then had to track it down after the fact.

[securitybreach]

Thanks for posting this Josh, I'm sure I would have never seen it in advance and then had to track it down after the fact.

No problem