X-Git-Url: https://pere.pagekite.me/gitweb/homepage.git/blobdiff_plain/d136442b3b0bfdb08372bbdcd60cce186c59e931..4b3704ec7452d7a9e642943dba0cfff18f9d9cc7:/blog/tags/bootsystem/index.html?ds=inline diff --git a/blog/tags/bootsystem/index.html b/blog/tags/bootsystem/index.html index 92bd6b8822..6c11973eef 100644 --- a/blog/tags/bootsystem/index.html +++ b/blog/tags/bootsystem/index.html @@ -20,6 +20,414 @@

Entries tagged "bootsystem".

+
+
+ How to stay with sysvinit in Debian Jessie +
+
+ 22nd November 2014 +
+
+

By now, it is well known that Debian Jessie will not be using +sysvinit as its boot system by default. But how can one keep using +sysvinit in Jessie? It is fairly easy, and here are a few recipes, +courtesy of +Erich +Schubert and +Simon +McVittie. + +

If you already are using Wheezy and want to upgrade to Jessie and +keep sysvinit as your boot system, create a file +/etc/apt/preferences.d/use-sysvinit with this content before +you upgrade:

+ +

+Package: systemd-sysv
+Pin: release o=Debian
+Pin-Priority: -1
+

+ +

This file content will tell apt and aptitude to not consider +installing systemd-sysv as part of any installation and upgrade +solution when resolving dependencies, and thus tell it to avoid +systemd as a default boot system. The end result should be that the +upgraded system keep using sysvinit.

+ +

If you are installing Jessie for the first time, there is no way to +get sysvinit installed by default (debootstrap used by +debian-installer have no option for this), but one can tell the +installer to switch to sysvinit before the first boot. Either by +using a kernel argument to the installer, or by adding a line to the +preseed file used. First, the kernel command line argument: + +

+preseed/late_command="in-target apt-get install --purge -y sysvinit-core"
+

+ +

Next, the line to use in a preseed file:

+ +

+d-i preseed/late_command string in-target apt-get install -y sysvinit-core
+

+ +

One can of course also do this after the first boot by installing +the sysvinit-core package.

+ +

I recommend only using sysvinit if you really need it, as the +sysvinit boot sequence in Debian have several hardware specific bugs +on Linux caused by the fact that it is unpredictable when hardware +devices show up during boot. But on the other hand, the new default +boot system still have a few rough edges I hope will be fixed before +Jessie is released.

+ +

Update 2014-11-26: Inspired by +a +blog post by Torsten Glaser, added --purge to the preseed +line.

+ +
+
+ + + Tags: bootsystem, debian, english. + + +
+
+
+ +
+
+ Testing sysvinit from experimental in Debian Hurd +
+
+ 3rd February 2014 +
+
+

A few days ago I decided to try to help the Hurd people to get +their changes into sysvinit, to allow them to use the normal sysvinit +boot system instead of their old one. This follow up on the +great +Google Summer of Code work done last summer by Justus Winter to +get Debian on Hurd working more like Debian on Linux. To get started, +I downloaded a prebuilt hard disk image from +http://ftp.debian-ports.org/debian-cd/hurd-i386/current/debian-hurd.img.tar.gz, +and started it using virt-manager.

+ +

The first think I had to do after logging in (root without any +password) was to get the network operational. I followed +the +instructions on the Debian GNU/Hurd ports page and ran these +commands as root to get the machine to accept a IP address from the +kvm internal DHCP server:

+ +

+settrans -fgap /dev/netdde /hurd/netdde
+kill $(ps -ef|awk '/[p]finet/ { print $2}')
+kill $(ps -ef|awk '/[d]evnode/ { print $2}')
+dhclient /dev/eth0
+

+ +

After this, the machine had internet connectivity, and I could +upgrade it and install the sysvinit packages from experimental and +enable it as the default boot system in Hurd.

+ +

But before I did that, I set a password on the root user, as ssh is +running on the machine it for ssh login to work a password need to be +set. Also, note that a bug somewhere in openssh on Hurd block +compression from working. Remember to turn that off on the client +side.

+ +

Run these commands as root to upgrade and test the new sysvinit +stuff:

+ +

+cat > /etc/apt/sources.list.d/experimental.list <<EOF
+deb http://http.debian.net/debian/ experimental main
+EOF
+apt-get update
+apt-get dist-upgrade
+apt-get install -t experimental initscripts sysv-rc sysvinit \
+    sysvinit-core sysvinit-utils
+update-alternatives --config runsystem
+

+ +

