date:20150414

 Hi.

On Tue, Apr 14, 2015 at 08:58:20AM +0200, Petter Adsen wrote:
> On Mon, 13 Apr 2015 15:41:03 +0200
> Vincent Lefevre  wrote:
> 
> > On 2015-04-13 14:45:25 +0200, Loïc Grenié wrote:
> > > 2015-04-13 14:39 GMT+02:00 Vincent Lefevre :
> > > > The problem is that this operation is (always?) very slow:
> > > > something like 100 seconds (1 minute and 40 seconds). It has been
> > > > reproducible for several months. The logs show nothing during
> > > > this operation.
> > > >
> > > > Any idea?
> > > 
> > > Maybe the directory is very large (even though its empty). Try
> > > 
> > > ls -ld tmp.
> > > 
> > >  and see if the file "tmp" is large.
> > 
> > Thanks! I didn't know that (I thought that the file system would
> > automatically "optimize" directories when files are removed, so
> > I've never looked closely at their size). Indeed:
> > 
> > ypig:~/eftests> ls -ld tmp
> > drwxr-xr-x 2 vlefevre vlefevre 29655040 2015-04-13 15:25:55 tmp/
> 
> Can someone please enlighten me as to why the entry for this directory
> is so large, even though it is empty? Since it's apparently obvious to
> everyone else, I would very much like to know :)

A case study:

$ mkdir tmp
$ du -sxh tmp
4.0Ktmp
$ for x in {1..10}; do touch tmp/$x; done
$ du -sxh tmp
2.1Mtmp
$ find tmp -type f | xargs rm
$ du -sxh tmp
2.1Mtmp
$ ls tmp | wc -l
0

Removing files from the directory does not change directory's inode
size. If using ext4, at least.

Reco


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20150414071227.GA7199@x101h

Re: reading an empty directory after reboot is very slow

On Tue, 14 Apr 2015 10:12:28 +0300
Reco  wrote:

>  Hi.
> 
> On Tue, Apr 14, 2015 at 08:58:20AM +0200, Petter Adsen wrote:
> > On Mon, 13 Apr 2015 15:41:03 +0200
> > Vincent Lefevre  wrote:
> > 
> > > On 2015-04-13 14:45:25 +0200, Loïc Grenié wrote:
> > > > 2015-04-13 14:39 GMT+02:00 Vincent Lefevre :
> > > > > The problem is that this operation is (always?) very slow:
> > > > > something like 100 seconds (1 minute and 40 seconds). It has
> > > > > been reproducible for several months. The logs show nothing
> > > > > during this operation.
> > > > >
> > > > > Any idea?
> > > > 
> > > > Maybe the directory is very large (even though its empty).
> > > > Try
> > > > 
> > > > ls -ld tmp.
> > > > 
> > > >  and see if the file "tmp" is large.
> > > 
> > > Thanks! I didn't know that (I thought that the file system would
> > > automatically "optimize" directories when files are removed, so
> > > I've never looked closely at their size). Indeed:
> > > 
> > > ypig:~/eftests> ls -ld tmp
> > > drwxr-xr-x 2 vlefevre vlefevre 29655040 2015-04-13 15:25:55 tmp/
> > 
> > Can someone please enlighten me as to why the entry for this
> > directory is so large, even though it is empty? Since it's
> > apparently obvious to everyone else, I would very much like to
> > know :)
> 
> A case study:
> 
> $ mkdir tmp
> $ du -sxh tmp
> 4.0Ktmp
> $ for x in {1..10}; do touch tmp/$x; done
> $ du -sxh tmp
> 2.1Mtmp
> $ find tmp -type f | xargs rm
> $ du -sxh tmp
> 2.1Mtmp
> $ ls tmp | wc -l
> 0
> 
> Removing files from the directory does not change directory's inode
> size. If using ext4, at least.

Interesting. Also good to know. Thank you :)

But if you create new files in that directory after deleting them, I
expect the inodes get reallocated?

Is this specific to Linux/ext4?

Petter

-- 
"I'm ionized"
"Are you sure?"
"I'm positive."


pgp9JfdVdPrPc.pgp
Description: OpenPGP digital signature

Re: Book questions

On Tue, 14 Apr 2015 02:43:53 +0800
Bret Busby  wrote:

> On 14/04/2015, Petter Adsen  wrote:
> 
> 
> 
> > My cat is walking on my keyboard now, demanding attention. Best not
> > to ignore him any longer. :)
> >
> 
> Can he program?

I'm not sure, but I take care to lock the screen and not let him see me
type my password.

> Cats are smart creatures.

You bet.

> "Dogs have masters - cats have staff"
> :)

That's how it works here, yes :)

Petter

-- 
"I'm ionized"
"Are you sure?"
"I'm positive."


pgpKSs6cJd1tQ.pgp
Description: OpenPGP digital signature

Re: Book questions

On Mon, 13 Apr 2015 16:36:44 -0500
David Wright  wrote:
> Quoting Petter Adsen (pet...@synth.no):
> > On Mon, 13 Apr 2015 20:21:49 +0300
> > Reco  wrote:
> > > Let's see as I didn't have OS design in mind. Something like:
> > > 
> > > Exit codes and their value in real life.
> > > Strings handling, memory allocation.
> > > Process control and daemonisation (sp?).
> > > Signal handling.
> > > Inter-process communication (sockets, pipes).
> > > IP protocol use and abuse.
> > > Shared memory.
> > > Threads.
> > > Libraries and their usage.
> > 
> > Just to pipe in here, these are among the things that I want an
> > understanding of - especially numbers 3, 4, 5, 6 and 9. With extra
> > focus on 9 and 6b :) Also things like communication between
> > processes and devices, file systems, etc. I want to learn how to
> > find out why things work the way they do, if that makes sense.
> 
> If you want to understand the basics, there is any number of tutorials
> on the web. If you want to play with them, then pick a language and go
> to a web page like https://docs.python.org/3/library/index.html
> and write some toy programs. Most of these facilities have wrappers
> that save you having to write C code to create, say, a couple of
> sockets that talk to each other. If you try this in C and it doesn't
> work, it might take you half a day to decide whether you've
> misunderstood the socket concept or just made a programming error.

I can understand that.

> As Reco said,
> 
> > > [...], and for the complex program you'll probably want
> > > something else as by today's standards C has poor result/effort
> > > ratio.

That I can also accept. I see that a lot of people advice me on going
with something other than C, and I can understand that there are good
reasons for this advice. While I still want to learn C at some point,
I'm beginning to think that it might be wise to consider getting a good
foundation in another language first.

Would Python be appropriate? I see a lot of software these days that is
written in Python, so it would be helpful in that way. The person I am
most likely to go to for help knows Python, so that's a bonus. And on
the subject of books, what would be a good introduction?

Petter

-- 
"I'm ionized"
"Are you sure?"
"I'm positive."


pgpmglATf2JKJ.pgp
Description: OpenPGP digital signature

Re: apt stuck at "Reading database"

2015-04-14 Thread Chris Bannister

On Mon, Apr 13, 2015 at 08:42:45AM -0400, Jape Person wrote:
> IIRC apt-listbugs or apt-listchanges (or both) don't work without the
> deb-src entries in /etc/apt/sources.list. 

Works fine for me. Did you *actually* try it?

-- 
"If you're not careful, the newspapers will have you hating the people
who are being oppressed, and loving the people who are doing the 
oppressing." --- Malcolm X


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20150414075903.GA19695@tal

Re: Debian 7 and external monitors and graphics adaptors

On 13/04/2015, Bret Busby  wrote:
> On 13/04/2015, Curt  wrote:
>> On 2015-04-09, Bret Busby  wrote:
>>> Hello.
>>>
>>> On a new installation of Debian 7 on an Acer "laptop" computer with an
>>> AMD Radeon R2 graphics adaptor, the external monitor does not work.
>>>
>>> The external monitor works with MS Win 7, with MS Win 8, with Debian
>>> 6, and with Ununtu 12.04 and with Ubuntu 14.04.
>>
>> Driver? (Ubuntu/Debian--compare).
>>
>>
>
> I have given the information of the graphics driver in Debian 7, for
> the Acer laptop with the AMD Radeon R2 graphics adaptor.
>

I note that, on the Acer V3-772G, Ubuntu shows the following, in
System -> Settings -> System -> Details -> Overview

"
Processor: Intel Core i7-4702MQ CPU A 2.20GHz x 8
Graphics: Intel Haswell Mobile
"

(In the window for that path in Ubuntu, it does not have a path
System -> Settings -> System -> Details -> Graphics)

so it apparently, is driving the inboard Intel graphics adaptor, and
not the nVIDIA GT750m graphics adaptor.

The Ubuntu information displayed, appears to not include the graphics driver.

I note that running lshw in Ubuntu 14.04 LTS, shows the NVIDIA graphics adaptor;

"
bret@bret-Aspire-V3-772:~$ lshw
WARNING: you should run this program as super-user.
bret-aspire-v3-772
description: Computer
width: 64 bits
capabilities: vsyscall32
  *-core
   description: Motherboard
   physical id: 0
 *-memory
  description: System memory
  physical id: 0
  size: 31GiB
 *-cpu
  product: Intel(R) Core(TM) i7-4702MQ CPU @ 2.20GHz
  vendor: Intel Corp.
  physical id: 1
  bus info: cpu@0
  size: 800MHz
  capacity: 800MHz
  width: 64 bits
  capabilities: fpu fpu_exception wp vme de pse tsc msr pae
mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr
sse sse2 ss ht tm pbe syscall nx pdpe1gb rdtscp x86-64 constant_tsc
arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc aperfmperf
eagerfpu pni pclmulqdq dtes64 monitor ds_cpl vmx est tm2 ssse3 fma
cx16 xtpr pdcm pcid sse4_1 sse4_2 movbe popcnt tsc_deadline_timer aes
xsave avx f16c rdrand lahf_lm abm ida arat epb xsaveopt pln pts dtherm
tpr_shadow vnmi flexpriority ept vpid fsgsbase tsc_adjust bmi1 avx2
smep bmi2 erms invpcid cpufreq
 *-pci
  description: Host bridge
  product: Xeon E3-1200 v3/4th Gen Core Processor DRAM Controller
  vendor: Intel Corporation
  physical id: 100
  bus info: pci@:00:00.0
  version: 06
  width: 32 bits
  clock: 33MHz
*-pci:0
 description: PCI bridge
 product: Xeon E3-1200 v3/4th Gen Core Processor PCI
Express x16 Controller
 vendor: Intel Corporation
 physical id: 1
 bus info: pci@:00:01.0
 version: 06
 width: 32 bits
 clock: 33MHz
 capabilities: pci normal_decode bus_master cap_list
 configuration: driver=pcieport
 resources: irq:40 ioport:4000(size=4096)
memory:d200-d2ff ioport:a000(size=536870912)
   *-display
description: 3D controller
product: GK107M [GeForce GT 750M]
vendor: NVIDIA Corporation
physical id: 0
bus info: pci@:01:00.0
version: a1
width: 64 bits
clock: 33MHz
capabilities: bus_master cap_list rom
configuration: driver=nouveau latency=0
resources: irq:51 memory:d200-d2ff
memory:a000-afff memory:b000-b1ff
ioport:4000(size=128) memory:b200-b207
*-display
 description: VGA compatible controller
 product: 4th Gen Core Processor Integrated Graphics Controller
 vendor: Intel Corporation
 physical id: 2
 bus info: pci@:00:02.0
 version: 06
 width: 64 bits
 clock: 33MHz
 capabilities: vga_controller bus_master cap_list rom
 configuration: driver=i915 latency=0
 resources: irq:48 memory:d300-d33f
memory:c000-cfff ioport:5000(size=64)
*-multimedia:0
 description: Audio device
 product: Xeon E3-1200 v3/4th Gen Core Processor HD Audio Controller
 vendor: Intel Corporation
 physical id: 3
 bus info: pci@:00:03.0
 version: 06
 width: 64 bits
 clock: 33MHz
 capabilities: bus_master cap_list
 configuration: driver=snd_hda_intel latency=0
 resources: irq:49 memory:d361-d3613fff
*-usb:0
 description: USB controller
 product: 8 Series/C220 Series Chipset Family USB xHCI
 vendor: Intel Corporation
 physical id: 14
 bus info: pci

Re: Is gnome-core really the gnome minimal install?

2015-04-14 Thread August Karlstrom


On 2015-04-14 03:20, Patrick Bartek wrote:

The rule mounts and unmounts flash drives -- just plug and unplug -- and
cards (any type using an external card or multi-card reader.  The
caveat is: you must plug the card in first, then plug the reader in.
Unmount by unplugging reader with the card still in it, then remove the
card. Doesn't work with internal multi-card readers.  Probably not with
single internal readers either.  For that you need a daemon like
udisks-daemon set to poll each card slot of the reader.

[...]

What advantages do you see with adding your own udev rule compared to 
simply starting a ConsoleKit session?


exec ck-launch-session dbus-launch 

instead of

exec 


-- August


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

Archive: https://lists.debian.org/mgijhm$ie4$1...@speranza.aioe.org

Re: reading an empty directory after reboot is very slow

 Hi.

On Tue, Apr 14, 2015 at 09:22:15AM +0200, Petter Adsen wrote:
> On Tue, 14 Apr 2015 10:12:28 +0300
> Reco  wrote:
> 
> >  Hi.
> > 
> > On Tue, Apr 14, 2015 at 08:58:20AM +0200, Petter Adsen wrote:
> > > On Mon, 13 Apr 2015 15:41:03 +0200
> > > Vincent Lefevre  wrote:
> > > 
> > > > On 2015-04-13 14:45:25 +0200, Loïc Grenié wrote:
> > > > > 2015-04-13 14:39 GMT+02:00 Vincent Lefevre :
> > > > > > The problem is that this operation is (always?) very slow:
> > > > > > something like 100 seconds (1 minute and 40 seconds). It has
> > > > > > been reproducible for several months. The logs show nothing
> > > > > > during this operation.
> > > > > >
> > > > > > Any idea?
> > > > > 
> > > > > Maybe the directory is very large (even though its empty).
> > > > > Try
> > > > > 
> > > > > ls -ld tmp.
> > > > > 
> > > > >  and see if the file "tmp" is large.
> > > > 
> > > > Thanks! I didn't know that (I thought that the file system would
> > > > automatically "optimize" directories when files are removed, so
> > > > I've never looked closely at their size). Indeed:
> > > > 
> > > > ypig:~/eftests> ls -ld tmp
> > > > drwxr-xr-x 2 vlefevre vlefevre 29655040 2015-04-13 15:25:55 tmp/
> > > 
> > > Can someone please enlighten me as to why the entry for this
> > > directory is so large, even though it is empty? Since it's
> > > apparently obvious to everyone else, I would very much like to
> > > know :)
> > 
> > A case study:
> > 
> > $ mkdir tmp
> > $ du -sxh tmp
> > 4.0Ktmp
> > $ for x in {1..10}; do touch tmp/$x; done
> > $ du -sxh tmp
> > 2.1Mtmp
> > $ find tmp -type f | xargs rm
> > $ du -sxh tmp
> > 2.1Mtmp
> > $ ls tmp | wc -l
> > 0
> > 
> > Removing files from the directory does not change directory's inode
> > size. If using ext4, at least.
> 
> Interesting. Also good to know. Thank you :)
> 
> But if you create new files in that directory after deleting them, I
> expect the inodes get reallocated?

Yes, they should.


> Is this specific to Linux/ext4?

No. I'm not sure about vxfs, btrfs and zfs (or rather - lazy to check
it), but for ext family, ufs and jfs2 - it works all the same.

Reco


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20150414091501.GA8777@x101h

Add a 3rd drive to a existing raid1 (not as spare)

2015-04-14 Thread basti

Hello
I want to add a 3rd drive to a raid 1 array (for disaster backup, the
drive will be connectet once a week).
I dry:

mdadm --add /dev/md1 /dev/sde1

when I fail the drive there is a message

FailSpare event detected on md device /dev/md/1, component device /dev/sde1

How can I add the 3rd drive as "real drive" and not as spare?

Best Regards


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/552ce0fe.2030...@arcor.de

Re: Add a 3rd drive to a existing raid1 (not as spare)

2015-04-14 Thread Darac Marjal

On Tue, Apr 14, 2015 at 11:42:22AM +0200, basti wrote:
> Hello
> I want to add a 3rd drive to a raid 1 array (for disaster backup, the
> drive will be connectet once a week).
> I dry:
> 
> mdadm --add /dev/md1 /dev/sde1
> 
> when I fail the drive there is a message
> 
> FailSpare event detected on md device /dev/md/1, component device /dev/sde1
> 
> How can I add the 3rd drive as "real drive" and not as spare?

