FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Debian > Debian User

 
 
LinkBack Thread Tools
 
Old 11-02-2008, 08:39 AM
Volkan YAZICI
 
Default Electricity Cutoffs, EXT3 and Filesystems

Hi,

I had used to be a ReiserFS user ~4 years and never had even a single
problem with it. It was blazingly fast and there isn't a second
filesystem I know of that could challange with it in the speed of
recovering at the boot after a system crash or electricity cutoff.

This year I'm obligated to administrate extra ~5 production servers and
as a result of major GNU/Linux headquarters moving from ReiserFS to
EXT3, I started to use EXT3 in those new servers. But unfortunately,
after every electricity cutoff[1], EXT3 just crashes and waits prompt
from me standing at boot. I start the servers with Knoppix (Gee!) and
run e2fsck on every single partition. (Keep on imagining this PITA!) No,
pressing `Y' to run a fsck on the partitions doesn't work. I tried my
luck with XFS, but it resulted same as EXT3.

Please, I don't want to start a flamewar between filesystems. But could
anybody give any recommendations to me? Should I switch back to ReiserFS
for my own mental sake? Is it possible to configure EXT3 to behave in a
more automatized manner and recover from crashes with minimum human
interruption? Do others also experience similar problems?


Regards.

[1] Yes, we have couples of UPS boxes around, but they are not capable
of standing the load for many hours. And yes, this is "Banana
Republic" and companies cut your electricity off without a clue.


--
To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
 
Old 11-02-2008, 08:57 AM
Andrei Popescu
 
Default Electricity Cutoffs, EXT3 and Filesystems

On Sun,02.Nov.08, 11:39:19, Volkan YAZICI wrote:

> Please, I don't want to start a flamewar between filesystems. But could
> anybody give any recommendations to me? Should I switch back to ReiserFS
> for my own mental sake? Is it possible to configure EXT3 to behave in a
> more automatized manner and recover from crashes with minimum human
> interruption? Do others also experience similar problems?

Please post an /etc/fstab and the output of 'dumpe2fs -h' for one of
your filesystems (considering that they have been created with same
options).

Regards,
Andrei
--
If you can't explain it simply, you don't understand it well enough.
(Albert Einstein)
 
Old 11-02-2008, 09:28 AM
Ron Johnson
 
Default Electricity Cutoffs, EXT3 and Filesystems

On 11/02/08 03:39, Volkan YAZICI wrote:
[snip]


[1] Yes, we have couples of UPS boxes around, but they are not capable
of standing the load for many hours. And yes, this is "Banana
Republic" and companies cut your electricity off without a clue.


Connect your UPSs to your servers with the relevant communications
wires, and then run UPS daemons like apcupsd or nuts. They will
cleanly shutdown the computers when the batteries get low.


--
Ron Johnson, Jr.
Jefferson LA USA

"I won't have to worry about putting gas in my car, I won't
have to worry about paying my mortgage."
Peggy Joseph, on why she loves Obama


--
To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
 
Old 11-03-2008, 03:51 AM
Mark Allums
 
Default Electricity Cutoffs, EXT3 and Filesystems

Volkan YAZICI wrote:

Hi,

I had used to be a ReiserFS user ~4 years and never had even a single
problem with it. It was blazingly fast and there isn't a second
filesystem I know of that could challange with it in the speed of
recovering at the boot after a system crash or electricity cutoff.

This year I'm obligated to administrate extra ~5 production servers and
as a result of major GNU/Linux headquarters moving from ReiserFS to
EXT3, I started to use EXT3 in those new servers. But unfortunately,
after every electricity cutoff[1], EXT3 just crashes and waits prompt
from me standing at boot. I start the servers with Knoppix (Gee!) and
run e2fsck on every single partition. (Keep on imagining this PITA!) No,
pressing `Y' to run a fsck on the partitions doesn't work. I tried my
luck with XFS, but it resulted same as EXT3.

Please, I don't want to start a flamewar between filesystems. But could
anybody give any recommendations to me? Should I switch back to ReiserFS
for my own mental sake? Is it possible to configure EXT3 to behave in a
more automatized manner and recover from crashes with minimum human
interruption? Do others also experience similar problems?