To reboot after switching boot system, you have to use +reboot-hurd instead of just reboot, as there is not +yet a sysvinit process able to receive the signals from the normal +'reboot' command. After switching to sysvinit as the boot system, +upgrading every package and rebooting, the network come up with DHCP +after boot as it should, and the settrans/pkill hack mentioned at the +start is no longer needed. But for some strange reason, there are no +longer any login prompt in the virtual console, so I logged in using +ssh instead. + +

Note that there are some race conditions in Hurd making the boot +fail some times. No idea what the cause is, but hope the Hurd porters +figure it out. At least Justus said on IRC (#debian-hurd on +irc.debian.org) that they are aware of the problem. A way to reduce +the impact is to upgrade to the Hurd packages built by Justus by +adding this repository to the machine:

+ +

+cat > /etc/apt/sources.list.d/hurd-ci.list <<EOF
+deb http://darnassus.sceen.net/~teythoon/hurd-ci/ sid main
+EOF
+

+ +

At the moment the prebuilt virtual machine get some packages from +http://ftp.debian-ports.org/debian, because some of the packages in +unstable do not yet include the required patches that are lingering in +BTS. This is the completely list of "unofficial" packages installed:

+ +

+# aptitude search '?narrow(?version(CURRENT),?origin(Debian Ports))'
+i   emacs                   - GNU Emacs editor (metapackage)
+i   gdb                     - GNU Debugger
+i   hurd-recommended        - Miscellaneous translators
+i   isc-dhcp-client         - ISC DHCP client
+i   isc-dhcp-common         - common files used by all the isc-dhcp* packages
+i   libc-bin                - Embedded GNU C Library: Binaries
+i   libc-dev-bin            - Embedded GNU C Library: Development binaries
+i   libc0.3                 - Embedded GNU C Library: Shared libraries
+i A libc0.3-dbg             - Embedded GNU C Library: detached debugging symbols
+i   libc0.3-dev             - Embedded GNU C Library: Development Libraries and Hea
+i   multiarch-support       - Transitional package to ensure multiarch compatibilit
+i A x11-common              - X Window System (X.Org) infrastructure
+i   xorg                    - X.Org X Window System
+i A xserver-xorg            - X.Org X server
+i A xserver-xorg-input-all  - X.Org X server -- input driver metapackage
+#
+

+ +

All in all, testing hurd has been an interesting experience. :) +X.org did not work out of the box and I never took the time to follow +the porters instructions to fix it. This time I was interested in the +command line stuff.

+ +

+
+ + + Tags: bootsystem, debian, english. + + +
+
+
+ +
+
+ Debian init.d boot script example for rsyslog +
+
+ 2nd November 2013 +
+
+

If one of the points of switching to a new init system in Debian is +to get rid of huge +init.d scripts, I doubt we need to switch away from sysvinit and +init.d scripts at all. Here is an example init.d script, ie a rewrite +of /etc/init.d/rsyslog:

+ +

+#!/lib/init/init-d-script
+### BEGIN INIT INFO
+# Provides:          rsyslog
+# Required-Start:    $remote_fs $time
+# Required-Stop:     umountnfs $time
+# X-Stop-After:      sendsigs
+# Default-Start:     2 3 4 5
+# Default-Stop:      0 1 6
+# Short-Description: enhanced syslogd
+# Description:       Rsyslog is an enhanced multi-threaded syslogd.
+#                    It is quite compatible to stock sysklogd and can be 
+#                    used as a drop-in replacement.
+### END INIT INFO
+DESC="enhanced syslogd"
+DAEMON=/usr/sbin/rsyslogd
+

+ +

Pretty minimalistic to me... For the record, the original sysv-rc +script was 137 lines, and the above is just 15 lines, most of it meta +info/comments.

+ +

How to do this, you ask? Well, one create a new script +/lib/init/init-d-script looking something like this: + +

