Re: bash, dash and sh

[Peter Viskup]

Hi Jeremy,
not sure whether you are aware of checkbashisms tool (part of devscripts
package). That could help you to learn how to write POSIX compliant scripts.
Others helped you much more. :-)

On Thu, Apr 23, 2015 at 5:02 AM, jeremy bentham  wrote:

> I am finally abandonning my fifteen-year-old computer and Lenny
> for a six (?) year old used Gateway 2802 (as a Bad Consumer
> (tm) I never buy anything new if I can avoid it) and, right now,
> it has a start at Wheezy on it.
>
> I happened to read on another list, and then verified for myself,
> that /bin/sh is now a link to dash, instead of bash.
>
> If I
>
> cd /bin
> sudo rm sh; ln -s bash sh
>
> will I break a bunch of stuff?
>
> I have a bunch of scripts
>
> (ls -1 ~/bin | wc
>138   139   1302)
>
> with the first line #!/bin/sh that use bashisms, and the above
> would be a lot easier than editing each one (of course, maybe
> just editing each one would be easier than doing this ;-) ).
>
> --
> Dave WilliamsIn order to save you from the terrorists, we
> d...@eskimo.com   need to find out about your sex life.  And we've
>  got the technology to do it!
>
>
> --
> 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/20150423030228.GS14392@benny
>
>

Re: reading an empty directory after reboot is very slow

[Nicolas George]

Le tridi 3 floréal, an CCXXIII, David Wright a écrit :
> OK. Here's a demonstration of a file going AWOL by moving *up* the
> directory listing. Because of read-ahead, readdir still sees the old
> name and the stat() fails.

What are you trying to prove with that test?

You would get the same failure if you put your delay between readdir() and
stat(). And on a preemptive multitasking OS (or even worse: with
multiprocessing), that "delay" could be just the normal run time of the
program. That is called a race condition, I am sure you know it.

The Unix filesystem API has race conditions all over the place, everybody
knows it. To eliminate them would require an explicit transactional API, and
these cause a whole lot of problems of their own (deadlocks).

I do not see any merit in singling out this particular race condition above
all the others.

>Again, because of read-ahead, I can't
> demonstrate the opposite effect in the same program because
> you'd have to have a directory bigger than the read-ahead buffer
> in order to see any effect.

Please do. Creating a thousands of files takes only a few seconds; strace
can show you the calls to getdents() that lie underneath readdir() and tell
you how many entries are read at once.

> But, as was said already, it's occurrence
> can be discovered by checking the inode numbers for duplicate returns.

I am not convinced that occurrence happens.

I believe that the readdir() should offer the following guarantee over the
course of a single "opendir + full readdir loop":

  All entries that were present in the directory during the whole run are
  returned exactly once, under any of the names they had during the run.

And for now, I have not seen any indication that this property were
violated, i.e. the same entry shown twice or none at all.

(There may be a more subtle issue: what happens if file is renamed into
file file0042 while readdir() is scanning around file5000? Would "file0042"
be returned twice, but with different inode values?)

I remember someone asking what happens with backup programs. I do not see it
as an issue, for two reasons:

First, a carefully written backup program could just make a consistency
check at the end: if stat()ing any file failed with ENOENT, assume something
has moved and run again. But this is useless, because:

Second, the issue is much broader than that. Imagine you move the
"billion_dollars_project" directory from ~/experimental to ~/finished while
the backup program is running. If the backup program proceeds in that order:
~/finished, ~/music, ~/experimental, and the move happens while it is
scanning ~/music, then it never sees billion_dollars_project at all, and
never sees an error for it.

To make reliable backups, you need a way of getting the state of the full
tree atomically. Nowadays, that is done with filesystem snapshots. Unless
you use that, you have to assume that any file that was moved in any way
during the backup was moved the stupid way, i.e. first delete the source
then re-create the target.

Regards,

-- 
  Nicolas George


signature.asc
Description: Digital signature

Re: Grub is not showing after install debian on windows 8.1 laptop

[Pascal Hambourg]

Darac Marjal a écrit :
> On Wed, Apr 22, 2015 at 01:29:24PM +0800, ??? wrote:
>>I tried to install debian whizzey into my laptop which runs windows 8.1
>>now, and the last step i have chosen to install grub with mbr.
>>Then it asked me to reboot, after reboot, there is no grub and directly
>>launching the windows as normal.
>>Can anyone help?
>>How can i get the grub to be shown before windows is showing?
> 
> Likely your laptop is set to use "Secure Boot". Debian Wheezy (and even
> Jessie) does not support this. The easiest option is to disable "Secure
> Boot" in your firmware menu.

It won't be enough.
Secure boot is associated with native (U)EFI boot mode, whereas "install
grub with MBR" means that grub-pc was installed and must be booted in
BIOS/CSM/legacy mode instead of grub-efi. Thus you must disable the
whole UEFI native mode and enable CSM/legacy mode to be able to boot
grub-pc. And the multiboot won't work, you won't be able to boot a UEFI
Windows boot manager from grub-pc and vice versa.

Debian should have been installed with the installer booted in UEFI
mode, so grub-efi would have been installed.


-- 
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/5538a263.90...@plouf.fr.eu.org

Re: /etc/network/interfaces in jessie and systemd?

[Vincent Lefevre]

On 2015-04-22 14:20:00 +0200, Michael Biebl wrote:
> Am 22.04.2015 um 10:21 schrieb Vincent Lefevre:
> > On 2015-04-21 17:27:46 +0200, Michael Biebl wrote:
> >> The ifup@.service is triggered by a udev rule and responsible to handle
> >> allow-hotplug interfaces.
> > 
> > I hope that this will remain always optional. For a laptop at least,
> > that's not the correct way to do.
> 
> Are you advocating the use of auto over allow-hotplug

I'm not advocating the use of auto either. Well, auto is OK for "lo",
but my point is that neither auto nor allow-hotplug is OK for eth* or
wlan*, at least when the network can change (e.g. for a laptop).

> or the use of something enirely else, more dynamic, like
> network-manager?

Yes, something better than allow-hotplug, like the netplug package
(for eth*). I don't know how network-manager works; perhaps it can
do similar things?

The problem with allow-hotplug is that it makes the interface UP even
when the interface is not ready for that, e.g. when an Ethernet cable
is not plugged in. Waiting for an Ethernet link may be needed for the
configuration, e.g. when using "mapping" and "test peer ... mac ...".
Or when a laptop is moved from a network to another one, one may want
to have the scripts under /etc/network rerun when an Ethernet cable
is unplugged / plugged in, and things like that.

-- 
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/20150423080017.ga24...@xvii.vinc17.org

Re: reading an empty directory after reboot is very slow

[Vincent Lefevre]

On 2015-04-22 23:28:46 -0500, David Wright wrote:
> Quoting Vincent Lefevre (vinc...@vinc17.net):
> > On 2015-04-21 12:47:14 -0500, David Wright wrote:
> > > Quoting Vincent Lefevre (vinc...@vinc17.net):
> > > > This mailbox is constantly open in a Mutt running in screen (in
> > > > read-only mode). I often read it, and I modify it from time to time,
> > > > either by adding new messages in the usual way, or by modifying some
> > > > header of existing messages with some tool of mine (in which case, I
> > > > restart Mutt to take the changes into account).
> > > 
> > > I guess I find it hard (not knowing what all these emails are) to get
> > > my head around needing an email-style random access to 145k emails in
> > > one folder.
> > 
> > I can then do any filtering I like to search for an old e-mail
> > instead of having to look at several folders individually.
> 
> You have more of these folders with thousands of emails in them?

Only one. This is the goal: store old e-mail at only one place. In the
past, I was using several folders, but this was impracticable because
for mail messages would naturally belong to several folders, and some
searches (such as getting all messages from/to some e-mail address)
needed a search in all folders. I've used tagging instead of folders
since 2003[*], and this is much more practical.

[*] At that time, this archive mailbox was much smaller, with
something like 20k messages.

> > No, I don't use caches (the header cache is not enabled and the
> > ~/.mutt-cache directory doesn't exist).
> 
> My fault; I had forgotten that I myself added these settings to .muttrc.
> After all, that was probably in 1998.
> 
> In which case, if you want to know how come mutt is so fast, take a
> look at the source. Just to mention one optimisation I would consider:
> slurp the directory and sort the entries by inode. Open the files in
> inode order.
> And another: it's probably faster to slurp bigger chunks of each file
> (with an intelligent guess of the best buffer size) and use a fast
> search for \nMessage-ID rather than reading and checking line by line.