Looking at the mdadm manpage (i.e. I've not tried this myself), you
could try being moew explicit about things:

mdadm --add /dev/md1 --raid-devices=3 --spare-devices=0 /dev/sde1

(Note however that the manpage I'm reading - the one in Wheezy - seems a
little unsure whether the option is --raid-devices or --raid-disks).

I think, also, you can convert /dev/sde1 from "spare" to "live" by
issuing:

mdadm --grow /dev/md1 --raid-devices=3 --spare-devices=0

One last thing to be aware of. If you DO set up your three-disk RAID1
and then take the "backup" drive out of the set, be aware that that will
mark the RAID as "degraded" and expect to get warnings to that effect.

There doesn't appear to be a way to re-mark a device as spare so, to
cleanly remove it, you will need to mark it as faulty (mdadm /dev/md1 -f
/dev/sde1). I don't know, off-hand, if this will affect the backup,
though.

> 
> Best Regards
> 
> 
> -- 
> To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
> with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
> Archive: https://lists.debian.org/552ce0fe.2030...@arcor.de
> 

signature.asc
Description: Digital signature

Re: Add a 3rd drive to a existing raid1 (not as spare)

2015-04-14 Thread basti

thanks but


# mdadm --add /dev/md1 --raid-devices=3 --spare-devices=0 /dev/sde1
mdadm:option --raid-devices not valid in manage mode

# mdadm --add /dev/md1 --spare-devices=0 /dev/sde1
mdadm:option --spare-devices not valid in manage mode

# mdadm --grow /dev/md1 --raid-devices=3 --spare-devices=0
mdadm:option --spare-devices not valid in grow mode

Am 14.04.2015 12:07, schrieb Darac Marjal:
> On Tue, Apr 14, 2015 at 11:42:22AM +0200, basti wrote:
>> Hello
>> I want to add a 3rd drive to a raid 1 array (for disaster backup, the
>> drive will be connectet once a week).
>> I dry:
>>
>> mdadm --add /dev/md1 /dev/sde1
>>
>> when I fail the drive there is a message
>>
>> FailSpare event detected on md device /dev/md/1, component device /dev/sde1
>>
>> How can I add the 3rd drive as "real drive" and not as spare?
> Looking at the mdadm manpage (i.e. I've not tried this myself), you
> could try being moew explicit about things:
>
> mdadm --add /dev/md1 --raid-devices=3 --spare-devices=0 /dev/sde1
>
> (Note however that the manpage I'm reading - the one in Wheezy - seems a
> little unsure whether the option is --raid-devices or --raid-disks).
>
> I think, also, you can convert /dev/sde1 from "spare" to "live" by
> issuing:
>
> mdadm --grow /dev/md1 --raid-devices=3 --spare-devices=0
>
> One last thing to be aware of. If you DO set up your three-disk RAID1
> and then take the "backup" drive out of the set, be aware that that will
> mark the RAID as "degraded" and expect to get warnings to that effect.
>
> There doesn't appear to be a way to re-mark a device as spare so, to
> cleanly remove it, you will need to mark it as faulty (mdadm /dev/md1 -f
> /dev/sde1). I don't know, off-hand, if this will affect the backup,
> though.
>
>> Best Regards
>>
>>
>> -- 
>> To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
>> with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
>> Archive: https://lists.debian.org/552ce0fe.2030...@arcor.de
>>


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/552cea8f.9020...@arcor.de

Re: debian 8

On Tuesday 14 April 2015 02:18:03 Petter Adsen wrote:
> On Mon, 13 Apr 2015 17:26:12 -0400
>
> Gene Heskett  wrote:
> > On Monday 13 April 2015 16:56:05 Celejar wrote:
> > > On Mon, 13 Apr 2015 20:00:15 +0200
> > >
> > > Petter Adsen  wrote:
> > > > On Mon, 13 Apr 2015 13:04:28 -0400
> > > >
> > > > Gene Heskett  wrote:
> > > > > Is there not another service that is more "friendly" to the
> > > > > use its used for?
> > > >
> > > > Not that many that has Linux clients, unfortunately. I know of
> > > > only two - Google Drive (unofficial client only, and I dislike
> > > > Google), and CloudMe (where I haven't got any free space right
> > > > now).
> > >
> > > As I've noted on another recent thread, some cloud providers
> > > (Yandex, Box) offer WebDAV access, which (potentially) makes linux
> > > access relatively straightforward via something like davfs2.
> > >
> > > Celejar
> >
> > I must be showing my age then, what in tuncket is davfs2?
>
> If you read this, I bet you will be able to guess what davfs2 is for
> ;)
>
> https://en.wikipedia.org/wiki/WebDAV
>
> Petter

Have already read it Petter, and it does sound useful. I expect its one 
of the things I'l install when I do a Jessie install near the end of the 
month.

Thanks Petter.

Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page 


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/201504140652.33033.ghesk...@wdtv.com

Re: reading an empty directory after reboot is very slow



On Tuesday 14 April 2015 02:58:20 Petter Adsen wrote:
> On Mon, 13 Apr 2015 15:41:03 +0200
>
> Vincent Lefevre  wrote:
> > On 2015-04-13 14:45:25 +0200, Loïc Grenié wrote:
> > > 2015-04-13 14:39 GMT+02:00 Vincent Lefevre :
> > > > The problem is that this operation is (always?) very slow:
> > > > something like 100 seconds (1 minute and 40 seconds). It has
> > > > been reproducible for several months. The logs show nothing
> > > > during this operation.
> > > >
> > > > Any idea?
> > >
> > > Maybe the directory is very large (even though its empty). Try
> > >
> > > ls -ld tmp.
> > >
> > >  and see if the file "tmp" is large.
> >
> > Thanks! I didn't know that (I thought that the file system would
> > automatically "optimize" directories when files are removed, so
> > I've never looked closely at their size). Indeed:
> >
> > ypig:~/eftests> ls -ld tmp
> > drwxr-xr-x 2 vlefevre vlefevre 29655040 2015-04-13 15:25:55 tmp/
>
> Can someone please enlighten me as to why the entry for this directory
> is so large, even though it is empty? Since it's apparently obvious to
> everyone else, I would very much like to know :)
>
> Petter

I'll second that request myself Petter.

Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page 


--
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/201504140654.38193.ghesk...@wdtv.com

Re: reading an empty directory after reboot is very slow

On Mon, Apr 13, 2015, at 19:28, Bob Proulx wrote:
> Without dir_index an ext filesystem with large directories is slow due
> to the linear nature of directories.  But with dir_index it should be
> using a B-tree data structure and should be much faster.  This can be
> turned off for a migration if it is off.
> 
>   tune2fs -O dir_index /dev/sda5
> 
> But existing directories are not converted.  Only new directories are

Do a forced e2fsck run on the filesystem, and it should add the indexes to all 
directories that lack it.  It can also change the hash algorithm.

BTW, the e2fsck manpage states that it WILL compress directories if it has any 
reason to touch the directory.

If you want e2fsck to rehash or compress all directories, you have to run it as 
e2fsck -D so that it will optimize/rehash every directory, not just those that 
were lacking indexes or that had to be repaired.

> it though so for the most part that is okay.  It is only directories
> such as /tmp that sporadically might have surged large that really
> benefit from a manual recreation conversion in order to have B-trees
> turned on for a migration to dir_index.

If you have the resources required (RAM), always have ephemeral "tmp" 
directories in tmpfs.  All contents will be discarded on reboot/poweroff or if 
you umount the tmpfs, but it should be the fastest possible filesystem in Linux 
as long as you don't start swapping (xfs and ext4 are much better optimized to 
the "hit the spinning rust" case than tmpfs+swapper IME).

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique de Moraes Holschuh 

-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/1429008998.2651374.253499429.00d16...@webmail.messagingengine.com

Re: Book questions

On Tuesday, April 14, 2015 at 1:10:04 PM UTC+5:30, Petter Adsen wrote:
> On Mon, 13 Apr 2015 16:36:44 -0500
> David Wright wrote:
> > Quoting Petter Adsen wrote:
> > > On Mon, 13 Apr 2015 20:21:49 +0300
> > > Reco  wrote:
> > > > Let's see as I didn't have OS design in mind. Something like:
> > > > 
> > > > Exit codes and their value in real life.
> > > > Strings handling, memory allocation.
> > > > Process control and daemonisation (sp?).
> > > > Signal handling.
> > > > Inter-process communication (sockets, pipes).
> > > > IP protocol use and abuse.
> > > > Shared memory.
> > > > Threads.
> > > > Libraries and their usage.
> > > 
> > > Just to pipe in here, these are among the things that I want an
> > > understanding of - especially numbers 3, 4, 5, 6 and 9. With extra
> > > focus on 9 and 6b :) Also things like communication between
> > > processes and devices, file systems, etc. I want to learn how to
> > > find out why things work the way they do, if that makes sense.
> > 
> > If you want to understand the basics, there is any number of tutorials
> > on the web. If you want to play with them, then pick a language and go
> > to a web page like https://docs.python.org/3/library/index.html
> > and write some toy programs. Most of these facilities have wrappers
> > that save you having to write C code to create, say, a couple of
> > sockets that talk to each other. If you try this in C and it doesn't
> > work, it might take you half a day to decide whether you've
> > misunderstood the socket concept or just made a programming error.
> 
> I can understand that.
> 
> > As Reco said,
> > 
> > > > [...], and for the complex program you'll probably want
> > > > something else as by today's standards C has poor result/effort
> > > > ratio.
> 
> That I can also accept. I see that a lot of people advice me on going
> with something other than C, and I can understand that there are good
> reasons for this advice. While I still want to learn C at some point,
> I'm beginning to think that it might be wise to consider getting a good
> foundation in another language first.

In case it helps I saw this

| And Rob Hagan at Monash had shown that you could teach students more COBOL
| with one semester of Scheme and one semester of COBOL than you could with 
| three semesters of COBOL. 
from here 
https://groups.google.com/d/msg/erlang-programming/5X1irAmLMD8/qCQJ11Y5jEAJ 

What that is saying is that priming your learning curve is more 
important than what you learn. And COBOL (like C) is a terrible way to do that

And if you still need convincing that C is a painful intro to programming,
please read section 4 of
http://www.the-magus.in/Publications/chor.pdf

Beyond that what you should take up really depends on what calls you:
- python is nice if its scripts
- something else (haskell?) or maybe something more esoteric like Julia, APL
if its mathematical
- etc
ie choose a language that optimizes an area that primarily calls you

> 
> Would Python be appropriate? I see a lot of software these days that is
> written in Python, so it would be helpful in that way.

Specifically for linux system-level stuff, python will give you 80-90% of the
C level stuff at ⅕ the pain.
eg for TCP/IP networking look at  https://docs.python.org/2/library/socket.html


--
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/5dfc17f1-9797-49b4-b0a2-9c2498353...@googlegroups.com

Re: [SOLVED] Trailing "m"s at the end of every line when viewing man pages

2015-04-14 Thread Stephen Powell

On Mon, 06 Apr 2015 21:51:05 -0400 (EDT), Stephen Powell wrote:
> 
> Here's how I fixed it, or rather, how I worked around it.
> ...

For those of you who are interested, I wrote up what I learned about serial 
terminals and
serial consoles and put it in my lilo web page at

   http://users.wowway.com/~zlinuxman/lilo.htm

Look for the section titled "Using a Serial Console".  I think I will eventually
break most of this information out into a separate web page about serial 
consoles and
terminals and reference it from the lilo web page.  But for now, until I can 
find the time to
redo it, it's in the lilo web page.

