Well yes, grub-reboot works – but only once you’re aware of the fact that you need to manually edit /etc/default/grub. It’s actually documented at wiki.debian.org/GrubReboot, but not in the man page/info document of grub-reboot itself (great idea to provide a separate wiki page for this issue but not consider editing the official documentation instead, not).

So here you go:

# grep GRUB_DEFAULT /etc/default/grub 
GRUB_DEFAULT=0
# sed -i 's/^GRUB_DEFAULT.*/GRUB_DEFAULT=saved/' /etc/default/grub
# grep GRUB_DEFAULT /etc/default/grub 
GRUB_DEFAULT=saved

# update-grub
[...]
# grep '^menuentry' /boot/grub/grub.cfg
menuentry 'Debian GNU/Linux, with Linux 3.2.0-4-amd64' --class debian --class gnu-linux --class gnu --class os {
menuentry 'Debian GNU/Linux, with Linux 3.2.0-4-amd64 (recovery mode)' --class debian --class gnu-linux --class gnu --class os {
menuentry 'Debian GNU/Linux, with Linux 2.6.32-20-pve' --class debian --class gnu-linux --class gnu --class os {
menuentry 'Debian GNU/Linux, with Linux 2.6.32-20-pve (recovery mode)' --class debian --class gnu-linux --class gnu --class os {
menuentry 'Debian GNU/Linux, with Linux 2.6.32-5-amd64' --class debian --class gnu-linux --class gnu --class os {
menuentry 'Debian GNU/Linux, with Linux 2.6.32-5-amd64 (recovery mode)' --class debian --class gnu-linux --class gnu --class os {

# grub-reboot 2  # to boot the third entry, the command writes to /boot/grub/grubenv
# reboot

FTR: Filed as #707695.

• grml2usb: install Grml system / ISO to usb device
• grml-debootstrap: wrapper around debootstrap for installing pure Debian
• grml-rescueboot: Integrates Grml ISO booting into GRUB

As the description states grml2usb is interesting for getting Grml onto a USB device when the dd(1) approach (“dd if=grml.iso of=/dev/sdX“) just isn’t flexible enough.

grml-debootstrap provides a decent way to install Debian systems from the command line. As its author I might be biased but I’ve to mention that it’s working so nice that it is in use at several of my customers for automated roll-outs without any worries at all, and I got reports from other companies that they are very happy users of it as well.

Finally the grml-rescueboot packages provides a very simple and nice way to boot a rescue system from within GRUB (short version: throw a Grml ISO to /boot/grml/, run update-grub and be done).

PS: Thanks everyone for joining the #newinwheezy game over at planet.debian.org.

• dc3dd: patched version of GNU dd with forensic features
• extundelete: utility to recover deleted files from ext3/ext4 partition
• rephrase: Specialized passphrase recovery tool for GnuPG
• rkhunter: rootkit, backdoor, sniffer and exploit scanner (see comments)
• rsakeyfind: locates BER-encoded RSA private keys in memory images
• undbx: Tool to extract, recover and undelete e-mail messages from .dbx files

Join the #newinwheezy game and present packages which are new in Debian/wheezy.

Thanks to libldm’s ldmtool this is no longer true. A short demonstration from a real-life IT forensics investigation (actual IDs/data randomized for obvious reasons):

# ldmtool
ldm> scan /dev/sdc*
[
  "1bad5bbc-a4b5-42e1-8823-001014b00003"
]
ldm> show diskgroup 1bad5bbc-a4b5-42e1-8823-001014b00003
{
  "name" : "FOOBAR-Dg0",
  "guid" : "1bad5bbc-a4b5-42e1-8823-001014b00003",
  "volumes" : [
    "Volume1"
  ],
  "disks" : [
    "Disk1",
    "Disk2"
  ]
}
ldm> show volume 1bad5bbc-a4b5-42e1-8823-001014b00003 Volume1
{
  "name" : "Volume1",
  "type" : "striped",
  "size" : 3907039232,
  "chunk-size" : 128,
  "hint" : "D:",
  "partitions" : [
    "Disk1-01",
    "Disk2-01"
  ]
}
ldm> show partition 1bad5bbc-a4b5-42e1-8823-001014b00003 Disk1-01
{
  "name" : "Disk1-01",
  "start" : 1985,
  "size" : 1953519616,
  "disk" : "Disk1"
}
ldm> create all
Unable to create volume Volume1 in disk group 1bad5bbc-a4b5-42e1-8823-001014b00003: Disk Disk2 required by striped volume Volume1 is missing
[
]
ldm> scan /dev/sdd*
[
  "1bad5bbc-a4b5-42e1-8823-001014b00003"
]
ldm> create all
[
  "ldm_vol_FOOBAR-Dg0_Volume1"
]
ldm>

The just created device mapper device then can be handled as usual:

# dmsetup ls | grep ldm
ldm_vol_FOOBAR-Dg0_Volume1        (254:4)
# mount /dev/mapper/ldm_vol_FOOBAR-Dg0_Volume1 /mnt/whatever

ldmtool just hit Debian unstable (and I intend to ship the tool with the upcoming version of Grml-Forensic).

• Devopsdays Rome/Italy 2012: videos from the talks
• PuppetConf 2012: videos from the talks
• Barcelona Ruby Conference 2012: videos from the talks
• DjangoCon US 2012: videos from the talks
• Jenkins User Conference San Francisco 2012: slides from the talks

If you have a build pipeline inside your Jenkins setup you might have so called upstream jobs which trigger downstream jobs. If such a downstream job fails you might want to set the build state of the upstream job to “failure” as well.

First of all install the Groovy Postbuild Plugin as well as the Copy Artifact Plugin. (The Copy Artifact Plugin is not strictly needed, you can also choose a different approach for artifact handling, but the plugin works very well for me.)

In the upstream job you have to archive artifacts. Otherwise the script that we will use in the downstream job doesn’t have a connection to the upstream job through the getUpstreamBuilds() method. If you don’t have any artifacts then just create a simple textfile and use that as artfifact file. After the artifact step you can place the trigger for the downstream job. This is the relevant part for a working sample configuration for such an upstream job:

In the downstream job make sure to grab the artifacts from the upstream job. Then use build steps or whatever you need as usual. This is the relevant part for a working sample configuration for such a downstream job:

Finally use the following Groovy script as the Groovy Postbuild action:

upstreamBuilds = manager.build.getUpstreamBuilds();

if(!upstreamBuilds) {
  manager.listener.logger.println("Error: could not identify upstream build");
} else {
  upstreamJob = upstreamBuilds.keySet().iterator().next();
  lastUpstreamBuild = upstreamJob.getLastBuild();
  buildResult = manager.build.result;

  if(lastUpstreamBuild.getResult().isBetterThan(buildResult)) {
    manager.listener.logger.println("Adjusting build state of upstream job to build result of this job, being " + buildResult);
    lastUpstreamBuild.setResult(buildResult);
  }
}

That’s it. Now every time your downstream job fails it should set the according upstream job to “failure” as well.

Guile:

guile <<< \#b100000
guile -c '((@@ (ice-9 format) format) #t "~d~%" #b100000)'

Racket:

racket -e '#b100000'

Ruby:

ruby -e 'puts "100000".to_i(2)'

Python:

python -c 'print int("100000", 2)'

Perl:

perl -e 'print 0b100000'

Zsh:

zsh -c 'print $((2#100000))'
zsh -c 'print $((2#1<<5))'

bc:

echo "ibase=2; 100000" | bc

Clojure:

clojure -e '2r100000'

Scala:

scala -e 'Console.println(Integer.parseInt("100000", 2))'

Octave:

octave -q --eval 'bin2dec("100000")'

AWK:

echo 100000 | awk '{r=0;for(i=1;i<=length;i++){r*=2;r+=(substr($0,i,1)!="0")} print r}'

C:

tcc -run - <<< $'#include <stdlib.h>\nint main() { printf ("%d\\n", strtol("100000", NULL, 2)); return 0;}'

Haskell:

runhaskell <<< 'import Data.Char; main = putStrLn $ show $ foldl1 ((+) . (*2)) $ map (digitToInt) "100000"'

CLISP:

clisp -q -x '#b100000'

jenkins-debian-glue allows you to build Debian and Ubuntu packages directly from the Jenkins continuous integration system. It retrieves package sources from a version control repository, adjusts debian/changelog (handle version number + mention changes that took place) and builds according source and binary packages out of it. Its lintitan integration provides Q/A reports about the resulting source and binary Debian packages.

It started as a small pet project of mine to get integration of Debian packaging inside Jenkins. I mainly had the needs for the Grml project in mind and starting with Grml 2011.12 every release (including also all the daily builds) was built using Jenkins since then. It turned out that my project would also be a perfect match for one of my customers, Sipwise GmbH. In December 2011 the sip:provider 2.4 was the first stable release that was built 100% through Jenkins and featuring jenkins-debian-glue.

Thanks to special needs and the open source friendliness of Sipwise I could invest further time into the project. Recently the project got even some further drive thanks to interest by some fellow Debian Developers, most notably are the icinga, nagios-plugins,… packages and the PostgreSQL in Debian Hackathon.

Now if you’re also interested in it: there’s an automated deployment procedure available for your service to get started with the whole jenkins-debian-glue and Jenkins stack in less than 10 minutes, working just fine on Debian as well as Ubuntu.

For further details please head over to jenkins-debian-glue.org or check out this 6:36min screencast (safe for work, no audio ):

This embedded video doesn’t work for you? Try heading over to YouTube.