Your message dated Wed, 13 Apr 2011 17:58:05 +0200
with message-id <20110413155805.GR28040@aenima>
and subject line Re: [Virtual-pkg-base-maintainers] Bug#622633: base: single
fixed disk is arbitrarily identified as /dev/sda or /dev/sdb, causing dumps to
fail
has caused the Debian Bug report #622633,
regarding base: single fixed disk is arbitrarily identified as /dev/sda or
/dev/sdb, causing dumps to fail
to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact [email protected]
immediately.)
--
622633: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=622633
Debian Bug Tracking System
Contact [email protected] with problems
--- Begin Message ---
Package: base
Severity: important
I have used "dump" and "restore" to perform system backups for many years.
Since upgrading to Debian 6.x, I have not been able to obtain consistent and
reliable dumps for the following reason:
Sometimes. my single fixed disk is labeled as /dev/sda, but
At other times, it is labeled as /dev/sdb.
My "dump" script identifies a partition to dump by its name (i.e. /home)
or partition (i.e. /dev/sda3) depending on the dump level.
If /var/lib/dumpdates indicates that the last lower value dump was performed
on partition /dev/sda3, and the system has assigned that partition to
/dev/sda3, then all is well; however if the system has
arbitrarily labeled that partition as /dev/sdb3, then "dump" thinks that no
lower level dump was ever performed on that partition, and it attempts to
perform a level 0 (i.e. full dump) dump and the tape in my tape drive is
insufficiently long to handle that amount of data.
This means that I must NOT rely on my automatic (crontab-based) dump
scripts, but interrogate the system manually, and if necessary, alter
/var/lib/dumpdates so that the script will run properly.
This is a REAL PAIN.
Is it possible that /etc/fstab, which now identifies the partitions on my
single fixed disc via UUID labels, is an unwilling participant in this
confusion?
Should I alter /dev/fstab to indicate the partitions as it was done before
(i.e. /dev/sda1 is /, /dev/sda3 is /home etc.)?
I look forward to your analysis and recommendation.
Dean
-- System Information:
Debian Release: 6.0.1
APT prefers stable-updates
APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: i386 (i686)
Kernel: Linux 2.6.32-5-686 (SMP w/2 CPU cores)
Locale: LANG=en_CA.utf8, LC_CTYPE=en_CA.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
--- End Message ---
--- Begin Message ---
Hi there, Dean
I am closing this bug report, as it is not a bug per se, even though I
see your pain and can understand it.
What I would do, were I in your shoes, is either post this same question
in the debian-user mailing list or write to Marco D'Itri, the udev
maintainer directly, he might have further advice on how to solve this.
Disks UIDs would certainly help, but I am sure there might be other ways
to ease this situation. Thanks for your report, and happy hacking!
--
.''`. Hate's no fun if you keep it to yourself
: :' : -- The life of David Gale
`. `'
`- Proudly running Debian GNU/Linux
--- End Message ---