I'll try to do some tests, but I would say that this doesn't matter
since what takes all the time is the I/O: when everything is in the
(Linux-level) cache, both Mutt and my tool take a few seconds.

> > Only once for indexing. This is persistent after reboots and not
> > used by Mutt at all.
> 
> No, I wasn't expecting mutt to use mairix. But I thought you might be
> using it. Otherwise, why do you index them?

I use mairix when I need a "body" search first, otherwise such a
search would be awfully slow with Mutt. Then I can open the generated
folder with Mutt, and try to do more filtering to find what I want.

> I also wondered what the problem would be with putting the thousands
> of emails in a general purpose database.

But Mutt can't use such a database.

> Don't they search and retrieve faster than perl scripts?

I use Perl scripts only to update the mailbox (the tags), not for
searching.

-- 
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/20150423082200.gb24...@xvii.vinc17.org

Re: reading an empty directory after reboot is very slow

[Vincent Lefevre]

On 2015-04-22 23:30:49 -0500, David Wright wrote:
> Quoting Vincent Lefevre (vinc...@vinc17.net):
> > On 2015-04-21 10:35:12 -0600, Bob Proulx wrote:
> > > Vincent Lefevre wrote:
> > > > So, there's still something I don't understand: after dropping the
> > > > caches, why is Mutt fast to read the mailbox (about 1 minute), but
> > > > not my tool (about 30 minutes)?
> > > 
> > > Are you using mutt's header_cache feature?  It keeps a cache of mail
> > > files off to the side.  It really improves Maildir performance.  I
> > > personally also have maildir_header_cache_verify=no set too.
> > 
> > No, I don't use it. This variable doesn't even exist with my compiled
> > version.
> 
> OK, I'll ask. What *is* your version?

This is in my headers: Mutt/1.5.23-6425-vl-r76280 (2015-03-04) i.e.
based on the hg repo + some patches. The variables are mentioned by
the generated manual, but are not available, probably because I don't
configure Mutt with --enable-hcache (with my current use of Mutt,
I don't really need it, and it's safer without it).

-- 
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/20150423082641.gc24...@xvii.vinc17.org

Re: wheezy multiarch: binutils:amd64 conflicts with binutils:i386?

[Darac Marjal]

On Thu, Apr 23, 2015 at 12:54:47AM -0400, Tom Roche wrote:
> 
> summary: 3 questions:
> 
> 1. Can one install both `binutils:amd64` and `binutils:i386` on the same 
> device?

I don't believe so.

> 2. If one can: how? or, what am I doing wrong?
> 3. If one cannot: why not?

Multiarch works for libraries because the library-loading mechanism has
been modified to look for libraries in, for example,
/usr/lib// as well as the traditional /usr/lib/. That is,
a binary says "I need libfoo" and the loader finds a version for the
appropriate architecture.

However, a similar scheme does not exist for binaries. I *suppose* it
could be possible to have /usr/bin/ and symlink the
"native" archtecture's version to /usr/bin/, but A) you'd end up with a
lot of links there and B) that may well break things.

So, as it is, *binaries* conflict with each other (that is, only one
architecture can provide /usr/bin/foo), but libraries do not (you can
have /usr/lib/i386-linux-gnu/libfoo.so as well as /usr/lib/
x86_64-linux-gnu/libfoo.so on the same system).