-- 
  .''`. Stephen Powell
 : :'  :
 `. `'`
   `-

-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/803123522.24065171.1429010715252.javamail.zim...@wowway.com

Re: Book questions

On Tue, 14 Apr 2015 03:59:15 -0700 (PDT)
Rusi Mody  wrote:
> On Tuesday, April 14, 2015 at 1:10:04 PM UTC+5:30, Petter Adsen wrote:
> > That I can also accept. I see that a lot of people advice me on
> > going with something other than C, and I can understand that there
> > are good reasons for this advice. While I still want to learn C at
> > some point, I'm beginning to think that it might be wise to
> > consider getting a good foundation in another language first.
> 
> In case it helps I saw this
> 
> | And Rob Hagan at Monash had shown that you could teach students
> more COBOL | with one semester of Scheme and one semester of COBOL
> than you could with | three semesters of COBOL. 
> from here
> https://groups.google.com/d/msg/erlang-programming/5X1irAmLMD8/qCQJ11Y5jEAJ 
> 
> What that is saying is that priming your learning curve is more 
> important than what you learn. And COBOL (like C) is a terrible way
> to do that

I understand.

> And if you still need convincing that C is a painful intro to
> programming, please read section 4 of
> http://www.the-magus.in/Publications/chor.pdf

The first few pages was enough to support your statement :)

> Beyond that what you should take up really depends on what calls you:
> - python is nice if its scripts

Well, on a practical level I need something that can be used for
sysadmin tasks, preferably in a way that is somewhat portable. If it
can also be used to learn basic GUI programming, then that is a big
bonus. Digging into system internals is also interesting.

> - something else (haskell?) or maybe something more esoteric like
> Julia, APL if its mathematical

"Esoteric" may be fascinating, but I need something where I can find
online resources and support, so nothing too weird.

> - etc
> ie choose a language that optimizes an area that primarily calls you
> 
> > 
> > Would Python be appropriate? I see a lot of software these days
> > that is written in Python, so it would be helpful in that way.
> 
> Specifically for linux system-level stuff, python will give you
> 80-90% of the C level stuff at ⅕ the pain.
> eg for TCP/IP networking look at
> https://docs.python.org/2/library/socket.html

OK, that sounds reasonable. I am looking at books that I can purchase
online, does anyone know if "Learning Python" from O'Reilly is decent?

Petter

-- 
"I'm ionized"
"Are you sure?"
"I'm positive."


pgpDJ9lsBL6wi.pgp
Description: OpenPGP digital signature

Re: Book questions

2015-04-14 Thread Nate Bargmann

As this is starting to take the tone of a religious argument ( :-) let
me say that while you may not need to know all of the dark corners of C,
you will want to know its semantics and here is why.  Inevitably you
will have to need to use system calls and when you look them up in the
manual pages what is described is the C interface.  Certainly, many
higher level languages offer wrappers around various system calls but
often not all of them so it will be to your benefit to at least be
comfortable with some knowledge of C semantics.

There will be times when you'll need to consult the C library
documentation and, guess what, its documentation is written assuming a
familiarity with C.  Many other libraries have documentation for C even
though wrappers are offered for various languages.  The list goes on.

Personally, until I got a better handle on C, I had difficulty really
understanding the Linux/POSIX system.

- Nate

-- 

"The optimist proclaims that we live in the best of all
possible worlds.  The pessimist fears this is true."

Ham radio, Linux, bikes, and more: http://www.n0nb.us


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20150414112806.gx...@n0nb.us

Re: Book questions

On Tuesday 14 April 2015 03:35:50 Petter Adsen wrote:
> On Mon, 13 Apr 2015 16:36:44 -0500
>
> David Wright  wrote:
> > Quoting Petter Adsen (pet...@synth.no):
> > > On Mon, 13 Apr 2015 20:21:49 +0300
> > >
> > > Reco  wrote:
> > > > Let's see as I didn't have OS design in mind. Something like:
> > > >
> > > > Exit codes and their value in real life.
> > > > Strings handling, memory allocation.
> > > > Process control and daemonisation (sp?).
> > > > Signal handling.
> > > > Inter-process communication (sockets, pipes).
> > > > IP protocol use and abuse.
> > > > Shared memory.
> > > > Threads.
> > > > Libraries and their usage.
> > >
> > > Just to pipe in here, these are among the things that I want an
> > > understanding of - especially numbers 3, 4, 5, 6 and 9. With extra
> > > focus on 9 and 6b :) Also things like communication between
> > > processes and devices, file systems, etc. I want to learn how to
> > > find out why things work the way they do, if that makes sense.
> >
> > If you want to understand the basics, there is any number of
> > tutorials on the web. If you want to play with them, then pick a
> > language and go to a web page like
> > https://docs.python.org/3/library/index.html and write some toy
> > programs. Most of these facilities have wrappers that save you
> > having to write C code to create, say, a couple of sockets that talk
> > to each other. If you try this in C and it doesn't work, it might
> > take you half a day to decide whether you've misunderstood the
> > socket concept or just made a programming error.
>
> I can understand that.
>
> > As Reco said,
> >
> > > > [...], and for the complex program you'll probably want
> > > > something else as by today's standards C has poor result/effort
> > > > ratio.
>
> That I can also accept. I see that a lot of people advice me on going
> with something other than C, and I can understand that there are good
> reasons for this advice. While I still want to learn C at some point,
> I'm beginning to think that it might be wise to consider getting a
> good foundation in another language first.
>
> Would Python be appropriate? I see a lot of software these days that
> is written in Python, so it would be helpful in that way. The person I
> am most likely to go to for help knows Python, so that's a bonus. And
> on the subject of books, what would be a good introduction?
>
> Petter

If I can interject a bit here, if one has come up thru the ranks of 
assembly, C is the next logical step above working in that cpu's native 
language. Its functions are basically a core group of assembly language 
functions contained in the various libraries one links in to get the  
job at hand done. For smaller cpu's that is.  I do 99% of my coding on a 
6809/6309 based machine in assembly.  And I am still doing it.

My understanding of the quad core phenom in this machine at that assembly 
level will never happen, so a higher level language that handles all the 
nitty's and gritty's, the greasy side of getting the job done is 
required in order to get anything of consequence done.  So much as I 
hate to say it, C is not my first choice to write a background task 
handler in.

Python would appear to be a good choice but I don't understand it well 
enough to be "productive" in it, so my choice was something a bit more 
conventional, so I'll plead guilty to having bash scripts doing even 
obscure background daemon work here.  Except for large number 
(double-double or double-float) math, it is entirely adequate for the 
jobs I ask it to do.

My point, if there is one, is that the language used, needs to be on a 
scale that allows the job to be done, with few or no "surprises" if one 
is to be productive in terms of getting the job done.  In some senses, 
the higher level lanuages also limit you, by offering only "canned" 
functions unless you can add to the libraries as needed.

Those languages that do such limits on the coder tend to be 5 year 
flashes in the pan and the repos are polluted with them. BUT, they do 
work well for what they do or they would never have gained any traction.  

Python I believe, has more than amply proved that it CAN do the job 
regardless of the versatility the coder asks it to do...

The name given to that language is completely arbitrary.  Python, from 
the greasy side, may well be the best parts of each mix of languages 
that start with bash/lisp and going upward until we have the next great 
thing.

Have we a next great thing waiting in the wings? I am reminded of that 
old saying about beauty being defined in the eye of the beerholder. ;-)  

Besides there is probably a Python 4 waiting to pounce on any upstarts 
that are in effect a wash, rinse, and repeat of an old language. ;-)

Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page 

-- 
To UNSUBSCRIBE, email to d

Re: reading an empty directory after reboot is very slow

On Tue, Apr 14, 2015, at 04:22, Petter Adsen wrote:
> But if you create new files in that directory after deleting them, I
> expect the inodes get reallocated?

They do, but a directory does not store inodes.
http://en.wikipedia.org/wiki/Inode

For ext4:
https://ext4.wiki.kernel.org/index.php/Ext4_Disk_Layout

And yes, directory entries are reused, just like inodes. But if I read that
page right, we do pay a price for somewhat limited backwards compatibility, and
I bet there are performance and scalability reasons why it is reusing/rewriting
sections of the htree on-disk instead of always writing it on its entirely
(which would have it always optimized on disk).

> Is this specific to Linux/ext4?

Not really. That said, a specific filesystem could optimize/compress on-media
directory structures when it detects the directory is in dire need of a
cleanup... at the cost of low performance (and high memory usage if the
directories can host very large number of objects) peaks at runtime, which is
something to be avoided.

Also, some filesystems always read/write directories as a whole, and thus
they're likely to keep it compressed/optimized at all times. But this will
come with some sort of (not that large) arbritary limit on number of entries in
a directory.

Leaving directory optimization to an out-of-band process makes the performance
hit predictable and schedulable by the system administrator. But it would be
really nice if we could do it with the ext4 filesystem online (as opposed to
have to unmount it first).

Anyway, just like file fragmentation, it really takes a pathogenic workload to
get directories as messed-up as the one in this thread. It won't happen in the
general use case.

Also, some of the Unix best-practices do address this kind of filesystem issue.
One such best-practice is that you don't remove just the files in ephemeral
directories: you either use an ephemeral filesystem (tmpfs) in the first place
which is optimized for reuse in Linux, Solaris and the BSDs, or you recursively
remove the directory itself (and recreate it -- but do it safely, there are
race condition concerns here if the parent is world-writeable).

--
"One disk to rule them all, One disk to find them. One disk to bring
them all and in the darkness grind them. In the Land of Redmond
where the shadows lie." -- The Silicon Valley Tarot
Henrique de Moraes Holschuh

--
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive:
https://lists.debian.org/1429012035.2661323.253500345.5a1a5...@webmail.messagingengine.com

Re: Book questions

On Tuesday, April 14, 2015 at 5:00:04 PM UTC+5:30, Petter Adsen wrote:
> On Tue, 14 Apr 2015 03:59:15 -0700 (PDT)
> Rusi Mody wrote:
> > Specifically for linux system-level stuff, python will give you
> > 80-90% of the C level stuff at ⅕ the pain.
> > eg for TCP/IP networking look at
> > https://docs.python.org/2/library/socket.html
> 
> OK, that sounds reasonable. I am looking at books that I can purchase
> online, does anyone know if "Learning Python" from O'Reilly is decent?

Learning python is good for learning python :-)
Not for learning linux system calls

Not sure of book for TCP/IP (sockets) but if you see this tutorial
https://docs.python.org/3/howto/sockets.html
you will see that in couple of lines you are actually trying something at the
interpreter.

C (or C++/Java/C#...) programmers never get the advantage of using an 
interpreter.
Heck you could use a C interpreter; but for some reason this is considered
improper

--
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/38add08d-c570-40d7-9f6d-7c54ac491...@googlegroups.com

Re: Book questions

On Tuesday, April 14, 2015 at 5:00:04 PM UTC+5:30, Petter Adsen wrote:
> On Tue, 14 Apr 2015 03:59:15 -0700 (PDT)
> Rusi Mody wrote:
> > Beyond that what you should take up really depends on what calls you:
> > - python is nice if its scripts
> 
> Well, on a practical level I need something that can be used for
> sysadmin tasks, preferably in a way that is somewhat portable. If it
> can also be used to learn basic GUI programming, then that is a big
> bonus. Digging into system internals is also interesting.

This seems to be at that level
http://macadmins.psu.edu/wp-content/uploads/sites/1567/2013/06/psumacconf2013-practical-python-for-mac-admins.pdf

[claims to be for mac - but not much mac-specific stuff that I can see]


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/80027cd1-5d45-4160-b999-a7446a937...@googlegroups.com

Re: Add a 3rd drive to a existing raid1 (not as spare)

 Hi.

On Tue, Apr 14, 2015 at 11:42:22AM +0200, basti wrote:
> Hello
> I want to add a 3rd drive to a raid 1 array (for disaster backup, the
> drive will be connectet once a week).
> I dry:
> 
> mdadm --add /dev/md1 /dev/sde1
> 
> when I fail the drive there is a message
> 
> FailSpare event detected on md device /dev/md/1, component device /dev/sde1
> 
> How can I add the 3rd drive as "real drive" and not as spare?

You've started going into right direction, but there's one small step
you need to take:

mdadm --add /dev/md1 /dev/sde1
mdadm --grow --raid-devices=3 /dev/md1

Last command will convert spare drive to a 'real' one.


Or, you can play rough:

mdadm --grow --raid-devices=3 --force /dev/md1
mdadm --add /dev/md1 /dev/sde1

Reco


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20150414122755.GA19826@x101h

Re: reading an empty directory after reboot is very slow

On 2015-04-13 15:50:40 -0500, David Wright wrote:
> That's staggering. My /var/lib/dpkg/info has ~8900 files and occupies
> 462848 bytes. So that would be over ½million files in your case.
> Does eftests stand for "excessive files tests"!

It means "elementary function tests", but what this doesn't say is
that these tests are exhaustive: 1 file = a small interval on which
the double-precision function (e.g. exp, log) can be approximated
by a small-degree polynomial, and the whole double-precision domain
must be covered.

Now, more interestingly, the fault is due to... proprietary software.
I wrote these tests about 15 years ago and I needed rigorous interval
arithmetic in multiple precision, and at that time, the Maple intpak
package was the only thing I found (though a few years later, despite
what its documentation said, it was shown that it was not rigorous at
all, and I might have chosen a better solution with free software).
So, I had to use Maple, and still use it (now with intpakX, which is
better but still based on assumptions that could be wrong) because I
haven't rewritten my tests completely. Maple is only used for ISO C
code generation. In normal use, code is generated, then run, and after
a few minutes (to get the result), the corresponding program can be
removed, so that few files are present in such a directory at the same
time. But some colleague in another lab needed these test files and he
didn't have Maple. So, I had to generate all of them (yes, something
like half a million) and give him a huge compressed tar file (not sent
by e-mail, of course!).

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20150414123552.ga25...@ypig.lip.ens-lyon.fr

Re: usb wireless keyboard and mouse (was debian 8)

2015-04-14 Thread Stefan Monnier

>> The bios, the last defense when things go south, may not
>> regcognise a bluetooth > usb attached keyboard.
> AFAIK the BIOS simply sees a USB keyboard and mouse whether or not the
> actual device will be reached via a wire or a radio signal.

This depends: there are two kinds of cordless mouses and keyboards
connected via a USB dongle:
- Bluetooth keyboard with a USB dongle, in which case the dongle is
  a generic Bluetooth adapter (and is not needed if your computer
  already has Bluetooth).
- A "wireless keyboard" using some proprietary wireless protocol.
In the second, case you don't need any special driver and the device
indeed appears as a plain old USB keyboard to the system.  But in the
first case, the keyboard won't be recognized by all BIOSes since it
first requires a driver for the USB<->Bluetooth dongle.


Stefan


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/jwviocyq4cq.fsf-monnier+gmane.linux.debian.u...@gnu.org

Re: Add a 3rd drive to a existing raid1 (not as spare)

2015-04-14 Thread Mart van de Wege

basti  writes:

If I do this it works:

# mdadm --create /dev/md0 --level=1 --raid-devices=2 /dev/loop0 /dev/loop1

Creates a two disk RAID1 array.

Adding a third disk:

# mdadm --grow /dev/md0 --level=1 --raid-devices=3 --add /dev/loop2

And:

# mdadm --detail /dev/md0
/dev/md0:
Version : 1.2
  Creation Time : Tue Apr 14 14:27:00 2015
 Raid Level : raid1
 Array Size : 1047552 (1023.17 MiB 1072.69 MB)
  Used Dev Size : 1047552 (1023.17 MiB 1072.69 MB)
   Raid Devices : 3
  Total Devices : 3
Persistence : Superblock is persistent

Update Time : Tue Apr 14 14:28:39 2015
  State : clean 
 Active Devices : 3
Working Devices : 3
 Failed Devices : 0
  Spare Devices : 0

   Name : gaheris:0  (local to host gaheris)
   UUID : f330ab72:fe728ef6:23d3ab0f:5a6c67ff
 Events : 40

Number   Major   Minor   RaidDevice State
   0   700  active sync   /dev/loop0
   1   711  active sync   /dev/loop1
   2   722  active sync   /dev/loop2


Removing it:

# mdadm /dev/md0 --fail /dev/loop2 --remove /dev/loop2
mdadm: set /dev/loop2 faulty in /dev/md0
mdadm: hot removed /dev/loop2 from /dev/md0

And set the array back to 2:

# mdadm --grow /dev/md0 --raid-devices=2
raid_disks for /dev/md0 set to 2



> thanks but
>
>
> # mdadm --add /dev/md1 --raid-devices=3 --spare-devices=0 /dev/sde1
> mdadm:option --raid-devices not valid in manage mode
>
> # mdadm --add /dev/md1 --spare-devices=0 /dev/sde1
> mdadm:option --spare-devices not valid in manage mode
>
> # mdadm --grow /dev/md1 --raid-devices=3 --spare-devices=0
> mdadm:option --spare-devices not valid in grow mode
>
> Am 14.04.2015 12:07, schrieb Darac Marjal:
>> On Tue, Apr 14, 2015 at 11:42:22AM +0200, basti wrote:
>>> Hello
>>> I want to add a 3rd drive to a raid 1 array (for disaster backup, the
>>> drive will be connectet once a week).
>>> I dry:
>>>
>>> mdadm --add /dev/md1 /dev/sde1
>>>
>>> when I fail the drive there is a message
>>>
>>> FailSpare event detected on md device /dev/md/1, component device /dev/sde1
>>>
>>> How can I add the 3rd drive as "real drive" and not as spare?
>> Looking at the mdadm manpage (i.e. I've not tried this myself), you
>> could try being moew explicit about things:
>>
>> mdadm --add /dev/md1 --raid-devices=3 --spare-devices=0 /dev/sde1
>>
>> (Note however that the manpage I'm reading - the one in Wheezy - seems a
>> little unsure whether the option is --raid-devices or --raid-disks).
>>
>> I think, also, you can convert /dev/sde1 from "spare" to "live" by
>> issuing:
>>
>> mdadm --grow /dev/md1 --raid-devices=3 --spare-devices=0
>>
>> One last thing to be aware of. If you DO set up your three-disk RAID1
>> and then take the "backup" drive out of the set, be aware that that will
>> mark the RAID as "degraded" and expect to get warnings to that effect.
>>
>> There doesn't appear to be a way to re-mark a device as spare so, to
>> cleanly remove it, you will need to mark it as faulty (mdadm /dev/md1 -f
>> /dev/sde1). I don't know, off-hand, if this will affect the backup,
>> though.
>>
>>> Best Regards
>>>
>>>
>>> -- 
>>> To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
>>> with a subject of "unsubscribe". Trouble? Contact 
>>> listmas...@lists.debian.org
>>> Archive: https://lists.debian.org/552ce0fe.2030...@arcor.de
>>>

-- 
"We will need a longer wall when the revolution comes."
--- AJS, quoting an uncertain source.


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/86k2xeevph@gaheris.avalon.lan

Re: Debian 7 and external monitors and graphics adaptors

2015-04-14 Thread Curt

On 2015-04-14, Bret Busby  wrote:
>
> so it apparently, is driving the inboard Intel graphics adaptor, and
> not the nVIDIA GT750m graphics adaptor.

The best thing would be to look at the log file for X (on Squeeze LTS
that is to be found at the following location: '/var/log/Xorg.0.log') in
order to know which driver you're using (amongst other things--errors,
warnings, etc.).

For the driver the following grep ditty seems to work fine:

curty@einstein:~$ grep -B2 'Module class: X.Org Video Driver' 
/var/log/Xorg.0.log
(II) Module fglrx: vendor="FireGL - ATI Technologies Inc."
 compiled for 1.4.99.906, module version = 8.95.3
 Module class: X.Org Video Driver

-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/slrnmiq3p9.31j.cu...@einstein.electron.org

Re: debian 8

On Mon, Apr 13, 2015, at 13:29, Gene Heskett wrote:
> On Monday 13 April 2015 08:07:40 Henrique de Moraes Holschuh wrote:
> > Sometimes it will also be necessary to remove the backup (RTC/CMOS)
> > battery.  In that case you will likely have to leave the box unpowered
> > (do not reconnect any of the batteries or power) for several hours
> > (try at least 12 hours) AFTER you did the power-button dance above, to
> > actually reset everything.
> 
> What has become of the triplet of header pins on the motherboard that 
> used to do that. Simply move the flea clip to the other end pair and 

Never seen that on a laptop, really. I'd return for my money back any server or 
desktop motherboard that did not have a CMOS clear or service/maintenance mode 
jumper, though.  The extremely handy FLASH write-disable jumper is harder to 
come by, though.

In a laptop, you also have persistent state in the embedded controller/EC 
(which can crash due to a bug, and often you can only recover from a crashed EC 
through the braindead procedure because the EC is the party responsible for 
cutting power to the mainboard :-p).  Just clearing CMOS won't fix it, you also 
need to "clear and reset the EC", which can be really easy on some laptops, but 
thruly annoying to do in others.

The "12 hours without any battery or power whatsoever, not even the backup CMOS 
battery" procedure is to take care of the annoying laptops that make it hard to 
power down the EC (which includes all Lenovo thinkpads), not just to drain the 
CMOS persistent RAM enough for it to fail the checksum test.

> And I will submit that if that is now the case, its a total B.S. excuse, 
> likely forced on the board makers by you know who, who is a convicted 
> monopolist and will do anything to survive in a world they might have 
> helped create but have now been superceeded by a generally superior 
> product that also happens to be essentially free.

Actually, IME usually you should not blame firmware code quality on anyone but 
the hardware vendors themselves. Ask anyone that works writing operating system 
kernels, be it Redmonders, Linuxers, or BSDers.

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique de Moraes Holschuh 

-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/1429016587.2678271.253525537.48e57...@webmail.messagingengine.com

Re: reading an empty directory after reboot is very slow

On 2015-04-13 16:28:27 -0600, Bob Proulx wrote:
> Vincent Lefevre wrote:
> > Loïc Grenié wrote:
> > > Vincent Lefevre wrote:
> > > > The problem is that this operation is (always?) very slow: something
> > > > like 100 seconds (1 minute and 40 seconds). It has been reproducible
> > > > for several months. The logs show nothing during this operation.
> > > >
> > > > Any idea?
> 
> Of course immediately after a reboot the file system buffer cache is
> completely clean.  You can avoid the reboot and recreate this
> situation by this:
> 
>   # echo 3 > /proc/sys/vm/drop_caches
> 
> See this for the documentation:
> 
>   https://www.kernel.org/doc/Documentation/sysctl/vm.txt

Thanks for the reference (also available locally in linux-doc-*
packages).

> That would certainly be less disruptive to recreate the situation than
> rebooting the entire system.
> 
> > > Maybe the directory is very large (even though its empty). Try
> > > 
> > > ls -ld tmp.
> > > 
> > >  and see if the file "tmp" is large.
> > 
> > Thanks! I didn't know that (I thought that the file system would
> > automatically "optimize" directories when files are removed, so
> > I've never looked closely at their size). Indeed:
> > 
> > ypig:~/eftests> ls -ld tmp
> > drwxr-xr-x 2 vlefevre vlefevre 29655040 2015-04-13 15:25:55 tmp/
> 
> What type of file system is it?  Does it have dir_index?  Both ext3
> and ext4 support it.  Others are similar.
> 
>   # tune2fs -l /dev/mapper/v1-var | grep --color Filesystem.features
>   Filesystem features:  has_journal ext_attr resize_inode dir_index 
> filetype needs_recovery sparse_super large_file

This is ext3 with dir_index:

# tune2fs -l /dev/sda1 | grep Filesystem.features
Filesystem features:  has_journal ext_attr resize_inode dir_index filetype 
needs_recovery sparse_super large_file

And for the FS creation:

Filesystem created:   Mon Jan  4 16:26:16 2010

My machine is old, but I've never changed anything concerning the
file system.

> Without dir_index an ext filesystem with large directories is slow due
> to the linear nature of directories.  But with dir_index it should be
> using a B-tree data structure and should be much faster.

So, why is it slow?

I also notice slowness with a large maildir directory:

drwx-- 2 vlefevre vlefevre 8409088 2015-03-24 14:04:33 Mail/oldarc/cur/

In this one, the files are real (145400 files), but I have a Perl
script that basically reads the headers and it takes a lot of time
(several dozens of minutes) after a reboot or dropping the caches
as you suggested above. With a second run of this script, it just
takes 8 seconds.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20150414130659.gb25...@ypig.lip.ens-lyon.fr

Re: reading an empty directory after reboot is very slow

On 2015-04-14 12:15:03 +0300, Reco wrote:
> On Tue, Apr 14, 2015 at 09:22:15AM +0200, Petter Adsen wrote:
> > On Tue, 14 Apr 2015 10:12:28 +0300
> > Reco  wrote:
> > > On Tue, Apr 14, 2015 at 08:58:20AM +0200, Petter Adsen wrote:
> > > Removing files from the directory does not change directory's inode
> > > size. If using ext4, at least.
> > 
> > Interesting. Also good to know. Thank you :)
> > 
> > But if you create new files in that directory after deleting them, I
> > expect the inodes get reallocated?
> 
> Yes, they should.
> 
> 
> > Is this specific to Linux/ext4?
> 
> No. I'm not sure about vxfs, btrfs and zfs (or rather - lazy to check
> it), but for ext family, ufs and jfs2 - it works all the same.

According to comments on

  http://unix.stackexchange.com/questions/38639/how-to-compact-a-directory

"xfs autoshrinks directories that have had files removed from them."

"ufs on the BSDs and Mac HFS both shrink directories on the fly also."

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20150414131502.gc25...@ypig.lip.ens-lyon.fr

Re: reading an empty directory after reboot is very slow

On 2015-04-14 08:47:15 -0300, Henrique de Moraes Holschuh wrote:
> Also, some of the Unix best-practices do address this kind of
> filesystem issue. One such best-practice is that you don't remove
> just the files in ephemeral directories: you either use an ephemeral
> filesystem (tmpfs) in the first place which is optimized for reuse
> in Linux, Solaris and the BSDs, or you recursively remove the
> directory itself (and recreate it -- but do it safely, there are
> race condition concerns here if the parent is world-writeable).

Note that in my case, though it was called "tmp", it wasn't ephemeral
in the sense that after a reboot, I want the data to be kept (it is
usually empty after a reboot, but just because I usually synchronize
the results with a server, and then I can empty it manually without
losing data).

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20150414132603.gd25...@ypig.lip.ens-lyon.fr

Re: reading an empty directory after reboot is very slow

On Tue, Apr 14, 2015 at 03:15:02PM +0200, Vincent Lefevre wrote:
> On 2015-04-14 12:15:03 +0300, Reco wrote:
> > On Tue, Apr 14, 2015 at 09:22:15AM +0200, Petter Adsen wrote:
> > > On Tue, 14 Apr 2015 10:12:28 +0300
> > > Reco  wrote:
> > > > On Tue, Apr 14, 2015 at 08:58:20AM +0200, Petter Adsen wrote:
> > > > Removing files from the directory does not change directory's inode
> > > > size. If using ext4, at least.
> > > 
> > > Interesting. Also good to know. Thank you :)
> > > 
> > > But if you create new files in that directory after deleting them, I
> > > expect the inodes get reallocated?
> > 
> > Yes, they should.
> > 
> > 
> > > Is this specific to Linux/ext4?
> > 
> > No. I'm not sure about vxfs, btrfs and zfs (or rather - lazy to check
> > it), but for ext family, ufs and jfs2 - it works all the same.
> 
> According to comments on
> 
>   http://unix.stackexchange.com/questions/38639/how-to-compact-a-directory
> 
> "xfs autoshrinks directories that have had files removed from them."

I did not mention xfs, but it's nice to know, thanks.


> "ufs on the BSDs and Mac HFS both shrink directories on the fly also."

We don't do BSD here. Ufs they put in Solaris does not do this :)

Reco


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20150414135759.GA25062@x101h

Sharing LVM storage

I'm using LVM as storage for virtual machines, and would like to share
a PV between two machines with iSCSI to be able to migrate the VM's.

Wikipedia says this:
"The LVM will also work in a shared-storage cluster (where disks holding
the PVs are shared between multiple host computers), but requires an
additional daemon to propagate state changes between cluster nodes."

But nothing else. Is the clvm (with dependencies) package everything I
need to do this? Or would I need to mess with all sorts of clustering
stuff to get that working?

I just want to try it out to see how it works, it's not something I
need by any stretch of the imagination, so there's a limit to how far
down that rabbit-hole I want to go.

Petter

-- 
"I'm ionized"
"Are you sure?"
"I'm positive."


pgpxVsIwWK8w1.pgp
Description: OpenPGP digital signature

Re: reading an empty directory after reboot is very slow

On Tue, Apr 14, 2015, at 10:06, Vincent Lefevre wrote:
> > Without dir_index an ext filesystem with large directories is slow due
> > to the linear nature of directories.  But with dir_index it should be
> > using a B-tree data structure and should be much faster.
> 
> So, why is it slow?

What kernel?  Here it is rather fast (3.10, ext4, enough RAM and a reasonably 
modern CPU).

If your kernel is new enough, switch that ext3 to ext4 even if you're not going 
to tune2fs and fsck it, and you will get some extra performance (but changed 
behavior, beware delayed allocation if your software is not well-behaved.  If 
it would cause problems with XFS, it will cause problems with ext4).

> I also notice slowness with a large maildir directory:
> 
> drwx-- 2 vlefevre vlefevre 8409088 2015-03-24 14:04:33 Mail/oldarc/cur/
> 
> In this one, the files are real (145400 files), but I have a Perl
> script that basically reads the headers and it takes a lot of time
> (several dozens of minutes) after a reboot or dropping the caches
> as you suggested above. With a second run of this script, it just
> takes 8 seconds.

It has to read not just the directory, but also all the inodes, which could be 
somewhat scattered all over the disk.  On top of that, it will also need to 
read some of the file data since you're actually opening and reading some of 
the contents.

I.e. if you do anything that involves stat()ing the directory entry, it has to 
read the inode as well.

Preload the directory and inode metadata with ls -lR >/dev/null before you run 
that perl script with cold caches, and you might get better performance as 
reading the file contents will not get in the way of batch-loading inodes and 
directory entries.

There is such as thing as the appropriate filesystem to the workload. ext3 is 
unlikely to be it nowadays, IME. And, of course, for anything where "decompress 
tarball to tmpfs, do the job here, tarball the results back to persistent fs 
(ext4 or XFS in my case), drop the tmpfs" is viable, I do just that.  Needs 
enough RAM, though.

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique de Moraes Holschuh 

-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/1429020246.2692201.253571761.39594...@webmail.messagingengine.com

Re: Jessie: No VGA signal after gdm3 login

On Tue, 14 Apr 2015 08:50:45 +0200
Petter Adsen  wrote:

> On Mon, 13 Apr 2015 15:42:03 -0400
> "Thomas H. George"  wrote:
> 
> > Just returned from vacation, booted up.
> > 
> > After gdm3 login screen goes blank, then No VGA Signal
> > Installed xdm. Same result
> > Ran apt-get update, apt-get dist-upgrade
> > Repeated xdm login. Same result
> > 
> > Before vacation login opened Gnome and I ran several programs with
> > no problems.
> > 
> > Even now consoles F1 through F6 work normally and I can run command
> > line programs.
> > 
> > What could have happened? Found nothing about this in April
> > lists.debian.org archives.
> 
> Can you tell us what is in /var/log/Xorg.0.log and ~/.xsession-errors?
> 
> I can't tell you what might have happened, though, at least not
> without starting with the contents of those two files.
> 
> Petter
> 

You really should send your reply to the list, not to me personally, so
that more people can see it, and potentially help you.

Received message:

On Tue, 14 Apr 2015 10:15:12 -0400
"Thomas H. George"  wrote:

> On Tue, Apr 14, 2015 at 08:50:45AM +0200, Petter Adsen wrote:
> > On Mon, 13 Apr 2015 15:42:03 -0400
> > "Thomas H. George"  wrote:
> > 
> > > Just returned from vacation, booted up.
> > > 
> > > After gdm3 login screen goes blank, then No VGA Signal
> > > Installed xdm. Same result
> > > Ran apt-get update, apt-get dist-upgrade
> > > Repeated xdm login. Same result
> > > 
> > > Before vacation login opened Gnome and I ran several programs
> > > with no problems.
> > > 
> > > Even now consoles F1 through F6 work normally and I can run
> > > command line programs.
> > > 
> > > What could have happened? Found nothing about this in April
> > > lists.debian.org archives.
> > 
> > Can you tell us what is in /var/log/Xorg.0.log and
> > ~/.xsession-errors?
> > 
> > I can't tell you what might have happened, though, at least not
> > without starting with the contents of those two files.
> > 
> > Petter
> 
> Here are files.
> 
> Xsession: X session started for tom2 at Sun Feb  8 09:28:34 EST 2015
> Error constructing proxy for
> org.gnome.Terminal:/org/gnome/Terminal/Factory0: Could not connect:
> Connection refused Xsession: X session started for tom2 at Sun Feb  8
> 10:46:56 EST 2015 localuser:tom2 being added to access control list
> openConnection: connect: No such file or directory cannot connect to
> brltty at :0 gnome-session-is-accelerated: llvmpipe detected.
> Xsession: X session started for tom2 at Sun Feb  8 10:47:37 EST 2015
> localuser:tom2 being added to access control list
> openConnection: connect: No such file or directory
> cannot connect to brltty at :0
> gnome-session-is-accelerated: llvmpipe detected.
> Xsession: X session started for tom2 at Sun Feb  8 10:48:24 EST 2015
> localuser:tom2 being added to access control list
> openConnection: connect: No such file or directory
> cannot connect to brltty at :0
> gnome-session-is-accelerated: llvmpipe detected.
> Xsession: X session started for tom2 at Sun Feb  8 13:04:00 EST 2015
> localuser:tom2 being added to access control list
> openConnection: connect: No such file or directory
> cannot connect to brltty at :0
> gnome-session-is-accelerated: llvmpipe detected.
> Xsession: X session started for tom2 at Tue Feb 10 10:04:43 EST 2015
> localuser:tom2 being added to access control list
> openConnection: connect: No such file or directory
> cannot connect to brltty at :0
> gnome-session-is-accelerated: llvmpipe detected.
> Xsession: X session started for tom2 at Tue Feb 10 10:18:50 EST 2015
> localuser:tom2 being added to access control list
> openConnection: connect: No such file or directory
> cannot connect to brltty at :0
> gnome-session-is-accelerated: llvmpipe detected.
> Xsession: X session started for tom2 at Wed Feb 11 09:52:48 EST 2015
> localuser:tom2 being added to access control list
> openConnection: connect: No such file or directory
> cannot connect to brltty at :0
> gnome-session-is-accelerated: llvmpipe detected.
> Xsession: X session started for tom2 at Wed Feb 11 09:54:08 EST 2015
> localuser:tom2 being added to access control list
> openConnection: connect: No such file or directory
> cannot connect to brltty at :0
> gnome-session-is-accelerated: llvmpipe detected.
> Xsession: X session started for tom2 at Mon Apr 13 15:05:16 EDT 2015
> localuser:tom2 being added to access control list
> openConnection: connect: No such file or directory
> cannot connect to brltty at :0
> gnome-session-is-accelerated: llvmpipe detected.
> Xsession: X session started for tom2 at Mon Apr 13 15:26:46 EDT 2015
> localuser:tom2 being added to access control list
> openConnection: connect: No such file or directory
> cannot connect to brltty at :0
> gnome-session-is-accelerated: llvmpipe detected.
> Xsession: X session started for tom2 at Tue Apr 14 07:28:06 EDT 2015
> localuser:tom2 being added to access control list
> openConnection: connect: No such file or directory
> cannot connect to brltty at :0
> gn

Re: Is gnome-core really the gnome minimal install?

2015-04-14 Thread Jonathan Dowland

On Mon, Apr 13, 2015 at 01:09:46PM -0500, David Wright wrote:
> Quoting Brian (a...@cityscape.co.uk):
> > On Mon 13 Apr 2015 at 12:00:52 -0500, David Wright wrote:
…
> > > So the most I could do is set up an account just to write "This list
> > > entry may mislead you" on the page.
…
> > You could do better than that :). It took half a minute to discover that
> > the "GNOME accessibility" entry needs removing or the entry adjusted to
> > reflect what version of Debian it applies to. Following the link is
> > sufficient to see why.

I've fixed the gnome-core definition on that page in less time than it took to
read any of the last three messages in this sub-thread, and therefore certainly
less time than it took to write them, using only information gleaned from posts
in this thread. In other words, any one of you could have done it just as well.

-- 
Jonathan Dowland


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20150414143247.ga2...@chew.redmars.org

Re: Is gnome-core really the gnome minimal install?

2015-04-14 Thread Patrick Bartek

On Tue, 14 Apr 2015, August Karlstrom wrote:

> On 2015-04-14 03:20, Patrick Bartek wrote:
> > The rule mounts and unmounts flash drives -- just plug and unplug
> > -- and cards (any type using an external card or multi-card
> > reader.  The caveat is: you must plug the card in first, then plug
> > the reader in. Unmount by unplugging reader with the card still in
> > it, then remove the card. Doesn't work with internal multi-card
> > readers.  Probably not with single internal readers either.  For
> > that you need a daemon like udisks-daemon set to poll each card
> > slot of the reader.
> [...]
> 
> What advantages do you see with adding your own udev rule compared to 
> simply starting a ConsoleKit session?
> 
> exec ck-launch-session dbus-launch 
> 
> instead of
> 
> exec 

None really, except to keep system overhead as small as possible.

This system is 4 to 9 years old depending on which part, and has been
upgraded numerous times, but even so was still showing its age as far as
performance. I wanted the smallest, lightest install of Wheezy 64-bit I
could get.  I started with a basic terminal system and added the rest
piece by piece. So, I just don't run (or have installed) a lot of
"support" stuff that normal "desktop" systems do. I even boot to a
terminal where I login, then manually start X and Openbox with startx.
I'm the only user.

Writing my own udev rules was in keeping with that minimalism.

Guess I could experiment with your way. Just for fun.

B 

-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20150414080504.762a4...@debian7.boseck208.net

Re: Sharing LVM storage

2015-04-14 Thread Thomas Schneider


-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
 
Hello,

I already did that with clvm and OpenAIS.

Regards,

Le 14/04/2015 16:01, Petter Adsen a écrit :
> I'm using LVM as storage for virtual machines, and would like to share
> a PV between two machines with iSCSI to be able to migrate the VM's.
>
> Wikipedia says this:
> "The LVM will also work in a shared-storage cluster (where disks holding
> the PVs are shared between multiple host computers), but requires an
> additional daemon to propagate state changes between cluster nodes."
>
> But nothing else. Is the clvm (with dependencies) package everything I
> need to do this? Or would I need to mess with all sorts of clustering
> stuff to get that working?
>
> I just want to try it out to see how it works, it's not something I
> need by any stretch of the imagination, so there's a limit to how far
> down that rabbit-hole I want to go.
>
> Petter
>

- -- 
*Thomas Schneider*
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.17 (MingW32)
 
iQEcBAEBAgAGBQJVLSyZAAoJEE02LTG9nTHNROQH+QHyW3nA1XybHAsT4Tpd6pPp
NKMgjp70WFHjcUa5AhBxgzwfHfuduXnOlssYr9jb4qKohRylci/3zHj2JEwy0Pbm
QroAf8YHHrTW10J1+3IwLkEbBFLX96EZXYAJkhicLcVi+h7JVgLV88IfkPiHPrrn
LA5pQikGOC2HZdLDXZfJdNfLx4HsNJQ1a0Pyynm/hM3fQvFku/gfDYHSHSBqqpl4
qvxbcpAfVzTC2tn0c2/fNPK1zDxJmB6aRAHe5yGq7rrf+tAri/YOIjcapGjrUly0
goL41o3Mn9uA7d95IE1h+E7Tg/qzRCHbUWVljtevECjmThpIPpKee8P44glKXlQ=
=dGyq
-END PGP SIGNATURE-

Re: Sharing LVM storage

 Hi.

On Tue, Apr 14, 2015 at 04:01:02PM +0200, Petter Adsen wrote:
> I'm using LVM as storage for virtual machines, and would like to share
> a PV between two machines with iSCSI to be able to migrate the VM's.

I did the thing some time ago. It worked, although I used ietd and not
today's tgtd. The main reason was - ietd had configuration file, tdtd
had not (as in 'our daemon does not need config at all, use tdtadm').

> Wikipedia says this:
> "The LVM will also work in a shared-storage cluster (where disks holding
> the PVs are shared between multiple host computers), but requires an
> additional daemon to propagate state changes between cluster nodes."
> 
> But nothing else. Is the clvm (with dependencies) package everything I
> need to do this? Or would I need to mess with all sorts of clustering
> stuff to get that working?

Not strictly as the main role of clvm is to guarantee that one LV will
always be used by one node. Secondary role of clvm is to handle LV
addition and removal by principle of least surprise. I.e. lvcreate on
node one should add the same LV on node two.

> I just want to try it out to see how it works, it's not something I
> need by any stretch of the imagination, so there's a limit to how far
> down that rabbit-hole I want to go.

As long as you don't forget to run lvscan on partner node after doing
basically anything with LV on main node - you should be OK.

But just to be on the safe side - don't export PV via iSCSI. Export LVs.

Reco

-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20150414151430.GA27818@x101h

Re: Debian 7 and external monitors and graphics adaptors

On 14/04/2015, Curt  wrote:
> On 2015-04-14, Bret Busby  wrote:
>>
>> so it apparently, is driving the inboard Intel graphics adaptor, and
>> not the nVIDIA GT750m graphics adaptor.
>
> The best thing would be to look at the log file for X (on Squeeze LTS
> that is to be found at the following location: '/var/log/Xorg.0.log') in
> order to know which driver you're using (amongst other things--errors,
> warnings, etc.).
>
> For the driver the following grep ditty seems to work fine:
>
> curty@einstein:~$ grep -B2 'Module class: X.Org Video Driver'
> /var/log/Xorg.0.log
> (II) Module fglrx: vendor="FireGL - ATI Technologies Inc."
>  compiled for 1.4.99.906, module version = 8.95.3
>  Module class: X.Org Video Driver
>
>
>

Thank you for that.

I have just ran it on this (Dell Inspire) desktop system running
Debian 6, to check it, and got

"
:~$ grep -B2 'Module class: X.Org Video Driver' /var/log/Xorg.0.log
(II) Module nouveau: vendor="X.Org Foundation"
compiled for 1.7.7, module version = 0.0.15
Module class: X.Org Video Driver
--
(II) Module nv: vendor="X.Org Foundation"
compiled for 1.7.7, module version = 2.1.17
Module class: X.Org Video Driver
--
(II) Module vesa: vendor="X.Org Foundation"
compiled for 1.7.7, module version = 2.3.0
Module class: X.Org Video Driver
"

and this system shows

"
:~$ lspci | grep -i vga
01:00.0 VGA compatible controller: nVidia Corporation GT218 [GeForce
310] (rev a2)
"

so I intend to run those two commands in each of the Ubuntu and Debian
installations on the Acer V3-772G system, tomorrow.

-- 
Bret Busby
Armadale
West Australia
..

"So once you do know what the question actually is,
 you'll know what the answer means."
- Deep Thought,
 Chapter 28 of Book 1 of
 "The Hitchhiker's Guide to the Galaxy:
 A Trilogy In Four Parts",
 written by Douglas Adams,
 published by Pan Books, 1992




-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/CACX6j8M5S3GaA64xXC+_pgzpB-KArRx+cHQctgpd=vbucxo...@mail.gmail.com

Re: Book questions

2015-04-14 Thread David Christensen


On 04/14/2015 12:35 AM, Petter Adsen wrote:

I see that a lot of people advice me on going
with something other than C, and I can understand that there are good
reasons for this advice. While I still want to learn C at some point,
I'm beginning to think that it might be wise to consider getting a good
foundation in another language first.
Would Python be appropriate? I see a lot of software these days that is
written in Python, so it would be helpful in that way. The person I am
most likely to go to for help knows Python, so that's a bonus.


I consider machine code to be the "foundation" programming language of 
most "general purpose" computers.  It is the most powerful and flexible 
of all programming languages, because it can execute any instruction the 
processor implements.  Macro assembler makes machine code accessible.  C 
is the next level up.  C++, C#, Java, Python, Perl, PHP, Ruby, etc., are 
still higher.  The downside with high-level languages is that you lose 
low-level detail and control -- e.g. branch on carry bit set, select 
indexed indirect addressing mode, etc..  Shell, Make, regular 
expressions, SQL, are domain-specific languages, and very useful for 
solving specific problems.  Sophisticated programs and systems integrate 
multiple pieces.  It's a pyramid of hidden complexities (or a house of 
cards, if you're a cynic).



There is also a hierarchy of concepts, founded in mathematics and 
computer science.



Good CS/ programming books explain both, and their the connections.


If you want to understand the guts of Unix, then you need to learn 
assembly language and C because those are what Unix is built from (and 
more, as noted by others).



If you want to write applications that run on top of Unix, higher level 
languages can produce working programs with fewer KLOC's.  (As can good 
libraries called from any language.)



I mentioned SICP before.  The concepts are great, but the Scheme 
programming language and REPL environment aren't my favorite.  If you're 
serious about computer science and computer programming, read it first 
and then choose what's next:


http://mitpress.mit.edu/sicp/full-text/book/book.html


David


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

Archive: https://lists.debian.org/552d3583.9030...@holgerdanske.com

FAQ's versus "Questions Newbies SHOULD Ask"?

2015-04-14 Thread Richard Owlett


I just spent an instructive morning reading about:
  * inodes
  * Ext2 vs Ext3 vs Ext4
  * Sudo vs Su {unfortunately most was heavily Ubuntu oriented 
not Debian specific}


Each of those were prompted by by reading various threads in this 
group and some actual problems I've run into.


FAQ's may indicate questions others have asked.
*BUT* is there any reference that would provoke investigating 
questions I have yet thought to ask? Can there be?


This partially prompted by a personal project whose working title 
is "A Minimalist's Minimal (but very INSTRUCTIVE) Install via 
debootstrap". {d-i does too much too silently for my tastes ;)




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

Archive: https://lists.debian.org/552d3a64.7090...@cloud85.net

Re: FAQ's versus "Questions Newbies SHOULD Ask"?

2015-04-14 Thread Lisi Reisz

On Tuesday 14 April 2015 17:03:48 Richard Owlett wrote:
> FAQ's may indicate questions others have asked.

In my experience they frequently indicate questions the writer is 
hoping/expecting you to ask, that noone has ever asked and that I have never 
thought of asking.

Lisi


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/201504141708.09427.lisi.re...@gmail.com

Re: reading an empty directory after reboot is very slow

2015-04-14 Thread Bob Proulx

Henrique de Moraes Holschuh wrote:
> Bob Proulx wrote:
> >   tune2fs -O dir_index /dev/sda5
> > But existing directories are not converted.  Only new directories are
> 
> Do a forced e2fsck run on the filesystem, and it should add the
> indexes to all directories that lack it.  It can also change the
> hash algorithm.
> 
> BTW, the e2fsck manpage states that it WILL compress directories if
> it has any reason to touch the directory.
> 
> If you want e2fsck to rehash or compress all directories, you have
> to run it as e2fsck -D so that it will optimize/rehash every
> directory, not just those that were lacking indexes or that had to
> be repaired.

Oh!  I was unaware of the e2fsck -D option.  Good deal!

> > it though so for the most part that is okay.  It is only directories
> > such as /tmp that sporadically might have surged large that really
> > benefit from a manual recreation conversion in order to have B-trees
> > turned on for a migration to dir_index.
> 
> If you have the resources required (RAM), always have ephemeral
> "tmp" directories in tmpfs.  All contents will be discarded on
> reboot/poweroff or if you umount the tmpfs, but it should be the
> fastest possible filesystem in Linux as long as you don't start
> swapping (xfs and ext4 are much better optimized to the "hit the
> spinning rust" case than tmpfs+swapper IME).

I also like tmpfs for /tmp for simple systems.  But it isn't a general
purpose solution for everyone.  There are many cases such as when /tmp
is used as a large file dropbox that it doesn't work to use a limited
size tmpfs.

It will take a while for people to change their habits to accomodate
the system.  In this case it means dropboxing large files in a
different directory other than /tmp.  And I don't like to work for the
machine.  I like the machine to work for me.  So I can't recommend
tmpfs /tmp for *everyone* but it does work well for the cases where it
doesn't hurt existing user practices.

Bob

signature.asc
Description: Digital signature

Re: reading an empty directory after reboot is very slow

On Tue, Apr 14, 2015, at 13:11, Bob Proulx wrote:
> Oh!  I was unaware of the e2fsck -D option.  Good deal!

I didn't recall it existed either, or I'd have mentioned it much earlier in the 
thread... but I noticed it in the manpage while doing some research due to my 
participation on this thread. It was time well spent!

> I also like tmpfs for /tmp for simple systems.  But it isn't a general
> purpose solution for everyone.  There are many cases such as when /tmp
> is used as a large file dropbox that it doesn't work to use a limited
> size tmpfs.

Yeah, that's a bad habit to have as it slows down way too many utilities (lots 
of stuff benefit for extremely lightweight ultra-fast tmpfs in /tmp and 
$TMPDIR, from "sort" to gcc without -pipe), but it is indeed widespread.

The "persistent dumping ground" lives in /var/tmp, it is not supposed to be in 
/tmp or ${TMPDIR}.  But old habits are hard to change.

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique de Moraes Holschuh 

-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/1429028776.3397338.253642965.32cbb...@webmail.messagingengine.com

Re: reading an empty directory after reboot is very slow

2015-04-14 Thread Bob Proulx

Petter Adsen wrote:
> Can someone please enlighten me as to why the entry for this directory
> is so large, even though it is empty? Since it's apparently obvious to
> everyone else, I would very much like to know :)

In the old days directories were simply an array of fixed sized
integers and fixed sized names.  The fixed maximum size of the name
was 14 characters.  The fixed size integer was the inode address.
That it was fixed sized allowed directories to be read into an array
of structures very efficiently using readdir(2) system call.
Individual entries were written by lseek(2)'ing to the proper slot and
writing just that fixed size entry leaving the rest of the (special
directory) file untouched.  Directories were an array of file entries.

That strategy was in use for many years in Unix systems.  But it has
unpleasant limitations.  Short fixed sized file names 14 characters or
less were one.  The linear nature of the array data structure was
another.  The array influenced things considerably.  When a file was
deleted the entree was simply zero'd out.  lseek() to the proper
entry and zero it out.  That meant that directories could grow in size
but never shrink.  If a directory became full it was easy to extend it
by writing the array longer.  But if an early entry in the array was
deleted the system would zero it out rather than move each and every
entry in the file system down a slot.  (I always wondered why they
didn't simply take the *last* entry and move it down to the deleted
entry and simply keep the array always compacted.  I wonder.  But they
didn't do it that way.)

The array makes it obvious why large directores are slow.  If you are
opening a single named file then the way to find the associated inode
number in the directory is to start reading at the start of the array
and continue looking for a match on the file name.  When a match is
found then you have the inode number associated with it.  The matched
file is always the last one you look for because you stop reading at
that time.  If there is a million files in the directory and it was
the last entry in the list then you must read the entire million
entries before finding the one you want.

Then along came B-tree data structures for directories.  It is an on
disk specialization of a tree data structure.  Really cool.

  https://en.wikipedia.org/wiki/B-tree

Using B-trees for directories was a huge revolution in performance and
efficiency.  This is the "dir_index" capability in ext3 and ext4.
Other file systems use B-trees similarly but call it different things.
Now even directories with a huge number of entries are fast to read
individual files.  But only if the directory has been converted or
created using B-trees.  The use of B-trees solves most of the
performance problems.

But!  Even with B-trees ext3 and ext4 do not shrink the directory size
when files are removed from them.  Doing so would expend effort.
Depending upon the deletion it would cause rotations in the data
structure and may take a bit of time to accomplish.  It is certainly
more complicated to code.

  https://en.wikipedia.org/wiki/B-tree#Insertions_and_deletions_cause_trouble

Therefore these new ext3 and ext4 file systems take advantage of the
fact that previously file system's directories had never been shrunk
before.  The new ones don't shrink either.  They use it as an speed
optimization and simply zero out the entries too.  Therefore in the
wild directories grow in size but don't shrink in size.

Other file systems such as xfs designed for large files and large
numbers of files DO shrink when files are removed.  That is one of the
reasons why xfs is recommended for industrial strength use.  It was
designed to handle those kinds of workloads.  However that means that
it must spend time when files are deleted to clean everything up.
Everything has a cost.  But xfs is one of the file systems that do
shrink directories when files are deleted.

Bob

signature.asc
Description: Digital signature

Re: reading an empty directory after reboot is very slow

On 2015-04-14 11:04:06 -0300, Henrique de Moraes Holschuh wrote:
> On Tue, Apr 14, 2015, at 10:06, Vincent Lefevre wrote:
> > > Without dir_index an ext filesystem with large directories is slow due
> > > to the linear nature of directories.  But with dir_index it should be
> > > using a B-tree data structure and should be much faster.
> > 
> > So, why is it slow?
> 
> What kernel?

3.16.7-ckt9-2

This is a Debian/unstable machine.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20150414175221.ga26...@xvii.vinc17.org

Re: reading an empty directory after reboot is very slow

2015-04-14 Thread Doug




On 04/14/2015 05:15 AM, Reco wrote:

  Hi.

On Tue, Apr 14, 2015 at 09:22:15AM +0200, Petter Adsen wrote:

/snip/

2015-04-13 14:39 GMT+02:00 Vincent Lefevre :

The problem is that this operation is (always?) very slow:
something like 100 seconds (1 minute and 40 seconds). It has
been reproducible for several months. The logs show nothing
during this operation.

Any idea?

 Maybe the directory is very large (even though its empty).
Try

ls -ld tmp.

  and see if the file "tmp" is large.

Thanks! I didn't know that (I thought that the file system would
automatically "optimize" directories when files are removed, so
I've never looked closely at their size). Indeed:

ypig:~/eftests> ls -ld tmp
drwxr-xr-x 2 vlefevre vlefevre 29655040 2015-04-13 15:25:55 tmp/

Can someone please enlighten me as to why the entry for this
directory is so large, even though it is empty? Since it's
apparently obvious to everyone else, I would very much like to
know :)

A case study:

$ mkdir tmp
$ du -sxh tmp
4.0Ktmp
$ for x in {1..10}; do touch tmp/$x; done
$ du -sxh tmp
2.1Mtmp
$ find tmp -type f | xargs rm
$ du -sxh tmp
2.1Mtmp
$ ls tmp | wc -l
0

Removing files from the directory does not change directory's inode
size. If using ext4, at least.


/snip/

What is the best way of solving this? Since the directory is empty, can you
just do an rmdir dirname ? Now if there are one or two files in it, will it
shrink the directory to fit them, as I think you are saying? If not, then
how?

--doug


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

Archive: https://lists.debian.org/552d53e8.2030...@optonline.net

Re: FAQ's versus "Questions Newbies SHOULD Ask"?



On Tuesday 14 April 2015 12:08:09 Lisi Reisz wrote:
> On Tuesday 14 April 2015 17:03:48 Richard Owlett wrote:
> > FAQ's may indicate questions others have asked.
>
> In my experience they frequently indicate questions the writer is
> hoping/expecting you to ask, that noone has ever asked and that I have
> never thought of asking.
>
> Lisi

Good for a grin, Lisi, thanks.  And here I thought I was alone in 
thinking that.

Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page 


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/201504141456.03689.ghesk...@wdtv.com

Re: no bluetooth audio in jessie

2015-04-14 Thread deloptes

Juha Heinanen wrote:

> A few days ago, I upgraded my laptop from wheezy to jessie.  After that
> I noticed that audio to my bluetooth speaker didn't work anymore.  I had
> been using alsa audio and had a bluetooth type entry in my .asoundrc for
> my speaker.
> 
> After a bit of digging it turned out that I had lost bluetooth audio,
> because bluez-alsa package does not exist in jessie.  If I understood
> correctly, the reason is that bluez version 5 does not support alsa
> anymore.
> 
> So I decided to try if my bluetooth speaker would work in jessies with
> pulseaudio.  Unfortunately that was not the case.  I got an error
> message:
> 
> Apr 12 12:22:02 lohi pulseaudio[6318]: org.bluez.Manager.GetProperties()
> failed: org.freedesktop.DBus.Error.UnknownMethod: Method "GetProperties"
> with signature "" on interface "org.bluez.Manager" doesn't exist
> 
> After a bit more digging, i found this thread that went way above my
> understanding:
> 
> https://github.com/ev3dev/ev3dev/issues/198
> 
> Long story short:  it would be nice if bluetooth audio would "just work"
> in jessie like it did in lenny and wheezy for years.
> 
> -- Juha

I had similar issue with upower where it lost the methods exposed to dbus.
The solution was to downgrade upower (install older version known to work).
Perhaps same is doable with the bluez package.
then mark the packages as "hold" so they don't get upgraded until solution
is provided.

regards



-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/mgjo4v$r35$1...@ger.gmane.org

Re: reading an empty directory after reboot is very slow

On Tue, Apr 14, 2015, at 14:52, Doug wrote:

> >>> Removing files from the directory does not change directory's inode
> >>> size. If using ext4, at least.

> What is the best way of solving this? Since the directory is empty, can you
> just do an rmdir dirname ? Now if there are one or two files in it, will it
> shrink the directory to fit them, as I think you are saying? If not, then
> how?

1. Switch to XFS, it is reported to auto-shrink directories automatically

or

2. unmount filesystem and run e2fsck -D on it every so often.

or

3.  suppose foo is the directory in need of shrinking, and that newfoo doesn't 
exist:

"mkdir newfoo && cp -alr foo/. newfoo/. && mv foo oldfoo && mv newfoo foo 
&& rm -fr oldfoo" at a time nothing is using "foo".

there are other possible solutions to the problem, of course.

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique de Moraes Holschuh 

-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/1429038362.3433980.253715609.6d50f...@webmail.messagingengine.com

Re: Is gnome-core really the gnome minimal install?

2015-04-14 Thread Brian

On Tue 14 Apr 2015 at 15:32:47 +0100, Jonathan Dowland wrote:

> On Mon, Apr 13, 2015 at 01:09:46PM -0500, David Wright wrote:
> > Quoting Brian (a...@cityscape.co.uk):
> > > On Mon 13 Apr 2015 at 12:00:52 -0500, David Wright wrote:
> …
> > > > So the most I could do is set up an account just to write "This list
> > > > entry may mislead you" on the page.
> …
> > > You could do better than that :). It took half a minute to discover that
> > > the "GNOME accessibility" entry needs removing or the entry adjusted to
> > > reflect what version of Debian it applies to. Following the link is
> > > sufficient to see why.
> 
> I've fixed the gnome-core definition on that page in less time than it took to
> read any of the last three messages in this sub-thread, and therefore 
> certainly
> less time than it took to write them, using only information gleaned from 
> posts
> in this thread. In other words, any one of you could have done it just as 
> well.

There is no arguing with that; we are pleased you found the information
useful. This is an excellent example illustrating how the interaction
between Debian users leads to a change and an improvement.


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/14042015195638.cf199210d...@desktop.copernicus.demon.co.uk

Has the rescatux and supergrubdisk project been terminated

On 07/02/2015, Diogene Laerce  wrote:
>



>
> You could give a try to Grub Rescue : http://www.supergrubdisk.org/
>
> Good luck !
>
>

Hello.

I have just tried to find the Rescatux web site, to try to download a
copy, and I found, at
http://www.supergrubdisk.org/

"Website disabled"

also at
http://rescatux.org
which redirects to
http://www.supergrubdisk.org/rescatux/

Does anyone know what is happening with the supergruubdisk thing and rescatux?

Have they been terminated?

Interestingly, a subdomain of rescatux.org;
http://wiki.rescatux.org/wiki/Main_Page

still appears to be functional.


-- 
Bret Busby
Armadale
West Australia
..

"So once you do know what the question actually is,
 you'll know what the answer means."
- Deep Thought,
 Chapter 28 of Book 1 of
 "The Hitchhiker's Guide to the Galaxy:
 A Trilogy In Four Parts",
 written by Douglas Adams,
 published by Pan Books, 1992




-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/cacx6j8o8k+gnkbnyrx8mm0evcxhfut+bqkmgvxuwkssgd1o...@mail.gmail.com

Subject: network-console installation and ssh keys

2015-04-14 Thread David Wright

I like the new Network Console option in the installer.
However, when I reinstall Debian onto a machine called, say, desk
select the necessary options, type in the password for the
installer session, and then sit back with a machine called, lap,
when I type   ssh installer@desk   I get the usual

@@@
@WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! @
@@@
IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
Someone could be eavesdropping on you right now (man-in-the-middle
attack)!
It is also possible that a host key has just been changed.
The fingerprint for the RSA key sent by the remote host is

because the installer has generated and is running with fresh keys.
(I frequently connect from lap to desk and vice versa and so
have authorised_keys as well as know_hosts there.)

What do most people do here?

Cheers,
David.


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20150414203155.ga13...@alum.home

Re: Is gnome-core really the gnome minimal install?

Patrick Bartek  writes:

> Of course, if you really want TOTAL control of your GUI, a window
> manager is the way to go.  That's what I did.  Installed Openbox.  The
> same WM that LXDE uses.  A little more work, but worth it.

Thanks.  I'm trying it.  In the web browser, I open a new tab with C-t, but
don't know how to do that in the terminal emulator.  The usual `C-shift-t' does
not work.