Regards.

[1] Yes, we have couples of UPS boxes around, but they are not capable
of standing the load for many hours. And yes, this is "Banana
Republic" and companies cut your electricity off without a clue.




The short answer is going to be, work on getting more UPSes, and
consider some type of longer-term (but still temporary) power source,
like a Diesel generator.


If you have any diagnostics at all, post a summary here. Someone may
see something to do. Also, fstab file and perhaps the contents of any
custom init scripts you use, or even your menu.list from /boot/grub.
Anything that may give someone a clue.


ReiserFS will work for a while, but unless they find some new, long-term
upstream maintainers, it will eventually not be feasible to use it.
Better to make the switch now, starting with new hardware. I still like
ext3 for now, and ext "4" is coming along nicely, I hear, it may be a
good choice at some point. (But not right now.)


Mark Allums


--
To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
 
Old 11-03-2008, 08:47 AM
Volkan YAZICI
 
Default Electricity Cutoffs, EXT3 and Filesystems

Hi,

Sorry for the late reply. (Guess what? Yet another electricity problem
and I've been struggling with servers since 2 days.)

On Sun, 2 Nov 2008, Andrei Popescu <andreimpopescu@gmail.com> writes:
> Please post an /etc/fstab and the output of 'dumpe2fs -h' for one of
> your filesystems (considering that they have been created with same
> options).

I've attached related /etc/fstab and "dumpe2fs -h" outputs for R&D and
PREPROD servers.


Regards.

# /etc/fstab: static file system information.
#
# <file system> <mount point> <type> <options> <dump> <pass>
proc /proc proc defaults 0 0
/dev/sda3 / ext3 noatime 1 1
/dev/sda4 /home ext3 noatime,nodev,nosuid 0 2
/dev/sda2 /boot ext2 noatime,nodev,nosuid 1 1
/dev/sda1 none swap sw 0 0
/dev/md0 /srv/fs ext3 noatime,nodev,nosuid 0 2
/dev/scd0 /media/cdrom0 udf,iso9660 user,noauto 0 0
Personalities : [raid1]
md0 : active raid1 sdb1[0] sdc1[1]
976759936 blocks [2/2] [UU]

unused devices: <none>
dumpe2fs 1.40-WIP (14-Nov-2006)
Filesystem volume name: <none>
Last mounted on: <not available>
Filesystem UUID: b4865677-ff37-4b02-b15a-357e54ccdf6f
Filesystem magic number: 0xEF53
Filesystem revision #: 1 (dynamic)
Filesystem features: filetype sparse_super
Default mount options: (none)
Filesystem state: not clean
Errors behavior: Continue
Filesystem OS type: Linux
Inode count: 490560
Block count: 979965
Reserved block count: 48998
Free blocks: 911604
Free inodes: 490522
First block: 1
Block size: 1024
Fragment size: 1024
Blocks per group: 8192
Fragments per group: 8192
Inodes per group: 4088
Inode blocks per group: 511
Last mount time: Mon Nov 3 11:19:02 2008
Last write time: Mon Nov 3 11:19:02 2008
Mount count: 12
Maximum mount count: 30
Last checked: Tue Oct 28 10:29:47 2008
Check interval: 0 (<none>)
Reserved blocks uid: 0 (user root)
Reserved blocks gid: 0 (group root)
First inode: 11
Inode size: 128

dumpe2fs 1.40-WIP (14-Nov-2006)
Filesystem volume name: <none>
Last mounted on: <not available>
Filesystem UUID: 1e3e5f03-3b47-410f-a984-f75aaa0883c1
Filesystem magic number: 0xEF53
Filesystem revision #: 1 (dynamic)
Filesystem features: has_journal resize_inode dir_index filetype needs_recovery sparse_super large_file
Filesystem flags: signed directory hash
Default mount options: (none)
Filesystem state: clean
Errors behavior: Continue
Filesystem OS type: Linux
Inode count: 5515776
Block count: 11010048
Reserved block count: 550527
Free blocks: 10558511
Free inodes: 5479226
First block: 0
Block size: 4096
Fragment size: 4096
Reserved GDT blocks: 1021
Blocks per group: 32768
Fragments per group: 32768
Inodes per group: 16416
Inode blocks per group: 513
Filesystem created: Wed May 7 11:05:58 2008
Last mount time: Mon Nov 3 11:18:55 2008
Last write time: Mon Nov 3 11:18:55 2008
Mount count: 12
Maximum mount count: 20
Last checked: Tue Oct 28 10:33:18 2008
Check interval: 15552000 (6 months)
Next check after: Sun Apr 26 11:33:18 2009
Reserved blocks uid: 0 (user root)
Reserved blocks gid: 0 (group root)
First inode: 11
Inode size: 128
Journal inode: 8
Default directory hash: tea
Directory Hash Seed: 8bd7f770-7257-41b8-9255-1a2f2a249276
Journal backup: inode blocks
Journal size: 128M

dumpe2fs 1.40-WIP (14-Nov-2006)
Filesystem volume name: <none>
Last mounted on: <not available>
Filesystem UUID: e6c37411-4128-4f1e-ba63-968729482da7
Filesystem magic number: 0xEF53
Filesystem revision #: 1 (dynamic)
Filesystem features: has_journal resize_inode dir_index filetype needs_recovery sparse_super large_file
Filesystem flags: signed directory hash
Default mount options: (none)
Filesystem state: clean
Errors behavior: Continue
Filesystem OS type: Linux
Inode count: 122109952
Block count: 244189984
Reserved block count: 12209499
Free blocks: 102270179
Free inodes: 122048893
First block: 0
Block size: 4096
Fragment size: 4096
Reserved GDT blocks: 965
Blocks per group: 32768
Fragments per group: 32768
Inodes per group: 16384
Inode blocks per group: 512
Filesystem created: Thu Jul 24 13:48:22 2008
Last mount time: Mon Nov 3 11:19:02 2008
Last write time: Mon Nov 3 11:19:02 2008
Mount count: 11
Maximum mount count: 27
Last checked: Thu Jul 24 13:48:22 2008
Check interval: 15552000 (6 months)
Next check after: Tue Jan 20 12:48:22 2009
Reserved blocks uid: 0 (user root)
Reserved blocks gid: 0 (group root)
First inode: 11
Inode size: 128
Journal inode: 8
Default directory hash: tea
Directory Hash Seed: 77ff3a0d-e769-491b-8ff3-e7dd13a9d464
Journal backup: inode blocks
Journal size: 128M

# /etc/fstab: static file system information.
#
# <file system> <mount point> <type> <options> <dump> <pass>
proc /proc proc defaults 0 0
/dev/sda3 / ext3 noatime 1 1
/dev/sda2 /boot ext2 noatime,nodev,nosuid 1 1
/dev/sda4 /home ext3 noatime,nodev,nosuid 0 2
/dev/sda1 none swap sw 0 0
/dev/sdb1 /srv/img0 ext3 noatime,nodev,nosuid 0 2
/dev/scd0 /media/cdrom0 udf,iso9660 user,noauto 0 0
dumpe2fs 1.40-WIP (14-Nov-2006)
Filesystem volume name: <none>
Last mounted on: <not available>
Filesystem UUID: 16411058-20c9-47d1-9d69-0ce99405e412
Filesystem magic number: 0xEF53
Filesystem revision #: 1 (dynamic)
Filesystem features: filetype sparse_super
Default mount options: (none)
Filesystem state: not clean
Errors behavior: Continue
Filesystem OS type: Linux
Inode count: 490560
Block count: 979965
Reserved block count: 48998
Free blocks: 905819
Free inodes: 490531
First block: 1
Block size: 1024
Fragment size: 1024
Blocks per group: 8192
Fragments per group: 8192
Inodes per group: 4088
Inode blocks per group: 511
Last mount time: Sat Nov 1 21:17:47 2008
Last write time: Sat Nov 1 21:17:47 2008
Mount count: 1
Maximum mount count: 30
Last checked: Sat Nov 1 19:57:39 2008
Check interval: 0 (<none>)
Reserved blocks uid: 0 (user root)
Reserved blocks gid: 0 (group root)
First inode: 11
Inode size: 128

dumpe2fs 1.40-WIP (14-Nov-2006)
Filesystem volume name: <none>
Last mounted on: <not available>
Filesystem UUID: 38ad52f3-52cc-43f1-bad6-42a167a3d670
Filesystem magic number: 0xEF53
Filesystem revision #: 1 (dynamic)
Filesystem features: has_journal resize_inode dir_index filetype needs_recovery sparse_super large_file
Filesystem flags: signed directory hash
Default mount options: (none)
Filesystem state: clean
Errors behavior: Continue
Filesystem OS type: Linux
Inode count: 854784
Block count: 1708914
Reserved block count: 85445
Free blocks: 1157346
Free inodes: 783593
First block: 0
Block size: 4096
Fragment size: 4096
Reserved GDT blocks: 417
Blocks per group: 32768
Fragments per group: 32768
Inodes per group: 16128
Inode blocks per group: 504
Filesystem created: Fri Jun 13 14:18:18 2008
Last mount time: Sat Nov 1 21:17:36 2008
Last write time: Sat Nov 1 21:17:36 2008
Mount count: 1
Maximum mount count: 27
Last checked: Sat Nov 1 21:17:03 2008
Check interval: 15552000 (6 months)
Next check after: Thu Apr 30 22:17:03 2009
Reserved blocks uid: 0 (user root)
Reserved blocks gid: 0 (group root)
First inode: 11
Inode size: 128
Journal inode: 8
Default directory hash: tea
Directory Hash Seed: f351a30f-3fb5-4ebc-89e9-a833af572116
Journal backup: inode blocks
Journal size: 128M

dumpe2fs 1.40-WIP (14-Nov-2006)
Filesystem volume name: <none>
Last mounted on: <not available>
Filesystem UUID: 49e20681-a271-4242-b800-0effa7fb38da
Filesystem magic number: 0xEF53
Filesystem revision #: 1 (dynamic)
Filesystem features: has_journal resize_inode dir_index filetype needs_recovery sparse_super large_file
Filesystem flags: signed directory hash
Default mount options: (none)
Filesystem state: clean
Errors behavior: Continue
Filesystem OS type: Linux
Inode count: 15876096
Block count: 31730383
Reserved block count: 1586519
Free blocks: 12969773
Free inodes: 15859115
First block: 0
Block size: 4096
Fragment size: 4096
Reserved GDT blocks: 1016
Blocks per group: 32768
Fragments per group: 32768
Inodes per group: 16384
Inode blocks per group: 512
Filesystem created: Fri Jun 13 14:18:21 2008
Last mount time: Sat Nov 1 21:17:47 2008
Last write time: Sat Nov 1 21:17:47 2008
Mount count: 23
Maximum mount count: 26
Last checked: Fri Jun 13 14:18:21 2008
Check interval: 15552000 (6 months)
Next check after: Wed Dec 10 13:18:21 2008
Reserved blocks uid: 0 (user root)
Reserved blocks gid: 0 (group root)
First inode: 11
Inode size: 128
Journal inode: 8
Default directory hash: tea
Directory Hash Seed: 1f091f35-fe12-44ed-b527-7e32493a1849
Journal backup: inode blocks
Journal size: 128M

dumpe2fs 1.40-WIP (14-Nov-2006)
Filesystem volume name: <none>
Last mounted on: <not available>
Filesystem UUID: 85e5c969-8850-4fc1-acc2-8aff3200a3f9
Filesystem magic number: 0xEF53
Filesystem revision #: 1 (dynamic)
Filesystem features: has_journal resize_inode dir_index filetype needs_recovery sparse_super large_file
Filesystem flags: signed directory hash
Default mount options: (none)
Filesystem state: clean
Errors behavior: Continue
Filesystem OS type: Linux
Inode count: 61063168
Block count: 122096000
Reserved block count: 6104800
Free blocks: 24025176
Free inodes: 61063156
First block: 0
Block size: 4096
Fragment size: 4096
Reserved GDT blocks: 994
Blocks per group: 32768
Fragments per group: 32768
Inodes per group: 16384
Inode blocks per group: 512
Filesystem created: Thu Oct 9 16:17:03 2008
Last mount time: Sat Nov 1 21:17:47 2008
Last write time: Sat Nov 1 21:17:47 2008
Mount count: 4
Maximum mount count: 37
Last checked: Thu Oct 9 16:17:03 2008
Check interval: 15552000 (6 months)
Next check after: Tue Apr 7 16:17:03 2009
Reserved blocks uid: 0 (user root)
Reserved blocks gid: 0 (group root)
First inode: 11
Inode size: 128
Journal inode: 8
Default directory hash: tea
Directory Hash Seed: a7dede76-cc38-4fb6-a31c-8f535a9c9b68
Journal backup: inode blocks
Journal size: 128M
 
Old 11-03-2008, 09:00 AM
Volkan YAZICI
 
Default Electricity Cutoffs, EXT3 and Filesystems

On Sun, 02 Nov 2008, Mark Allums <mark@allums.com> writes:
> The short answer is going to be, work on getting more UPSes, and
> consider some type of longer-term (but still temporary) power source,
> like a Diesel generator.
>
> If you have any diagnostics at all, post a summary here. Someone may
> see something to do. Also, fstab file and perhaps the contents of any
> custom init scripts you use, or even your menu.list from
> /boot/grub. Anything that may give someone a clue.

Besides system setup information I sent to Andrei, in all servers /boot
is located at /dev/sda2 and formatted with ext2 filesystem.

> ReiserFS will work for a while, but unless they find some new,
> long-term upstream maintainers, it will eventually not be feasible to
> use it.

I really wonder the future of ReiserFS. I don't follow kernel related
improvements (and discussions) that much, but I still don't have a
reliable information about the development issues with ReiserFS.
Somebody is saying something, and another one is duplicating it --
without giving a single grain of thought -- to others and so on. But
AFAIK, there still isn't any official (you know what I mean by
_official_) explanation related with ReiserFS. Yep, Hans Reiser did some
nasty things. But would development of Linux stop if Linus Torvalds gets
in some sort of trouble, e.g. arrested?