> 
> details:
> 
> I need to setup a 32-bit app (don't ask!) on a 64-bit linode with

You might find a chroot a suitable alternative.



signature.asc
Description: Digital signature

Re: reading an empty directory after reboot is very slow

[Vincent Lefevre]

On 2015-04-22 23:06:47 -0500, David Wright wrote:
> Quoting Vincent Lefevre (vinc...@vinc17.net):
> > On 2015-04-21 11:05:58 -0500, David Wright wrote:
> > > Quoting Vincent Lefevre (vinc...@vinc17.net):
> > > > On 2015-04-20 13:04:41 -0500, David Wright wrote:
> > > > > Quoting Vincent Lefevre (vinc...@vinc17.net):
> > > > > > But with the current solution (no automatic moving of an
> > > > > > entry), you can't miss an entry that hasn't been removed.
> > > [...]
> > > > > ...so if you happen to be reading the entry for file5 at the
> > > > > time I typed mv, you'll get the entry for file4 twice, under
> > > > > two different names. (Or the opposite.)
> > > > 
> > > > OK, so, if the rename(2) system call can reorder the entries
> > > > (this is not quite clear because one doesn't see the empty
> > > > entries here),
> > > 
> > > No, and you wouldn't *normally* see them with readdir, I'd suppose.
> > 
> > But this matters for the implementation in the kernel.
> 
> What's "this". And what does it matter? You make some system calls,
> and you get replies. They come out of a black box.

I mean: to know what is done internally in order to prove that there
is a problem. Otherwise you need to provide a test based on readdir,
not on the "ls -lU ..." output, which contains incomplete information
(because the kernel has more information, which could be used by the
implementation of readdir).

[...]
> So you don't believe the problem when it's demonstrated,

What I'm saying is that you haven't demonstrating anything: you showed
some "ls -lU ..." output, but did not say what was done internally by
the kernel. So, the readdir test as you have now done below was
necessary.

> but you do believe some hypotheticals you just made up.

I do not believe that. I've just said that this was a possibility.

> Ask yourself why an efficient filesystem would move a load of
> directory entries just because someone renamed a file.

First I wonder why such an efficient filesystem moves a directory
entry while this is not needed. With your example:

drwxr-x--- 2 david david 4096 Apr 21 10:58 file1
drwxr-x--- 2 david david 4096 Apr 21 10:58 file4
drwxr-x--- 2 david david 4096 Apr 21 10:58 file5
drwxr-x--- 2 david david 4096 Apr 21 10:58 file6
drwxr-x--- 2 david david 4096 Apr 21 10:58 file2
drwxr-x--- 2 david david 4096 Apr 21 10:58 file3

becomes

drwxr-x--- 2 david david 4096 Apr 21 10:58 file1
drwxr-x--- 2 david david 4096 Apr 21 10:58 file4
drwxr-x--- 2 david david 4096 Apr 21 10:58 file5
drwxr-x--- 2 david david 4096 Apr 21 10:58 
file3file3file3file3file3file3file3file3file3file3file3file3file3
drwxr-x--- 2 david david 4096 Apr 21 10:58 file6
drwxr-x--- 2 david david 4096 Apr 21 10:58 file2

after the rename, while I would have expected:

drwxr-x--- 2 david david 4096 Apr 21 10:58 file1
drwxr-x--- 2 david david 4096 Apr 21 10:58 file4
drwxr-x--- 2 david david 4096 Apr 21 10:58 file5
drwxr-x--- 2 david david 4096 Apr 21 10:58 file6
drwxr-x--- 2 david david 4096 Apr 21 10:58 file2
drwxr-x--- 2 david david 4096 Apr 21 10:58 
file3file3file3file3file3file3file3file3file3file3file3file3file3

So, the kernel is doing non-trivial things.

> > What actually needs to be done is a real test
> > using readdir.
> 
> OK. Here's a demonstration of a file going AWOL by moving *up* the
> directory listing. Because of read-ahead, readdir still sees the old
> name and the stat() fails. Again, because of read-ahead, I can't
> demonstrate the opposite effect in the same program because
> you'd have to have a directory bigger than the read-ahead buffer
> in order to see any effect. But, as was said already, it's occurrence
> can be discovered by checking the inode numbers for duplicate returns.
> 
> I scan the directory with readdir, then stat the file to obtain its
> inode number. E is stat's return code, I is inode number.
> When the latter matches 497051, I sleep for 5 seconds so that
> another process can rename a file.
> 
> ~ $ for j in 1 2 3 4 5 6 ; do mkdir /tmp/testdir/file$j ; done
> 
> ~ $ /tmp/a.out /tmp/testdir/ ← before doing anything
> 1 E: 0 I: 496992 file1
> 2 E: 0 I: 497007 file4
> 3 E: 0 I: 497039 file5
> 4 E: 0 I: 488682 .
> 5 E: 0 I: 497051 file6
> sleeping ← I give myself 5 seconds to do something
> 6 E: 0 I: 488641 ..
> 7 E: 0 I: 497003 file2
> 8 E: 0 I: 497006 file3
> 
> ~ $ /tmp/a.out /tmp/testdir/ ← during the alteration
> 1 E: 0 I: 496992 file1
> 2 E: 0 I: 497007 file4
> 3 E: 0 I: 497039 file5
> 4 E: 0 I: 488682 .
> 5 E: 0 I: 497051 file6
> sleeping← here I renamed file2 (in another xterm)
> 6 E: 0 I: 488641 ..
> 7 E: -1 I: 488641 file2 ← oops, file2 stat() fails (so the inode number is 
> untouched from the previous call)
> 8 E: 0 I: 497006 file3
> 
> ~ $ /tmp/a.out /tmp/testdir/ ← after the alteration
> 1 E: 0 I: 496992 file1
> 2 E: 0 I: 497007 file4
> 3 E: 0 I: 497039 file5
> 4 E: 0 I: 488682 .
> 5 E: 0 I: 497003 
> file2file2file2file2file2file2file2file2file2file2file2file2file2file2 ← here 
> it is
> 6 

Re: reading an empty directory after reboot is very slow

[Vincent Lefevre]

On 2015-04-23 09:13:02 +0200, Nicolas George wrote:
> Le tridi 3 floréal, an CCXXIII, David Wright a écrit :
> > OK. Here's a demonstration of a file going AWOL by moving *up* the
> > directory listing. Because of read-ahead, readdir still sees the old
> > name and the stat() fails.
> 
> What are you trying to prove with that test?
> 
> You would get the same failure if you put your delay between readdir() and
> stat(). And on a preemptive multitasking OS (or even worse: with
> multiprocessing), that "delay" could be just the normal run time of the
> program. That is called a race condition, I am sure you know it.

David's test was to show what could happen in practice after some
simple change, such as removing objects from the directory, not to
take care of all possible race conditions (which is not possible,
except by checking them afterwards, e.g. by looking at the mtime of
the directory, though I'm not even sure that this is reliable).

[...]
> I believe that the readdir() should offer the following guarantee over the
> course of a single "opendir + full readdir loop":
> 
>   All entries that were present in the directory during the whole run are
>   returned exactly once, under any of the names they had during the run.
> 
> And for now, I have not seen any indication that this property were
> violated, i.e. the same entry shown twice or none at all.

David's test shows that the renamed file is missed.

[...]
> To make reliable backups, you need a way of getting the state of the full
> tree atomically. Nowadays, that is done with filesystem snapshots. Unless
> you use that, you have to assume that any file that was moved in any way
> during the backup was moved the stupid way, i.e. first delete the source
> then re-create the target.

I agree, but this needs support from the filesystem itself.

-- 
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/20150423091955.ge24...@xvii.vinc17.org

Re: reading an empty directory after reboot is very slow

[Nicolas George]

Le quartidi 4 floréal, an CCXXIII, Vincent Lefevre a écrit :
> David's test was to show what could happen in practice after some
> simple change, such as removing objects from the directory, not to
> take care of all possible race conditions

Simple changes are the bricks for race conditions.

>   (which is not possible,
> except by checking them afterwards, e.g. by looking at the mtime of
> the directory, though I'm not even sure that this is reliable).

It is not, depending on your actual goal.

> David's test shows that the renamed file is missed.

No, it shows that the renamed file is NOT missed: he renamed the entry for
inode 497003 from file2 into a long name, and that entry is returned,
exactly once, under its old name. The "oops, file2 stat() fails" only shows
the race condition between readdir() return and stat(); I am sure that if he
printed dirent.d_ino instead of stat.st_ino, it would have printed 497003.

> I agree, but this needs support from the filesystem itself.

That would not be enough. Reliable backups require application support. Just
think of all the Vim swap files or the temp file just before an atomic
update. But that is another discussion.

Regards,

-- 
  Nicolas George


signature.asc
Description: Digital signature

Re: reading an empty directory after reboot is very slow

[Vincent Lefevre]

On 2015-04-23 11:31:27 +0200, Nicolas George wrote:
> Le quartidi 4 floréal, an CCXXIII, Vincent Lefevre a écrit :
> > David's test shows that the renamed file is missed.
> 
> No, it shows that the renamed file is NOT missed: he renamed the entry for
> inode 497003 from file2 into a long name, and that entry is returned,
> exactly once, under its old name. The "oops, file2 stat() fails" only shows
> the race condition between readdir() return and stat(); I am sure that if he
> printed dirent.d_ino instead of stat.st_ino, it would have printed 497003.

I only focused on the inode number and I thought that David's test was
printing dirent.d_ino (which was the obvious thing to do). Now, after
re-reading carefully what he said:

  "I scan the directory with readdir, then stat the file to obtain its
   ^^^
   inode number."
   

Indeed, this is the wrong way to do!

So, there's a need for a new test.

BTW, in Perl, readdir only returns the filename, but I suppose that
this isn't a problem and that one still gets all the directory entries:
in case of rename, one should be aware that the filename corresponds
either to the old name or to the new name, and it's up to the script
to handle race conditions if need be, depending on the context.

> > I agree, but this needs support from the filesystem itself.
> 
> That would not be enough. Reliable backups require application support. Just
> think of all the Vim swap files or the temp file just before an atomic
> update. But that is another discussion.

Yes, one may see a temp file instead of the real file, but data
are not lost. Applications should be able to detect that (this can
also happen after a power failure, so that this is not specific to
backups).

-- 
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/20150423100430.ga29...@xvii.vinc17.org

Re: Need help fixing an unhandled irq

[claude juif]

Hi,

Did the mouse lags occurs on all usb port ? Because you lspci return usb1
on IRQ16 and usb2 on IRQ23.

So if your problem is related to IRQ16, changing USB port might resolv the
problem. If the problem still there, i guess IRQ16 have nothing to do with
your mouse lags.

Regards,

2015-04-22 17:33 GMT+02:00 Kynn Jones :

> On Tue, Apr 21, 2015 at 9:49 PM, Kynn Jones  wrote:
>
> > OK, I found a way to turn off one of the two snd_hda_intel,
> > but it turned out to be the one on IRQ 45.  (In any case,
> > doing this did not solve the problem.)  The method I used was
>
> > 1. find the prefix of the audio device(s) in the output of lspci
> > 2. search for a path under /sys/devices with this prefix in the basename
> > 3. add a line of the form
>
> > echo 1 > /path/found/in/previous/step/remove
>
> > When did step (1) I found two candidate prefixes 00:03.0 and 00.1b.0,
> from the lines
>
> > 00:03.0 Audio device: Intel Corporation Haswell HD Audio Controller
> (rev 06)
> > 00:1b.0 Audio device: Intel Corporation Lynx Point High Definition
> Audio Controller (rev 04)
>
> > but in step (2) I was able to find only one matching path, namely
>
> > /sys/devices/pci:00/:00:1b.0
>
> Correction: when I looked again I did find a file for 00.03.0:
>
>/sys/devices/pci:00/:00:03.0
>
> I'm not sure why I missed it the first time.
>
> > I went ahead and added the line
>
> > echo 1 > /sys/devices/pci:00/:00:1b.0/remove
>
> > to /etc/rc.local, and rebooted.
>
> I repeated the same thing once more with this line instead:
>
> echo 1 > /sys/devices/pci:00/:00:03.0/remove
>
> ...and now after rebooting the IRQ 16 line of /proc/interrupts
> shows only one driver:
>
> # grep '^ 16:' /proc/interrupts
>  16:   1211  0  0  0  IR-IO-APIC-fasteoi
> ehci_hcd:usb1
>
> But, unfortunately, this turned out to be a red herring: the
> unhandled IRQ 16 error continues to happen, and along with it the
> mouse that, as it were, "wakes drunk from sleep".  (At least the
> system's sound continues to work fine, AFAICT.)
>
> Now it looks like the problem is with the ehci_hcd driver.
>
> In this case, I don't think that disabling the driver is an
> option, so I decided to send a full bug report to the
> debian-kernel list, here:
>
> https://lists.debian.org/debian-kernel/2015/04/msg00348.html
>
> Putting aside the main issue (the problem with the mouse) I now
> have the additional (but far less pressing) question of which of
> the two instances of snd_hda_intel I should keep around?
>
> kj
>
>

Re: Need help fixing an unhandled irq

[Kynn Jones]

Thanks for your comment.

It turns out that unhandled IRQ16 happens irrespective of which USB port
the mouse is connected to, or even if the mouse is connected at all at the
time the system goes to sleep (in the latter case, when the mouse is
re-connected, it still shows the same lag).  (I posted about this in the
bug report I sent: https://bugzilla.kernel.org/show_bug.cgi?id=97131)

I think the mouse here is an "innocent bystander caught in the crossfire" :)

kj

On Thu, Apr 23, 2015 at 6:25 AM, claude juif  wrote:

> Hi,
>
> Did the mouse lags occurs on all usb port ? Because you lspci return usb1
> on IRQ16 and usb2 on IRQ23.
>
> So if your problem is related to IRQ16, changing USB port might resolv the
> problem. If the problem still there, i guess IRQ16 have nothing to do with
> your mouse lags.
>
> Regards,
>
> 2015-04-22 17:33 GMT+02:00 Kynn Jones :
>
>> On Tue, Apr 21, 2015 at 9:49 PM, Kynn Jones  wrote:
>>
>> > OK, I found a way to turn off one of the two snd_hda_intel,
>> > but it turned out to be the one on IRQ 45.  (In any case,
>> > doing this did not solve the problem.)  The method I used was
>>
>> > 1. find the prefix of the audio device(s) in the output of lspci
>> > 2. search for a path under /sys/devices with this prefix in the basename
>> > 3. add a line of the form
>>
>> > echo 1 > /path/found/in/previous/step/remove
>>
>> > When did step (1) I found two candidate prefixes 00:03.0 and 00.1b.0,
>> from the lines
>>
>> > 00:03.0 Audio device: Intel Corporation Haswell HD Audio Controller
>> (rev 06)
>> > 00:1b.0 Audio device: Intel Corporation Lynx Point High Definition
>> Audio Controller (rev 04)
>>
>> > but in step (2) I was able to find only one matching path, namely
>>
>> > /sys/devices/pci:00/:00:1b.0
>>
>> Correction: when I looked again I did find a file for 00.03.0:
>>
>>/sys/devices/pci:00/:00:03.0
>>
>> I'm not sure why I missed it the first time.
>>
>> > I went ahead and added the line
>>
>> > echo 1 > /sys/devices/pci:00/:00:1b.0/remove
>>
>> > to /etc/rc.local, and rebooted.
>>
>> I repeated the same thing once more with this line instead:
>>
>> echo 1 > /sys/devices/pci:00/:00:03.0/remove
>>
>> ...and now after rebooting the IRQ 16 line of /proc/interrupts
>> shows only one driver:
>>
>> # grep '^ 16:' /proc/interrupts
>>  16:   1211  0  0  0
>> IR-IO-APIC-fasteoi   ehci_hcd:usb1
>>
>> But, unfortunately, this turned out to be a red herring: the
>> unhandled IRQ 16 error continues to happen, and along with it the
>> mouse that, as it were, "wakes drunk from sleep".  (At least the
>> system's sound continues to work fine, AFAICT.)
>>
>> Now it looks like the problem is with the ehci_hcd driver.
>>
>> In this case, I don't think that disabling the driver is an
>> option, so I decided to send a full bug report to the
>> debian-kernel list, here:
>>
>> https://lists.debian.org/debian-kernel/2015/04/msg00348.html
>>
>> Putting aside the main issue (the problem with the mouse) I now
>> have the additional (but far less pressing) question of which of
>> the two instances of snd_hda_intel I should keep around?
>>
>> kj
>>
>>
>

Re: Need help fixing an unhandled irq

[claude juif]

By the way, have you tried to boot with irqpoll as the kernel says ?

And i suppose you use wheezy according to your kernel (3.2.65) version, so
did you try to upgrade kernel from backport (3.16.7) ?

2015-04-23 14:26 GMT+02:00 Kynn Jones :

> Thanks for your comment.
>
> It turns out that unhandled IRQ16 happens irrespective of which USB port
> the mouse is connected to, or even if the mouse is connected at all at the
> time the system goes to sleep (in the latter case, when the mouse is
> re-connected, it still shows the same lag).  (I posted about this in the
> bug report I sent: https://bugzilla.kernel.org/show_bug.cgi?id=97131)
>
> I think the mouse here is an "innocent bystander caught in the crossfire"
> :)
>
> kj
>
> On Thu, Apr 23, 2015 at 6:25 AM, claude juif 
> wrote:
>
>> Hi,
>>
>> Did the mouse lags occurs on all usb port ? Because you lspci return usb1
>> on IRQ16 and usb2 on IRQ23.
>>
>> So if your problem is related to IRQ16, changing USB port might resolv
>> the problem. If the problem still there, i guess IRQ16 have nothing to do
>> with your mouse lags.
>>
>> Regards,
>>
>> 2015-04-22 17:33 GMT+02:00 Kynn Jones :
>>
>>> On Tue, Apr 21, 2015 at 9:49 PM, Kynn Jones  wrote:
>>>
>>> > OK, I found a way to turn off one of the two snd_hda_intel,
>>> > but it turned out to be the one on IRQ 45.  (In any case,
>>> > doing this did not solve the problem.)  The method I used was
>>>
>>> > 1. find the prefix of the audio device(s) in the output of lspci
>>> > 2. search for a path under /sys/devices with this prefix in the
>>> basename
>>> > 3. add a line of the form
>>>
>>> > echo 1 > /path/found/in/previous/step/remove
>>>
>>> > When did step (1) I found two candidate prefixes 00:03.0 and 00.1b.0,
>>> from the lines
>>>
>>> > 00:03.0 Audio device: Intel Corporation Haswell HD Audio
>>> Controller (rev 06)
>>> > 00:1b.0 Audio device: Intel Corporation Lynx Point High Definition
>>> Audio Controller (rev 04)
>>>
>>> > but in step (2) I was able to find only one matching path, namely
>>>
>>> > /sys/devices/pci:00/:00:1b.0
>>>
>>> Correction: when I looked again I did find a file for 00.03.0:
>>>
>>>/sys/devices/pci:00/:00:03.0
>>>
>>> I'm not sure why I missed it the first time.
>>>
>>> > I went ahead and added the line
>>>
>>> > echo 1 > /sys/devices/pci:00/:00:1b.0/remove
>>>
>>> > to /etc/rc.local, and rebooted.
>>>
>>> I repeated the same thing once more with this line instead:
>>>
>>> echo 1 > /sys/devices/pci:00/:00:03.0/remove
>>>
>>> ...and now after rebooting the IRQ 16 line of /proc/interrupts
>>> shows only one driver:
>>>
>>> # grep '^ 16:' /proc/interrupts
>>>  16:   1211  0  0  0
>>> IR-IO-APIC-fasteoi   ehci_hcd:usb1
>>>
>>> But, unfortunately, this turned out to be a red herring: the
>>> unhandled IRQ 16 error continues to happen, and along with it the
>>> mouse that, as it were, "wakes drunk from sleep".  (At least the
>>> system's sound continues to work fine, AFAICT.)
>>>
>>> Now it looks like the problem is with the ehci_hcd driver.
>>>
>>> In this case, I don't think that disabling the driver is an
>>> option, so I decided to send a full bug report to the
>>> debian-kernel list, here:
>>>
>>> https://lists.debian.org/debian-kernel/2015/04/msg00348.html
>>>
>>> Putting aside the main issue (the problem with the mouse) I now
>>> have the additional (but far less pressing) question of which of
>>> the two instances of snd_hda_intel I should keep around?
>>>
>>> kj
>>>
>>>
>>
>

Re: Need help fixing an unhandled irq

[Kynn Jones]

I did boot with irqpoll, and indeed the unhandled interrupt does not occur,
but my understanding is that the irqpoll option is a temporary measure
(maybe to get past anotherwise fatal unhandled interrupt), but not a
permanent fix.  (Because it is inefficient for the kernel to perform such
polling?  I'm not sure.)

I have not tried the upgrade kernel from backport.  I'll give that a shot.
Thanks!


On Thu, Apr 23, 2015 at 8:46 AM, claude juif  wrote:

> By the way, have you tried to boot with irqpoll as the kernel says ?
>
> And i suppose you use wheezy according to your kernel (3.2.65) version, so
> did you try to upgrade kernel from backport (3.16.7) ?
>
> 2015-04-23 14:26 GMT+02:00 Kynn Jones :
>
>> Thanks for your comment.
>>
>> It turns out that unhandled IRQ16 happens irrespective of which USB port
>> the mouse is connected to, or even if the mouse is connected at all at the
>> time the system goes to sleep (in the latter case, when the mouse is
>> re-connected, it still shows the same lag).  (I posted about this in the
>> bug report I sent: https://bugzilla.kernel.org/show_bug.cgi?id=97131)
>>
>> I think the mouse here is an "innocent bystander caught in the crossfire"
>> :)
>>
>> kj
>>
>> On Thu, Apr 23, 2015 at 6:25 AM, claude juif 
>> wrote:
>>
>>> Hi,
>>>
>>> Did the mouse lags occurs on all usb port ? Because you lspci return
>>> usb1 on IRQ16 and usb2 on IRQ23.
>>>
>>> So if your problem is related to IRQ16, changing USB port might resolv
>>> the problem. If the problem still there, i guess IRQ16 have nothing to do
>>> with your mouse lags.
>>>
>>> Regards,
>>>
>>> 2015-04-22 17:33 GMT+02:00 Kynn Jones :
>>>
 On Tue, Apr 21, 2015 at 9:49 PM, Kynn Jones  wrote:

 > OK, I found a way to turn off one of the two snd_hda_intel,
 > but it turned out to be the one on IRQ 45.  (In any case,
 > doing this did not solve the problem.)  The method I used was

 > 1. find the prefix of the audio device(s) in the output of lspci
 > 2. search for a path under /sys/devices with this prefix in the
 basename
 > 3. add a line of the form

 > echo 1 > /path/found/in/previous/step/remove

 > When did step (1) I found two candidate prefixes 00:03.0 and 00.1b.0,
 from the lines

 > 00:03.0 Audio device: Intel Corporation Haswell HD Audio
 Controller (rev 06)
 > 00:1b.0 Audio device: Intel Corporation Lynx Point High
 Definition Audio Controller (rev 04)

 > but in step (2) I was able to find only one matching path, namely

 > /sys/devices/pci:00/:00:1b.0

 Correction: when I looked again I did find a file for 00.03.0:

/sys/devices/pci:00/:00:03.0

 I'm not sure why I missed it the first time.

 > I went ahead and added the line

 > echo 1 > /sys/devices/pci:00/:00:1b.0/remove

 > to /etc/rc.local, and rebooted.

 I repeated the same thing once more with this line instead:

 echo 1 > /sys/devices/pci:00/:00:03.0/remove

 ...and now after rebooting the IRQ 16 line of /proc/interrupts
 shows only one driver:

 # grep '^ 16:' /proc/interrupts
  16:   1211  0  0  0
 IR-IO-APIC-fasteoi   ehci_hcd:usb1

 But, unfortunately, this turned out to be a red herring: the
 unhandled IRQ 16 error continues to happen, and along with it the
 mouse that, as it were, "wakes drunk from sleep".  (At least the
 system's sound continues to work fine, AFAICT.)

 Now it looks like the problem is with the ehci_hcd driver.

 In this case, I don't think that disabling the driver is an
 option, so I decided to send a full bug report to the
 debian-kernel list, here:

 https://lists.debian.org/debian-kernel/2015/04/msg00348.html

 Putting aside the main issue (the problem with the mouse) I now
 have the additional (but far less pressing) question of which of
 the two instances of snd_hda_intel I should keep around?

 kj


>>>
>>
>

Re: reading an empty directory after reboot is very slow

[David Wright]

Quoting Vincent Lefevre (vinc...@vinc17.net):
> On 2015-04-22 23:28:46 -0500, David Wright wrote:
> > No, I wasn't expecting mutt to use mairix. But I thought you might be
> > using it. Otherwise, why do you index them?
> 
> I use mairix when I need a "body" search first, otherwise such a
> search would be awfully slow with Mutt. Then I can open the generated
> folder with Mutt, and try to do more filtering to find what I want.

I was under the impression that mairix could do both.

> > I also wondered what the problem would be with putting the thousands
> > of emails in a general purpose database.
> 
> But Mutt can't use such a database.

I was thinking of a scenario where you retrieve the matching emails
and place them in a scratch directory, then run mutt on that folder
so you can still read the results with an email interface.
Of course I have no idea whether you're trying to match a few emails
or thousands at a time.

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/20150423151054.GA8639@alum

Re: reading an empty directory after reboot is very slow

[David Wright]

Quoting Nicolas George (geo...@nsup.org):
> Le tridi 3 floréal, an CCXXIII, David Wright a écrit :
> > OK. Here's a demonstration of a file going AWOL by moving *up* the
> > directory listing. Because of read-ahead, readdir still sees the old
> > name and the stat() fails.
> 
> What are you trying to prove with that test?

With respect, if you read the thread, you'd know. In fact, just read
the post ("P") you've commented on. It's in the penultimate paragraph.

> You would get the same failure if you put your delay between readdir() and
> stat(). And on a preemptive multitasking OS (or even worse: with
> multiprocessing), that "delay" could be just the normal run time of the
> program. That is called a race condition, I am sure you know it.

Yes, I know it. I'm trying to demonstrate it.

> The Unix filesystem API has race conditions all over the place, everybody
> knows it. To eliminate them would require an explicit transactional API, and
> these cause a whole lot of problems of their own (deadlocks).
> 
> I do not see any merit in singling out this particular race condition above
> all the others.

Because refuting an argument only requires one counterexample. I'm not
trying to write a guide to systems programming, you know.

> >  Again, because of read-ahead, I can't
> > demonstrate the opposite effect in the same program because
> > you'd have to have a directory bigger than the read-ahead buffer
> > in order to see any effect.
> 
> Please do. Creating a thousands of files takes only a few seconds; strace
> can show you the calls to getdents() that lie underneath readdir() and tell
> you how many entries are read at once.

As the last sentence of "P" said: "Why should I care?".

getdents read many entries at a time. AFAICT it requires a buffer to
put them in. AFAICT you don't know a priori how long to make that
buffer to get all the entries in one call (a 32KB buffer takes 2
calls to read my /usr/share/doc/). So don't you just push the problem
one level down? I don't know. You tell me.

> > But, as was said already, it's occurrence
> > can be discovered by checking the inode numbers for duplicate returns.
> 
> I am not convinced that occurrence happens.
> 
> I believe that the readdir() should offer the following guarantee over the
> course of a single "opendir + full readdir loop":
> 
>   All entries that were present in the directory during the whole run are
>   returned exactly once, under any of the names they had during the run.

Is that a quotation? Where from?

> And for now, I have not seen any indication that this property were
> violated, i.e. the same entry shown twice or none at all.
> 
> (There may be a more subtle issue: what happens if file is renamed into
> file file0042 while readdir() is scanning around file5000? Would "file0042"
> be returned twice, but with different inode values?)

You really haven't read the thread, have you.

> I remember someone asking what happens with backup programs.

Yes, I quoted it in "P".

> I do not see it
> as an issue, for two reasons:
> 
> First, a carefully written backup program could just make a consistency
> check at the end: if stat()ing any file failed with ENOENT, assume something
> has moved and run again.

Yes, that's in "P". Vincent brought up the looping problem.

> But this is useless, because:
> 
> Second, the issue is much broader than that. Imagine you move the
> "billion_dollars_project" directory from ~/experimental to ~/finished while
> the backup program is running. If the backup program proceeds in that order:
> ~/finished, ~/music, ~/experimental, and the move happens while it is
> scanning ~/music, then it never sees billion_dollars_project at all, and
> never sees an error for it.

Yes, but I was showing that that can happen even without moving directory.

> To make reliable backups, you need a way of getting the state of the full
> tree atomically. Nowadays, that is done with filesystem snapshots. Unless
> you use that, you have to assume that any file that was moved in any way
> during the backup was moved the stupid way, i.e. first delete the source
> then re-create the target.

Yes, but I know nothing about doing all that. As I said in the last
sentence of the antepenultimate paragraph of "P", "But don't expect me
to come up with a bullet-proof scheme."

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/20150423160052.GB8639@alum

Re: reading an empty directory after reboot is very slow

[David Wright]

Quoting Vincent Lefevre (vinc...@vinc17.net):
> On 2015-04-23 11:31:27 +0200, Nicolas George wrote:
> > Le quartidi 4 floréal, an CCXXIII, Vincent Lefevre a écrit :
> > > David's test shows that the renamed file is missed.
> > 
> > No, it shows that the renamed file is NOT missed: he renamed the entry for
> > inode 497003 from file2 into a long name, and that entry is returned,
> > exactly once, under its old name. The "oops, file2 stat() fails" only shows
> > the race condition between readdir() return and stat(); I am sure that if he
> > printed dirent.d_ino instead of stat.st_ino, it would have printed 497003.

Yes, it would. See below as to why I printed the stat() version.

But actually, the answer is no. dirent.d_ino could fail as well.
readdir is not thread-safe so the dirent could get clobbered between
the call to readdir and printing it.

> I only focused on the inode number and I thought that David's test was
> printing dirent.d_ino (which was the obvious thing to do). Now, after
> re-reading carefully what he said:
> 
>   "I scan the directory with readdir, then stat the file to obtain its
>^^^
>inode number."
>
> 
> Indeed, this is the wrong way to do!

Well, the program I filched, because filch it I did, printed more
*interesting* stuff about the file, stuff like the size etc.
I switched it to printing the (to most people, boring) inode number
because, *for the purpose of this exercise*, the inode number acts as
a unique identifier for a file which has just changed name.

I guess if you only even scan directories to admire the interesting
numbers, then leave stat alone and enjoy the delicious delights of dirents!

> So, there's a need for a new test.

Feel free to write it.

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/20150423162211.GC8639@alum

Re: Debian 7 and external monitors and graphics adaptors

[Chris Bannister]

On Tue, Apr 21, 2015 at 03:35:13PM -0500, David Wright wrote:
> Quoting Chris Bannister (cbannis...@slingshot.co.nz):
> > On Sun, Apr 19, 2015 at 04:03:37PM +, Curt wrote:
> > > On 2015-04-19, Cindy-Sue Causey  wrote:
> > > >
> > > > With this many others of us not having any problems on multiple
> > > > various browsers, I wonder what (other) secondary things might be
> > > 
> > > 2 is 'many' in your book?
> > 
> > Don't confuse primary and secondary with counting. Think 'primary =
> > main' and 'secondary = subsidary' for example. 'There could be a number
> > of primary concerns' is a valid English sentence.
> 
> I don't think you and I are interpreting "2" in the same manner.
> Curt has counted the number of general successes from people (other
> than me), ie Lisi and Cindy-Sue. Hence his surprise at Cindy-Sue's
> phrase "this many others of us".

LOL, I was equating Curt's 2 with Cundy-Sue's secondary. 
Apologies to Curt for the strange reply. 

-- 
"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/20150423164527.GB3300@tal

Re: reading an empty directory after reboot is very slow

[David Wright]

Quoting Vincent Lefevre (vinc...@vinc17.net):
> On 2015-04-22 23:06:47 -0500, David Wright wrote:
> > Quoting Vincent Lefevre (vinc...@vinc17.net):
> > > On 2015-04-21 11:05:58 -0500, David Wright wrote:
> > > > Quoting Vincent Lefevre (vinc...@vinc17.net):
> > > > > On 2015-04-20 13:04:41 -0500, David Wright wrote:
> > > > > > Quoting Vincent Lefevre (vinc...@vinc17.net):
> > > > > > > But with the current solution (no automatic moving of an
> > > > > > > entry), you can't miss an entry that hasn't been removed.
> > > > [...]
> > > > > > ...so if you happen to be reading the entry for file5 at the
> > > > > > time I typed mv, you'll get the entry for file4 twice, under
> > > > > > two different names. (Or the opposite.)
> > > > > 
> > > > > OK, so, if the rename(2) system call can reorder the entries
> > > > > (this is not quite clear because one doesn't see the empty
> > > > > entries here),
> > > > 
> > > > No, and you wouldn't *normally* see them with readdir, I'd suppose.
> > > 
> > > But this matters for the implementation in the kernel.
> > 
> > What's "this". And what does it matter? You make some system calls,
> > and you get replies. They come out of a black box.
> 
> I mean: to know what is done internally in order to prove that there
> is a problem. Otherwise you need to provide a test based on readdir,
> not on the "ls -lU ..." output, which contains incomplete information
> (because the kernel has more information, which could be used by the
> implementation of readdir).
> 
> [...]
> > So you don't believe the problem when it's demonstrated,
> 
> What I'm saying is that you haven't demonstrating anything: you showed
> some "ls -lU ..." output, but did not say what was done internally by
> the kernel. So, the readdir test as you have now done below was
> necessary.

Well, I'm assuming that ls -U is honest, and it really doesn't shuffle
the order that it receives from the filesystem.

> > Ask yourself why an efficient filesystem would move a load of
> > directory entries just because someone renamed a file.
> 
> First I wonder why such an efficient filesystem moves a directory
> entry while this is not needed. With your example:

It is needed. With the naive directory structure (a simple list), you
can't put a long string where a short string was.

> So, the kernel is doing non-trivial things.

[test snipped]

> Thanks for this test. I have two remarks:
> 
> 1. I'm wondering why the kernel moves a renamed directory entry instead
> of just modifying it. For easier recovery in case of serious problem
> (hardware failure, kernel crash...)?

[hashing snipped]

> Do you know why it is doing this? To retrieve a file faster via the
> hash, by starting at the "right" place instead of the beginning of
> the directory?

You answered it yourself.

> I suppose that this would work well only when there
> is only one block (small directories), otherwise things get messed
> up after that.

I think they do better than that!

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/20150423163903.GD8639@alum

Re: boot-time messages, /init touch not found

[songbird]

songbird wrote:
> Mike Kupfer wrote:
>
>> Hi, after updating a jessie VM, I noticed a message during boot, before
>> lightdm started.  The message was something like
>>
>>   /init [stuff I didn't catch] touch: not found
>>
>> After logging in, I tried using journalctl to find the message, with no
>> success.  Is journalctl the right tool to find the message?  If not,
>> what is?
>
>   Mike, i'm not running a VM and have the same 
> message showing up.
>
>   it is in the early boot stage so you might need
> some other way to capture the message, there used
> to be a package called bootlog, but i don't know
> how well it works with systemd.

  installed the package bootlogd and so output should
show up in /var/log/boot, but that file remains empty.


/init: 401: /init: touch: not found...


>   doesn't seem to be affecting anything or preventing
> my system from coming up so i've ignore it until i
> saw your note.  likely someone changed a script in 
> the early boot process that now uses the command 
> touch when it should not be assumed to exist yet...

  that's as far as i've gotten.


  songbird


-- 
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/4umn0c-581@id-306963.user.uni-berlin.de

Unable to install owncloud-client in wheezy

[Peter Ley]

Hi all,

I'm trying to install owncloud-client-cmd in wheezy and I get the
following:
--
Reading package lists... Done
Building dependency tree   
Reading state information... Done
Some packages could not be installed. This may mean that you have
requested an impossible situation or if you are using the unstable
distribution that some required packages have not yet been created
or been moved out of Incoming.
The following information may help to resolve the situation:

The following packages have unmet dependencies:
 owncloud-client-cmd : Depends: libowncloudsync0 (= 1.5.0+dfsg-4~bpo70+1) but 
it is not going to be installed
   Depends: libocsync0 (>= 0.91.0) but it is not installable
E: Unable to correct problems, you have held broken packages.
--

The output of 'apt-cache policy libocsync0':
--
libocsync0:
  Installed: (none)
  Candidate: (none)
  Version table:
--

My sources.list file:
--
deb http://debian.osuosl.org/debian/ wheezy main contrib non-free
deb-src http://debian.osuosl.org/debian/ wheezy main contrib non-free

deb http://security.debian.org/ wheezy/updates main
deb-src http://security.debian.org/ wheezy/updates main

# wheezy-updates, previously known as 'volatile'
deb http://debian.osuosl.org/debian/ wheezy-updates main
deb-src http://debian.osuosl.org/debian/ wheezy-updates main

# backports
deb http://debian.osuosl.org/debian/ wheezy-backports main

# zandronum
deb http://debian.drdteam.org/ stable multiverse

# torproject
deb http://deb.torproject.org/torproject.org wheezy main
deb-src http://deb.torproject.org/torproject.org wheezy main
--

And I also have this in sources.list.d/owncloud.list, per owncloud.org:
deb 
http://download.opensuse.org/repositories/isv:ownCloud:community/Debian_7.0/ /

Things I've done:
- apt-get update && apt-get upgrade
- apt-get clean
- apt-get -f
- dpkg --configure -a

I'm not really versed in the finer points of debian, so forgive me if
I've missed something obvious or done some unnecessary things. I've been
poking about on forum posts for a little while. 


-- 
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/87wq12r8al@enterprise.kinaa.net

Re: Unable to install owncloud-client in wheezy

[Bob Proulx]

Peter Ley wrote:
> I'm trying to install owncloud-client-cmd in wheezy and I get the
> following:

What command were you using?  Please say what command you were trying
to run when you were trying to install owncloud.

> Things I've done:
> - apt-get update && apt-get upgrade
> - apt-get clean
> - apt-get -f
> - dpkg --configure -a

Of course none of those install owncloud.

> I'm not really versed in the finer points of debian, so forgive me if
> I've missed something obvious or done some unnecessary things. I've
> been poking about on forum posts for a little while.

Did you forget the -t option?  It appears to me that you are trying to
install owncloud from backports.

> ... libowncloudsync0 (= 1.5.0+dfsg-4~bpo70+1) ...

Are you installing from backports?  Or from some place else.  If from
backports then you don't show it but you need to include the -t
backports option.  Here are instructions.

  http://backports.debian.org/Instructions/

If elsewhere then it needs a different target.

> And I also have this in sources.list.d/owncloud.list, per owncloud.org:
> deb 
> http://download.opensuse.org/repositories/isv:ownCloud:community/Debian_7.0/ /

Here it looks like you are trying to install from owncloud.org not
Debian.  If you are trying to install from owncloud.org then it looks
like a bug in owncloud's package that they are depending upon
something that doesn't exist anymore.  They have an exact dependency,
the "(=" part, which is fragile.  If you are trying to install their
packages then you need to get them involved for supporting them.

  https://owncloud.org/support/

Bob


signature.asc
Description: Digital signature

Re: Unable to install owncloud-client in wheezy

[Peter Ley]

> What command were you using?  Please say what command you were trying
> to run when you were trying to install owncloud.

Sorry, I thought it could be safely assumed I was using

apt-get install owncloud-client

> Of course none of those install owncloud.

Yes, thank you. Those were various proposed solutions from googling
about held broken packages. I never claimed they were supposed to
install owncloud, but possibly solve some underlying issue.

> Did you forget the -t option?  It appears to me that you are trying to
> install owncloud from backports.

> Are you installing from backports?  Or from some place else.  If from
> backports then you don't show it but you need to include the -t
> backports option.

I'm not trying to install from backports, although

apt-get install -t wheezy-backports owncloud-client

gives the same results.

> Here it looks like you are trying to install from owncloud.org not
> Debian.  If you are trying to install from owncloud.org then it looks
> like a bug in owncloud's package that they are depending upon
> something that doesn't exist anymore.  They have an exact dependency,
> the "(=" part, which is fragile.  If you are trying to install their
> packages then you need to get them involved for supporting them.

I actually added that as an attempt to solve the initial problem, which
still presents itself now that I have removed the file
/etc/apt/sources.list.d/owncloud.list entirely. I don't think the
problem has to do with the exact dependency, as that package does exist
with that version in the repo, but that libocsync0 does not exist. 


-- 
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/87383qqybc@enterprise.kinaa.net

Re: can't automatically launch lxde

[James]

On 04/22/2015 10:42 PM, James wrote:



On 04/21/2015 11:46 PM, Gary Dale wrote:

On 21/04/15 08:21 PM, James wrote:
I installed lxde as a gui desktop but I can't get it to run 
automatically.

I need to login as me and then do sudo kdm (sudo lxdm doesn't work).


It sounds like kdm isn't starting automatically, so you probably 
don't have any gui starting (is this correct?).

Correct.


You probably have kdm or lxdm installed but not both, which is why 
only one starts. Lxdm is not a Debian package so if you are running 
Debian, that would explain it.

I am running Debian Jessie and I have lxde 8.
I think I just installed the lxde package.
https://wiki.debian.org/LXDE#LXDE_in_Debian



The easiest way to fix the problem may be to:

sudo apt-get purge kdm
sudo apt-get install kdm

This should fix any corruption that may have occurred and should set 
up kdm to run on startup. If you prefer lxdm, simply change the 
install line to lxdm (assuming that you are running Ubuntu).

sudo apt-get install lxde
Reading package lists... Done
Building dependency tree
Reading state information... Done
lxde is already the newest version.
0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.

I purged kdm and still no GUI starts, I had to use startx.



--
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/5539798f.30...@lockie.ca

Re: Unable to install owncloud-client in wheezy

[Bob Proulx]

Peter Ley wrote:
> > What command were you using?  Please say what command you were trying
> > to run when you were trying to install owncloud.
> 
> Sorry, I thought it could be safely assumed I was using
> 
> apt-get install owncloud-client

Well...  You said Wheezy too and owncloud isn't available in Wheezy 7
but is included in Jessie 8.  I saw the sources.list entries.  It
could easily have been an installation from 3rd party locations due to
the 3rd party sources.list file.

> > Of course none of those install owncloud.
> 
> Yes, thank you. Those were various proposed solutions from googling
> about held broken packages. I never claimed they were supposed to
> install owncloud, but possibly solve some underlying issue.

Sorry.  Missing the specifics (now provided) left me in an ambiguous
state.  But have that figured out now.  All good.  Broken.  But
understood now.

> > Are you installing from backports?  ...
> 
> I'm not trying to install from backports, although

Actually, you would normally want to be.  Because owncloud isn't in
Wheezy 7.  Therefore on Wheezy it would need to come from some place
different.  Here is a list of versions available from Debian.

  
https://packages.debian.org/search?keywords=owncloud-client&searchon=names&suite=all§ion=all

Knowing that it is from backports I set that up here and tried it and
get exactly the same results.  Therefore I conclude that Debian
backports of owncloud is broken.

I suggest taking this issue to the debian-backpo...@lists.debian.org
mailing list and reporting the problem there.  That is where all
issues surrounding the backports repository are discussed.  It would
be perfect there.

Alternatively owncloud is in Jessie 8 which is due to be released
April 25th.  That is only two days from now!

  https://lists.debian.org/debian-devel-announce/2015/03/msg00016.html

Meaning that instead of using backports at this point it might make a
lot of sense to upgrade to Jessie 8 and use the owncloud-client from
there.  And because of the release there might not be too much
motivation for someone of the backports team to work on fixing it
there.  Only two more days before Debian Stable has left Wheezy and
moved to Jessie.

Most of the final work in Jessie is being done on the installer.  You
already have a system and don't need the installer.  I suggest reading
through the upgrade notes and then upgrading to Jessie.  I think at
this very late date Jessie is ready and won't be any different two
days from now.  Here are the current draft release notes.

  https://www.debian.org/releases/testing/amd64/release-notes/

There may be more changes happening in the draft release notes.  I
don't know.  I expect that the documentation is one of the places
where last minute changes will be made as more people finalize the
release.

> > Here it looks like you are trying to install from owncloud.org not
> > Debian.  If you are trying to install from owncloud.org then it looks
> > like a bug in owncloud's package that they are depending upon
> > something that doesn't exist anymore.  They have an exact dependency,
> > the "(=" part, which is fragile.  If you are trying to install their
> > packages then you need to get them involved for supporting them.
> 
> I actually added that as an attempt to solve the initial problem, which
> still presents itself now that I have removed the file
> /etc/apt/sources.list.d/owncloud.list entirely. I don't think the
> problem has to do with the exact dependency, as that package does exist
> with that version in the repo, but that libocsync0 does not exist. 

Sorry.  I fixated on the "=" dependency of the "bpo" version which is
the tag line for all packages in the backports repository.  Often see
problems when using "=" instead of ">=".

But here you are right that it is the missing libocsync0 not available
anywhere that is the problem.  The libowncloudsync0 in Jessie 8
doesn't depend upon libocsync0 and therefore isn't an issue there.

Bob


signature.asc
Description: Digital signature

Re: boot-time messages, /init touch not found

[Mike Kupfer]

songbird wrote:

> songbird wrote:
> > Mike Kupfer wrote:
> >
> >> Hi, after updating a jessie VM, I noticed a message during boot, before
> >> lightdm started.  The message was something like
> >>
> >>   /init [stuff I didn't catch] touch: not found
> >>
> >> After logging in, I tried using journalctl to find the message, with no
> >> success.  Is journalctl the right tool to find the message?  If not,
> >> what is?
> >
> >   Mike, i'm not running a VM and have the same 
> > message showing up.
> >
> >   it is in the early boot stage so you might need
> > some other way to capture the message, there used
> > to be a package called bootlog, but i don't know
> > how well it works with systemd.
> 
>   installed the package bootlogd and so output should
> show up in /var/log/boot, but that file remains empty.

Darn.  Thanks for checking.

> /init: 401: /init: touch: not found...

Ah, yes, that matches exactly the message I've been seeing.  I thought
401 might be a pid, but there's no process 401 by the time I log in.

> 
> >   doesn't seem to be affecting anything or preventing
> > my system from coming up

Same here.

I don't recall seeing the message on my host (which is also running
Jessie), but the messages on the host disappear even faster than they do
on the guest.

> > so i've ignore it until i
> > saw your note.  likely someone changed a script in 
> > the early boot process that now uses the command 
> > touch when it should not be assumed to exist yet...
> 
>   that's as far as i've gotten.

Okay, thanks.

I suppose it's also worth noting that I see it between the 2 fsck's of
the root partition.

mike


-- 
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/4231.1429834701@allegro.localdomain

Re: bash, dash and sh

[jeremy bentham]

On Wed, Apr 22, 2015 at 11:43:17PM -0600, Glenn English wrote:
> 
> On Apr 22, 2015, at 9:22 PM, Bob Proulx  wrote:
> 
> > jeremy bentham wrote:
> >> I am finally abandonning my fifteen-year-old computer and Lenny
> >> for a six (?) year old used Gateway 2802 (as a Bad Consumer
> >> (tm) I never buy anything new if I can avoid it) and, right now,
> >> it has a start at Wheezy on it.

> As a consumer running an elderly server with Lenny on it, I too
> congratulate you -- Wheezy is more fun than Lenny. They fixed a
> lot of stuff that gave me trouble with Lenny.

> >> I have a bunch of scripts 
> >> 
> >> (ls -1 ~/bin | wc
> >>   138   139   1302)
> >> 
> >> with the first line #!/bin/sh that use bashisms, and the above
> >> would be a lot easier than editing each one (of course, maybe
> >> just editing each one would be easier than doing this ;-) ).

> May I suggest just changing the pointer from Dash back to Bash.
> You sound like somebody that stays with a release for a while,
> and this is would be a lot less work than editing all those
> scripts. 

I probably wasn't clear enough in my Real Question, which is,
will doing this--what I really want--Seriously Break Something? 
Lots of stuff uses "/bin/sh".

> Or maybe editing the top line of them from #!/bin/sh to
> #!/bin/bash, for the time being. 

And this was what I was trying to avoid, while possibly learning
something without having to type "man dash".  Terminal Laziness
(again, (TM)).

I'll use this reply to say, thanks for the suggestions--
especially that sed command line.  I know about sed, of course,
but I use it so seldom that I basically have to relearn it every
time I need it.

> -- 
> Glenn English

-- 
 Dave WilliamsWhen the professional politicians decide to
 d...@eskimo.com   solve a problem, the best we can hope for is 
  that they won't make it worse.


-- 
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/20150424003105.GV14392@benny

Re: bash, dash and sh

[John Hasler]

jeremy bentham writes:
> I probably wasn't clear enough in my Real Question, which is, will
> doing this--what I really want--Seriously Break Something?  Lots of
> stuff uses "/bin/sh".

Not likely.  When called as sh Bash goes into a compatibility mode.
-- 
John Hasler 
jhas...@newsguy.com
Elmwood, WI USA


-- 
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/87egnany3u@thumper.dhh.gt.org

Re: boot-time messages, /init touch not found

[The Wanderer]

On 04/23/2015 at 01:32 PM, songbird wrote:

> songbird wrote:
> 
>> Mike Kupfer wrote:
>> 
>>> Hi, after updating a jessie VM, I noticed a message during boot,
>>> before lightdm started.  The message was something like
>>> 
>>> /init [stuff I didn't catch] touch: not found
>>> 
>>> After logging in, I tried using journalctl to find the message,
>>> with no success.  Is journalctl the right tool to find the
>>> message?  If not, what is?
>> 
>> Mike, i'm not running a VM and have the same message showing up.
>> 
>> it is in the early boot stage so you might need some other way to
>> capture the message, there used to be a package called bootlog, but
>> i don't know how well it works with systemd.
> 
> installed the package bootlogd and so output should show up in
> /var/log/boot, but that file remains empty.

I would advise you to first make sure the initramfs / initrd for that
kernel version has been updated:

update-initramfs -u -k $VERSION

where $VERSION is either the kernel version number (as listed under
/lib/modules/) or the word "all".


If that doesn't help, then I'd advise that you expand the initramfs /
initrd file from under /boot into an empty directory, and see what it
contains. It may very well be missing either bin/touch or some related
thing.

At the very least, you may be able to check the script which is trying
to run 'touch', see the exact command, and potentially be able to
troubleshoot from there. (I suspect that this script is standard and
does not change between systems, so the problem probably lies elsewhere,
but it could be a useful way to work towards identifying the problem.)

The "expand" step can be done with a command like the following. (Make
sure that you're in an _empty_ directory when you run this!. It's
probably best to create a new directory for the purpose.)

gunzip - < /boot/initrd.img-$(uname -r) | cpio -i

-- 
   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: Unable to install owncloud-client in wheezy

[Peter Ley]

Ah, I didn't realize that it had to be from backports only. I guess I'll
upgrade to Jessie then. Thanks for the help!


-- 
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/87h9s6ql7n@enterprise.kinaa.net

nfs problems

[briand]

Hi all,

There's only 1 thing worse than getting nfs to work on a linux system and 
that's getting cups to work.

So a long time ago i had nfs working with bind , but i changed computers didn't 
use nfs for a while and lost the recipe, i.e. all this was most definitely 
working.


the idea was to do this :


  /home /nfs4exports/home none bind 0 0

and that command remained- so I know it's right. The client side set-up is what 
I lost.

the client should be able to do somthing like

  server:/nfs4exports/home/user1  /mnt/home/user1   nfs4  rw,hard,intr  0   
  0
  server:/nfs4exports/home/user2  /mnt/home/user2   nfs4  rw,hard,intr  0   
  0

etc...

however the client side mount commands are apparently wrong because I get this :

mount.nfs4: mounting server:/nfs4exports/home/user1 failed, reason given by 
server:
  No such file or directory

and as usual the error message is completely unhelpful because 
/nfs4exports/home/user1 most certainly DOES exist on the server.


Any help appreciated.


Brian


-- 
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/20150423205743.39277...@cedar.deldotd.com

qemu-kvm and glusterfs support

[Risto Paavola]

Hello!

In Debian Jessie, why qemu-kvm has been compiled without glusterfs network
disk type support?

BR,
-Risto Paavola

Re: nfs problems

[Bob Proulx]

bri...@aracnet.com wrote:
> however the client side mount commands are apparently wrong because
> I get this:
> 
> mount.nfs4: mounting server:/nfs4exports/home/user1 failed, reason given by 
> server:
>   No such file or directory
> 
> and as usual the error message is completely unhelpful because
> /nfs4exports/home/user1 most certainly DOES exist on the server.

Hmm...  Guessing...  What is in /etc/exports?  'exportfs -a'?  What
does 'showmount -e' show?

Bob


signature.asc
Description: Digital signature

Re: can't automatically launch lxde

[Petter Adsen]

On Thu, 23 Apr 2015 19:00:31 -0400
James  wrote:

> 
> 
> On 04/22/2015 10:42 PM, James wrote:
> >
> >
> > On 04/21/2015 11:46 PM, Gary Dale wrote:
> >> On 21/04/15 08:21 PM, James wrote:
> >>> I installed lxde as a gui desktop but I can't get it to run 
> >>> automatically.
> >>> I need to login as me and then do sudo kdm (sudo lxdm doesn't
> >>> work).
> >>>
> >>>
> >> It sounds like kdm isn't starting automatically, so you probably 
> >> don't have any gui starting (is this correct?).
> > Correct.
> >>
> >> You probably have kdm or lxdm installed but not both, which is why 
> >> only one starts. Lxdm is not a Debian package so if you are
> >> running Debian, that would explain it.
> > I am running Debian Jessie and I have lxde 8.
> > I think I just installed the lxde package.
> > https://wiki.debian.org/LXDE#LXDE_in_Debian
> >
> >>
> >> The easiest way to fix the problem may be to:
> >>
> >> sudo apt-get purge kdm
> >> sudo apt-get install kdm
> >>
> >> This should fix any corruption that may have occurred and should
> >> set up kdm to run on startup. If you prefer lxdm, simply change
> >> the install line to lxdm (assuming that you are running Ubuntu).
> > sudo apt-get install lxde
> > Reading package lists... Done
> > Building dependency tree
> > Reading state information... Done
> > lxde is already the newest version.
> > 0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
> I purged kdm and still no GUI starts, I had to use startx.

What happens when you do "sudo systemctl restart lightdm.service"? And
what's in /var/log/lightdm/lightdm.log?

Petter

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


pgpVtKoDPRWKm.pgp
Description: OpenPGP digital signature