Rodolfo

-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/877fte3024@gmail.com

Re: Is gnome-core really the gnome minimal install?

2015-04-14 Thread Lisi Reisz

On Tuesday 14 April 2015 20:11:30 Brian wrote:
> On Tue 14 Apr 2015 at 15:32:47 +0100, Jonathan Dowland wrote:
> > On Mon, Apr 13, 2015 at 01:09:46PM -0500, David Wright wrote:
> > > Quoting Brian (a...@cityscape.co.uk):
> > > > On Mon 13 Apr 2015 at 12:00:52 -0500, David Wright wrote:
> >
> > …
> >
> > > > > So the most I could do is set up an account just to write "This
> > > > > list entry may mislead you" on the page.
> >
> > …
> >
> > > > You could do better than that :). It took half a minute to discover
> > > > that the "GNOME accessibility" entry needs removing or the entry
> > > > adjusted to reflect what version of Debian it applies to. Following
> > > > the link is sufficient to see why.
> >
> > I've fixed the gnome-core definition on that page in less time than it
> > took to read any of the last three messages in this sub-thread, and
> > therefore certainly less time than it took to write them, using only
> > information gleaned from posts in this thread. In other words, any one of
> > you could have done it just as well.
>
> There is no arguing with that; we are pleased you found the information
> useful. This is an excellent example illustrating how the interaction
> between Debian users leads to a change and an improvement.