> Better to make the switch now, starting with new hardware. I still
> like ext3 for now, and ext "4" is coming along nicely, I hear, it may
> be a good choice at some point. (But not right now.)

I dunno. I still think EXT3 as an ancient technology supported by major
IT companies. And people tend to swim in the direction of the flow, no
matter if it's right or wrong.


Regards.


--
To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
 
Old 11-03-2008, 09:08 AM
Volkan YAZICI
 
Default Electricity Cutoffs, EXT3 and Filesystems

On Mon, 03 Nov 2008, Robert E A Harvey <bobharvey@europe.com> writes:
> I used to operate a whole bunch of Solaris systems on survey ships,
> and power-loss situations were always fraught.
>
> My thoughts: ReiserFS is still available and stable, why not use it
> for a year and see what happens?

Actually, I'm inclined going in that direction too. In Turkish we have a
saying: "While wise one looks around for a bridge, mad on gets across
the river by swimming."

> My other thought: Hardly a recommendation, because I have not tried
> it, but have you looked at http://jfs.sourceforge.net/? You could put
> it on an old box and pull the power cord half a dozen times to see
> what happens

After all, JFS also does meta-data journaling. I don't think it'll bring
much more features than ReiserFS, except a so called community support.

> Passing thought: I've worked with instruments that use real-time
> linux, and most of those had a crash-proof file system of one sort or
> another. A bit of research into what they use might be good. I do
> know that Arcom use what they call "Compressed Journalling Flash File
> System (JFFS2)", but there are larger real-time systems with hard
> disks. One data acquisition system I used just used ext3 but mounted
> nosync. It didn't cause much trouble.