+#!/bin/sh
+
+# Define LSB log_* functions.
+# Depend on lsb-base (>= 3.2-14) to ensure that this file is present
+# and status_of_proc is working.
+. /lib/lsb/init-functions
+
+#
+# Function that starts the daemon/service
+
+#
+do_start()
+{
+	# Return
+	#   0 if daemon has been started
+	#   1 if daemon was already running
+	#   2 if daemon could not be started
+	start-stop-daemon --start --quiet --pidfile $PIDFILE --exec $DAEMON --test > /dev/null \
+		|| return 1
+	start-stop-daemon --start --quiet --pidfile $PIDFILE --exec $DAEMON -- \
+		$DAEMON_ARGS \
+		|| return 2
+	# Add code here, if necessary, that waits for the process to be ready
+	# to handle requests from services started subsequently which depend
+	# on this one.  As a last resort, sleep for some time.
+}
+
+#
+# Function that stops the daemon/service
+#
+do_stop()
+{
+	# Return
+	#   0 if daemon has been stopped
+	#   1 if daemon was already stopped
+	#   2 if daemon could not be stopped
+	#   other if a failure occurred
+	start-stop-daemon --stop --quiet --retry=TERM/30/KILL/5 --pidfile $PIDFILE --name $NAME
+	RETVAL="$?"
+	[ "$RETVAL" = 2 ] && return 2
+	# Wait for children to finish too if this is a daemon that forks
+	# and if the daemon is only ever run from this initscript.
+	# If the above conditions are not satisfied then add some other code
+	# that waits for the process to drop all resources that could be
+	# needed by services started subsequently.  A last resort is to
+	# sleep for some time.
+	start-stop-daemon --stop --quiet --oknodo --retry=0/30/KILL/5 --exec $DAEMON
+	[ "$?" = 2 ] && return 2
+	# Many daemons don't delete their pidfiles when they exit.
+	rm -f $PIDFILE
+	return "$RETVAL"
+}
+
+#
+# Function that sends a SIGHUP to the daemon/service
+#
+do_reload() {
+	#
+	# If the daemon can reload its configuration without
+	# restarting (for example, when it is sent a SIGHUP),
+	# then implement that here.
+	#
+	start-stop-daemon --stop --signal 1 --quiet --pidfile $PIDFILE --name $NAME
+	return 0
+}
+
+SCRIPTNAME=$1
+scriptbasename="$(basename $1)"
+echo "SN: $scriptbasename"
+if [ "$scriptbasename" != "init-d-library" ] ; then
+    script="$1"
+    shift
+    . $script
+else
+    exit 0
+fi
+
+NAME=$(basename $DAEMON)
+PIDFILE=/var/run/$NAME.pid
+
+# Exit if the package is not installed
+#[ -x "$DAEMON" ] || exit 0
+
+# Read configuration variable file if it is present
+[ -r /etc/default/$NAME ] && . /etc/default/$NAME
+
+# Load the VERBOSE setting and other rcS variables
+. /lib/init/vars.sh
+
+case "$1" in
+  start)
+	[ "$VERBOSE" != no ] && log_daemon_msg "Starting $DESC" "$NAME"
+	do_start
+	case "$?" in
+		0|1) [ "$VERBOSE" != no ] && log_end_msg 0 ;;
+		2) [ "$VERBOSE" != no ] && log_end_msg 1 ;;
+	esac
+	;;
+  stop)
+	[ "$VERBOSE" != no ] && log_daemon_msg "Stopping $DESC" "$NAME"
+	do_stop
+	case "$?" in
+		0|1) [ "$VERBOSE" != no ] && log_end_msg 0 ;;
+		2) [ "$VERBOSE" != no ] && log_end_msg 1 ;;
+	esac
+	;;
+  status)
+	status_of_proc "$DAEMON" "$NAME" && exit 0 || exit $?
+	;;
+  #reload|force-reload)
+	#
+	# If do_reload() is not implemented then leave this commented out
+	# and leave 'force-reload' as an alias for 'restart'.
+	#
+	#log_daemon_msg "Reloading $DESC" "$NAME"
+	#do_reload
+	#log_end_msg $?
+	#;;
+  restart|force-reload)
+	#
+	# If the "reload" option is implemented then remove the
+	# 'force-reload' alias
+	#
+	log_daemon_msg "Restarting $DESC" "$NAME"
+	do_stop
+	case "$?" in
+	  0|1)
+		do_start
+		case "$?" in
+			0) log_end_msg 0 ;;
+			1) log_end_msg 1 ;; # Old process is still running
+			*) log_end_msg 1 ;; # Failed to start
+		esac
+		;;
+	  *)
+		# Failed to stop
+		log_end_msg 1
+		;;
+	esac
+	;;
+  *)
+	echo "Usage: $SCRIPTNAME {start|stop|status|restart|force-reload}" >&2
+	exit 3
+	;;
+esac
+
+:
+

+ +

It is based on /etc/init.d/skeleton, and could be improved quite a +lot. I did not really polish the approach, so it might not always +work out of the box, but you get the idea. I did not try very hard to +optimize it nor make it more robust either.

+ +

A better argument for switching init system in Debian than reducing +the size of init scripts (which is a good thing to do anyway), is to +get boot system that is able to handle the kernel events sensibly and +robustly, and do not depend on the boot to run sequentially. The boot +and the kernel have not behaved sequentially in years.

+ +
+
+ + + Tags: bootsystem, debian, english. + + +
+
+
+
How is booting into runlevel 1 different from single user boots? @@ -764,6 +1172,77 @@ insserv'. Will need to test if that work. :)

Archive