Yes, but it now needs something about accessibility.  Accessibility is one of 
Gnome's strengths, and as this site was before it only took a click on the 
provided link to get all the information.  I think that the change is 
detrimental. 

Lisi


--
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/201504142205.41541.lisi.re...@gmail.com

Re: Subject: network-console installation and ssh keys

2015-04-14 Thread Liam O'Toole

On 2015-04-14, David Wright  wrote:
> I like the new Network Console option in the installer.
> However, when I reinstall Debian onto a machine called, say, desk
> select the necessary options, type in the password for the
> installer session, and then sit back with a machine called, lap,
> when I type   ssh installer@desk   I get the usual
>
> @@@
> @WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! @
> @@@
> IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
> Someone could be eavesdropping on you right now (man-in-the-middle
> attack)!
> It is also possible that a host key has just been changed.
> The fingerprint for the RSA key sent by the remote host is
>
> because the installer has generated and is running with fresh keys.
> (I frequently connect from lap to desk and vice versa and so
> have authorised_keys as well as know_hosts there.)
>
> What do most people do here?
>
> Cheers,
> David.

Put the following in ~/.ssh/config:

Host desk
UserKnownHostsFile /dev/null
StrictHostKeyChecking no

See the man page of ssh_config for details.

-- 

Liam



-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/slrnmir1ui.1t0.liam.p.otoole@dipsy.tubbynet

Re: Is gnome-core really the gnome minimal install?

2015-04-14 Thread David Wright

Quoting Jonathan Dowland (j...@debian.org):
> On Mon, Apr 13, 2015 at 01:09:46PM -0500, David Wright wrote:
> > Quoting Brian (a...@cityscape.co.uk):
> > > On Mon 13 Apr 2015 at 12:00:52 -0500, David Wright wrote:
> …
> > > > So the most I could do is set up an account just to write "This list
> > > > entry may mislead you" on the page.
> …
> > > You could do better than that :). It took half a minute to discover that
> > > the "GNOME accessibility" entry needs removing or the entry adjusted to
> > > reflect what version of Debian it applies to. Following the link is
> > > sufficient to see why.
> 
> I've fixed the gnome-core definition on that page in less time than it took to
> read any of the last three messages in this sub-thread, and therefore 
> certainly
> less time than it took to write them, using only information gleaned from 
> posts
> in this thread. In other words, any one of you could have done it just as 
> well.

Thanks for making the change. I'm still not sure I understand, for
example, how the core (item4) differs from the desktop task (item1),
because the latter pulls in the former and not much mo...

Look, I think I'll bow out of this conversation. The OP seems to have
got something useful out of the thread. I think I'll ask questions
about the wiki page for Bluetooth instead.

Cheers,
David.


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20150414215208.ga14...@alum.home

Re: Jessie: No VGA signal after gdm3 login

2015-04-14 Thread Thomas H. George

