Re: boot times out after dist-upgrade on Stretch

[Borden Rhodes]

Thank you for your message, Michael, and please forgive the delay in responding.

I tried booting with the 4.5 kernel after 4.6 failed to boot. It
seems, by then, that the damage had been done as I got identical
symptoms on both boots. I agree with you that the cryptsetup/LVM is to
blame (although I'd blame LVM more).

The hypothesis to test multi-user.wants came from being able to boot
into single user mode without incident and isolate default.target once
I'm in single user mode. I can also isolate default.target from the
early debug shell.

I tried to follow your advice. It seems that my box could accurately
identify the partitions from `ls`-ing through the /dev directory and
seeing everything set up correctly. fstab and crypttab also seem to be
intact during the hangup.

I ran `udevadm info` on everything I could find in /sys/class/block/
the settings you told me to check are as follows:
./dm-0 (mapper/sda5_crypt): SYSTEMD_READY=1; TAGS=:systemd:
./dm-1 (mapper/LVG-root): TAGS=:systemd: (SYSTEMD_READY is not present)
./dm-2 (mapper/LVG-var): TAGS=:systemd: (SYSTEMD_READY is not present)
./dm-3 (mapper/LVG-tmp): TAGS=:systemd: (SYSTEMD_READY is not present)
./dm-4 (mapper/LVG-home): TAGS=:systemd: (SYSTEMD_READY is not present)
./sda: TAGS=:systemd: (SYSTEMD_READY is not present)
./sda1 (/boot): TAGS=:systemd: (SYSTEMD_READY is not present)
./sda5 (crypttab/LVM partition): TAGS=:systemd: (SYSTEMD_READY is not present)

I hope that's legible. I can pastebin the full output for each of
those commands if it helps.

For kicks and giggles, I ran `sudo lvmconfig --type diff` which yielded
devices {
cache_dir="/run/lvm"
}
I'm grasping at straws so I don't know if this is relevant or not.

With thanks,

By-the-by, since it's been a while since I've been able to tackle
this, here's the rest of the e-mail thread for context:
https://lists.debian.org/debian-user/2016/06/msg00670.html

Newer mutt in stable

[Andre Majorel]

The version of Mutt in Debian 8 (1.5.23-3) has a very annoying
bug (https://dev.mutt.org/hg/mutt/rev/755a18da99bc). I'd like
to upgrade to 1.5.24 or newer.

Unstable and testing have Mutt 1.6.0-1 but I don't see any back
ports of Mutt for stable.

Things I'd rather not do :
- install from source,
- install a package from unstable or testing in case it drags in
  new versions of libc etc.,
- install unstable or testing in a VM (not against the idea,
  just too many other things on my plate at the moment),
- upgrade to unstable or testing.

So what are my options ? How about

  apt-get source --build mutt /unstable && dpkg -i mutt*.deb

Would that be the way to go ? Any traps I should be aware of ?

Thanks in advance.

-- 
André Majorel 
bugs.debian.org - spammer's delight.

Re: Newer mutt in stable

[Alberto Luaces]

Andre Majorel writes:

> Things I'd rather not do :
> - install from source,
> - install a package from unstable or testing in case it drags in
>   new versions of libc etc.,

This is the first thing I would try, because it is the easiest path.

If the number of dependencies is unbearable to you, then I would try to
compile the source package (but you could also be asked for updated
build dependencies as well).

-- 
Alberto

After a few days, strange inter-process communication bugs in up-to-date Jessie GNOME

[David Guyot]

Hello, there.

I run my up-to-date Jessie the whole week, starting it on Monday morning
and shutting it down on Friday evening. I noticed strange bugs occurring
after a few days running, i.e. often on Wednesday in my case: SSH begins
behaving like there is no SSH agent and insists asking my key
passphrases every time I start a SSH session, GNOME starts preventing me
switching between windows until I ask, then escape from, the Alt+F2
Execute popup, and Chromium starts opening the links in a new session on
each URL click, complaining that the default profile is damaged and
cannot be used.

At first, I thought that it was independent bugs, but I noticed that
these bugs regularly show a few days after the last boot, that when one
shows, the other one also shows on the next triggering condition, and
that they both involve an inter-process communication of some sort. My
conclusion is that they are related to inter-process communication.

Am I correctly interpreting these elements? If so, against which package
should I fill a bug ticket, or how to figure out? Else, what information
should I retrieve to examine the bug from all sides?

Awaiting your answers,

Regards.
-- 
David Guyot
Administrateur système, réseau et télécom / Sysadmin
Europe Camions Interactive / Stockway
Moulin Collot
F-88500 Ambacourt
03 29 30 47 85


signature.asc
Description: This is a digitally signed message part

Re: After a few days, strange inter-process communication bugs in up-to-date Jessie GNOME

[Michael Biebl]

Am 19.07.2016 um 14:42 schrieb David Guyot:

> should I fill a bug ticket, or how to figure out? Else, what information
> should I retrieve to examine the bug from all sides?

Have you tried running the applications from a console so you get the
output from stdout/stderr? Do you have any specific error messages?

Does journalctl list any errors?


-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature

Re: After a few days, strange inter-process communication bugs in up-to-date Jessie GNOME

[David Guyot]

Le mardi 19 juillet 2016 à 15:04 +0200, Michael Biebl a écrit :
> Have you tried running the applications from a console so you get the
> output from stdout/stderr? Do you have any specific error messages?
No, I started the applications from the graphical interface; I just
started them from terminal to see, but, at least from Chromium, I don't
expect much data, as, when the problem arises, it shows itself by
starting a new Chromium instance, whose output will be lost AFAIK.
Regarding SSH, I didn't run it in verbose mode, and the normal mode
didn't printed anything different from the case of a key not yet entered
into the agent.

> Does journalctl list any errors?
Currently, no, but the problem hasn't show itself since the last boot;
that could explain the "No journal files were found." message.

I'll post the data I gathered on the next occurrence of the bug as soon
as it will show itself.
-- 
David Guyot
Administrateur système, réseau et télécom / Sysadmin
Europe Camions Interactive / Stockway
Moulin Collot
F-88500 Ambacourt
03 29 30 47 85


signature.asc
Description: This is a digitally signed message part

GLX, (xserver-)xorg(-dev), and nvidia-driver under jessie(-backports)

[Jeffrey Mark Siskind]

I have installed jessie. Among other packages installed, I have

   apt-get -y install gnome
   apt-get -y install xorg
   apt-get -y install xserver-xorg-dev
   apt-get -y install afni
   apt-get -y -t jessie-backports install nvidia-driver
   apt-get -y -t jessie-backports install nvidia-cuda-toolkit

I installed skype with:
   # https://wiki.debian.org/skype#Debian_7_.22Wheezy.22
   # wget -O /tmp/usb/skype-install.deb 
http://www.skype.com/go/getskype-linux-deb
   dpkg --add-architecture i386
   apt-get update
   dpkg -i /tmp/usb/skype-install.deb
   apt-get -y -f install
   apt-get clean

There appear to be two (possibly related) problems with GLX. One is that I run

   xvfb-run \
 --auto-servernum \
 --server-num=20 \
 -s "-screen 0 1024x768x24 -ac +extension GLX +render -noreset" \
 align_epi_anat.py ...

This used to work under wheezy. Now I get.

 3dSkullStrip -orig_vol -input ./__tt_subject01-anat+orig -prefix 
./__tt_subject01-anat_ns
   Xlib:  extension "GLX" missing on display ":20".
   freeglut (3dSkullStrip): OpenGL GLX extension not supported by display ':20'
   ** ERROR: Could not strip skull

   ** ERROR - script failed

The second is that I run

   qobi@tlamachilistli>ldd `which skype`|fgrep not
  libGL.so.1 => not found
libGL.so.1 => not found
   qobi@tlamachilistli>

Despite the fact that the problems manifest when running 3dSkullStrip (afni)
and skype, I believe that the problems do not lie in those packages. They lie
in the way that nvidia-driver changes the alternatives for xorg and
xserver-xorg-dev.

Note that I did not manually select alternatives. All I did was the above
apt-get and dpkg commands.

Any suggestions for how to properly fix would be appreciated.

Jeff (http://engineering.purdue.edu/~qobi)

qobi@tlamachilistli>ls -l /usr/lib/x86_64-linux-gnu/libGL.so
lrwxrwxrwx 1 root root 48 Jun 16 16:16 /usr/lib/x86_64-linux-gnu/libGL.so -> 
/etc/alternatives/glx--libGL.so-x86_64-linux-gnu
qobi@tlamachilistli>ls -l /etc/alternatives/glx--libGL.so-x86_64-linux-gnu
lrwxrwxrwx 1 root root 48 Jun 16 16:16 
/etc/alternatives/glx--libGL.so-x86_64-linux-gnu -> 
/usr/lib/mesa-diverted/x86_64-linux-gnu/libGL.so
qobi@tlamachilistli>ls -l /usr/lib/mesa-diverted/x86_64-linux-gnu/libGL.so
lrwxrwxrwx 1 root root 10 Jun 16 16:16 
/usr/lib/mesa-diverted/x86_64-linux-gnu/libGL.so -> libGL.so.1
qobi@tlamachilistli>ls -l /usr/lib/mesa-diverted/x86_64-linux-gnu/libGL.so.1
lrwxrwxrwx 1 root root 14 Aug 19  2015 
/usr/lib/mesa-diverted/x86_64-linux-gnu/libGL.so.1 -> libGL.so.1.2.0
qobi@tlamachilistli>ls -l /usr/lib/mesa-diverted/x86_64-linux-gnu/libGL.so.1.2.0
-rw-r--r-- 1 root root 627320 Aug 19  2015 
/usr/lib/mesa-diverted/x86_64-linux-gnu/libGL.so.1.2.0
qobi@tlamachilistli>ls -l /usr/lib/mesa-diverted/i386-linux-gnu/libGL.so.1
lrwxrwxrwx 1 root root 14 Aug 19  2015 
/usr/lib/mesa-diverted/i386-linux-gnu/libGL.so.1 -> libGL.so.1.2.0
qobi@tlamachilistli>ls -l /usr/lib/mesa-diverted/i386-linux-gnu/libGL.so.1.2.0
-rw-r--r-- 1 root root 695836 Aug 19  2015 
/usr/lib/mesa-diverted/i386-linux-gnu/libGL.so.1.2.0
qobi@tlamachilistli>ls -l /usr/lib/mesa-diverted/libGL.so-master
lrwxrwxrwx 1 root root 33 Jun 16 16:16 /usr/lib/mesa-diverted/libGL.so-master 
-> /etc/alternatives/libGL.so-master/
qobi@tlamachilistli>ls -l /etc/alternatives/libGL.so-master/
total 12
drwxr-xr-x 2 root root 4096 Apr 19 17:54 arm-linux-gnueabihf/
drwxr-xr-x 2 root root 4096 Jun 16 16:23 i386-linux-gnu/
lrwxrwxrwx 1 root root   33 Jun 16 16:16 libGL.so-master -> 
/etc/alternatives/libGL.so-master/
drwxr-xr-x 2 root root 4096 Jun 16 16:16 x86_64-linux-gnu/
qobi@tlamachilistli>ls -l /usr/lib/x86_64-linux-gnu/libGL.so
lrwxrwxrwx 1 root root 48 Jun 16 16:16 /usr/lib/x86_64-linux-gnu/libGL.so -> 
/etc/alternatives/glx--libGL.so-x86_64-linux-gnu
qobi@tlamachilistli>ls -l /etc/alternatives/glx--libGL.so-x86_64-linux-gnu
lrwxrwxrwx 1 root root 48 Jun 16 16:16 
/etc/alternatives/glx--libGL.so-x86_64-linux-gnu -> 
/usr/lib/mesa-diverted/x86_64-linux-gnu/libGL.so
qobi@tlamachilistli>ls -l /usr/lib/mesa-diverted/x86_64-linux-gnu/libGL.so
lrwxrwxrwx 1 root root 10 Jun 16 16:16 
/usr/lib/mesa-diverted/x86_64-linux-gnu/libGL.so -> libGL.so.1
qobi@tlamachilistli>ls -l /usr/lib/mesa-diverted/x86_64-linux-gnu/libGL.so.1
lrwxrwxrwx 1 root root 14 Aug 19  2015 
/usr/lib/mesa-diverted/x86_64-linux-gnu/libGL.so.1 -> libGL.so.1.2.0
qobi@tlamachilistli>ls -l /usr/lib/mesa-diverted/x86_64-linux-gnu/libGL.so.1.2.0
-rw-r--r-- 1 root root 627320 Aug 19  2015 
/usr/lib/mesa-diverted/x86_64-linux-gnu/libGL.so.1.2.0
qobi@tlamachilistli>ls -l /usr/lib/x86_64-linux-gnu/nvidia/libGL.so.1
lrwxrwxrwx 1 root root 53 Jun 16 16:16 
/usr/lib/x86_64-linux-gnu/nvidia/libGL.so.1 -> 
/etc/alternatives/nvidia--libGL.so.1-x86_64-linux-gnu
qobi@tlamachilistli>ls -l /etc/alternatives/nvidia--libGL.so.1-x86_64-linux-gnu
lrwxrwxrwx 1 root root 51 Jun 16 16:19 
/etc/alternat

Hot swapping failed disk /dev/sda in RAID 1 array

[Urs Thuermann]

In my RAID 1 array /dev/md0 consisting of two SATA drives /dev/sda1
and /dev/sdb1 the first drive /dev/sda has failed.  I have called
mdadm --fail and mdadm --remove on that drive and then pulled the
cables and removed the drive.  The RAID array continues to work fine
but in degraded mode.

I have some questions:

1. The block device nodes /dev/sda and /dev/sda1 still exist and the
   partitions are still listed in /proc/partitions.

   That causes I/O errors when running LVM tools or fdisk -l or other
   tools that try to access/scan all block devices.

   Shouldn't the device nodes and entries in /proc/partitions
   disappear when the drive is pulled?  Or does the BIOS or the SATA
   controller have to support this?

2. Can I hotplug the new drive and rebuild the RAID array?  Since
   removal of the old drive seems not to be detected I wonder if the
   new drive will be detected correctly.  Will the kernel continue
   with the old drive's size and partitioning, as is still found in
   /proc/partitions?  Will a call

blockdev --rereadpt /dev/sda

   help?

3. Alternativley, I could reboot the system.  I have called

grub-install /dev/sdb

   and hope this suffices to make the system bootable again.
   Would that be safer?

Any other suggestions?


urs

Re: does anybody remember which debian release was it that asked for the MAC ID details at the end ?

[Lennart Sorensen]

On Tue, Jul 19, 2016 at 01:45:58AM +0200, Geert Stappers wrote:
> Not me.
> And I think there was never such bug as asking for MAC details from the User.

I have certainly never seen it, and don't recall any such thing in any
installer I have used since 2.0.

> In https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=295888 is
> an user request asking _showing_ MAC address. Quoting the BR:
> 
> |  Primary network interface:
> |  eth0: BROADCOM Corporation NetXtreme BCM5704 Gigabit Ethernet
> |  eth1: BROADCOM Corporation NetXtreme BCM5704 Gigabit Ethernet
> |
> |  The user has no chance to select the right network interface.
> |  At least the MAC address should be displayed.
> 
> 
> The installation would continue without tricks
> just by picking an I/F.

That I can certainly believe, which would have been a hassle for those
affected by it.

> > I am in midst of making a presentation hence need that historical
> > information for accuracy.
> 
> Was there ever the bug as the original poster described?

I don't think so.  I can't think of a reason the installer would ever
ask for the MAC, unless you are talking some odd ball ARM hardware that
didn't have a MAC in hardware and required the user to provide one.
But would Debian have even had an installer for such a thing?

Searching the bug database for bugs mentioning mac in the subject (which I
would hope anyone submitting a bug about such a problem would have used)
against debian-installer and boot-floppies, I see nothing what so ever
that as anything like this in archived and unarchived bugs.

-- 
Len Sorensen

Re: Hot swapping failed disk /dev/sda in RAID 1 array

[Peter Ludikovsky]

Ad 1: Yes, the SATA controller has to support Hot-Swap. You _can_ remove
the device nodes by running
# echo 1 > /sys/block//device/delete

Ad 2: Depends on the controller, see 1. It might recognize the new
drive, or not. It might see the correct device, or not.

Ad 3: As long as the second HDD is within the BIOS boot order, that
should work.

Regards,
/peter

Am 19.07.2016 um 16:01 schrieb Urs Thuermann:
> In my RAID 1 array /dev/md0 consisting of two SATA drives /dev/sda1
> and /dev/sdb1 the first drive /dev/sda has failed.  I have called
> mdadm --fail and mdadm --remove on that drive and then pulled the
> cables and removed the drive.  The RAID array continues to work fine
> but in degraded mode.
> 
> I have some questions:
> 
> 1. The block device nodes /dev/sda and /dev/sda1 still exist and the
>partitions are still listed in /proc/partitions.
> 
>That causes I/O errors when running LVM tools or fdisk -l or other
>tools that try to access/scan all block devices.
> 
>Shouldn't the device nodes and entries in /proc/partitions
>disappear when the drive is pulled?  Or does the BIOS or the SATA
>controller have to support this?
> 
> 2. Can I hotplug the new drive and rebuild the RAID array?  Since
>removal of the old drive seems not to be detected I wonder if the
>new drive will be detected correctly.  Will the kernel continue
>with the old drive's size and partitioning, as is still found in
>/proc/partitions?  Will a call
> 
> blockdev --rereadpt /dev/sda
> 
>help?
> 
> 3. Alternativley, I could reboot the system.  I have called
> 
> grub-install /dev/sdb
> 
>and hope this suffices to make the system bootable again.
>Would that be safer?
> 
> Any other suggestions?
> 
> 
> urs
> 



signature.asc
Description: OpenPGP digital signature

Re: Hot swapping failed disk /dev/sda in RAID 1 array

[Andy Smith]

Hi Urs,

On Tue, Jul 19, 2016 at 04:01:39PM +0200, Urs Thuermann wrote:
> 2. Can I hotplug the new drive and rebuild the RAID array?

It should work, if your SATA port supports hotplug. Plug the new
drive in and see if the new device node appears. If it does then
you're probably good to go.

You can dump out the partition table from an existing drive with
something like:

# sfdisk -d /dev/sdb > sdb.out

And then partition the new drive the same with something like:

# sfdisk /dev/sdc < sdb.out

(assuming sdb is your working existing drive and sdc is the device
node of the new drive)

Then add the new device to the md with something like:

# mdadm /dev/md0 --add /dev/sdc1

(assuming your array is md0; adjust to suit)

At that point /proc/mdstat should show a rebuild taking place.

If you run into difficulty try asking on the linux-raid mailing list
- it's very good for support and it's best to ask there before doing
anything that you have the slightest doubt about!

Cheers,
Andy

-- 
http://bitfolk.com/ -- No-nonsense VPS hosting

Re: Newer mutt in stable

[Sven Joachim]

On 2016-07-19 12:05 +0200, Andre Majorel wrote:

> The version of Mutt in Debian 8 (1.5.23-3) has a very annoying
> bug (https://dev.mutt.org/hg/mutt/rev/755a18da99bc). I'd like
> to upgrade to 1.5.24 or newer.
>
> Unstable and testing have Mutt 1.6.0-1 but I don't see any back
> ports of Mutt for stable.
>
> Things I'd rather not do :
> - install from source,
> - install a package from unstable or testing in case it drags in
>   new versions of libc etc.,
> - install unstable or testing in a VM (not against the idea,
>   just too many other things on my plate at the moment),

You don't need a VM, a chroot is sufficient.  And with schroot executing
commands from the chroot is relatively painless.

> - upgrade to unstable or testing.
>
> So what are my options ? How about
>
>   apt-get source --build mutt /unstable && dpkg -i mutt*.deb

Omit the space between mutt and /unstable.  And "dpkg -i" must be run as
root, while you should build packages as a normal user.

> Would that be the way to go ?

Rebuilding the source package from testing on stable would definitely my
choice, provided that it works.

> Any traps I should be aware of ?

Make backups of your mailboxes, just in case the new mutt causes havoc.

Cheers,
   Sven

Bluetooth Questions Using wheezy

[Martin McCormick]

I see the following messages in dmesg:

 Bluetooth: Core ver 2.16
 Bluetooth: HCI device and connection manager initialized
 Bluetooth: HCI socket layer initialized
 Bluetooth: L2CAP socket layer initialized
 Bluetooth: SCO socket layer initialized
 Bluetooth: BNEP (Ethernet Emulation) ver 1.3
 Bluetooth: BNEP filters: protocol multicast

Does this mean there is a bluetooth transceiver active on
this Dell mother board? If so, I never knew it in all the years I
have had this system which is about 16 or 17 years.

Another old Dell optiplex running wheezy also produces
exactly the same messages when running dmesg.

Is there any utility I can run to see if they are alive
and useful?

I ran across these accidentally when I was looking for
something else and now it has my curiosity peaked; something new
to play with. Thanks.

Martin McCormick

Re: Bluetooth Questions Using wheezy

[Reco]

Hi.

On Tue, 19 Jul 2016 11:08:08 -0500
"Martin McCormick"  wrote:

>   I see the following messages in dmesg:
> 
>  Bluetooth: Core ver 2.16
>  Bluetooth: HCI device and connection manager initialized
>  Bluetooth: HCI socket layer initialized
>  Bluetooth: L2CAP socket layer initialized
>  Bluetooth: SCO socket layer initialized
>  Bluetooth: BNEP (Ethernet Emulation) ver 1.3
>  Bluetooth: BNEP filters: protocol multicast
> 
>   Does this mean there is a bluetooth transceiver active on
> this Dell mother board? If so, I never knew it in all the years I
> have had this system which is about 16 or 17 years.

No, it does not. These messages mean that assorted bluetooth modules
are loaded.


>   Another old Dell optiplex running wheezy also produces
> exactly the same messages when running dmesg.
> 
>   Is there any utility I can run to see if they are alive
> and useful?

But if /bin/hciconfig shows you at least one hci device - that means
that your kernel actually sees Bluethooth transceiver.

For instance, on this PC it looks like this:

$ hciconfig
hci0:   Type: BR/EDR  Bus: USB
BD Address: xx:xx:xx:xx:xx:xx  ACL MTU: 384:8  SCO MTU: 64:8
UP RUNNING PSCAN
RX bytes:506 acl:0 sco:0 events:23 errors:0
TX bytes:343 acl:0 sco:0 commands:23 errors:0

Reco

Re: gimp resynthesizer

[peter]

pe...@easthope.ca wrote:
> Any tips to make the gimp resynthesizer work?

From: Siard 
Date: Wed, 13 Jul 2016 22:04:57 +0200
> AFAICT, the Resynthesizer plug-in adds a script called Heal Selection 
> ...
> run the Heal Selection filter (Image Menu > Filters > Enhance > Heal
> Selection).

From: Sven Arvidsson 
Date: Wed, 13 Jul 2016 23:35:04 +0200
> At least on my system (sid) it's in Filters → Map → Resynthesize.

OK, yes, in debian jessie with the  gimp-plugin-registry package 
installed, Filters > Map > Resynthesize works.  Usage is straightforward.  
Select an area to use as the source of the patch.  Select the area to be 
patched.  Then let the resynthesizer do the work.  

Task completed with no significant difficulty.  Thanks to Siard and Sven,
  ... Peter E.

-- 
123456789 123456789 123456789 123456789 123456789 123456789 123456789
Tel +1 360 639 0202 
http://easthope.ca/Peter.html Bcc: peter at easthope. ca

Re: Bluetooth Questions Using wheezy

[Martin McCormick]

Reco  writes:
> No, it does not. These messages mean that assorted bluetooth modules
> are loaded.
> 
> 
> >   Another old Dell optiplex running wheezy also produces
> > exactly the same messages when running dmesg.
> >
> >   Is there any utility I can run to see if they are alive
> > and useful?
> 
> But if /bin/hciconfig shows you at least one hci device - that means
> that your kernel actually sees Bluethooth transceiver.
> 
> For instance, on this PC it looks like this:
> 
> $ hciconfig
> hci0:   Type: BR/EDR  Bus: USB
> BD Address: xx:xx:xx:xx:xx:xx  ACL MTU: 384:8  SCO MTU: 64:8
> UP RUNNING PSCAN
> RX bytes:506 acl:0 sco:0 events:23 errors:0
> TX bytes:343 acl:0 sco:0 commands:23 errors:0

When I try that, I get:

$/bin/hciconfig
bash: /bin/hciconfig: No such file or directory

That settles it. Neither system has one. I feel better now.

Thank you. That is a good command to know.

Martin

Re: Bluetooth Questions Using wheezy

[David Wright]

On Tue 19 Jul 2016 at 12:36:22 (-0500), Martin McCormick wrote:
> Reco  writes:
> > No, it does not. These messages mean that assorted bluetooth modules
> > are loaded.
> > 
> > 
> > >   Another old Dell optiplex running wheezy also produces
> > > exactly the same messages when running dmesg.
> > >
> > >   Is there any utility I can run to see if they are alive
> > > and useful?
> > 
> > But if /bin/hciconfig shows you at least one hci device - that means
> > that your kernel actually sees Bluethooth transceiver.
> > 
> > For instance, on this PC it looks like this:
> > 
> > $ hciconfig
> > hci0:   Type: BR/EDR  Bus: USB
> > BD Address: xx:xx:xx:xx:xx:xx  ACL MTU: 384:8  SCO MTU: 64:8
> > UP RUNNING PSCAN
> > RX bytes:506 acl:0 sco:0 events:23 errors:0
> > TX bytes:343 acl:0 sco:0 commands:23 errors:0
> 
> When I try that, I get:
> 
> $/bin/hciconfig
> bash: /bin/hciconfig: No such file or directory

... because wheezy's hciconfig is in /usr/sbin.

Cheers,
David.

freezing gnome

[peekaa]

Hello,

I got quite new comp, Debian testing/sid with Gnome and this is 
sometimes freezing so that only 5s pressing power button helps. Not sure 
if its about hw or sw, not sure, how to find, what to test.


hw: http://pastebin.com/H9YyJBsb
sw: Linux chief 4.6.0-1-amd64 #1 SMP Debian 4.6.3-1 (2016-07-04) x86_64 
GNU/Linux with GNOME Shell 3.20.3, fully updated and upgraded.



I can provide more info, if needed. Found, that it is more often, when 
cpu temperature over 50degrees so I add another fan. Now it less 
frequently, but still, once/twice a week, mostly a few minutes after 
login to gnome.


Thank you
Pavel

Re: Bluetooth Questions Using wheezy

[Martin McCormick]

David Wright  writes:
> ... because wheezy's hciconfig is in /usr/sbin.

I probably should have used locate or which and it would
have reported the path. In this case, /usr/sbin is one of the
paths in my $pATH and there is no bluetooth interface as running
hciconfig with the correct path simply goes away for a fraction
of a second and produces nothing.

Thanks greatly.

Martin

Re: Hot swapping failed disk /dev/sda in RAID 1 array

[Pascal Hambourg]

Le 19/07/2016 à 16:01, Urs Thuermann a écrit :


   Shouldn't the device nodes and entries in /proc/partitions
   disappear when the drive is pulled?  Or does the BIOS or the SATA
   controller have to support this?

2. Can I hotplug the new drive and rebuild the RAID array?


As others replied, the SATA controller must support hot-plug, but also 
must be configured in AHCI mode in the BIOS settings so that the kernel 
is notified when a device is added or removed.

synaptic package manager error

[Jesse Stephen]

I'm getting an error message when I run ther synaptic package manager that
I have to manually run the dpkg-- configure to correct the problem. This is
not something I no how to do, I am very green at this.

Re: Internationalisation

[Lisi Reisz]

On Sunday 17 July 2016 15:03:32 Mark Fletcher wrote:
> which may mean I've failed to install something I need,

ibus-anthy??

Lisi

Re: synaptic package manager error

[Brian]

On Tue 19 Jul 2016 at 17:35:51 -0400, Jesse Stephen wrote:

> I'm getting an error message when I run ther synaptic package manager that
> I have to manually run the dpkg-- configure to correct the problem. This is
> not something I no how to do, I am very green at this.

It is almost impossible to advise on this when the command to run has to
be guessed and what was being done at the time is not mentioned. I do
not use synaptic but the first thing to do is find out how to display a
terminal in whatever environment you are using (GNOME?).

At the prompt type

  dpkg --configure -a

and press the ENTER key. What you do next depends on what you were doing
in the first place.

re: Lynx yellowwhite [broken thread]

[Wes]

On Wed, 6 Jul 2016 09:48:59 +0300, Oskar Skog wrote:

I took a look at my site in Lynx and noticed that it somehow rendered
the text that would
be extra large on a crappy browser yellow and the rest white.

Is this easter egg from a patch or upstream?

Lynx renders what in CSS would be span.thenumberofthebeast yellow
rather than white.
Example:

[snipped]

If you are seeing what I think you are seeing, begin here:

 https://lists.nongnu.org/archive/html/lynx-dev/2015-12/msg00036.html

TLDR:

 https://lists.nongnu.org/archive/html/lynx-dev/2015-12/msg00039.html

-wes

Re: synaptic package manager error

[Jesse Stephen]

I am using GNOME. I have a problem with no sound on you tube I cant run
updates And I can not download the Google talk plug-in because it says the
package updater is open

On Tue, Jul 19, 2016 at 6:47 PM, Brian  wrote:

> On Tue 19 Jul 2016 at 17:35:51 -0400, Jesse Stephen wrote:
>
> > I'm getting an error message when I run ther synaptic package manager
> that
> > I have to manually run the dpkg-- configure to correct the problem. This
> is
> > not something I no how to do, I am very green at this.
>
> It is almost impossible to advise on this when the command to run has to
> be guessed and what was being done at the time is not mentioned. I do
> not use synaptic but the first thing to do is find out how to display a
> terminal in whatever environment you are using (GNOME?).
>
> At the prompt type
>
>   dpkg --configure -a
>
> and press the ENTER key. What you do next depends on what you were doing
> in the first place.
>
>

Re: synaptic package manager error

[Gene Heskett]

On Tuesday 19 July 2016 17:35:51 Jesse Stephen wrote:

> I'm getting an error message when I run ther synaptic package manager
> that I have to manually run the dpkg-- configure to correct the
> problem. This is not something I no how to do, I am very green at
> this.

The proper command is:

sudo dpkg --configure -a

note the spaces, very important that they are in the correct places.

It will ask you for YOUR password IF you are the first user, who did the 
install in the first place.  Otherwise have that user do it.

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