I've neither used, nor heard anyone using a JFFS[2] on a production
server, except embedded devices. Any experiences?

> It is the obvious solution: rig the serial output from the UPS to
> trigger a shutdown immediately.
>
> It is possible hough that the UPS may not be large enough to provide
> the amps required for all those servers during normal operation. I too
> have worked in Banana republics and on ships where the UPS is more
> trouble than it is worth.

Word.


Regards.


--
To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
 
Old 11-03-2008, 09:46 AM
Michael Iatrou
 
Default Electricity Cutoffs, EXT3 and Filesystems

When the date was Sunday 02 November 2008, Volkan YAZICI wrote:

> Please, I don't want to start a flamewar between filesystems. But could
> anybody give any recommendations to me?

First of all, avoid XFS at any cost: it has a bad history with power
failures.

IMHO, if you don't have any good reason for using ext3 (and I actually can
can't think any) go with ReiserFS.

Still, bare in mind that both reiserfs and ext3 are kind of obsolete: we are
all waiting brtfs and ext4 to become production-ready :>

--
Michael Iatrou (hluf)


--
To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
 
Old 11-03-2008, 12:23 PM
"Douglas A. Tutty"
 
Default Electricity Cutoffs, EXT3 and Filesystems

On Mon, Nov 03, 2008 at 11:47:40AM +0200, Volkan YAZICI wrote:
> On Sun, 2 Nov 2008, Andrei Popescu <andreimpopescu@gmail.com> writes:
> > Please post an /etc/fstab and the output of 'dumpe2fs -h' for one of
> > your filesystems (considering that they have been created with same
> > options).
>
> I've attached related /etc/fstab and "dumpe2fs -h" outputs for R&D and
> PREPROD servers.