On Tue, Apr 14, 2015 at 04:22:24PM +0200, Petter Adsen wrote:
> On Tue, 14 Apr 2015 08:50:45 +0200
> Petter Adsen  wrote:
> 
> > On Mon, 13 Apr 2015 15:42:03 -0400
> > "Thomas H. George"  wrote:
> > 
> > > Just returned from vacation, booted up.
> > > 
> > > After gdm3 login screen goes blank, then No VGA Signal
> > > Installed xdm. Same result
> > > Ran apt-get update, apt-get dist-upgrade
> > > Repeated xdm login. Same result
> > > 
> > > Before vacation login opened Gnome and I ran several programs with
> > > no problems.
> > > 
> > > Even now consoles F1 through F6 work normally and I can run command
> > > line programs.
> > > 
> > > What could have happened? Found nothing about this in April
> > > lists.debian.org archives.
> > 
> > Can you tell us what is in /var/log/Xorg.0.log and ~/.xsession-errors?
> > 
> > I can't tell you what might have happened, though, at least not
> > without starting with the contents of those two files.
> > 
> > Petter
> > 
> 
> You really should send your reply to the list, not to me personally, so
> that more people can see it, and potentially help you.
> 
I agree and this reply is to the list.  I only replied directly to you
because last week I received a sharp rebuke from an individual who had
responded to one of my posts. He claimed it is very bad manners to post
his responce - it was a very helpful one which I acknowledged - to the
list when he had responded from his personal address.  

What is the protocol? In reponding should I hit r or L? Obviously a continuing 
string of discussion posted
to the list should be advantageous to all.
> Received message:
> 
> On Tue, 14 Apr 2015 10:15:12 -0400
> "Thomas H. George"  wrote:
> 
> > On Tue, Apr 14, 2015 at 08:50:45AM +0200, Petter Adsen wrote:
> > > On Mon, 13 Apr 2015 15:42:03 -0400
> > > "Thomas H. George"  wrote:
> > > 
> > > > Just returned from vacation, booted up.
> > > > 
> > > > After gdm3 login screen goes blank, then No VGA Signal
> > > > Installed xdm. Same result
> > > > Ran apt-get update, apt-get dist-upgrade
> > > > Repeated xdm login. Same result
> > > > 
> > > > Before vacation login opened Gnome and I ran several programs
> > > > with no problems.
> > > > 
> > > > Even now consoles F1 through F6 work normally and I can run
> > > > command line programs.
> > > > 
> > > > What could have happened? Found nothing about this in April
> > > > lists.debian.org archives.
> > > 
> > > Can you tell us what is in /var/log/Xorg.0.log and
> > > ~/.xsession-errors?
> > > 
> > > I can't tell you what might have happened, though, at least not
> > > without starting with the contents of those two files.
> > > 
> > > Petter
> > 
> > Here are files.
> > 
> > Xsession: X session started for tom2 at Sun Feb  8 09:28:34 EST 2015
> > Error constructing proxy for
> > org.gnome.Terminal:/org/gnome/Terminal/Factory0: Could not connect:
> > Connection refused Xsession: X session started for tom2 at Sun Feb  8
> > 10:46:56 EST 2015 localuser:tom2 being added to access control list
> > openConnection: connect: No such file or directory cannot connect to
> > brltty at :0 gnome-session-is-accelerated: llvmpipe detected.
> > Xsession: X session started for tom2 at Sun Feb  8 10:47:37 EST 2015
> > localuser:tom2 being added to access control list
> > openConnection: connect: No such file or directory
> > cannot connect to brltty at :0
> > gnome-session-is-accelerated: llvmpipe detected.
> > Xsession: X session started for tom2 at Sun Feb  8 10:48:24 EST 2015
> > localuser:tom2 being added to access control list
> > openConnection: connect: No such file or directory
> > cannot connect to brltty at :0
> > gnome-session-is-accelerated: llvmpipe detected.
> > Xsession: X session started for tom2 at Sun Feb  8 13:04:00 EST 2015
> > localuser:tom2 being added to access control list
> > openConnection: connect: No such file or directory
> > cannot connect to brltty at :0
> > gnome-session-is-accelerated: llvmpipe detected.
> > Xsession: X session started for tom2 at Tue Feb 10 10:04:43 EST 2015
> > localuser:tom2 being added to access control list
> > openConnection: connect: No such file or directory
> > cannot connect to brltty at :0
> > gnome-session-is-accelerated: llvmpipe detected.
> > Xsession: X session started for tom2 at Tue Feb 10 10:18:50 EST 2015
> > localuser:tom2 being added to access control list
> > openConnection: connect: No such file or directory
> > cannot connect to brltty at :0
> > gnome-session-is-accelerated: llvmpipe detected.
> > Xsession: X session started for tom2 at Wed Feb 11 09:52:48 EST 2015
> > localuser:tom2 being added to access control list
> > openConnection: connect: No such file or directory
> > cannot connect to brltty at :0
> > gnome-session-is-accelerated: llvmpipe detected.
> > Xsession: X session started for tom2 at Wed Feb 11 09:54:08 EST 2015
> > localuser:tom2 being added to access control list
> > openConnection: connect: No such file or directory
> > cannot connect to brltty at :0
> > gnome-s

Re: Is gnome-core really the gnome minimal install?

David Wright  writes:

> The OP seems to have got something useful out of the thread. I think I'll ask
> questions about the wiki page for Bluetooth instead.

I read carefully all the messages of the thread and appreciated and am grateful
to anyone who wrote.  I'm still thinking all it over.

Thanks,

Rodolfo

-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/878uduz6br@gmail.com

Bluetooth file transfer on jessie

2015-04-14 Thread David Wright

Hi, I transfer the photos off my mobile using bluetooth on wheezy and
I'm trying to do the same on jessie and having some difficulty.

Under wheezy, things are simple:

1)
# /usr/sbin/hciconfig hci0 piscan
makes the laptop discoverable.

2)
$ bluetooth-agent 1234
sets a passkey to connect to the laptop.

3)
$ yes | bt-obex -s /tmp/
OBEXAgent registered
saves me typing y as each file comes in from the mobile.

I omit (2) after having paired the first time.

With jessie, step (1) is fine and I can see:

$ hciconfig 
hci0:   Type: BR/EDR  Bus: USB
BD Address: 00:1E:37:AF:C2:CC  ACL MTU: 310:10  SCO MTU: 64:8
UP RUNNING PSCAN ISCAN 
RX bytes:1056 acl:6 sco:0 events:48 errors:0
TX bytes:757 acl:7 sco:0 commands:29 errors:0

$ systemctl status bluetooth
● bluetooth.service - Bluetooth service
   Loaded: loaded (/lib/systemd/system/bluetooth.service; enabled)
   Active: active (running) since Tue 2015-04-14 15:45:49 CDT; 53min ago
 Docs: man:bluetoothd(8)
 Main PID: 688 (bluetoothd)
   Status: "Running"
   CGroup: /system.slice/bluetooth.service
   └─688 /usr/lib/bluetooth/bluetoothd

Apr 14 15:45:35 west bluetoothd[688]: Bluetooth daemon 5.23
Apr 14 15:45:49 west bluetoothd[688]: Starting SDP server
Apr 14 15:45:54 west bluetoothd[688]: Bluetooth management interface 1.6 
initialized
Apr 14 15:45:55 west bluetoothd[688]: Sap driver initialization failed.
Apr 14 15:45:55 west bluetoothd[688]: sap-server: Operation not permitted (1)
$ 

But I don't know what to run to set up a passkey as in (2). None of
the   man blue   pages seem to say, as in wheezy:

  bluetooth-agent [--adapter adapter-path] [--path agent-path]  
[]

(They are blueman-adapters blueman-applet blueman-assistant
blueman-browse blueman-manager blueman-sendto blueman-services
bluetoothctl.) In fact, most of the man pages look like skeletal
placeholders.

Packages containing blue|obex
wheezy: bluetooth bluez bluez-alsa bluez-cups bluez-gstreamer bluez-tools 
libbluetooth3 obexd-client obexd-server
jessie: blueman bluetooth bluez bluez-cups bluez-obexd bluez-test-scripts 
bluez-tools libbluetooth3:i386 obex-data-server

Any ideas?

Cheers,
David.


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20150414223628.gb14...@alum.home

[solved] Re: Error message on console at logging in

Rodolfo Medina  writes:

> Darac Marjal  writes:
>
>> On Mon, Feb 02, 2015 at 10:06:43AM +, Rodolfo Medina wrote:
>>> Hi all.
>>> 
>>> With Debian 8: on my Acer netbook, when logging in, if I rotate the screen,
>>> many undesired lines appear on the console complaining:
>>> 
>>>  usb 2-1: device descriptor read/64, error -71
>>> 
>>> .  No usb device is inserted in the machine, but the error message disturbs
>>> the logging in.  With previous Debian versions, such kernel messages were
>>> avoided simply appending to /etc/init.d/rc.local the line:
>>
>> Check lsusb. Some machines have internally connected USB devices. See if
>> you have anything connected at Bus 002 Device 001. Error -71 is,
>> apparently, a "protocol error", which might suggest that the screen
>> rotation is either causing a bit of noise on a cable (is there, for
>> example, a USB hub built into your monitor?) or perhaps your monitor is
>> trying to communicate the fact that it has rotated over USB and that's
>> failing.
>>
>>> 
>>> dmesg -n 1
>>> 
>>> , but now this does not help any more.
>
>
>
> Here's the output of `lsusb':
>
> Bus 005 Device 012: ID 0c45:62c0 Microdia Sonix USB 2.0 Camera
> Bus 005 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
> Bus 004 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
> Bus 003 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
> Bus 002 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
> Bus 001 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
>
> Notice that with Debian 6, installed on another partition of the same
> machine, the problem does not occur, the message doesn't appear.


It seems to be solved appending to the file /etc/init.d/rc.local the following
stuff:

 dmesg -n 1

; and, besides, in /etc/sysctl.conf uncommenting the following line:

 kernel.printk = 3 4 1 3

Rodolfo


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/87egnmxrd5.fsf...@gmail.com

Re: Subject: network-console installation and ssh keys

2015-04-14 Thread Christian Seiler


On 04/14/2015 10:31 PM, David Wright wrote:

I like the new Network Console option in the installer.
However, when I reinstall Debian onto a machine called, say, desk
select the necessary options, type in the password for the
installer session, and then sit back with a machine called, lap,
when I type   ssh installer@desk   I get the usual

@@@
@WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! @
@@@
IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
Someone could be eavesdropping on you right now (man-in-the-middle
attack)!
It is also possible that a host key has just been changed.
The fingerprint for the RSA key sent by the remote host is

because the installer has generated and is running with fresh keys.
(I frequently connect from lap to desk and vice versa and so
have authorised_keys as well as know_hosts there.)

What do most people do here?


It depends on what I want to achieve:

- Host temporarily has a different key because of a running
  installation (or rescue CD or so), but will have the right
  keys again in the future. I have the following alias defined:

alias sshnv='ssh -o GlobalKnownHostsFile=/dev/null
 -o UserKnownHostsFile=/dev/null'

  (Just one line, but my mail client wants to wrap.)

  This allows me to do sshnv user@host, but the temporary key will
  not be remembered (I still have to accept it though).

  This is also useful if I don't want to remember the key even if
  it's not already in the known_hosts file.

- Host will permanently have a new key.

ssh-keygen -R hostname

  This will remove all keys for a given host from the known_hosts
  file, and then a new key can be accepted for that host, which will
  be stored permanently.

Hope that helps.

Christian


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

Archive: https://lists.debian.org/552d9814.6060...@iwakd.de

Re: reading an empty directory after reboot is very slow

2015-04-14 Thread Cam Hutchison

Vincent Lefevre  writes:

>On 2015-04-13 16:28:27 -0600, Bob Proulx wrote:

>> Without dir_index an ext filesystem with large directories is slow due
>> to the linear nature of directories.  But with dir_index it should be
>> using a B-tree data structure and should be much faster.

>So, why is it slow?

I don't think dir_index has anything to do with it. An index speeds up
lookups. You are not doing lookups; you are traversing the entire data
structure. A B-tree data structure can take longer to traverse than a
contiguous array data structure due to prefetching generally being
beneficial to arrays, but less so to pointer-based structures.

It's slow because every block of the directory needs to be read to get
the contents, even if every block contains empty entries. You don't know
that until you've read it.

>I also notice slowness with a large maildir directory:

>drwx-- 2 vlefevre vlefevre 8409088 2015-03-24 14:04:33 Mail/oldarc/cur/

>In this one, the files are real (145400 files), but I have a Perl
>script that basically reads the headers and it takes a lot of time
>(several dozens of minutes) after a reboot or dropping the caches
>as you suggested above. With a second run of this script, it just
>takes 8 seconds.

Your large directory is about 3.5 times the size of this one, so we
would expect all things being equal that it would take 30s to read the
larger directory based on the time of reading your maildir.

One thing that is likely not equal is fragmentation. It is quite
possible that your 30MB directory is fragmented across the disk and
involves many seeks to read it all. If you really want to know if this
is the case, use debugfs(8) to have a look:

# debugfs /dev/sda1  # sub sda1 with your device
debugfs:  blocks /path/to/directory  # path relative to root of filesystem

That will output all the blocks used by the directory, in the order of
the blocks in the directory. You'll be able to see how much seeking
would be needed to read those blocks linearly.

e.g.
# debugfs /dev/mapper/m500-var
debugfs 1.42.5 (29-Jul-2012)
debugfs:  blocks /lib/dpkg/info
8236 8207 8204 8221 8222 8223 8231 8232 8234 8333 8394 8395 8393 8396
8399 8400 8402 8747 8913 9258 9289 9311 9433 9405 9432 9452 9407 32084
32237 32238 32236 32245 32254 9555 9978 9908 

You can see the blocks are reasonable contiguous until it jumps up to
the 32000's, and then back to the 9000's. If you see a lot of that in
your large empty directory, you'll find it slow to seek around the whole
lot. (In my case, that's on an SSD, so I don't care).

-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/4206.552d9c3f.b4...@xdna.net

Re: Is gnome-core really the gnome minimal install?

2015-04-14 Thread Patrick Bartek

On Tue, 14 Apr 2015, Rodolfo Medina wrote:

