Bug#520927: More information needed about this dump corruption bug
On Tue, 16 Mar 2010, Christian Perrier wrote: tags 520927 moreinfo thanks Hello Jenny, Back in March 2009, you reported a bug about file corruption when dumping filesystems. Bdale Garbee, who maintains the relevant package asked the upstream author (Stelian Pop) whether that rings some bells for him. Stelian answered the following, which was apparently never forwarded to you (or at least in a visible way). This sounds like some tests could be done on your side. Hopefully, you're still in position to do them... No I have no record of this. Stelian Pop's answer: On Mon, Aug 31, 2009 at 05:15:37PM -0600, Bdale Garbee wrote: One of the users of my Debian package of dump reported repeatable corruption when using dump over rmt to a remote tape drive. See the item in our bug tracking system at http://bugs.debian.org/520927 for more information. I've poked around a bit, but it won't be easy for me to reproduce the problem. Does this ring any bells with you? This sounds a lot like the kind of problems that can be encountered when dumping a live filesystem. In order to completly rule out any network related corruptions, I would suggest to try doing a dumping locally (into a file in /tmp for example), and try restoring (or comparing) this dump. I had tested local dumps before I reported the problem. Neither a local dump to a tape, nor a dump piped into restore to a disk, nor to a file on disk have given any problem I can locate even tho they are from a live system. And remote tar also seems ok. So as reported then the problem was confined to remote dump. As for the live filesystem problem, the only way to confirm that this is the cause is, well, to umount (or mount R/O) the filesystem before dumping. It was not the problem. See above. What I have not done is tried a remote dump to tape again in recent months so if any patch may have fixed it I could try one again. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#520927: Some files corrupted from remote dump/restore reproducably
On Thu, 18 Jun 2009, Bdale Garbee wrote: On Mon, 2009-03-23 at 17:14 +, Jenny Barna wrote: Package: dump Version: 0.4b41-5+b1 Severity: critical Justification: causes serious data loss I set up dump using a SLT24 tape system and tested local and remote dump and restore with restoring single files OK. When I restored a user's lost file I discovered I had got back text from another (unrelated?) file. Which rmt are you using? On Debian systems, there are several packages that can provide rmt, so the 'alternatives' mechanism is used to allow you to choose which one you want. By default, you probably get the one provided by the 'tar' package. It would be interesting to know whether you're configured to use the rmt that comes with dump, with tar, or some other version. It appears to be using /usr/sbin/rmt-dump Since I wrote that in March I switched to using tar for my two remote machines whereas I stayed with dump for the machine that has the tape system on it. Jenny Barna| Email j...@cam.ac.uk SBS Computing Facility | Web computing.bio.cam.ac.uk Dept of Biochemistry | Telephone (Direct) +44 1223 333644 Tennis Court Road | Switchboard +44 1223 333600 Cambridge, CB2 1QW, UK | Fax: +44 1223 45 -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#520927: Some files corrupted from remote dump/restore reproducably
It appears to be using /usr/sbin/rmt-dump Since I wrote that in March I switched to using tar for my two remote machines whereas I stayed with dump for the machine that has the tape system on it. That's interesting. So are you using rmt with tar, or some other transport mechanism? If you're using rmt-dump in all cases, that would certainly help point the finger squarely at dump itself! I guess so. After I reported this I had found to my horror that my remote dumps were useless with multiple corrupted files eg in /etc whereas remote tar seemed ok. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#520927: Some files corrupted from remote dump/restore reproducably
Package: dump Version: 0.4b41-5+b1 Severity: critical Justification: causes serious data loss I set up dump using a SLT24 tape system and tested local and remote dump and restore with restoring single files OK. When I restored a user's lost file I discovered I had got back text from another (unrelated?) file. Therefore I restored the whole of /etc (critical) locally from a typical dump and cannot see a problem, on the system where the tape drive is. But when I dump/restore from this system to the remote tape drive (same OS) I am reproducably finding some files corrupted (using /etc for all tests). When I do file * in the restored etc I find two files listed as Vim swap files. These seem in some way related eg hosts.allow is full of the wrong contents and one of my old copies (I dated them .0902xx etc) is reported as a Vim file. This behaviour happens with the default block size, with a block size of 64 and one of 256. The files in question are not open when I do the test dump though it is true the file system is mounted. I have not proved no files are corrupted on any local dump. I have read that dump may not be as reliable for a mounted file system under Linux as with Solaris, which I was using before, but if this is a feature not a bug then I am unsure how to avoid it. hosts.allow has definitely been edited with vi but another file that seems corrupted is mailcap and I do not think I have edited that. The key thing is that the same corrupted files are seen each time I do this test ie from /etc on this system to the remote tape drive on the same OS. dump and restore give no errors. Thanks. -- System Information: Debian Release: 5.0 APT prefers stable APT policy: (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 2.6.26-1-amd64 (SMP w/32 CPU cores) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages dump depends on: ii e2fslibs 1.41.3-1 ext2 filesystem libraries ii libblkid1 1.41.3-1 block device id library ii libc6 2.7-18 GNU C Library: Shared libraries ii libcomerr21.41.3-1 common error description library ii libncurses5 5.7+20081213-1 shared libraries for terminal hand ii libreadline5 5.2-3.1GNU readline and history libraries ii libuuid1 1.41.3-1 universally unique id library ii tar 1.20-1 GNU version of the tar archiving u dump recommends no packages. dump suggests no packages. -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#513479: gdm: desktop does not appear after giving login credentials after upgrade 090129
Package: gdm Version: 2.20.7-4 Severity: grave Justification: renders package unusable Today I did an apt-get update and apt-get upgrade which appeared to hang. I rebooted and I can login via ssh but not via the console. It's a Sun with ILOM and if the console is redirected one gets the same broken result. The initial login screen does appear and seems to accept the username and password but then one can get nothing else. Trying all the function keys revealed that the print screen button could elicit a response. I also note an error: Jan 29 12:24:19 charlotte gdm[5066]: PAM unable to dlopen(/lib/security/pam_gnome_keyring.so): /lib/security/pam_gnome_keyring.so: cannot open shared object file: No such file or directory but I think this may have been pre-existing. I hope I am right this is a gdm bug as I usually operate via ssh not GUIs ps -ef indicates jcjb 7607 7581 0 13:13 ?00:00:00 x-window-manager jcjb 7653 7607 0 13:13 ?00:00:00 /usr/bin/ssh-agent /usr/bin/dbus-launch --exit-with-session x-window-manager jcjb 7656 1 0 13:13 ?00:00:00 /usr/bin/dbus-launch --exit-with-session x-window-manager jcjb 7657 1 0 13:13 ?00:00:00 /usr/bin/dbus-daemon --fork --print-pid 6 --print-address 9 --session jcjb 7659 1 0 13:13 ?00:00:00 /usr/lib/libgconf2-4/gconfd-2 6 -- System Information: Debian Release: 5.0 APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 2.6.26-1-amd64 (SMP w/8 CPU cores) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages gdm depends on: ii adduser3.110 add and remove users and groups ii debconf [debconf-2.0] 1.5.24Debian configuration management sy ii gksu 2.0.0-6 graphical frontend to su ii gnome-terminal [x-term 2.22.3-3 The GNOME 2 terminal emulator appl ii konsole [x-terminal-em 4:3.5.9.dfsg.1-6 X terminal emulator for KDE ii libart-2.0-2 2.3.20-2 Library of functions for 2D graphi ii libatk1.0-01.22.0-1 The ATK accessibility toolkit ii libattr1 1:2.4.43-1Extended attribute shared library ii libc6 2.7-18GNU C Library: Shared libraries ii libcairo2 1.6.4-7 The Cairo 2D vector graphics libra ii libdbus-1-31.2.1-5 simple interprocess messaging syst ii libdbus-glib-1-2 0.76-1simple interprocess messaging syst ii libdmx11:1.0.2-3 X11 Distributed Multihead extensio ii libfontconfig1 2.6.0-3 generic font configuration library ii libfreetype6 2.3.7-2 FreeType 2 font engine, shared lib ii libglade2-01:2.6.2-1 library to load .glade files at ru ii libglib2.0-0 2.16.6-1 The GLib library of C routines ii libgnomecanvas2-0 2.20.1.1-1A powerful object-oriented display ii libgtk2.0-02.12.11-4 The GTK+ graphical user interface ii libpam-modules 1.0.1-5 Pluggable Authentication Modules f ii libpam-runtime 1.0.1-5 Runtime support for the PAM librar ii libpam0g 1.0.1-5 Pluggable Authentication Modules l ii libpango1.0-0 1.20.5-3 Layout and rendering of internatio ii librsvg2-2 2.22.2-2lenny1SAX-based renderer library for SVG ii librsvg2-common2.22.2-2lenny1SAX-based renderer library for SVG ii libselinux12.0.65-5 SELinux shared libraries ii libwrap0 7.6.q-16 Wietse Venema's TCP wrappers libra ii libx11-6 2:1.1.5-2 X11 client-side library ii libxau61:1.0.3-3 X11 authorisation library ii libxdmcp6 1:1.0.2-3 X11 Display Manager Control Protoc ii libxext6 2:1.0.4-1 X11 miscellaneous extension librar ii libxi6 2:1.1.4-1 X11 Input extension library ii libxinerama1 2:1.0.3-2 X11 Xinerama extension library ii libxml22.6.32.dfsg-5 GNOME XML library ii lsb-base 3.2-20Linux Standard Base 3.2 init scrip ii metacity [x-window-man 1:2.22.0-2A lightweight GTK2 based Window Ma ii twm [x-window-manager] 1:1.0.4-2 Tab window manager ii xterm [x-terminal-emul 235-2 X terminal emulator ii zlib1g 1:1.2.3.3.dfsg-12 compression library - runtime Versions of packages gdm recommends: pn gdm-themes none (no description available) ii whiptail 0.52.2-11.3 Displays user-friendly dialog boxe pn xserver-xephyr | xnest none (no description available) ii xserver-xorg 1:7.3+18the X.Org X server
Bug#513479: gdm: desktop does not appear after giving login credentials after upgrade 090129
Thanks for sending detailed information, it helps a lot. Here is the problem. You don’t have a session manager installed, so the X11 startup scripts choose to run x-window-manager. ii metacity [x-window-man 1:2.22.0-2A lightweight GTK2 based Window Ma ii twm [x-window-manager] 1:1.0.4-2 Tab window manager And here, x-window-manager certainly points to metacity. Which is just a window manager, not something able to start programs. There is a reason why gdm depends on a session manager (x-window-manager being a fallback), and a reason why metacity recommends gnome-session. Many thanks! I am deeply impressed by the speed of your response but I remained a little confused because the desk-top manager was working fine before. I realized since I submitted the report that I had no evidence that the problem started today because for some weeks, during which I did several apt-get upgrades, I have not used the desktop. So apologies for filing a misleading report even though my details led you to diagnose it correctly. I have installed gnome-session and again obtained a desktop. I now see that what must have happened is when I was installing/deinstalling python libraries for a developer-user a few days ago either apt-get install or autoremove removed gnome-session, at least that is what I deduce from the careful records I have kept with dpkg --get-selections. This is somewhat dangerous behaviour from my point of view and I shall be alert in future. Thanks again.