> # /etc/fstab: static file system information.
> #
> # <file system> <mount point> <type> <options> <dump> <pass>
> proc /proc proc defaults 0 0
> /dev/sda3 / ext3 noatime 1 1
> /dev/sda4 /home ext3 noatime,nodev,nosuid 0 2
> /dev/sda2 /boot ext2 noatime,nodev,nosuid 1 1
> /dev/sda1 none swap sw 0 0
> /dev/md0 /srv/fs ext3 noatime,nodev,nosuid 0 2
> /dev/scd0 /media/cdrom0 udf,iso9660 user,noauto 0 0

If you mount ext3 with the data=journal option you may have better
recovery. See the man page. data=journal is what ext3 used to do but
the default was changed to give better performance.

My experience with jfs was good. I never had the system die (not be
able to recover) and I don't think I ever lost data (I too don't have a
UPS and I used to live where the power was very unreliable). JFS
recovers fast (a design criteria). However, do a google search on
lists.debian.org for JFS and read the thread where it has been
discussed. In the midst of that thread, I received an email from the
maintainer of jfstools which forwarded an email from the one person at
IBM who is left to watch for bugs: he was recommended agains JFS for new
projects since IBM pulled the rest of his team off of JFS.

Doug.


--
To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
 
Old 11-03-2008, 12:28 PM
"Aneurin Price"
 
Default Electricity Cutoffs, EXT3 and Filesystems

On Mon, Nov 3, 2008 at 10:46 AM, Michael Iatrou <m.iatrou@freemail.gr> wrote:
> When the date was Sunday 02 November 2008, Volkan YAZICI wrote:
>
>> Please, I don't want to start a flamewar between filesystems. But could
>> anybody give any recommendations to me?
>
> First of all, avoid XFS at any cost: it has a bad history with power
> failures.
>

I'd second this very strongly. I used XFS for a year or so on my
desktop and every time there was a power cut or a nasty crash I ended
up with filesystem damage - seemingly random files (not just ones in
active or recent use) truncated or just plain trashed; it's really
annoying when /etc/passwd gets filled with garbage. I eventually got
around to switching after it destroyed my filesystem beyond my ability
to recover it.

I'd recommend anything over XFS, including FAT12 or just writing stuff
down on a piece of paper.

-Nye

PS. Apparently they've improved some power-failure problems with XFS
since I used it, but then they also said that *before* I started using
it so I can't say I'd put any trust in that.


--
To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
 

Thread Tools




All times are GMT. The time now is 02:55 PM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org