> Patrick Bartek  writes:
> 
> > Of course, if you really want TOTAL control of your GUI, a window
> > manager is the way to go.  That's what I did.  Installed Openbox.
> > The same WM that LXDE uses.  A little more work, but worth it.
> 
> Thanks.  I'm trying it.  In the web browser, I open a new tab with
> C-t, but don't know how to do that in the terminal emulator.  The
> usual `C-shift-t' does not work.

Depends on which terminal emulator you're using. I use xterm, and it
doesn't support tabbed windows -- as far as I can tell.  Never
bothered to check.  But that's okay. I prefer multiple terminals instead
of a single one with multiple tabs.

B

-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20150414175355.704bf...@debian7.boseck208.net

Re: FAQ's versus "Questions Newbies SHOULD Ask"?

2015-04-14 Thread Nate Bargmann

* On 2015 14 Apr 13:57 -0500, Gene Heskett wrote:
> 
> 
> On Tuesday 14 April 2015 12:08:09 Lisi Reisz wrote:
> > On Tuesday 14 April 2015 17:03:48 Richard Owlett wrote:
> > > FAQ's may indicate questions others have asked.
> >
> > In my experience they frequently indicate questions the writer is
> > hoping/expecting you to ask, that noone has ever asked and that I have
> > never thought of asking.
> >
> > Lisi
> 
> Good for a grin, Lisi, thanks.  And here I thought I was alone in 
> thinking that.

We're all cynics!

For some odd reason I seem to have questions that are lightly or not
covered by the documentation.

For Richard, many of my searches lead me to the Stack Overflow
collection of web sites.  The answers I find are usually very good and
often times there are one or two additional detailed explanations.

Of course someone will weigh in saying that all questions are ansered in
the source...

- Nate

-- 

"The optimist proclaims that we live in the best of all
possible worlds.  The pessimist fears this is true."

Ham radio, Linux, bikes, and more: http://www.n0nb.us

-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20150415015216.gz...@n0nb.us

Re: reading an empty directory after reboot is very slow

On 2015-04-14 10:55:12 -0600, Bob Proulx wrote:
> Other file systems such as xfs designed for large files and large
> numbers of files DO shrink when files are removed.  That is one of the
> reasons why xfs is recommended for industrial strength use.  It was
> designed to handle those kinds of workloads.  However that means that
> it must spend time when files are deleted to clean everything up.
> Everything has a cost.  But xfs is one of the file systems that do
> shrink directories when files are deleted.

This could be done efficiently, for instance by delaying the shrink
operation (with mechanisms similar to cache write back), so that the
time spent for the clean up is guaranteed to remain small (or spent
when there is nothing else to do).

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20150415021115.ga19...@xvii.vinc17.org

Re: reading an empty directory after reboot is very slow

On 2015-04-14 13:26:16 -0300, Henrique de Moraes Holschuh wrote:
> Yeah, that's a bad habit to have as it slows down way too many
> utilities (lots of stuff benefit for extremely lightweight
> ultra-fast tmpfs in /tmp and $TMPDIR, from "sort" to gcc without
> -pipe), but it is indeed widespread.

Can't disk caching be as fast as tmpfs (or almost)?

> The "persistent dumping ground" lives in /var/tmp, it is not
> supposed to be in /tmp or ${TMPDIR}. But old habits are hard to
> change.

When Debian/unstable temporarily switched /tmp to tmpfs by default,
the /tmp size became too small for files that were really temporary.
So, /var/tmp was *not* the right choice, and /tmp became unusable
as too small.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20150415021824.gb19...@xvii.vinc17.org

wheezy drive recognition?

Greetings drive guru's;

I have a 3 drive hot swap cage in my machine for a couple years now, and no it 
is NOT setup as a raid of any kind.

It has had a triplet of 1T seagate drives in it since installing it.

My main boot drive had a 10.04-4 LTS Ubuntu install on it, but the drive 
went read only a couple months back, so I swapped the top 2 and put 
wheezy on what is now /dev/sda.

I eventually had copied off what I needed from the old drive so I removed 
it, leaving slot 2 empty while I ordered up 2 more drives from 
TigerDirect, but had to settle for the 2Tb version this time.

Tonight I cut the blisterpack off the first of the 2Tb drives and slid 
it into slot 2.

Wheezy, with "SMP Debian 3.2.65-1+deb7u2 x86_64 GNU/Linux" kernel running 
cannot connect to it, doing this from /var/log/messages:

Apr 14 21:14:33 coyote kernel: [1098002.318613] ata2: hard resetting link
Apr 14 21:14:39 coyote kernel: [1098008.240015] ata2: link is slow to respond, 
please be patient (ready=-19)
Apr 14 21:14:43 coyote kernel: [1098012.328022] ata2: hard resetting link
Apr 14 21:14:49 coyote kernel: [1098018.256019] ata2: link is slow to respond, 
please be patient (ready=-19)
Apr 14 21:14:53 coyote kernel: [1098022.344027] ata2: hard resetting link
Apr 14 21:14:59 coyote kernel: [1098028.264018] ata2: link is slow to respond, 
please be patient (ready=-19)

Followed by quite a few megabytes of this:
Apr 14 21:15:27 coyote kernel: [1098055.934065] sr 4:0:0:0: [sr0]  Result: 
hostbyte=DID_OK driverbyte=DRIVER_SENSE
Apr 14 21:15:27 coyote kernel: [1098055.934070] sr 4:0:0:0: [sr0]  Sense Key : 
Illegal Request [current] 
Apr 14 21:15:27 coyote kernel: [1098055.934074] sr 4:0:0:0: [sr0]  Add. Sense: 
Illegal mode for this track
Apr 14 21:15:27 coyote kernel: [1098055.934081] sr 4:0:0:0: [sr0] CDB: 
Read(10): 28 00 00 00 00 00 00 00 02 00
Apr 14 21:15:27 coyote kernel: [1098055.935512] sr 4:0:0:0: [sr0]  Result: 
hostbyte=DID_OK driverbyte=DRIVER_SENSE
Apr 14 21:15:27 coyote kernel: [1098055.935515] sr 4:0:0:0: [sr0]  Sense Key : 
Illegal Request [current] 
Apr 14 21:15:27 coyote kernel: [1098055.935518] sr 4:0:0:0: [sr0]  Add. Sense: 
Illegal mode for this track
Apr 14 21:15:27 coyote kernel: [1098055.935522] sr 4:0:0:0: [sr0] CDB: 
Read(10): 28 00 00 00 00 00 00 00 01 00

I got the impression that it was not even spinning up.
So I plugged the old, read-only drive in to see if the slot was bad, 
but it signs on like this:
Apr 14 21:35:05 coyote kernel: [1099234.688032] ata2: hard resetting link
Apr 14 21:35:11 coyote kernel: [1099240.608030] ata2: link is slow to respond, 
please be patient (ready=-19)
Apr 14 21:35:15 coyote kernel: [1099244.704026] ata2: hard resetting link
Apr 14 21:35:16 coyote kernel: [1099245.588034] ata2: SATA link up 1.5 Gbps 
(SStatus 113 SControl 300)
Apr 14 21:35:16 coyote kernel: [1099245.596577] ata2.00: ATA-8: ST31000340AS, 
SD1A, max UDMA/133
Apr 14 21:35:16 coyote kernel: [1099245.596582] ata2.00: 1953525168 sectors, 
multi 0: LBA48 NCQ (depth 31/32)
Apr 14 21:35:16 coyote kernel: [1099245.612502] ata2.00: configured for UDMA/133
Apr 14 21:35:16 coyote kernel: [1099245.612512] ata2: EH complete
Apr 14 21:35:16 coyote kernel: [1099245.612633] scsi 1:0:0:0: Direct-Access 
ATA  ST31000340AS SD1A PQ: 0 ANSI: 5
Apr 14 21:35:16 coyote kernel: [1099245.612851] sd 1:0:0:0: Attached scsi 
generic sg5 type 0
Apr 14 21:35:16 coyote kernel: [1099245.612895] sd 1:0:0:0: [sde] 1953525168 
512-byte logical blocks: (1.00 TB/931 GiB)
Apr 14 21:35:16 coyote kernel: [1099245.612993] sd 1:0:0:0: [sde] Write Protect 
is off
Apr 14 21:35:16 coyote kernel: [1099245.613034] sd 1:0:0:0: [sde] Write cache: 
enabled, read cache: enabled, doesn't support DPO or FUA
Apr 14 21:35:16 coyote kernel: [1099245.665063]  sde: sde1 sde2 sde3
Apr 14 21:35:16 coyote kernel: [1099245.665558] sd 1:0:0:0: [sde] Attached SCSI 
disk

Essentially normal except if I try to write to it, it will go read-only 
immediately.

These 2 new drives are sata-3, 6Gb/sec drives.  From the logs, the driver
had set it down to 1.5Gbs in an attempt to talk to it, but obviously
failed. The motherboard book only claims 3Gbs.

Have I a duff drive, or, is either this kernel, or this Asus M2N-SLI Deluxe 
motherboard incapable of dealing with a 6Gb/sec, 2Tb drive with 4096 byte 
physical sectors?  Or maybe a drive that needs a firmware update?  All of 
those 1T's needed it before they settled down and Just Worked for several
years.

FWIW, the 1Tb drive as my main boot, is also a 4096 byte physical sector 
drive and seems to be ok AFTER I finally got an "aligned" partitioning 
scheme setup.

Basically with a pair of drives this big, I am walking on brand new dirt 
here.

Opinions, swags anybody?

Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page 


-- 
To UNSUBSCRIBE, email to debian-use

Re: FAQ's versus "Questions Newbies SHOULD Ask"?



On Tuesday 14 April 2015 21:52:16 Nate Bargmann wrote:
> * On 2015 14 Apr 13:57 -0500, Gene Heskett wrote:
> > On Tuesday 14 April 2015 12:08:09 Lisi Reisz wrote:
> > > On Tuesday 14 April 2015 17:03:48 Richard Owlett wrote:
> > > > FAQ's may indicate questions others have asked.
> > >
> > > In my experience they frequently indicate questions the writer is
> > > hoping/expecting you to ask, that noone has ever asked and that I
> > > have never thought of asking.
> > >
> > > Lisi
> >
> > Good for a grin, Lisi, thanks.  And here I thought I was alone in
> > thinking that.
>
> We're all cynics!
>
Amen! And while I am not originally from Missouri, I have been there 
often enough to be infected with the Show me viri.

> For some odd reason I seem to have questions that are lightly or not
> covered by the documentation.
>
> For Richard, many of my searches lead me to the Stack Overflow
> collection of web sites.  The answers I find are usually very good and
> often times there are one or two additional detailed explanations.

Which I, like you, have found to be usefull.

> Of course someone will weigh in saying that all questions are ansered
> in the source...
>
> - Nate

That is provided the source is written in something resembling ANSI C.  
Our gcc today has very little resemblance to ANSI C.  And its the ANSI 
that has not kept up, those K&R #1 and #2 books we all once used for a 
Bible back in the day is now 24 years old.

Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page 


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/201504142240.29180.ghesk...@wdtv.com

Re: reading an empty directory after reboot is very slow

2015-04-14 Thread The Wanderer

On 04/14/2015 at 12:55 PM, Bob Proulx wrote:

> Petter Adsen wrote:
> 
>> Can someone please enlighten me as to why the entry for this
>> directory is so large, even though it is empty? Since it's
>> apparently obvious to everyone else, I would very much like to know
>> :)
> 
> In the old days directories were simply an array of fixed sized 
> integers and fixed sized names.  The fixed maximum size of the name 
> was 14 characters.  The fixed size integer was the inode address. 
> That it was fixed sized allowed directories to be read into an array 
> of structures very efficiently using readdir(2) system call. 
> Individual entries were written by lseek(2)'ing to the proper slot
> and writing just that fixed size entry leaving the rest of the
> (special directory) file untouched.  Directories were an array of
> file entries.
> 
> That strategy was in use for many years in Unix systems.  But it has 
> unpleasant limitations.  Short fixed sized file names 14 characters
> or less were one.  The linear nature of the array data structure was 
> another.  The array influenced things considerably.  When a file was 
> deleted the entree was simply zero'd out.  lseek() to the proper 
> entry and zero it out.  That meant that directories could grow in
> size but never shrink.  If a directory became full it was easy to
> extend it by writing the array longer.  But if an early entry in the
> array was deleted the system would zero it out rather than move each
> and every entry in the file system down a slot.  (I always wondered
> why they didn't simply take the *last* entry and move it down to the
> deleted entry and simply keep the array always compacted.  I wonder.
> But they didn't do it that way.)

I'd guess that it was in order to avoid having the "internal order" of
files in a directory - which can affect the order in which they are
processed, depending on how you get your directory listing - be changed
by a seemingly unrelated operation.

Thanks for the lengthy explanation and historical background. By the
time I got started, apparently the 14-character limit was already far
enough in the background that it never made it into the documentation
that I read...

-- 
   The Wanderer

The reasonable man adapts himself to the world; the unreasonable one
persists in trying to adapt the world to himself. Therefore all
progress depends on the unreasonable man. -- George Bernard Shaw



signature.asc
Description: OpenPGP digital signature

Re: reading an empty directory after reboot is very slow

On 2015-04-14 23:01:19 -, Cam Hutchison wrote:
> I don't think dir_index has anything to do with it. An index speeds up
> lookups. You are not doing lookups; you are traversing the entire data
> structure. A B-tree data structure can take longer to traverse than a
> contiguous array data structure due to prefetching generally being
> beneficial to arrays, but less so to pointer-based structures.
> 
> It's slow because every block of the directory needs to be read to get
> the contents, even if every block contains empty entries. You don't know
> that until you've read it.

I would have imagined that a B-tree data structure would simplify
when elements are removed. In fact, it isn't even a B-tree:

http://en.wikipedia.org/wiki/B-tree#Definition says:

  Every non-leaf node (except root) has at least ⌈m⁄2⌉ children.

So, there should be only a root node.

> >I also notice slowness with a large maildir directory:
> 
> >drwx-- 2 vlefevre vlefevre 8409088 2015-03-24 14:04:33 Mail/oldarc/cur/
> 
> >In this one, the files are real (145400 files), but I have a Perl
> >script that basically reads the headers and it takes a lot of time
> >(several dozens of minutes) after a reboot or dropping the caches

31 minutes

> >as you suggested above. With a second run of this script, it just
> >takes 8 seconds.
> 
> Your large directory is about 3.5 times the size of this one, so we
> would expect all things being equal that it would take 30s to read the
> larger directory based on the time of reading your maildir.
> 
> One thing that is likely not equal is fragmentation. It is quite
> possible that your 30MB directory is fragmented across the disk and
> involves many seeks to read it all. If you really want to know if this
> is the case, use debugfs(8) to have a look:
> 
> # debugfs /dev/sda1  # sub sda1 with your device
> debugfs:  blocks /path/to/directory  # path relative to root of filesystem
[...]

The blocks are increasing and more or less contiguous. But since the
beginning of each file needs to be read, the time may be spent there.
That would be around 12 - 13 ms for each file. But

  ioping Mail/oldarc/cur

gives 162 us in average! But I'm wondering whether I need to add
options. Using -D is more interesting, but I don't know the meaning:

ypig:~> ioping -D Mail/oldarc/cur
4 KiB from Mail/oldarc/cur (ext3 /dev/sda1): request=1 time=11.8 ms
4 KiB from Mail/oldarc/cur (ext3 /dev/sda1): request=2 time=176 us
4 KiB from Mail/oldarc/cur (ext3 /dev/sda1): request=3 time=6.50 ms
4 KiB from Mail/oldarc/cur (ext3 /dev/sda1): request=4 time=6.09 ms
4 KiB from Mail/oldarc/cur (ext3 /dev/sda1): request=5 time=133 us
4 KiB from Mail/oldarc/cur (ext3 /dev/sda1): request=6 time=158 us
4 KiB from Mail/oldarc/cur (ext3 /dev/sda1): request=7 time=159 us
4 KiB from Mail/oldarc/cur (ext3 /dev/sda1): request=8 time=1.79 ms
4 KiB from Mail/oldarc/cur (ext3 /dev/sda1): request=9 time=1.90 ms
4 KiB from Mail/oldarc/cur (ext3 /dev/sda1): request=10 time=176 us
4 KiB from Mail/oldarc/cur (ext3 /dev/sda1): request=11 time=3.45 ms
4 KiB from Mail/oldarc/cur (ext3 /dev/sda1): request=12 time=158 us
^C
--- Mail/oldarc/cur (ext3 /dev/sda1) ioping statistics ---
12 requests completed in 11.8 s, 369 iops, 1.44 MiB/s
min/avg/max/mdev = 133 us / 2.71 ms / 11.8 ms / 3.53 ms

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20150415025033.gc19...@xvii.vinc17.org

Re: wheezy drive recognition?

2015-04-14 Thread David Christensen


On 04/14/2015 07:30 PM, Gene Heskett wrote:

I have a 3 drive hot swap cage ...
wheezy on what is now /dev/sda. ...
Tonight I cut the blisterpack off the first of the 2Tb drives and slid
it into slot 2. ...
Wheezy, with "SMP Debian 3.2.65-1+deb7u2 x86_64 GNU/Linux" kernel running
cannot connect to it, doing this from /var/log/messages: ...
These 2 new drives are sata-3, 6Gb/sec drives.  From the logs, the driver
had set it down to 1.5Gbs in an attempt to talk to it, but obviously
failed. The motherboard book only claims 3Gbs. ...
Asus M2N-SLI Deluxe motherboard ...


My one Asus motherboard (M2NPV-VM) worked fine, right up until the day 
it died.  If yours still works, I would expect it to work with new 
Seagate SATA 3 HDD's.



Disconnect all drives and the cage.


Get a power supply tester and test your power supply.


Test your memory:

http://www.memtest.org/


Take an image of your system drive and back up all of your data.


Install one new HDD in an internal drive bay.  Connect it to a known 
good power cable, and a known good SATA port on the motherboard using a 
known good SATA cable.  Boot the HDD manufacturer diagnostic CD and run 
all the utilities.  For Seagate, I use SeaTools for DOS:


http://www.seagate.com/support/downloads/item/seatools-dos-master/


If the HDD passes all the tests, boot a Debian Wheezy installation CD, 
install Debian on the HDD, boot the HDD, log in, and see if there are 
errors in the logs.



If Debian works correctly, move the HDD to the cage, connect the cage, 
and try again.



If you run into problems, post the details.


David


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

Archive: https://lists.debian.org/552ddaa8.4010...@holgerdanske.com

Re: wheezy drive recognition?

On Tuesday 14 April 2015 23:27:36 David Christensen wrote:
> On 04/14/2015 07:30 PM, Gene Heskett wrote:
> > I have a 3 drive hot swap cage ...
> > wheezy on what is now /dev/sda. ...
> > Tonight I cut the blisterpack off the first of the 2Tb drives and
> > slid it into slot 2. ...
> > Wheezy, with "SMP Debian 3.2.65-1+deb7u2 x86_64 GNU/Linux" kernel
> > running cannot connect to it, doing this from /var/log/messages: ...
> > These 2 new drives are sata-3, 6Gb/sec drives.  From the logs, the
> > driver had set it down to 1.5Gbs in an attempt to talk to it, but
> > obviously failed. The motherboard book only claims 3Gbs. ...
> > Asus M2N-SLI Deluxe motherboard ...
>
> My one Asus motherboard (M2NPV-VM) worked fine, right up until the day
> it died.  If yours still works, I would expect it to work with new
> Seagate SATA 3 HDD's.
>
>
> Disconnect all drives and the cage.
>
>
> Get a power supply tester and test your power supply.

I am monitoring it right now with gkrellm, its good.
>
> Test your memory:
>
>  http://www.memtest.org/

3 full cycles about 6 weeks back before I installed wheezy.>
>
> Take an image of your system drive and back up all of your data.

Amanda does that nightly.

>
> Install one new HDD in an internal drive bay.  Connect it to a known
> good power cable, and a known good SATA port on the motherboard using
> a known good SATA cable.  Boot the HDD manufacturer diagnostic CD and
> run all the utilities.  For Seagate, I use SeaTools for DOS:
> 
> http://www.seagate.com/support/downloads/item/seatools-dos-master/

Ok.
>
>
> If the HDD passes all the tests, boot a Debian Wheezy installation CD,
> install Debian on the HDD, boot the HDD, log in, and see if there are
> errors in the logs.
>
>
> If Debian works correctly, move the HDD to the cage, connect the cage,
> and try again.
>
>
> If you run into problems, post the details.
>
Will do, thanks.

> David

Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page 


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/201504142354.23766.ghesk...@wdtv.com

Re: gnome-settings-daemon, dbus use about %80 of CPU

2015-04-14 Thread Mikael Flood

Hello,

Try removing user file under ~/.config/dconf
rm ~/.config/dconf/user

This will revert your desktop to a "factory default" state (all shortcuts
and desktop changes will be reverted).

Let me know if this helps.


On 13 April 2015 at 17:18, claude juif  wrote:

> Hi,
>
> Can you check xsession log Xorg.log for any errors that might happens ?
>
> I see you take a screenshot from a X windows terminal, so X is responsive.
>
> Regards,
>
> 2015-04-09 21:02 GMT+02:00 Magdi Mahmoud :
>
>>  Hi
>>
>>
>>
>> Please find the system info below the issue happening  at least once a
>> day when trying to move to going between  windows
>>
>>
>>
>>
>>
>> Linux lamborghini 3.16.0-4-amd64 #1 SMP Debian 3.16.7-ckt7-1 (2015-03-01)
>> x86_64 GNU/Linux
>>
>> 00:02.0 VGA compatible controller: Intel Corporation Xeon E3-1200 v3/4th
>> Gen Core Processor Integrated Graphics Controller (rev 06)
>>
>>total   used   free
>> sharedbuffers cached
>> Mem:  163448561490504   14854352 176264  37924 621124
>> -/+ buffers/cache: 831456   15513400
>> Swap:0  0  0
>>
>>
>> [image: Description: Inline image 1]
>>
>> Thanks
>>
>> M
>>
>>
>>
>>
>>
>> *From:* claude juif [mailto:claude.j...@gmail.com]
>> *Sent:* 08 April 2015 11:17
>> *To:* Magdi Mahmoud
>> *Cc:* debian-user@lists.debian.org
>> *Subject:* Re: gnome-settings-daemon, dbus use about %80 of CPU
>>
>>
>>
>> Hi,
>>
>>
>>
>> We need more informations (a lot more) on this.
>>
>>
>>
>> Computer Arch ? Video Card ? Amount of RAM ? Is the system swapping ? X
>> logs ? What are your X drivers ?
>>
>>
>>
>> If you don't give us something to work on we can't do anything.
>>
>>
>>
>>
>>
>> PS: We read your email, no need to send it 3 or 4 times
>>
>>
>>
>>
>>
>>
>>
>> 2015-04-08 11:33 GMT+02:00 Magdi Mahmoud :
>>
>>
>>
>> Hi All,
>>
>>
>>
>> I have a problem with rel. 8.0 testing  since installed  sometimes
>> randomly  getting about %80  of CPU busy and X-Win doesn’t responding
>>
>> gnome-settings-daemon, dbus   daemon utilise  about %70-%80.
>>
>>
>>
>> Can someone  advise please
>>
>>
>>
>>
>>
>> Thank you
>>
>>
>>
>> Mag
>>
>>
>>
>>
>>
>>
>>
>> This email and any attachments may be confidential and/or legally
>> privileged. If you have received this e-mail and you are not a named
>> addressee, please inform the sender of this email by sending a return email
>> to the address above and then delete the e-mail and your response from your
>> system. If you are not a named addressee you must not use, disclose,
>> distribute, copy, print or rely on this e-mail. Any views or opinions
>> presented are solely those of the author. Any statements made, or
>> intentions expressed in this communication may not necessarily reflect the
>> view of Easynet. No content herein will bind Easynet or any associated
>> company unless confirmed by the execution of a formal contract by Easynet.
>> Any figures or amounts given in this email are quotations only and are
>> subject to change. Although Easynet routinely screen for viruses,
>> addressees should scan this e-mail and any attachments for viruses. Easynet
>> make no representation or warranty as to the absence of viruses in this
>> e-mail or any attachments. Please note that to ensure regulatory compliance
>> and for the protection of our customers and business, we may monitor and
>> read e-mails sent to and from our server(s). Easynet Limited (registered
>> number 02954343) and Easynet Global Services Limited (registered number
>> 08458875) are incorporated in England and Wales and share the same
>> registered office at St. James House, Oldbury, Bracknell, Berkshire, RG12
>> 8TH
>>
>>
>>
>
>


-- 
//Yours sincerely Mikael Flood

Re: Debian 7 and external monitors and graphics adaptors

On 14/04/2015, Bret Busby  wrote:
> On 14/04/2015, Curt  wrote:
>> On 2015-04-14, Bret Busby  wrote:
>>>
>>> so it apparently, is driving the inboard Intel graphics adaptor, and
>>> not the nVIDIA GT750m graphics adaptor.
>>
>> The best thing would be to look at the log file for X (on Squeeze LTS
>> that is to be found at the following location: '/var/log/Xorg.0.log') in
>> order to know which driver you're using (amongst other things--errors,
>> warnings, etc.).
>>
>> For the driver the following grep ditty seems to work fine:
>>
>> curty@einstein:~$ grep -B2 'Module class: X.Org Video Driver'
>> /var/log/Xorg.0.log
>> (II) Module fglrx: vendor="FireGL - ATI Technologies Inc."
>>  compiled for 1.4.99.906, module version = 8.95.3
>>  Module class: X.Org Video Driver
>>
>>
>>
>
> Thank you for that.
>
> I have just ran it on this (Dell Inspire) desktop system running
> Debian 6, to check it, and got
>
> "
> :~$ grep -B2 'Module class: X.Org Video Driver' /var/log/Xorg.0.log
> (II) Module nouveau: vendor="X.Org Foundation"
>   compiled for 1.7.7, module version = 0.0.15
>   Module class: X.Org Video Driver
> --
> (II) Module nv: vendor="X.Org Foundation"
>   compiled for 1.7.7, module version = 2.1.17
>   Module class: X.Org Video Driver
> --
> (II) Module vesa: vendor="X.Org Foundation"
>   compiled for 1.7.7, module version = 2.3.0
>   Module class: X.Org Video Driver
> "
>
> and this system shows
>
> "
> :~$ lspci | grep -i vga
> 01:00.0 VGA compatible controller: nVidia Corporation GT218 [GeForce
> 310] (rev a2)
> "
>
> so I intend to run those two commands in each of the Ubuntu and Debian
> installations on the Acer V3-772G system, tomorrow.
>


On the Acer V3-772G, for Ubuntu, I have

"
bret@bret-Aspire-V3-772:~$ grep -B2 'Module class: X.Org Video Driver'
/var/log/Xorg.0.log
[26.440] (II) Module intel: vendor="X.Org Foundation"
[26.440]compiled for 1.15.1, module version = 2.99.910
[26.440]Module class: X.Org Video Driver
--
[26.449] (II) Module nouveau: vendor="X.Org Foundation"
[26.449]compiled for 1.15.0, module version = 1.0.10
[26.449]Module class: X.Org Video Driver
--
[26.449] (II) Module modesetting: vendor="X.Org Foundation"
[26.449]compiled for 1.15.0, module version = 0.8.1
[26.449]Module class: X.Org Video Driver
--
[26.450] (II) Module fbdev: vendor="X.Org Foundation"
[26.450]compiled for 1.15.0, module version = 0.4.4
[26.450]Module class: X.Org Video Driver
--
[26.450] (II) Module vesa: vendor="X.Org Foundation"
[26.450]compiled for 1.15.0, module version = 2.3.3
[26.450]Module class: X.Org Video Driver
--
[26.450] (II) Module intel: vendor="X.Org Foundation"
[26.450]compiled for 1.15.1, module version = 2.99.910
[26.450]Module class: X.Org Video Driver
--
[26.450] (II) Module nouveau: vendor="X.Org Foundation"
[26.450]compiled for 1.15.0, module version = 1.0.10
[26.450]Module class: X.Org Video Driver
--
[26.451] (II) Module modesetting: vendor="X.Org Foundation"
[26.451]compiled for 1.15.0, module version = 0.8.1
[26.451]Module class: X.Org Video Driver
--
[26.451] (II) Module fbdev: vendor="X.Org Foundation"
[26.451]compiled for 1.15.0, module version = 0.4.4
[26.451]Module class: X.Org Video Driver
--
[26.451] (II) Module vesa: vendor="X.Org Foundation"
[26.451]compiled for 1.15.0, module version = 2.3.3
[26.451]Module class: X.Org Video Driver
"

and

"
bret@bret-Aspire-V3-772:~$  lspci | grep -i vga
00:02.0 VGA compatible controller: Intel Corporation 4th Gen Core
Processor Integrated Graphics Controller (rev 06)
"

and in the ouput from sudo lshw, is

"
 *-pci
  description: Host bridge
  product: Xeon E3-1200 v3/4th Gen Core Processor DRAM Controller
  vendor: Intel Corporation
  physical id: 100
  bus info: pci@:00:00.0
  version: 06
  width: 32 bits
  clock: 33MHz
*-pci:0
 description: PCI bridge
 product: Xeon E3-1200 v3/4th Gen Core Processor PCI
Express x16 Controller
 vendor: Intel Corporation
 physical id: 1
 bus info: pci@:00:01.0
 version: 06
 width: 32 bits
 clock: 33MHz
 capabilities: pci pm msi pciexpress normal_decode
bus_master cap_list
 configuration: driver=pcieport
 resources: irq:40 ioport:4000(size=4096)
memory:d200-d2ff ioport:a000(size=536870912)
   *-display
description: 3D controller
product: GK107M [GeForce GT 750M]
vendor: NVIDIA Corporation
physical id: 0
bus info: pci@:01:00.0
version: a1
width: 64 bits
clock: 33MHz
capabilities: pm msi pciexpress bus

Re: Book questions

On Tuesday, April 14, 2015 at 9:20:06 PM UTC+5:30, David Christensen wrote:
> I mentioned SICP before.  The concepts are great, but the Scheme 
> programming language and REPL environment aren't my favorite.  If you're 
> serious about computer science and computer programming, read it first 
> and then choose what's next:
> 
>  http://mitpress.mit.edu/sicp/full-text/book/book.html

I guess I am the diagonally opposite corner: personally I enjoyed scheme (along 
with APL) more than any other language; SICP not so much

However if the content of SICP calls you and not scheme the medium, here's
SICP in python
http://www-inst.eecs.berkeley.edu/~cs61a/sp12/book/

Well I suppose I am coming across as a python fanboy.. anyways... that's SICP 
in python  -- if that calls you.

Why SICP-the-book doesn't get SICP-the-contents:
http://blog.languager.org/2013/08/applying-si-on-sicp.html

I find the Friedman books better.

On a more tangential note here are the "Tears of Donald Knuth"
https://www.youtube.com/watch?v=gAXdDEQveKw

And a historian commenting on the same:
http://cacm.acm.org/magazines/2015/1/181633-the-tears-of-donald-knuth/fulltext

Should give a picture of how CS has shifted in ½ a century


--
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/668cd205-865e-4507-90c1-7b1c5d27a...@googlegroups.com

[solved] Re: Error message on console at logging in

Rodolfo Medina  writes:

> Hi all.
>
> With Debian 8: on my Acer netbook, when logging in, if I rotate the screen,
> many undesired lines appear on the console complaining:
>
>  usb 2-1: device descriptor read/64, error -71
>
> .  No usb device is inserted in the machine, but the error message disturbs
> the logging in.  With previous Debian versions, such kernel messages were
> avoided simply appending to /etc/init.d/rc.local the line:
>
> dmesg -n 1
>
> , but now this does not help any more.  Apparently, the message does not seem
> to correspond to any effective problem, so I wish I could prevent it to
> appear.


It seems to be solved appending to the file /etc/init.d/rc.local the following
stuff:

 dmesg -n 1

; and, besides, in /etc/sysctl.conf uncommenting the following line:

 kernel.printk = 3 4 1 3

Rodolfo


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/87618xsxkh@gmail.com

Re: debian 8

On 13/04/2015, Petter Adsen  wrote:
> On Mon, 13 Apr 2015 23:23:54 +0800
> Bret Busby  wrote:
>> 2. As indicated in earlier posts, the two computers to which I have
>> referred; the Acer V3-772G and the Acer E5-521-238Q (I think that is
>> the model number of the newer one - it is in my previous posts), both
>> have the poor quality Insyde20 (?) (Inshite20) (I think it is) Setup
>> Utility, that controls whether the computer boots into UEFI or BIOS,
>> and forces Secure Boot when the computer boots into UEFI. So the "The
>> problem is really caused by halfbaked IOS/UEFI/EC firmware" sounds
>> quite credible. Acer needs to provide a decent Setup Utility with its
>> computers. The Setup Utitility (the Inshite20 one) appears to be third
>> party, and, not from the motherboards manufacturer(s), but, I could be
>> wrong in that.
>
> They very often are.
>
>> Unfortunately, the newer computer being a computer less than ten years
>> old, did not come with a printed manual, and I can not easily remove
>> the battery, so I will need to make a warranty claim on it - it is, I
>> think, less than a month old, or, at most, less than three months old.
>
> I do not know if this will solve your problem, but I found a manual for
> what I believe is your machine on Acer's website, and put it on my
> Dropbox account for you:
>
> https://www.dropbox.com/s/09lfo01vnl9z9d7/UM_asE5-571_531_551_521_511_EN_Win8.1_v2.pdf?dl=0
>
> Page 49 describes how to remove the battery pack, so with that guide in
> hand you can try to do it yourself without handing it in for a two week
> wait. I can't imagine that doing this would in any way affect your
> warranty.
>
> Good luck.
>
> Petter
>


The whole thing (getting the E5-521-238Q working again) ended up being
a witchcraft and entrails kind of thing.

1. A "suitable tool" for applying to the battery latch hole, is
"something like a paper clip or a pin or something", so, for safety, I
used the blunt end of a straight sewing needle (where is a paper clip,
when one is needed?).

2. Step one - make sure computer is disconnected from power supply.

3. Step 2 - insert "appropiate tool" into battery release hole, five times.

4. Step 3 - use "appropriate tool" to slide battery release latch
sideways, and remove battery.

5. Step 4 -  press power button five times.

6. Step 5 - re-insert batter.

7. Step 6 - connect to power supply.

8. Step 7 - press power button.

System is restored, as is session that existed when crash occurred.

Probaby best not done when dancing widdershins around a bonfire while
surrounded by twelve naked virgins of the user's preferred gender (too
many distractions).

Oh, and I found the purchase receipt for the computer - purchased on
02 April - did not last long, before first problem that required
warranty assistance.


-- 
Bret Busby
Armadale
West Australia
..

"So once you do know what the question actually is,
 you'll know what the answer means."
- Deep Thought,
 Chapter 28 of Book 1 of
 "The Hitchhiker's Guide to the Galaxy:
 A Trilogy In Four Parts",
 written by Douglas Adams,
 published by Pan Books, 1992




-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/cacx6j8m2teclhcvc7zoosgy3nmeuufdrv-rbuwmoatb2laz...@mail.gmail.com

Re: Sharing LVM storage

On Tue, 14 Apr 2015 18:14:31 +0300
Reco  wrote:

>  Hi.
> 
> On Tue, Apr 14, 2015 at 04:01:02PM +0200, Petter Adsen wrote:
> > I'm using LVM as storage for virtual machines, and would like to
> > share a PV between two machines with iSCSI to be able to migrate
> > the VM's.
> 
> I did the thing some time ago. It worked, although I used ietd and not
> today's tgtd. The main reason was - ietd had configuration file, tdtd
> had not (as in 'our daemon does not need config at all, use tdtadm').

I've already set up iSCSI, and went with ietd, too. To be fair, I
didn't know about tgtd :)

> > Wikipedia says this:
> > "The LVM will also work in a shared-storage cluster (where disks
> > holding the PVs are shared between multiple host computers), but
> > requires an additional daemon to propagate state changes between
> > cluster nodes."
> > 
> > But nothing else. Is the clvm (with dependencies) package
> > everything I need to do this? Or would I need to mess with all
> > sorts of clustering stuff to get that working?
> 
> Not strictly as the main role of clvm is to guarantee that one LV will
> always be used by one node. Secondary role of clvm is to handle LV
> addition and removal by principle of least surprise. I.e. lvcreate on
> node one should add the same LV on node two.

That sounds reasonable.

> > I just want to try it out to see how it works, it's not something I
> > need by any stretch of the imagination, so there's a limit to how
> > far down that rabbit-hole I want to go.
> 
> As long as you don't forget to run lvscan on partner node after doing
> basically anything with LV on main node - you should be OK.
> 
> But just to be on the safe side - don't export PV via iSCSI. Export
> LVs.

May I ask why, so I don't mess anything up? I was thinking of exporting
maybe my VM VG, so that all LV's for VM's were available to both
machines. Or just the device itself.

Thank you for the advice!

Petter

-- 
"I'm ionized"
"Are you sure?"
"I'm positive."


pgp6KFb6sdCkK.pgp
Description: OpenPGP digital signature

Re: Debian 7 and external monitors and graphics adaptors

On 15/04/2015, Bret Busby  wrote:
> On 14/04/2015, Bret Busby  wrote:
>> On 14/04/2015, Curt  wrote:
>>> On 2015-04-14, Bret Busby  wrote:

 so it apparently, is driving the inboard Intel graphics adaptor, and
 not the nVIDIA GT750m graphics adaptor.
>>>
>>> The best thing would be to look at the log file for X (on Squeeze LTS
>>> that is to be found at the following location: '/var/log/Xorg.0.log') in
>>> order to know which driver you're using (amongst other things--errors,
>>> warnings, etc.).
>>>
>>> For the driver the following grep ditty seems to work fine:
>>>
>>> curty@einstein:~$ grep -B2 'Module class: X.Org Video Driver'
>>> /var/log/Xorg.0.log
>>> (II) Module fglrx: vendor="FireGL - ATI Technologies Inc."
>>>  compiled for 1.4.99.906, module version = 8.95.3
>>>  Module class: X.Org Video Driver
>>>
>>>
>>>
>>
>> Thank you for that.
>>
>> I have just ran it on this (Dell Inspire) desktop system running
>> Debian 6, to check it, and got
>>
>> "
>> :~$ grep -B2 'Module class: X.Org Video Driver' /var/log/Xorg.0.log
>> (II) Module nouveau: vendor="X.Org Foundation"
>>  compiled for 1.7.7, module version = 0.0.15
>>  Module class: X.Org Video Driver
>> --
>> (II) Module nv: vendor="X.Org Foundation"
>>  compiled for 1.7.7, module version = 2.1.17
>>  Module class: X.Org Video Driver
>> --
>> (II) Module vesa: vendor="X.Org Foundation"
>>  compiled for 1.7.7, module version = 2.3.0
>>  Module class: X.Org Video Driver
>> "
>>
>> and this system shows
>>
>> "
>> :~$ lspci | grep -i vga
>> 01:00.0 VGA compatible controller: nVidia Corporation GT218 [GeForce
>> 310] (rev a2)
>> "
>>
>> so I intend to run those two commands in each of the Ubuntu and Debian
>> installations on the Acer V3-772G system, tomorrow.
>>
>
>
> On the Acer V3-772G, for Ubuntu, I have
>
> "
> bret@bret-Aspire-V3-772:~$ grep -B2 'Module class: X.Org Video Driver'
> /var/log/Xorg.0.log
> [26.440] (II) Module intel: vendor="X.Org Foundation"
> [26.440]  compiled for 1.15.1, module version = 2.99.910
> [26.440]  Module class: X.Org Video Driver
> --
> [26.449] (II) Module nouveau: vendor="X.Org Foundation"
> [26.449]  compiled for 1.15.0, module version = 1.0.10
> [26.449]  Module class: X.Org Video Driver
> --
> [26.449] (II) Module modesetting: vendor="X.Org Foundation"
> [26.449]  compiled for 1.15.0, module version = 0.8.1
> [26.449]  Module class: X.Org Video Driver
> --
> [26.450] (II) Module fbdev: vendor="X.Org Foundation"
> [26.450]  compiled for 1.15.0, module version = 0.4.4
> [26.450]  Module class: X.Org Video Driver
> --
> [26.450] (II) Module vesa: vendor="X.Org Foundation"
> [26.450]  compiled for 1.15.0, module version = 2.3.3
> [26.450]  Module class: X.Org Video Driver
> --
> [26.450] (II) Module intel: vendor="X.Org Foundation"
> [26.450]  compiled for 1.15.1, module version = 2.99.910
> [26.450]  Module class: X.Org Video Driver
> --
> [26.450] (II) Module nouveau: vendor="X.Org Foundation"
> [26.450]  compiled for 1.15.0, module version = 1.0.10
> [26.450]  Module class: X.Org Video Driver
> --
> [26.451] (II) Module modesetting: vendor="X.Org Foundation"
> [26.451]  compiled for 1.15.0, module version = 0.8.1
> [26.451]  Module class: X.Org Video Driver
> --
> [26.451] (II) Module fbdev: vendor="X.Org Foundation"
> [26.451]  compiled for 1.15.0, module version = 0.4.4
> [26.451]  Module class: X.Org Video Driver
> --
> [26.451] (II) Module vesa: vendor="X.Org Foundation"
> [26.451]  compiled for 1.15.0, module version = 2.3.3
> [26.451]  Module class: X.Org Video Driver
> "
>
> and
>
> "
> bret@bret-Aspire-V3-772:~$  lspci | grep -i vga
> 00:02.0 VGA compatible controller: Intel Corporation 4th Gen Core
> Processor Integrated Graphics Controller (rev 06)
> "
>
> and in the ouput from sudo lshw, is
>
> "
>  *-pci
>   description: Host bridge
>   product: Xeon E3-1200 v3/4th Gen Core Processor DRAM Controller
>   vendor: Intel Corporation
>   physical id: 100
>   bus info: pci@:00:00.0
>   version: 06
>   width: 32 bits
>   clock: 33MHz
> *-pci:0
>  description: PCI bridge
>  product: Xeon E3-1200 v3/4th Gen Core Processor PCI
> Express x16 Controller
>  vendor: Intel Corporation
>  physical id: 1
>  bus info: pci@:00:01.0
>  version: 06
>  width: 32 bits
>  clock: 33MHz
>  capabilities: pci pm msi pciexpress normal_decode
> bus_master cap_list
>  configuration: driver=pcieport
>  resources: irq:40 ioport:4000(size=4096)
> memory:d200-d2ff ioport:a000(size=536870912)
>*-display
> description: 3D controller
> product: GK107M [GeForce GT 750M]
> vendor: NVIDIA Corporation
>

Re: Sharing LVM storage