wiki:AndreesStuff

Version 19 (modified by andree, 12 years ago) (diff)

--

Mixed bag of things I'm just jotting down for now... I'd prefer if people could refrain from updating this page - get your own mixed bag! ;-)

Restore Problems

ext2fs_check_if_mount: No such file or directory while determining whether <device> is mounted.

This error is issued by mkfs. The reason is that no mtab support is present in busybox and busybox's mount is used.

busybox 1.1.3 (and possbily other version) may be broken on amd64 in that they seem to require the existence of /etc/mtab regardless of whether the corresponding configuration option is set or not. This is not an issue on i386.

mondorestore killed

If mondorestore gets killed during restore for no apparent reason, this may be a memory problem. If there is still swap space available, the underlying issue maybe the kernel OOM killer.

On Debian Sid amd64, kernel linux-image-2.6.16-2-amd64-k8, version 2.6.16-14 has this problem, whereas kernel linux-image-2.6.16-2-amd64-generic, version 2.6.16-14 is fine.

Compilation Problems

Compiler Warnings

gcc 4.1.2 appears to be stricter than earlier versions when '-Wall' is used. The following is fine in earlier versions of gcc:

*pos++;

but gives the following warning with gcc 4.1.2 (and '-Wall'):

warning: value computed is not used

This is rubbish, as e.g. it is perfectly valid to change a string pointer without ever directly using it because we might only be interested in the string from a certain position. A workaround to avoid the warning is to use:

pos += 1;

(No '*' at the front!)

busybox Error './sh: Cannot set tty process group (Operation not permitted)'

On Debian sid amd64, busybox versions 1.00, 1.1.3 and possibly others may give the following error when called as sh:

./sh: Cannot set tty process group (Operation not permitted)

Given that there is no prompt, this is a rather severe problem. Removing NFS mount supprot from busybox addresses the problem. Also, compilation against glibc 2.4 makes this go away. More info about the glibc side of things can be found here: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=367656

This problem does not occur on i386.

Build from SVN on Debian (and maybe others)

Trying to build packages from SVN may currently have some issues. The following tries to address the ones I experience on Debian. They may be applicable to other environments as well.

bash: ./tools/svn2build: /bin/sh: bad interpreter: Permission denied

This has nothing to do with the build script. Rather it indicates that the filesystem the script lives in does not allow anything to be executed. As an example, for an NFS mount this happens when the noexec flag is set in the mount options.

cat: <some path>mondo/VERSION: No such file or directory

(followed by some more errors)

This is because tools/svn-env makes assumptions about the user's directory layout which are not necessily true. To overcome this, change tools/svn-env to:

#!/bin/bash
#
# Creates common environment for SVN repository
#
# $Id: svn-env 553 2006-05-17 22:40:32Z bcornec $
#

export VER="`cat ${TOOLHOME}/../mondo/VERSION`"
export SVNBRANCH="`dirname ${TOOLHOME}`"

# To be safe for SVN commands
export REVISION=`(cd $TOOLHOME/.. ; svnversion .)`
export TAG=`cat ${TOOLHOME}/TAG`

tools/svn2build.andree: line 35: cd: /home/<user>/mondo/svn: No such file or directory

This is because svn2build assumes that there is an svn directory in the ${BASE} directory as defined in tools/common-env. This assumption may not be valid, e.g. my SVN tree is somewhere else. Changing common-env could address this. But so can commenting the following in svn2build:

# Make it safe for SVN commands
#cd ${BASE}/svn

<some path>/stable/tools/distro-env: line 120: rpm: command not found

svn2build also reads in information about distribution specific activities from distro-env. distro-env needs to be adjusted for Debian.

Can't locate Date/Manip?.pm in @INC …

Install Debian package 'libdate-manip-perl'.

/bin/sh: man2dvi: command not found

Unfortunately, Debian does not have a package that would provide this tool. Fortuntely it is just a little shell script:

#! /bin/sh
#
# script to format manpages to dvi
# Copyright (c) 1997 Tobias Begalke (tb@lst.de)
#
# Changelog:
# 23May06AL: - extracted from upstream man-1.6c package which can be found at
#              http://primates.ximian.com/~flucifredi/man/
#            - changed:
#                location=`man -c -w $1`
#              to:
#                location=`man -w $1`
#

groff="groff -Tdvi -mandoc"

if [ ! $# = 1 ]; then
  echo "$0: usage:"
  echo "  $0 [topic] > topic.dvi"
  exit 1
fi

location=`man -w $1`

if [ "$location" = "" ]; then
  exit 1
fi

case `file $location` in
  *gzip* )
    zcat $location | $groff
    ;;

  *troff* )
    $groff $location
    ;;
esac

Save the abive in e.g. /usr/local/bin/man2dvi and make the resulting file executable.

make: docbook2ps: Command not found

Install Debian package 'docbook-utils'.

