Log messages show the following errors in the syslog.
[158492.039848] udevd[12606]: failed to execute '/lib/udev/socket:@/org/freedesktop/hal/udev_event' 'socket:@/org/freedesktop/hal/udev_event': No such file or directory
This is due to deprecated syntax used by hal in the /lib/udev/rules.d/90-hal.rules file. The "+=" syntax is deprecated.
Solution: Remove hal. The Debian hal maintainer reports in Bug#726374#10 that hal is now deprecated. Nothing should depend upon hal anymore. If installing a new Jessie system hal would not be installed anymore. Therefore we should now purge hal to clean up this left behind bit of system lint.
apt-get purge hal
Probably want to 'dpkg -l | grep hal' and purge all related packages.
Update! George reports this following from his laptop.
You recommend removing hal. I tried that on my wheezy laptop in preparation for upgrading, and find that sleepd (or kin) on wheezy will then put the laptop to sleep, even if it is on AC power. Re-install hal, and it stays awake while plugged in.
Looking at the sleepd package, it seems that its Recommends: of hal has gone away in jessie, so things might just work correctly there. It looks like it's switched from hal to upower (in addition to apm and acpi). Sounds like something to experiment with.
Some background on the problem is available here.
http://lists.debian.org/debian-devel-announce/2009/09/msg00003.html http://lists.debian.org/debian-devel-announce/2010/05/msg00009.html http://people.skolelinux.org/pere/blog/Debian_init_d_boot_script_example_for_rsyslog.html A good and quite accurate rant against systemd. http://wizardofbits.tumblr.com/post/45232318557/systemd-more-like-shit-stemd Tom H wrote: This thread https://lists.debian.org/debian-devel/2013/10/msg00444.html lead to this thread https://lists.debian.org/debian-devel/2013/10/msg00651.html Russ Allberry https://lists.debian.org/debian-devel/2012/02/msg00911.html https://lists.debian.org/debian-devel/2012/02/msg01079.html https://lists.debian.org/debian-devel/2012/04/msg00638.html https://lists.debian.org/debian-devel/2013/07/msg00456.html Ben Hutchings https://lists.debian.org/debian-devel/2012/05/msg00263.html Roger Leigh (sysvinit developer) https://lists.debian.org/debian-devel/2012/05/msg00267.html Petter Reinholdtsen (sysvinit developer) https://lists.debian.org/debian-devel/2012/02/msg01043.html http://judecnelson.blogspot.com/2014/09/systemd-biggest-fallacies.html http://www.troubleshooters.com/linux/systemd/lol_systemd.htm http://www.troubleshooters.com/linux/systemd/debating.htm Combatting revisionist history http://forums.debian.net/viewtopic.php?f=20&t=120652&p=570371 http://skarnet.org/software/s6/why.html http://www.shroomery.org/forums/showflat.php/Number/21616608 http://without-systemd.org/wiki/index.php/Main_Page http://without-systemd.org/wiki/index.php/How_to_remove_systemd_from_the_Netinst_CD http://without-systemd.org/wiki/index.php/How_to_remove_systemd_from_a_Debian_jessie/sid_installation https://lists.debian.org/debian-ctte/2013/12/threads.html
Also available as http://bugs.debian.org/727708 but it is too long for the web browser since it is all in one page. I suggest pulling the bug as a mailbox and browsing the discussion that way.
wget -O bug_727708.mbox "http://bugs.debian.org/cgi-bin/bugreport.cgi?mboxmaint=yes;mbox=yes;bug=727708"
Really good resource. https://ewontfix.com/14/
The systemd package installs /usr/lib/sysctl.d/50-default.conf that disables SysRq and makes other sweeping system wide configuration changes outside of its domain. The systemd package maintainers, like the GNOME maintainers, argue that Debian should do whatever the upstream wants everywhere regardless of applicability. There is no check to balance them. How is disabling SysRq a good thing?
I filed this bug Bug#735002. But it was closed without discussion as a duplicate of Bug#725422. That bug had been filed and closed without being fixed or even acknowledged as being a problem. Argh! The systemd maintainers are infuriating!
On Wheezy: cat /proc/sys/kernel/sysrq 438 On Jessie: cat /proc/sys/kernel/sysrq 16
According to https://www.kernel.org/doc/Documentation/sysrq.txt this maps to:
0 - disable sysrq completely
1 - enable all functions of sysrq
>1 - bitmask of allowed sysrq functions (see below for detailed function
description):
2 = 0x2 - enable control of console logging level
4 = 0x4 - enable control of keyboard (SAK, unraw)
8 = 0x8 - enable debugging dumps of processes etc.
16 = 0x10 - enable sync command
32 = 0x20 - enable remount read-only
64 = 0x40 - enable signalling of processes (term, kill, oom-kill)
128 = 0x80 - allow reboot/poweroff
256 = 0x100 - allow nicing of all RT tasks
Therefore by default sync is now enabled but all other actions are disabled.
Change this by setting kernel.sysrq in sysctl or otherwise.
echo 1 >/proc/sys/kernel/sysrq And probably creating /etc/sysctl.d/sysrq.conf with: kernel.sysrq=1
Except that the above won't work. It depends upon the version of systemd. It appears that earlier versions require the override to happen early later versions require it to be late. To be safe you need to have two copies of the file to work with both versions. That is nasty.
/etc/sysctl.d/00-sysrq.conf /etc/sysctl.d/zz-sysrq.conf
Same thing with kernel.core_uses_pid=1. It isn't that this is not a good value. It is a fine choice. The problem is that it is not within the realm of the systemd package to set it. Should systemd choose my MTA to be Postfix? That is also a very reasonable thing and so who should complain? Anyone who doesn't use Postfix. Should systemd also choose to install anacron automatically? Should systemd choose to install a iptables firewall rules automatically? Should systemd also choose to install fail2ban automatically?
What is the difference between making any of these choices and the ones systemd just made? Nothing that I can see. That the values are reasonable is not the point. The point is that systemd should not be setting those values because they are outside of the its domain.
Look through /usr/lib/sysctl.d/50-default.conf and determine what setting you as the local admin want to see for each of those settings. Override those settings as needed.
This entire file should be removed from the package. If that doesn't happen then the entire file should be diverted away. This can be done as a local admin action. It is sufficient to make sure it does not end with a .conf suffix so that sysctl will ignore it.
dpkg-divert --divert /usr/lib/sysctl.d/50-default.conf.systemd.disabled --rename /usr/lib/sysctl.d/50-default.conf
To return to sysvinit and remove systemd perform the following.
# cat > /etc/apt/preferences.d/no-systemd <<EOF Package: systemd-sysv Pin: release o=Debian Pin-Priority: -1 EOF
apt-get install sysvinit-core sysvinit sysvinit-utils ...reboot... apt-get remove --purge --auto-remove systemd ...reboot...
Now that Jessie is released the release notes on this topic are available. If one wants to avoid converting to systemd on upgrade then install a local preferences file as described above before performing the upgrade. Here is a direct link to the official reference.
https://www.debian.org/releases/stable/i386/release-notes/ch-information.en.html#systemd-upgrade-default-init-system
The /etc/pam.d/login file used to contain:
It now contains.session optional pam_motd.so motd=/run/motd.dynamic session optional pam_motd.so
session optional pam_exec.so type=open_session stdout /bin/uname -snrvm session optional pam_motd.so
That uname call is now hard coded and cannot be suppressed at login time. Previously ~/.hushlogin can be used to silence the motd at login time. And it still does suppress motd. But it does not suppress the uname which used to be part of it.
I am commenting out that line.
#session optional pam_exec.so type=open_session stdout /bin/uname -snrvm session optional pam_motd.so
I am not sure of the exact problem. But a CentOS 6 image that boots okay under the previous version now hangs at boot time. Something has changed. Need to figure this out sometime. Newly built images run okay. With previous major upgrades I have needed to make changes to the machine config to roll with the changes. I expect something like that has happened again.
The new system has more firmware removed. If you need the nonfree firmware to boot then you might want to install from the unofficial cd image that includes the nonfree firmware in it. See https://wiki.debian.org/Firmware
http://cdimage.debian.org/cdimage/unofficial/non-free/cd-including-firmware/
Update: I think this is now fixed in the released Jessie. It was a problem for Testing.
See Bug#747195 https://bugs.debian.org/747195 for details. This must be set after the upgrade. I think if no changes have otherwise been made to this file that it will be hands-off. Needs testing.
listen.owner = www-data listen.group = www-data
Adobe Flash is no longer supported by Adobe. Flash sites are using newer versions than work in the current version of Adobe Flash available. Google supports Flash in Chrome. So how to support newer Flash to be able to view today's Flash sites in Chromium? Extract it from Chrome.
The new contrib installer is pepperflashplugin-nonfree. It downloads Chrome from Google. It unpacks it. It then makes the included Flash player available for use in Chromium.
apt-get install pepperflashplugin-nonfree
The default value of PermitRootLogin has changed from "yes" to "without-password". The reasoning is documented in the README.Debian file which references https://bugs.debian.org/298138 and https://bugzilla.mindrot.org/show_bug.cgi?id=2164 .
/usr/share/doc/openssh-server/README.Debian.gz https://bugs.debian.org/298138 https://bugzilla.mindrot.org/show_bug.cgi?id=2164
If you use aptitude then the following configuration makes it more sane. Otherwise it favors removal over upgrade and always wants to remove half of the world. https://lists.debian.org/543FF3BD.1020609@zen.co.uk
Aptitude::ProblemResolver {
SolutionCost "priority, removals, canceled-actions";
}
I still need to understand the ramifications but scroll-up and scroll-down have been replaced with scroll-up-command and scroll-down-comand. http://lists.gnu.org/archive/html/help-gnu-emacs/2015-01/msg00440.html
The command `scroll-up' is indeed older, and it is still usable. It is, in fact, the core of the `scroll-up-command' implementation. (In Emacs, it is often the case that you can use a command non-interactively, though this is sometimes explicitly not recommended for certain commands.) `scroll-up-command' was added in Emacs 24.1, to (a) retain the `scroll-up' behavior as a separate function, and yet (b) provide additional behavior when you scroll interactively, in particular the handling of the new (in 24.1) option `scroll-error-top-bottom'.
Just putting this following as a placeholder for further processing later. Basically the quote characters in info changing to unicode quotes so that they are then hard for traditionalists to search for.
#16292 - http://debbugs.gnu.org/cgi/bugreport.cgi?bug=16292
info docs now contain single straight quotes instead of `'
#13131 - http://debbugs.gnu.org/cgi/bugreport.cgi?bug=13131
Allow curly quotes to be found by searching for straight quotes?
#16439 - http://debbugs.gnu.org/cgi/bugreport.cgi?bug=16439
Highlighting of strings within Info buffers
#13228 - http://debbugs.gnu.org/cgi/bugreport.cgi?bug=13228
Request for highlighting back-quote/quote pair notation
gpgv 1.4.18-5 has changed and now requires the file argument for a detached signature. Unfortunately medley used the previous form. Meaning medley 0.5 will not work on Jessie with gpgv 1.4.18-5 or later.
The myhostname defaults change. This won't affect us because we always set myhostname directly but I wanted to document the change.
rwp@torpid:~$ postconf -d myhostname myhostname = torpid.localdomain
In Jessie 8 this becomes
bob@hysteria:~$ postconf -d myhostname myhostname = hysteria.proulx.com
Previously Debian had shipped a modified fastcgi_params files that included SCRIPT_FILENAME set in it. The upstream version of this file did not contain this setting. I am sure that people must have complained. Or something. In Jessie the unmodified upstream version of this file is shipped without the SCRIPT_FILENAME setting. This completely breaks any previous php5-fpm configuration which requires SCRIPT_FILENAME to be set.
The old setting in fastcgi_params:
fastcgi_param SCRIPT_FILENAME $request_filename;
The new setting in fastcgi.conf:
fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
The usual use was to "include fastcgi_params:". Now that needs to either switch to "include fastcgi.conf;" or to include an inline setting of SCRIPT_FILENAME in the config. If you include SCRIPT_FILENAME in the section then it works either way. That is what I have decided to do. I am putting it after the include in case the order matters.
fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
For some reason or another bootlogd is messed up for me after the upgrade. Twice now I have found the three /etc/init.d/*bootlogd* scripts moved to a .dpkg-old name and disabled. I purged and re-installed the bootlogd and cleaned those files to fix it. Those three files are listed as conffiles and get special dpkg handling.
/etc/init.d/bootlogd /etc/init.d/stop-bootlogd /etc/init.d/stop-bootlogd-single
Update: This is really a problem in the last upgrade. It seems that in Wheezy 7 those files were obsoleted but not handled properly by the package scripts. The best answer is to fix it in Wheezy 7 before upgrading to jessie.
In WHEEZY fix the conffile problem.
rm -f /etc/init.d/bootlogd rm -f /etc/init.d/stop-bootlogd rm -f /etc/init.d/stop-bootlogd-single apt-get install --reinstall initscripts
That should do it. Check this in Wheezy 7 before upgrading and it is simpler than trying to fix it up in Jessie 8. Before upgrading double check that all obsolete files have been fixed in Wheezy 7.
dpkg-query -W -f='${Package} ${Conffiles}\n' | less +/obsolete
After ugprading to Jessie 8 and after any upgrade it turns out it is a good idea to check for obsolete files as a post inspection. I should have been doing that all along.
I only caught this after the Stretch 9 release. For whatever reason fonts-smc in a previous version left an empty directory behind. It is pure lint. Just remove it.
Wheezy 7 had fonts-smc version 5.0.1-2 with this directory and a file below it. Basically the file was misplaced. It was fixed in Oct 2013 with 5.0.1-5 (as it passed through Sid then) by removing the file. But nothing removed the directory. Jessie 8 had fonts-smc version 6.0-1 with this corrected but never cleaned up the directory.
ls -ld /etc/fonts/conf.avail/65-0-fonts-smc.conf rmdir /etc/fonts/conf.avail/65-0-fonts-smc.conf