/bin/sh: man2html: command not found

Install Debian package 'man2html'.

groff: can't find `DESC' file

groff:fatal error: invalid device `dvi'

make: * [mindi.8.ps] Error 3

Install Debian package 'groff'. (This is not the same as 'groff-base'.)

Tip

Run the following to just get mindi and mondo source tarballs:

tools/svn2build "mondo-doc mindi mondo"

Creating Backtraces

Backtraces can be very helpful when trouble-shooting issues like segmentation faults. To create a useful backtrace, you need gdb (the GNU Debugger) installed and an application (and possibly libraries) with debugging symbols built in. The following will explain how to do this.

gdb

gdb should be part of your distribution just use your favourite way to install the package, e.g.

apt-get install gdb

for Debian and friends (such as Ubuntu) or

yum install gdb

for Fedora/RedHat/Mandriva?

mondoarchive/mondorescue with debugging symbols

To get mondoarchive and mondorescue with debugging symbols built in, you need to build from the source.

Get the latest stable mondo source package from ftp://ftp.mondorescue.org/src/, e.g. mondo-2.0.9.tar.gz, unpack:

tar xvzf mondo-2.0.9.tar.gz

enter into the new directory and build using make:

cd mondo-2.0.9
./configure --prefix=/usr
make

You will end up with binary in the following locations which are non-stripped, i.e. they contain debugging symbols:

file mondo/mondoarchive/mondoarchive
mondo/mondoarchive/mondoarchive: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), for GNU/Linux 2.2.0, dynamically linked (uses shared libs), not stripped

and

file mondo/mondorestore/mondorestore
mondo/mondorestore/mondorestore: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), for GNU/Linux 2.2.0, dynamically linked (uses shared libs), not stripped

Make backups of the original mondoarchive and mondorestore binaries and copy they newly created over the original ones.

Trouble-Shooting mondoarchive

The best approach is to run the mondoarchive binary you just created with debugging symbols built in from its location in the built directory under gdb. So:

cd mondo/mondoarchive
gdb ./mondoarchive
run <usual arguments you use>

Note: Running it from within its build directory makes it so that more valuable information about source lines will be avilable in the backtrace.

When the segmentation fault happens, enter:

bt

and send the output to the list.

Trouble-Shooting mondorestore

If you do partial restore onto a live system, the same approach as described for mondoarchive can be used.

However, more likely you will experience a segmentation fault during restore. To run a backtrace in that situation proceeed as follows:

First, you need a mondorestore binary with debugging symbols. This should already been taken care of if you copied the newly compiled binaries as described above. Next, you need to make sure that gdb is available on your restore media. To achieve this, add this to /etc/mindi/deplist.txt before doing a mondoarchive run:

gdb
libthread_db.so.1

Boot the restore media into expert mode. Then start mondorestore like this:

gdb /usr/sbin/mondorestore
run

As described previously, once the segmentation fault happens, do:

bt

and send the output to the list. (If you can't get the backtrace copied as text, you can use a photo of the screen as the last resort.

Advanced Topics

Attaching to Running Processes

You can attach to a running process using:

gdb /usr/sbin/mondorestore <pid>

where <pid> is the process ID.

This can be particulary useful when running mondoarchive with the '-g' or when running mondorestore.

Using libraries with debugging symbols

The libraries used by a binary can be determined using the ldd command, e.g.:

ldd /usr/sbin/mondoarchive
                libmondo.so.2 => /usr/lib/libmondo.so.2 (0xb7f8d000)
        libmondo-newt.so.1 => /usr/lib/libmondo-newt.so.1 (0xb7f82000)
        libnewt.so.0.51 => /usr/lib/libnewt.so.0.51 (0xb7f71000)
        libdl.so.2 => /lib/tls/libdl.so.2 (0xb7f6e000)
        libpthread.so.0 => /lib/tls/libpthread.so.0 (0xb7f5f000)
        libc.so.6 => /lib/tls/libc.so.6 (0xb7e2a000)
        libslang.so.1-UTF8 => /lib/libslang.so.1-UTF8 (0xb7db7000)
        libm.so.6 => /lib/tls/libm.so.6 (0xb7d94000)
        /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0xb7fea000)

some of those libraries may come with debugging symbols built in as an alternative package, others can be buiolt from scratch and installed with debugging sysmbols installed. Using your distribtuion's standard built process is probably a good idea for this.

Getting the entire kernel log on restore media

The kernel ring buffer that dmesg reads defaults to 32k on recent kernels. This is not enough to capture the entire sequence of kernel message when Mondo Rescue boots off a restore media.

To increase the kernel ring buffer to 128k at boot time (and without recompilation) add the following kernel boot parameter:

log_buf_len=128k

e.g.

expert log_buf_len=128k

dmesg needs to be told what buffer size to use to ensure that everything is displayed from the start. The -s parameter can be used for this like this:

dmesg -s 131072 | less