Re: Problems with Buster and Bluetooth
It turns out this may have been a hardware issue all along. When I got the new PC a few weeks ago, I just plugged the USB Bluetooth adapter into a port on the front and went from there. It turns out that I had chosen a USB 3.1 port, which can cause interference and connection issues with Bluetooth. I moved the adapter to a USB 2.0 port and so far it seems to be working much better. I'm going to try it like this for a while and see how it goes. If the problems come back, I'll keep digging! On Thu, Oct 10, 2019 at 2:09 AM deloptes wrote: > David Parker wrote: > > > # dbus-send --print-reply --system --dest=org.bluez > > /org/bluez/hci0/dev_9B_1F_48_B8_55_F6 org.freedesktop.DBus.Properties.Get > > string:org.bluez.Device1 string:TxPower > > This is a property of the device. I am not sure if it is visible onlywhen > connected. I am sure I have seen it in dbus, but could be I am wrong or it > was the network. In any case the property is in the interface > specification, but I do not know why it is not visible > > > Error org.freedesktop.DBus.Error.InvalidArgs: No such property 'TxPower' > > > > The strings I have available are: > > > > Address > > AddressType > > Name > > Alias > > Class > > Icon > > Paired > > Trusted > > Blocked > > LegacyPairing > > Connected > > UUIDs > > Adapter > > ServicesResolved > > > > Anything else I should check? > > What about the PA latency? For example I google for "fine tuning > pulseaudio" > https://forums.linuxmint.com/viewtopic.php?t=44862 > https://wiki.archlinux.org/index.php/PulseAudio > > someone also susggest to try without PA > > http://shellscreen.blogspot.com/2015/01/tips-to-fix-sound-server-issues-on.html > > regards > > -- Dave Parker '11 Database & Systems Administrator Utica College Integrated Information Technology Services (315) 792-3229 Registered Linux User #408177
Re: Problems with Buster and Bluetooth
Hello, That's a good question. "Audio" is not listed even when the earbuds are connected and working. I have no explanation for that. It looks like TxPower is not an available string in the dbus-send output: # dbus-send --print-reply --system --dest=org.bluez /org/bluez/hci0/dev_9B_1F_48_B8_55_F6 org.freedesktop.DBus.Properties.Get string:org.bluez.Device1 string:TxPower Error org.freedesktop.DBus.Error.InvalidArgs: No such property 'TxPower' The strings I have available are: Address AddressType Name Alias Class Icon Paired Trusted Blocked LegacyPairing Connected UUIDs Adapter ServicesResolved Anything else I should check? Thanks! On Mon, Oct 7, 2019 at 6:07 PM deloptes wrote: > David Parker wrote: > > > # hciconfig -a > > hci0: Type: Primary Bus: USB > > BD Address: 5C:F3:70:8C:B7:98 ACL MTU: 1021:8 SCO MTU: 64:1 > > UP RUNNING PSCAN > > RX bytes:62062 acl:40 sco:0 events:3178 errors:0 > > TX bytes:499936 acl:776 sco:0 commands:1088 errors:38 > > Features: 0xbf 0xfe 0xcf 0xfe 0xdb 0xff 0x7b 0x87 > > Packet type: DM1 DM3 DM5 DH1 DH3 DH5 HV1 HV2 HV3 > > Link policy: RSWITCH SNIFF > > Link mode: SLAVE ACCEPT > > Name: 'debian' > > Class: 0x100104 > > Service Classes: Object Transfer > > Device Class: Computer, Desktop workstation > > HCI Version: 4.0 (0x6) Revision: 0x153a > > LMP Version: 4.0 (0x6) Subversion: 0x220e > > Manufacturer: Broadcom Corporation (15) > > Under Service Classes you have only "Object Transfer" > > hci0: Type: Primary Bus: USB > BD Address: ACL MTU: 310:10 SCO MTU: 64:8 > UP RUNNING PSCAN > RX bytes:19767535 acl:62926 sco:0 events:3572 errors:0 > TX bytes:390503 acl:2479 sco:0 commands:1081 errors:0 > Features: 0xff 0xff 0x8f 0xfe 0x9b 0xff 0x59 0x83 > Packet type: DM1 DM3 DM5 DH1 DH3 DH5 HV1 HV2 HV3 > Link policy: RSWITCH HOLD SNIFF PARK > Link mode: SLAVE ACCEPT > Name: 'fujitsu' > Class: 0x3c0104 > Service Classes: Rendering, Capturing, Object Transfer, Audio > Device Class: Computer, Desktop workstation > HCI Version: 2.1 (0x4) Revision: 0x12e7 > LMP Version: 2.1 (0x4) Subversion: 0x12e7 > Manufacturer: Cambridge Silicon Radio (10) > > Why is Audio not listed? > > You can get the TxPower (if lucky) from the device via DBUS Device1 > Interface > > dbus-send --print-reply --system --dest=org.bluez > /org/bluez/hci0/dev_XX_XX_XX_XX_XX_XX > org.freedesktop.DBus.Properties.Get string:org.bluez.Device1 string:TxPower > > dbus-send --print-reply --system --dest=org.bluez > /org/bluez/hci0/dev_XX_XX_XX_XX_XX_XX > org.freedesktop.DBus.Properties.GetAll string:org.bluez.Device1 > > replace dev_XX_XX_XX_XX_XX_XX with your BT MAC > > > > -- Dave Parker '11 Database & Systems Administrator Utica College Integrated Information Technology Services (315) 792-3229 Registered Linux User #408177
Re: Problems with Buster and Bluetooth
Hello, I need to correct my previous statements; I was previously running Stretch, not Jessie. I hooked up my old hard drive and verified the versions I was using before: bluez 5.43-2+deb9u1 pulseaudio-module-bluetooth 10.0-1+deb9u1 Everything worked under those versions, on Debian 9. I'll give hcidump a try and see if that reveals anything I didn't see with btmon. Thanks for the suggestion. And as requested: # hciconfig -a hci0: Type: Primary Bus: USB BD Address: 5C:F3:70:8C:B7:98 ACL MTU: 1021:8 SCO MTU: 64:1 UP RUNNING PSCAN RX bytes:62062 acl:40 sco:0 events:3178 errors:0 TX bytes:499936 acl:776 sco:0 commands:1088 errors:38 Features: 0xbf 0xfe 0xcf 0xfe 0xdb 0xff 0x7b 0x87 Packet type: DM1 DM3 DM5 DH1 DH3 DH5 HV1 HV2 HV3 Link policy: RSWITCH SNIFF Link mode: SLAVE ACCEPT Name: 'debian' Class: 0x100104 Service Classes: Object Transfer Device Class: Computer, Desktop workstation HCI Version: 4.0 (0x6) Revision: 0x153a LMP Version: 4.0 (0x6) Subversion: 0x220e Manufacturer: Broadcom Corporation (15) # sdptool browse 9B:1F:48:B8:55:F6 Browsing 9B:1F:48:B8:55:F6 ... (There's no other output from sdptool, it just exits back to the shell). Thanks, Dave On Thu, Oct 3, 2019 at 6:20 PM deloptes wrote: > David Parker wrote: > > > I'm starting to suspect that this is mostly a bluetooth issue and not > > really a PA one. I struggle to get these earbuds connected whether > > PulseAudio is involved or not. I can trust them and pair them just fine, > > but the actual connection generally fails, and when it does work, it > > doesn't stay connected for long. I'm not sure how to check the BT power > > strength, but bluetoothctl reports that the controller is powered: > > OK, but in Jessie you had bluez 5.23-2+deb8u1 and in Stretch 5.43-2+deb9u1 > and in buster 5.50-1. Can you confirm which you had in Jessie and which in > what you use now? > > PA is as following > pulseaudio-module-bluetooth (5.0-13) > pulseaudio-module-bluetooth (10.0-1+deb9u1) > pulseaudio-module-bluetooth (12.2-4+deb10u1) > > did you use PA in Jessie at all? > > I also find it difficult debugging, I usually do both BT and PA but if you > think it is BT you can try hcidump (sudo hcidump -i hci0). You can also > monitor dbus > $ dbus-monitor --system > > and for the curiosity paste here output of > $ hciconfig -a > $ sdptool browse > please > > > > regards > > -- Dave Parker '11 Database & Systems Administrator Utica College Integrated Information Technology Services (315) 792-3229 Registered Linux User #408177
Re: Problems with Buster and Bluetooth
Hi, I'm starting to suspect that this is mostly a bluetooth issue and not really a PA one. I struggle to get these earbuds connected whether PulseAudio is involved or not. I can trust them and pair them just fine, but the actual connection generally fails, and when it does work, it doesn't stay connected for long. I'm not sure how to check the BT power strength, but bluetoothctl reports that the controller is powered: [bluetooth]# show Controller 5C:F3:70:8C:B7:98 (public) Name: debian Alias: debian Class: 0x001c0104 *Powered: yes* Discoverable: no Pairable: yes UUID: Headset AG(1112--1000-8000-00805f9b34fb) UUID: Generic Attribute Profile (1801--1000-8000-00805f9b34fb) UUID: A/V Remote Control(110e--1000-8000-00805f9b34fb) UUID: OBEX File Transfer(1106--1000-8000-00805f9b34fb) UUID: Generic Access Profile(1800--1000-8000-00805f9b34fb) UUID: OBEX Object Push (1105--1000-8000-00805f9b34fb) UUID: PnP Information (1200--1000-8000-00805f9b34fb) UUID: IrMC Sync (1104--1000-8000-00805f9b34fb) UUID: A/V Remote Control Target (110c--1000-8000-00805f9b34fb) UUID: Audio Source (110a--1000-8000-00805f9b34fb) UUID: Audio Sink(110b--1000-8000-00805f9b34fb) UUID: Vendor specific (5005--1000-8000-0002ee01) UUID: Message Notification Se.. (1133--1000-8000-00805f9b34fb) UUID: Phonebook Access Server (112f--1000-8000-00805f9b34fb) UUID: Message Access Server (1132--1000-8000-00805f9b34fb) UUID: Headset (1108--1000-8000-00805f9b34fb) Modalias: usb:v1D6Bp0246d0532 Discovering: no Likewise, I'm not sure how to check the LE details. It doesn't seem to matter whether or not I am moving around. I can set the earbuds down on my desk, a few feet from the BT adapter on my PC, and the connection will go haywire and then drop after a random (but brief) period of time. But I can pair them with my phone and connect without any problems, and walk 10-20 feet away with no signal interruption or disconnections. I did solve one mystery, though: the left/right channels are actually reversed in the earbuds. I tested it on my phone and verified. I have an identical pair at home which do not have this issue, so it must just be a defect in this pair. So at least that's not related to PA or anything else. Thanks, Dave On Thu, Oct 3, 2019 at 3:33 PM deloptes wrote: > David Parker wrote: > > > Thanks for the additional information. Unfortunately, the connection > > problems have returned and I haven't made any progress in solving them. > > When I kill the pulseaudio process, it simply restarts itself and I'm > > unable to stop this behavior, so I therefore can't run it manually with > > the -vvv to further trace the Bluetooth issue. I have followed > everything > > I found online, including the steps from the PulseAudio page in the > Debian > > wiki[1] but nothing seems to work. > > > > you kill the PA server with pulseaudio -k - it shouldn't spawn > automatically > You can also add no-spawn option to the config file > > > I found instructions yesterday to enable PA debugging by adding "-d" to > > its startup options and setting a specific log file. It worked (I got > > output to the file) but it didn't log anything during my subsequent > > Bluetooth issues. > > You didn't answer my previous questions - is it interrupting while you are > moving and did you check > - latency in PA > - power strength on BT > - specific LE details > > > > > > -- Dave Parker '11 Database & Systems Administrator Utica College Integrated Information Technology Services (315) 792-3229 Registered Linux User #408177
Re: Problems with Buster and Bluetooth
Non-flushable Packet Boundary Flag Link Supervision Timeout Changed Event Inquiry TX Power Level Extended features < HCI Command: R.. (0x01|0x001c) plen 3 #672 [hci0] 2019-10-02 11:25:56.688956 Handle: 12 Page: 1 > HCI Event: Command St.. (0x0f) plen 4 #673 [hci0] 2019-10-02 11:25:56.689923 Read Remote Extended Features (0x01|0x001c) ncmd 1 Status: Success (0x00) > HCI Event: Read Remo.. (0x23) plen 13 #674 [hci0] 2019-10-02 11:25:56.694963 Status: Success (0x00) Handle: 12 Page: 1/1 Features: 0x01 0x00 0x00 0x00 0x00 0x00 0x00 0x00 Secure Simple Pairing (Host Support) < HCI Command:... (0x01|0x0019) plen 10 #675 [hci0] 2019-10-02 11:25:56.695006 Address: 9B:1F:48:B8:55:F6 (OUI 9B-1F-48) Page scan repetition mode: R2 (0x02) Page scan mode: Mandatory (0x00) Clock offset: 0x < ACL Data TX: Han.. flags 0x00 dlen 10 #676 [hci0] 2019-10-02 11:25:56.695011 L2CAP: Information Request (0x0a) ident 1 len 2 Type: Extended features supported (0x0002) > HCI Event: Command St.. (0x0f) plen 4 #677 [hci0] 2019-10-02 11:25:56.695956 Remote Name Request (0x01|0x0019) ncmd 1 Status: Success (0x00) > HCI Event: Remote N.. (0x07) plen 255 #678 [hci0] 2019-10-02 11:25:56.716936 Status: Success (0x00) Address: 9B:1F:48:B8:55:F6 (OUI 9B-1F-48) Name: BT910 @ MGMT Event: De.. (0x000b) plen 25 {0x0002} [hci0] 2019-10-02 11:25:56.716969 BR/EDR Address: 9B:1F:48:B8:55:F6 (OUI 9B-1F-48) Flags: 0x Data length: 12 Name (complete): BT910 Class: 0x240404 Major class: Audio/Video (headset, speaker, stereo, video, vcr) Minor class: Wearable Headset Device Rendering (Printing, Speaker) Audio (Speaker, Microphone, Headset) @ MGMT Event: De.. (0x000b) plen 25 {0x0001} [hci0] 2019-10-02 11:25:56.716969 BR/EDR Address: 9B:1F:48:B8:55:F6 (OUI 9B-1F-48) Flags: 0x Data length: 12 Name (complete): BT910 Class: 0x240404 Major class: Audio/Video (headset, speaker, stereo, video, vcr) Minor class: Wearable Headset Device Rendering (Printing, Speaker) Audio (Speaker, Microphone, Headset) < ACL Data TX: Han.. flags 0x00 dlen 12 #679 [hci0] 2019-10-02 11:26:00.830607 L2CAP: Connection Request (0x02) ident 2 len 4 PSM: 1 (0x0001) Source CID: 64 > HCI Event: Disconnect.. (0x05) plen 4 #680 [hci0] 2019-10-02 11:26:02.824947 Status: Success (0x00) Handle: 12 Reason: Remote User Terminated Connection (0x13) @ MGMT Event: Dev.. (0x000c) plen 8 {0x0002} [hci0] 2019-10-02 11:26:02.824985 BR/EDR Address: 9B:1F:48:B8:55:F6 (OUI 9B-1F-48) Reason: Connection terminated by remote host (0x03) @ MGMT Event: Dev.. (0x000c) plen 8 {0x0001} [hci0] 2019-10-02 11:26:02.824985 BR/EDR Address: 9B:1F:48:B8:55:F6 (OUI 9B-1F-48) Reason: Connection terminated by remote host (0x03) = bluetoothd: 9B:1F:48:B8:55:F6: error updating... 2019-10-02 11:26:02.825623 < HCI Command: W.. (0x03|0x001a) plen 1 #681 [hci0] 2019-10-02 11:26:02.862646 Scan enable: Page Scan (0x02) > HCI Event: Command Co.. (0x0e) plen 4 #682 [hci0] 2019-10-02 11:26:02.863930 Write Scan Enable (0x03|0x001a) ncmd 1 Status: Success (0x00) On Wed, Oct 2, 2019 at 10:15 AM David Parker wrote: > Correction: The "-d" for debugging to a file was for bluetoothd, not PA. > > On Wed, Oct 2, 2019 at 10:10 AM David Parker wrote: > >> Thanks for the additional information. Unfortunately, the connection >> problems have returned and I haven't made any progress in solving them. >> When I kill the pulseaudio process, it simply restarts itself and I'm >> unable to stop this behavior, so I therefore can't run it manually with the >> -vvv to further trace the Bluetooth issue. I have followed everything I >> found online, including the steps from the PulseAudio page in the Debian >> wiki[1] but nothing seems to work. >> >> I found instructions yesterday to enable PA debugging by adding "-d" to >> its startup options and setting a specific log file. It worked (I got >> output to the file) but it didn't log anything during my subsequent >> Bluetooth issues. >> >> Thanks, >> Dave >> >> [1] https://wiki.debian.org/PulseAudio#Disabling_daemon_autospawn) >> >> On Thu, Sep 26, 2019 at 3:21 PM deloptes wrote: >> >>> David Parker wrote: >>> >>> > This issue seems to not be fixed entirely, after all. Yesterday, the >>> > earbuds would pair but not connect when I powered them on. I had to >>> > connect them manually each time, us
Re: Problems with Buster and Bluetooth
Correction: The "-d" for debugging to a file was for bluetoothd, not PA. On Wed, Oct 2, 2019 at 10:10 AM David Parker wrote: > Thanks for the additional information. Unfortunately, the connection > problems have returned and I haven't made any progress in solving them. > When I kill the pulseaudio process, it simply restarts itself and I'm > unable to stop this behavior, so I therefore can't run it manually with the > -vvv to further trace the Bluetooth issue. I have followed everything I > found online, including the steps from the PulseAudio page in the Debian > wiki[1] but nothing seems to work. > > I found instructions yesterday to enable PA debugging by adding "-d" to > its startup options and setting a specific log file. It worked (I got > output to the file) but it didn't log anything during my subsequent > Bluetooth issues. > > Thanks, > Dave > > [1] https://wiki.debian.org/PulseAudio#Disabling_daemon_autospawn) > > On Thu, Sep 26, 2019 at 3:21 PM deloptes wrote: > >> David Parker wrote: >> >> > This issue seems to not be fixed entirely, after all. Yesterday, the >> > earbuds would pair but not connect when I powered them on. I had to >> > connect them manually each time, using either bluetoothctl or >> > blueman-manager. At one point they disconnected, and subsequent >> attempts >> > to reconnect them resulted in a "Device or resource busy" error in >> syslog. >> > I had to remove them and go through the pairing and connection process >> > again to fix it. >> > >> > So, there's definitely still a problem here, although they do work most >> of >> > the time, which is better than where I started. >> >> Hmmm - what priority PA is running at? >> >> I don't know really why it is a problem - I think this new combination of >> BT+PA is not quite ready yet, but was forced to us without alternative. I >> suffer in a different way by the replacement of bluez4. >> >> Anyway - what you also can try is try to fine tune PA - for example there >> were options regarding latency and so on. >> >> Also the signal strength - is it breaking when you are moving? >> >> and so on. >> >> I do not think you have to remove pairing to solve the problem - could be >> you restart BT+PA. >> >> Also try running pulseaudio with -v or -vv or -vvv to get more information >> and find out where is exactly your problem. >> >> I also read about LE that this is still somehow buggy, but if you say it >> was >> working for you before ... >> >> regards >> >> > > -- > Dave Parker '11 > Database & Systems Administrator > Utica College > Integrated Information Technology Services > (315) 792-3229 > Registered Linux User #408177 > -- Dave Parker '11 Database & Systems Administrator Utica College Integrated Information Technology Services (315) 792-3229 Registered Linux User #408177
Re: Problems with Buster and Bluetooth
Thanks for the additional information. Unfortunately, the connection problems have returned and I haven't made any progress in solving them. When I kill the pulseaudio process, it simply restarts itself and I'm unable to stop this behavior, so I therefore can't run it manually with the -vvv to further trace the Bluetooth issue. I have followed everything I found online, including the steps from the PulseAudio page in the Debian wiki[1] but nothing seems to work. I found instructions yesterday to enable PA debugging by adding "-d" to its startup options and setting a specific log file. It worked (I got output to the file) but it didn't log anything during my subsequent Bluetooth issues. Thanks, Dave [1] https://wiki.debian.org/PulseAudio#Disabling_daemon_autospawn) On Thu, Sep 26, 2019 at 3:21 PM deloptes wrote: > David Parker wrote: > > > This issue seems to not be fixed entirely, after all. Yesterday, the > > earbuds would pair but not connect when I powered them on. I had to > > connect them manually each time, using either bluetoothctl or > > blueman-manager. At one point they disconnected, and subsequent attempts > > to reconnect them resulted in a "Device or resource busy" error in > syslog. > > I had to remove them and go through the pairing and connection process > > again to fix it. > > > > So, there's definitely still a problem here, although they do work most > of > > the time, which is better than where I started. > > Hmmm - what priority PA is running at? > > I don't know really why it is a problem - I think this new combination of > BT+PA is not quite ready yet, but was forced to us without alternative. I > suffer in a different way by the replacement of bluez4. > > Anyway - what you also can try is try to fine tune PA - for example there > were options regarding latency and so on. > > Also the signal strength - is it breaking when you are moving? > > and so on. > > I do not think you have to remove pairing to solve the problem - could be > you restart BT+PA. > > Also try running pulseaudio with -v or -vv or -vvv to get more information > and find out where is exactly your problem. > > I also read about LE that this is still somehow buggy, but if you say it > was > working for you before ... > > regards > > -- Dave Parker '11 Database & Systems Administrator Utica College Integrated Information Technology Services (315) 792-3229 Registered Linux User #408177
Re: Problems with Buster and Bluetooth
This issue seems to not be fixed entirely, after all. Yesterday, the earbuds would pair but not connect when I powered them on. I had to connect them manually each time, using either bluetoothctl or blueman-manager. At one point they disconnected, and subsequent attempts to reconnect them resulted in a "Device or resource busy" error in syslog. I had to remove them and go through the pairing and connection process again to fix it. So, there's definitely still a problem here, although they do work most of the time, which is better than where I started. On Tue, Sep 24, 2019 at 5:52 PM deloptes wrote: > Mark Fletcher wrote: > > > On Tue, Sep 24, 2019 at 01:21:03PM -0400, David Parker wrote: > >> Ok, I think I may have solved the connectivity issue. Some additional > >> Googling revealed that GDM starts an instance of PulseAudio, and that > >> conflicts with the PulseAudio server used by the Bluetooth device. The > >> steps to stop GDM from starting PulseAudio can be found online, and I've > >> adapted them for Buster here: > >> > >> (as root): > >> echo "autospawn = no" >> /var/lib/gdm3/.config/pulse/client.conf > >> echo "daemon-binary = /bin/true" >> > >> /var/lib/gdm3/.config/pulse/client.conf su - Debian-gdm -c "mkdir -p > >> /var/lib/gdm3/.config/systemd/user" su - Debian-gdm -c "ln -s /dev/null > >> /var/lib/gdm/.config/systemd/user/pulseaudio.socket" > >> > > > > Ah -- that old chestnut! I had that problem back in the day (wheezy or > > stretch, I don't remember which) with a pair of high-end bluetooth > > headphones. > > > > I recently fresh-installed Buster, I've used Bluetooth with a speaker > > but not with my headphones without problems, but I just checked and I > > _do_ have 2 instances of pulseaudio running, one as my regular user and > > one as Debian-. Isn't that a bug in Debian's setup? Is there > > some reason one would want things that way? > > > > Mark > > I just check, I do not use gdm - don't have it installed, but I also have > two processes. I found this and many other entries dedicated to the topic > > https://lists.debian.org/debian-user/2015/11/msg01119.html > > However I do not have any issues with audio - very strange - also the date > of the thread. > > regards > > > -- Dave Parker '11 Database & Systems Administrator Utica College Integrated Information Technology Services (315) 792-3229 Registered Linux User #408177
Re: Problems with Buster and Bluetooth
Ok, I think I may have solved the connectivity issue. Some additional Googling revealed that GDM starts an instance of PulseAudio, and that conflicts with the PulseAudio server used by the Bluetooth device. The steps to stop GDM from starting PulseAudio can be found online, and I've adapted them for Buster here: (as root): echo "autospawn = no" >> /var/lib/gdm3/.config/pulse/client.conf echo "daemon-binary = /bin/true" >> /var/lib/gdm3/.config/pulse/client.conf su - Debian-gdm -c "mkdir -p /var/lib/gdm3/.config/systemd/user" su - Debian-gdm -c "ln -s /dev/null /var/lib/gdm/.config/systemd/user/pulseaudio.socket" After a reboot, the issue seems to be fixed. The earbuds have now been connected for over 40 minutes. The channels are still reversed, but at least now they'll stay connected long enough to troubleshoot that problem. - Dave On Tue, Sep 24, 2019 at 12:06 PM David Parker wrote: > Oh man, it turns out the original issue is still there, too. The earbuds > stayed connected for about 15 minutes, but suddenly the sound got really > choppy and distorted, and then went silent, and then they disconnected and > this was in syslog: > > Sep 24 12:02:58 debian bluetoothd[627]: Start: Connection timed out (110) > Sep 24 12:02:58 debian pulseaudio[1408]: E: [bluetooth] bluez5-util.c: > Transport Acquire() failed for transport > /org/bluez/hci0/dev_9B_1F_48_B8_55_F6/fd0 (Input/output error) > Sep 24 12:02:58 debian bluetoothd[627]: avdtp_start failed > Sep 24 12:02:58 debian pulseaudio[1408]: E: [bluetooth] bluez5-util.c: > Transport Acquire() failed for transport > /org/bluez/hci0/dev_9B_1F_48_B8_55_F6/fd0 (Operation Not Authorized) > Sep 24 12:03:00 debian bluetoothd[627]: Abort: Connection timed out (110) > Sep 24 12:03:00 debian gsd-media-keys[1510]: Unable to get default sink > > So it looks like I still have Bluetooth and/or pulseaudio issues here. > This was definitely broken by something that changed between Jessie and > Buster. Should I file a bug report, perhaps? > > On Tue, Sep 24, 2019 at 11:58 AM David Parker wrote: > >> Thanks for the advice. I unpaired the earbuds, removed my >> ~/.config/pulse directory, rebooted, then used bluetoothctl to trust, pair, >> and connect them again. It seems to have worked (they have been connected >> for about 10 minutes and have not disconnected yet), but I am still having >> a few issues which I did not have under Jessie: >> >> 1. The left/right channels are swapped (according to the speaker test in >> the Gnome sound settings) >> 2. The sound frequently becomes choppy and/or cuts out for several >> seconds. I am sitting about 3 feet from the USB Bluetooth adapter plugged >> into the PC, and it was always fine before. >> >> Any ideas on fixing the channels and sound quality? >> >> Thanks! >> >> On Fri, Sep 20, 2019 at 5:40 PM deloptes wrote: >> >>> David Parker wrote: >>> >>> > But I just got a new PC and installed Buster on >>> > it, and now I struggle just to get the earbuds paired and connected >>> >>> if there are problems with the GUI in Gnome use bluetoothctl for pairing >>> There are also few options you may try >>> >>> >>> >>> >> >> -- >> Dave Parker '11 >> Database & Systems Administrator >> Utica College >> Integrated Information Technology Services >> (315) 792-3229 >> Registered Linux User #408177 >> > > > -- > Dave Parker '11 > Database & Systems Administrator > Utica College > Integrated Information Technology Services > (315) 792-3229 > Registered Linux User #408177 > -- Dave Parker '11 Database & Systems Administrator Utica College Integrated Information Technology Services (315) 792-3229 Registered Linux User #408177
Re: Problems with Buster and Bluetooth
Oh man, it turns out the original issue is still there, too. The earbuds stayed connected for about 15 minutes, but suddenly the sound got really choppy and distorted, and then went silent, and then they disconnected and this was in syslog: Sep 24 12:02:58 debian bluetoothd[627]: Start: Connection timed out (110) Sep 24 12:02:58 debian pulseaudio[1408]: E: [bluetooth] bluez5-util.c: Transport Acquire() failed for transport /org/bluez/hci0/dev_9B_1F_48_B8_55_F6/fd0 (Input/output error) Sep 24 12:02:58 debian bluetoothd[627]: avdtp_start failed Sep 24 12:02:58 debian pulseaudio[1408]: E: [bluetooth] bluez5-util.c: Transport Acquire() failed for transport /org/bluez/hci0/dev_9B_1F_48_B8_55_F6/fd0 (Operation Not Authorized) Sep 24 12:03:00 debian bluetoothd[627]: Abort: Connection timed out (110) Sep 24 12:03:00 debian gsd-media-keys[1510]: Unable to get default sink So it looks like I still have Bluetooth and/or pulseaudio issues here. This was definitely broken by something that changed between Jessie and Buster. Should I file a bug report, perhaps? On Tue, Sep 24, 2019 at 11:58 AM David Parker wrote: > Thanks for the advice. I unpaired the earbuds, removed my ~/.config/pulse > directory, rebooted, then used bluetoothctl to trust, pair, and connect > them again. It seems to have worked (they have been connected for about 10 > minutes and have not disconnected yet), but I am still having a few issues > which I did not have under Jessie: > > 1. The left/right channels are swapped (according to the speaker test in > the Gnome sound settings) > 2. The sound frequently becomes choppy and/or cuts out for several > seconds. I am sitting about 3 feet from the USB Bluetooth adapter plugged > into the PC, and it was always fine before. > > Any ideas on fixing the channels and sound quality? > > Thanks! > > On Fri, Sep 20, 2019 at 5:40 PM deloptes wrote: > >> David Parker wrote: >> >> > But I just got a new PC and installed Buster on >> > it, and now I struggle just to get the earbuds paired and connected >> >> if there are problems with the GUI in Gnome use bluetoothctl for pairing >> There are also few options you may try >> >> >> >> > > -- > Dave Parker '11 > Database & Systems Administrator > Utica College > Integrated Information Technology Services > (315) 792-3229 > Registered Linux User #408177 > -- Dave Parker '11 Database & Systems Administrator Utica College Integrated Information Technology Services (315) 792-3229 Registered Linux User #408177
Re: Problems with Buster and Bluetooth
Thanks for the advice. I unpaired the earbuds, removed my ~/.config/pulse directory, rebooted, then used bluetoothctl to trust, pair, and connect them again. It seems to have worked (they have been connected for about 10 minutes and have not disconnected yet), but I am still having a few issues which I did not have under Jessie: 1. The left/right channels are swapped (according to the speaker test in the Gnome sound settings) 2. The sound frequently becomes choppy and/or cuts out for several seconds. I am sitting about 3 feet from the USB Bluetooth adapter plugged into the PC, and it was always fine before. Any ideas on fixing the channels and sound quality? Thanks! On Fri, Sep 20, 2019 at 5:40 PM deloptes wrote: > David Parker wrote: > > > But I just got a new PC and installed Buster on > > it, and now I struggle just to get the earbuds paired and connected > > if there are problems with the GUI in Gnome use bluetoothctl for pairing > There are also few options you may try > > > > -- Dave Parker '11 Database & Systems Administrator Utica College Integrated Information Technology Services (315) 792-3229 Registered Linux User #408177
Problems with Buster and Bluetooth
Hello, I have a set of Bluetooth earbuds and a USB Bluetooth adapter (Plugable USB-BT4LE). With minimal effort, I had everything working fine under Jessie for several months. But I just got a new PC and installed Buster on it, and now I struggle just to get the earbuds paired and connected, and when they do connect, it's not long before they randomly disconnect again. And when they are connected, the left and right channels are reversed (per the speaker test in Gnome Settings > Sound > Output > Test Speakers). I have tried just about everything I can find in my Google searches. Nothing seems to work. When the earbuds fail to connect after pairing, syslog shows the following: Sep 20 15:11:59 debian bluetoothd[654]: connect error: Software caused connection abort (103) And when they disconnect after some random interval: Sep 20 15:23:48 debian bluetoothd[654]: Start: Connection timed out (110) Sep 20 15:23:48 debian pulseaudio[1381]: E: [pulseaudio] bluez5-util.c: Transport Acquire() failed for transport /org/bluez/hci0/dev_9B_1F_48_B8_55_F6/fd1 (Input/output error) Sep 20 15:23:50 debian bluetoothd[654]: Abort: Connection timed out (110) What's most frustrating about all of this is that I was able to get them paired, connected, and used as the default output with very little hassle under Debian 9. I'm not sure what's changed in 10, but I've been trying to get this working for days and I'm out of ideas. Any help is greatly appreciated. Thanks, Dave -- Dave Parker '11 Database & Systems Administrator Utica College Integrated Information Technology Services (315) 792-3229 Registered Linux User #408177
Re: Removing firefox-esr also removes gnome
Thanks for the information. I guess I'm just surprised that the dependencies are limited to firefox/firefox-esr/chromium. Seems like other browsers like Iceweasel are just arbitrarily left out. - Dave On Mon, Nov 5, 2018 at 12:01 PM Greg Wooledge wrote: > On Mon, Nov 05, 2018 at 11:55:48AM -0500, David Parker wrote: > > Does anyone know why Gnome apparently depends on > > firefox-esr, and how I can just uninstall firefox-esr and leave Gnome > alone? > > apt-cache show gnome-core | grep Depends > > It says "... firefox-esr (>= 30) | firefox (>= 30) | chromium ..." > so you would need to replace firefox-esr with one of those two > alternatives instead of just flat-out trying to remove it. > > -- Dave Parker '11 Database & Systems Administrator Utica College Integrated Information Technology Services (315) 792-3229 Registered Linux User #408177
Removing firefox-esr also removes gnome
Hello, I'm running Debian 9.5 (amd64) and attempting to uninstall firefox-esr. However, apt says that gnome and gnome-core are among the packages which will also be uninstalled. Does anyone know why Gnome apparently depends on firefox-esr, and how I can just uninstall firefox-esr and leave Gnome alone? Thanks! # apt-get remove firefox-esr Reading package lists... Done Building dependency tree Reading state information... Done The following packages were automatically installed and are no longer required: empathy empathy-common fonts-stix hyphen-en-us libdiscid0 libjsoncpp1 libreoffice libreoffice-help-en-us libreoffice-report-builder-bin libtelepathy-farstream3 mythes-en-us sound-juicer telepathy-gabble telepathy-salut Use 'apt autoremove' to remove them. The following packages will be REMOVED: firefox-esr gnome gnome-core iceweasel libarchive12 libepc-1.0-3 libepc-ui-1.0-3 libgnutls-deb0-28 libgnutls28 libhogweed2 libhogweed2:i386 libnettle4 libnettle4:i386 task-gnome-desktop 0 upgraded, 0 newly installed, 14 to remove and 82 not upgraded. After this operation, 121 MB disk space will be freed. Do you want to continue? [Y/n] n Abort. -- Dave Parker '11 Database & Systems Administrator Utica College Integrated Information Technology Services (315) 792-3229 Registered Linux User #408177
Re: Error while upgrading from Wheezy to Stretch
I never thought to use the backports repo in Jessie to keep pacemaker installed. That's a great idea, I'll give it a try and see what happens. Regarding Pacemaker's data and config, as far as I could tell, it was gone. I'm not positive what happened with it, but I wonder if the fact that the pacemaker package was missing entirely from the new release caused apt to just get rid of it during the upgrade. I can also re-try that and keep closer track of what gets removed. I do know that when I upgraded from Wheezy to Jessie and then to Stretch, and then I re-installed Pacemaker in Stretch, it didn't find any old config data and acted like a new installation. Thanks! Dave On Thu, Apr 19, 2018 at 11:32 AM, Roberto C. Sánchezwrote: > On Thu, Apr 19, 2018 at 11:26:20AM -0400, Greg Wooledge wrote: > > > > According to http://packages.debian.org/pacemaker there is also a > > backport of the stretch version of the package in the jessie-backports > > repository. So perhaps there is some way to convince the jessie upgrade > > to use the jessie-backports version of this package rather than removing > > it. But that's beyond my experience. > > > > I totally forgot about backports. Generally, including backports > repositories of the upgrade target (i.e., the suite being upgraded to) > is not a good idea. However, this situation would qualify as extenuating > circumstances. Plus, someone who manages a HA cluster almost certainly > has the skills to deal with the occasional minor hiccup assocaited with > mixing backports into an upgrade. > > The only thing I would say is use apt "pinning" to prioritize the > backports repository lower than the other repositories so you don't > accidentally get backports for *everything* that has a backport > available. > > Regards, > > -Roberto > -- > Roberto C. Sánchez > > -- Dave Parker '11 Database & Systems Administrator Utica College Integrated Information Technology Services (315) 792-3229 Registered Linux User #408177
Re: Error while upgrading from Wheezy to Stretch
Hi all, Sorry I didn't get back to this sooner, had some crazy life stuff getting in the way. I should have said in my original post that there is a reason I'm trying to jump from Wheezy to Stretch. These boxes are in an HA cluster with Pacemaker, Corosync, and DRBD. I have all 3 of these installed from the Debian packages. Pacemaker is not in Jessie (apparently the devs missed the deadline for inclusion), so an upgrade to Jessie uninstalls pacemaker and all of its configuration. That's what I was hoping to avoid, because setting up an configuring Pacemaker always takes me a while to get right, so an upgrade path which does not include the removal of it is preferable. I did read the documentation and I did try Wheezy -> Jessie - > Stretch first, but the problem was that Pacemaker was removed. Hence, I was hoping to skip Jessie. If it's simply not possible to do this upgrade then I guess that's that. I'll have to reinstall and reconfigure Pacemaker, which hopefully will continue to be delivered in future releases without fail. Thanks, Dave On Thu, Apr 12, 2018 at 2:35 PM, David Wright <deb...@lionunicorn.co.uk> wrote: > On Thu 12 Apr 2018 at 06:42:33 (-0400), Dan Ritter wrote: > > On Wed, Apr 11, 2018 at 07:57:07PM -0500, David Wright wrote: > > > On Wed 11 Apr 2018 at 15:31:32 (-0400), David Parker wrote: > > > > I am trying to upgrade two test boxes from Wheezy to Stretch > (skipping > > > > Jessie). The upgrade worked on one of them, although I ran into > errors and > > > > had to run "apt-get -f install" a few times, but that resolved the > issues > > > > and it ultimately worked. > > > > > > > > However, on the second box, I ran into an error about halfway > through the > > > > upgrade, and I'm not able to get past it. No matter what I do, I > keep > > > > running into version mismatch issue with libpam-modules. It's > preventing > > > > the upgrade from finishing. > > > > > > The other "incantation" that's worth trying is > > > > > > # dpkg --configure -a > > That's the short answer. > > > I would start by reinstating jessie in all of your sources > > files, then try dpkg --configure -a, then apt-get -f install, > > then apt-get dist-upgrade to jessie. After a successful jessie > > reboot, upgrade to stretch. > > dpkg --configure -a and apt-get -f install can be useful > to fix a logjam, but when you get an error like > E: Sub-process /usr/bin/dpkg returned an error code (1) > it's worth running dpkg directly, seeing which packages are stuck, > and then try dpkg -i > as this can sometimes fix circular and reciprocal dependencies > that running from apt* is unable to solve. > > BTW if they're test boxes, keep on trying: you may learn something > useful about rescuing systems, which the reinstall people won't. > > Cheers, > David. > > -- Dave Parker '11 Database & Systems Administrator Utica College Integrated Information Technology Services (315) 792-3229 Registered Linux User #408177
Error while upgrading from Wheezy to Stretch
Hello, I am trying to upgrade two test boxes from Wheezy to Stretch (skipping Jessie). The upgrade worked on one of them, although I ran into errors and had to run "apt-get -f install" a few times, but that resolved the issues and it ultimately worked. However, on the second box, I ran into an error about halfway through the upgrade, and I'm not able to get past it. No matter what I do, I keep running into version mismatch issue with libpam-modules. It's preventing the upgrade from finishing. # apt-get -f install Reading package lists... Done Building dependency tree Reading state information... Done Correcting dependencies... Done The following packages were automatically installed and are no longer required: libcfg4 libcib1 libclass-isa-perl libconfdb4 libcoroipcc4 libcoroipcs4 libcrmcluster1 libcrmcommon2 libevs4 liblogsys4 libpe-status3 libpengine3 libpload4 libquorum4 libsam4 libstonithd1 libswitch-perl libsystemd-login0 libtransitioner1 libvotequorum4 Use 'apt autoremove' to remove them. The following additional packages will be installed: libpam-modules The following packages will be upgraded: libpam-modules 1 upgraded, 0 newly installed, 0 to remove and 199 not upgraded. 2 not fully installed or removed. Need to get 0 B/308 kB of archives. After this operation, 62.5 kB of additional disk space will be used. Do you want to continue? [Y/n] Preconfiguring packages ... dpkg: dependency problems prevent processing triggers for man-db: man-db depends on bsdmainutils; however: Package bsdmainutils is not configured yet. dpkg: error processing archive /var/cache/apt/archives/libpam-modules_1.1.8-3.6_amd64.deb (--unpack): dependency problems - leaving triggers unprocessed Errors were encountered while processing: /var/cache/apt/archives/libpam-modules_1.1.8-3.6_amd64.deb E: Sub-process /usr/bin/dpkg returned an error code (1) Any ideas or suggestions for resolving this will be greatly appreciated. Thanks! Dave -- Dave Parker '11 Database & Systems Administrator Utica College Integrated Information Technology Services (315) 792-3229 Registered Linux User #408177
Re: All of my enoX interfaces are mapped to eth0
I don't normally set IP addresses on interfaces which I know to be offline, so perhaps my methodology here was flawed. In this case, I set IP addresses on eno2, eno3, and eno4 to test whether or not they were actually discrete interfaces, or if they were all somehow mapped to the one interface which was actually connected. Normally, I only set IP addresses on interfaces which are already connected, but in that case I will stop seeing a ping response from any IP on an interface which is subsequently disconnected, regardless of whether or not I have multiple interfaces on the same subnet. The reason I was trying to figure out whether or not they were actually mapped to the same physical interface was that I needed to setup a bonded interface. A quick unload/reload of the network driver resulted in a correct mapping (eno1->eth0, eno2->eth1, etc.) and then I was able to set up the bonded interface in active/passive failover mode just fine. So it's all set now. Thanks! On Sat, Mar 31, 2018 at 10:11 AM, David Wright <deb...@lionunicorn.co.uk> wrote: > On Fri 30 Mar 2018 at 23:16:26 (-0400), David Parker wrote: > > They are all on the same subnet, yes. But I haven't ever seen this > > behavior before. Normally, when I have an interface which is unplugged, > > its IP is unreachable. > > So we have two machines, one with eth0, eth1, eth2, eth3 and one > with eno1, eno2, eno3, eno4. The first one has no issues, and the > second reportedly does. > > What differences are there in the symptoms presented by the two > machines? Are the former's interfaces on the same subnet too? > > AIUI, which is not very much, your ping behaviour is not unexpected, > and running multiple interfaces on the same subnet takes some out > of the ordinary configuration. (Or are your interfaces eno2-4 just > treading water until you have something to connect them too?) > > Cheers, > David. > > -- Dave Parker '11 Database & Systems Administrator Utica College Integrated Information Technology Services (315) 792-3229 Registered Linux User #408177
Re: All of my enoX interfaces are mapped to eth0
They are all on the same subnet, yes. But I haven't ever seen this behavior before. Normally, when I have an interface which is unplugged, its IP is unreachable. On Fri, Mar 30, 2018 at 10:30 PM, David Wright <deb...@lionunicorn.co.uk> wrote: > On Fri 30 Mar 2018 at 22:01:23 (-0400), David Parker wrote: > > That's what I thought, too. As you pointed out, the logs show each eno > > interface being assigned to a different MAC address. However, I am able > to > > assign IP addresses to any (or all) of those interfaces and then ping > them > > from a different machine, even though the first interface is the only one > > which is physically connected to the network. The other three interfaces > > are unplugged. So that leads me to believe that all 4 eno interfaces are > > actually mapping to the first physical interface (a.k.a. eth0). > > Do you have the IP addresses for the different interfaces on the same > subnet? > > Cheers, > David. > > -- Dave Parker '11 Database & Systems Administrator Utica College Integrated Information Technology Services (315) 792-3229 Registered Linux User #408177
Re: All of my enoX interfaces are mapped to eth0
That's what I thought, too. As you pointed out, the logs show each eno interface being assigned to a different MAC address. However, I am able to assign IP addresses to any (or all) of those interfaces and then ping them from a different machine, even though the first interface is the only one which is physically connected to the network. The other three interfaces are unplugged. So that leads me to believe that all 4 eno interfaces are actually mapping to the first physical interface (a.k.a. eth0). That's why I'm really confused. Thanks! On Fri, Mar 30, 2018 at 7:50 PM, David Wright <deb...@lionunicorn.co.uk> wrote: > On Fri 30 Mar 2018 at 16:19:30 (-0400), David Parker wrote: > > Hello, > > > > I have two identical HP servers running Debian 9. One of them is a clean > > install of 9, whereas the other was upgraded from Debian 8. > > > > The one that was upgraded has no networking issues (indeed, it still uses > > the ethX interface names). However, the one that was installed from > > scratch is having an issue which I can't seem to figure out. There are 4 > > network interfaces -- eno[1-4] -- but they are all getting mapped to > eth0. > > It looks like they were mapped correctly until I reloaded the network > > driver a few days ago. Any idea how I can get them back into a 1:1 > mapping > > with the actual physical interfaces, instead of all pointing to the same > > one? > > > > Some dmesg output for reference: > > > > [Wed Mar 28 17:00:45 2018] tg3.c:v3.137 (May 11, 2014) > > [Wed Mar 28 17:00:45 2018] tg3 :03:00.0 eth0: Tigon3 > > [partno(629133-001) rev 5719001] (PCI Express) MAC address > d8:9d:67:2c:ec:e0 > > [Wed Mar 28 17:00:45 2018] tg3 :03:00.0 eth0: attached PHY is 5719C > > (10/100/1000Base-T Ethernet) (WireSpeed[1], EEE[1]) > > [Wed Mar 28 17:00:45 2018] tg3 :03:00.0 eth0: RXcsums[1] > LinkChgREG[0] > > MIirq[0] ASF[1] TSOcap[1] > > [Wed Mar 28 17:00:45 2018] tg3 :03:00.0 eth0: dma_rwctrl[0001] > > dma_mask[64-bit] > > [Wed Mar 28 17:00:45 2018] tg3 :03:00.1 eth1: Tigon3 > > [partno(629133-001) rev 5719001] (PCI Express) MAC address > d8:9d:67:2c:ec:e1 > > [Wed Mar 28 17:00:45 2018] tg3 :03:00.1 eth1: attached PHY is 5719C > > (10/100/1000Base-T Ethernet) (WireSpeed[1], EEE[1]) > > [Wed Mar 28 17:00:45 2018] tg3 :03:00.1 eth1: RXcsums[1] > LinkChgREG[0] > > MIirq[0] ASF[1] TSOcap[1] > > [Wed Mar 28 17:00:45 2018] tg3 :03:00.1 eth1: dma_rwctrl[0001] > > dma_mask[64-bit] > > [Wed Mar 28 17:00:45 2018] tg3 :03:00.2 eth2: Tigon3 > > [partno(629133-001) rev 5719001] (PCI Express) MAC address > d8:9d:67:2c:ec:e2 > > [Wed Mar 28 17:00:45 2018] tg3 :03:00.2 eth2: attached PHY is 5719C > > (10/100/1000Base-T Ethernet) (WireSpeed[1], EEE[1]) > > [Wed Mar 28 17:00:45 2018] tg3 :03:00.2 eth2: RXcsums[1] > LinkChgREG[0] > > MIirq[0] ASF[1] TSOcap[1] > > [Wed Mar 28 17:00:45 2018] tg3 :03:00.2 eth2: dma_rwctrl[0001] > > dma_mask[64-bit] > > [Wed Mar 28 17:00:45 2018] tg3 :03:00.3 eth3: Tigon3 > > [partno(629133-001) rev 5719001] (PCI Express) MAC address > d8:9d:67:2c:ec:e3 > > [Wed Mar 28 17:00:45 2018] tg3 :03:00.3 eth3: attached PHY is 5719C > > (10/100/1000Base-T Ethernet) (WireSpeed[1], EEE[1]) > > [Wed Mar 28 17:00:45 2018] tg3 :03:00.3 eth3: RXcsums[1] > LinkChgREG[0] > > MIirq[0] ASF[1] TSOcap[1] > > [Wed Mar 28 17:00:45 2018] tg3 :03:00.3 eth3: dma_rwctrl[0001] > > dma_mask[64-bit] > > > > > > > > *[Wed Mar 28 17:00:45 2018] tg3 :03:00.1 eno2: renamed from eth1[Wed > > Mar 28 17:00:45 2018] tg3 :03:00.0 eno1: renamed from eth0[Wed Mar 28 > > 17:00:45 2018] tg3 :03:00.3 eno4: renamed from eth3[Wed Mar 28 > 17:00:45 > > 2018] tg3 :03:00.2 eno3: renamed from eth2* > > > > Looks fine, but then... > > > > [Wed Mar 28 17:12:33 2018] tg3.c:v3.137 (May 11, 2014) > > [Wed Mar 28 17:12:33 2018] tg3 :03:00.0 eth0: Tigon3 > > [partno(629133-001) rev 5719001] (PCI Express) MAC address > d8:9d:67:2c:ec:e0 > > [Wed Mar 28 17:12:33 2018] tg3 :03:00.0 eth0: attached PHY is 5719C > > (10/100/1000Base-T Ethernet) (WireSpeed[1], EEE[1]) > > [Wed Mar 28 17:12:33 2018] tg3 :03:00.0 eth0: RXcsums[1] > LinkChgREG[0] > > MIirq[0] ASF[1] TSOcap[1] > > [Wed Mar 28 17:12:33 2018] tg3 :03:00.0 eth0: dma_rwctrl[0001] > > dma_mask[64-bit] > > *[Wed Mar 28 17:12:33 2018] tg3 :03:00.0 eno1: renamed from eth0* > > [Wed Mar 28 17:12:33 2018] tg3 :03:00.1 eth0: Tigon3 > > [partno(629133-001) rev 5719001] (PCI Express) MAC address &
All of my enoX interfaces are mapped to eth0
Hello, I have two identical HP servers running Debian 9. One of them is a clean install of 9, whereas the other was upgraded from Debian 8. The one that was upgraded has no networking issues (indeed, it still uses the ethX interface names). However, the one that was installed from scratch is having an issue which I can't seem to figure out. There are 4 network interfaces -- eno[1-4] -- but they are all getting mapped to eth0. It looks like they were mapped correctly until I reloaded the network driver a few days ago. Any idea how I can get them back into a 1:1 mapping with the actual physical interfaces, instead of all pointing to the same one? Some dmesg output for reference: [Wed Mar 28 17:00:45 2018] tg3.c:v3.137 (May 11, 2014) [Wed Mar 28 17:00:45 2018] tg3 :03:00.0 eth0: Tigon3 [partno(629133-001) rev 5719001] (PCI Express) MAC address d8:9d:67:2c:ec:e0 [Wed Mar 28 17:00:45 2018] tg3 :03:00.0 eth0: attached PHY is 5719C (10/100/1000Base-T Ethernet) (WireSpeed[1], EEE[1]) [Wed Mar 28 17:00:45 2018] tg3 :03:00.0 eth0: RXcsums[1] LinkChgREG[0] MIirq[0] ASF[1] TSOcap[1] [Wed Mar 28 17:00:45 2018] tg3 :03:00.0 eth0: dma_rwctrl[0001] dma_mask[64-bit] [Wed Mar 28 17:00:45 2018] tg3 :03:00.1 eth1: Tigon3 [partno(629133-001) rev 5719001] (PCI Express) MAC address d8:9d:67:2c:ec:e1 [Wed Mar 28 17:00:45 2018] tg3 :03:00.1 eth1: attached PHY is 5719C (10/100/1000Base-T Ethernet) (WireSpeed[1], EEE[1]) [Wed Mar 28 17:00:45 2018] tg3 :03:00.1 eth1: RXcsums[1] LinkChgREG[0] MIirq[0] ASF[1] TSOcap[1] [Wed Mar 28 17:00:45 2018] tg3 :03:00.1 eth1: dma_rwctrl[0001] dma_mask[64-bit] [Wed Mar 28 17:00:45 2018] tg3 :03:00.2 eth2: Tigon3 [partno(629133-001) rev 5719001] (PCI Express) MAC address d8:9d:67:2c:ec:e2 [Wed Mar 28 17:00:45 2018] tg3 :03:00.2 eth2: attached PHY is 5719C (10/100/1000Base-T Ethernet) (WireSpeed[1], EEE[1]) [Wed Mar 28 17:00:45 2018] tg3 :03:00.2 eth2: RXcsums[1] LinkChgREG[0] MIirq[0] ASF[1] TSOcap[1] [Wed Mar 28 17:00:45 2018] tg3 :03:00.2 eth2: dma_rwctrl[0001] dma_mask[64-bit] [Wed Mar 28 17:00:45 2018] tg3 :03:00.3 eth3: Tigon3 [partno(629133-001) rev 5719001] (PCI Express) MAC address d8:9d:67:2c:ec:e3 [Wed Mar 28 17:00:45 2018] tg3 :03:00.3 eth3: attached PHY is 5719C (10/100/1000Base-T Ethernet) (WireSpeed[1], EEE[1]) [Wed Mar 28 17:00:45 2018] tg3 :03:00.3 eth3: RXcsums[1] LinkChgREG[0] MIirq[0] ASF[1] TSOcap[1] [Wed Mar 28 17:00:45 2018] tg3 :03:00.3 eth3: dma_rwctrl[0001] dma_mask[64-bit] *[Wed Mar 28 17:00:45 2018] tg3 :03:00.1 eno2: renamed from eth1[Wed Mar 28 17:00:45 2018] tg3 :03:00.0 eno1: renamed from eth0[Wed Mar 28 17:00:45 2018] tg3 :03:00.3 eno4: renamed from eth3[Wed Mar 28 17:00:45 2018] tg3 :03:00.2 eno3: renamed from eth2* Looks fine, but then... [Wed Mar 28 17:12:33 2018] tg3.c:v3.137 (May 11, 2014) [Wed Mar 28 17:12:33 2018] tg3 :03:00.0 eth0: Tigon3 [partno(629133-001) rev 5719001] (PCI Express) MAC address d8:9d:67:2c:ec:e0 [Wed Mar 28 17:12:33 2018] tg3 :03:00.0 eth0: attached PHY is 5719C (10/100/1000Base-T Ethernet) (WireSpeed[1], EEE[1]) [Wed Mar 28 17:12:33 2018] tg3 :03:00.0 eth0: RXcsums[1] LinkChgREG[0] MIirq[0] ASF[1] TSOcap[1] [Wed Mar 28 17:12:33 2018] tg3 :03:00.0 eth0: dma_rwctrl[0001] dma_mask[64-bit] *[Wed Mar 28 17:12:33 2018] tg3 :03:00.0 eno1: renamed from eth0* [Wed Mar 28 17:12:33 2018] tg3 :03:00.1 eth0: Tigon3 [partno(629133-001) rev 5719001] (PCI Express) MAC address d8:9d:67:2c:ec:e1 [Wed Mar 28 17:12:33 2018] tg3 :03:00.1 eth0: attached PHY is 5719C (10/100/1000Base-T Ethernet) (WireSpeed[1], EEE[1]) [Wed Mar 28 17:12:33 2018] tg3 :03:00.1 eth0: RXcsums[1] LinkChgREG[0] MIirq[0] ASF[1] TSOcap[1] [Wed Mar 28 17:12:33 2018] tg3 :03:00.1 eth0: dma_rwctrl[0001] dma_mask[64-bit] *[Wed Mar 28 17:12:33 2018] tg3 :03:00.1 eno2: renamed from eth0* [Wed Mar 28 17:12:33 2018] tg3 :03:00.2 eth0: Tigon3 [partno(629133-001) rev 5719001] (PCI Express) MAC address d8:9d:67:2c:ec:e2 [Wed Mar 28 17:12:33 2018] tg3 :03:00.2 eth0: attached PHY is 5719C (10/100/1000Base-T Ethernet) (WireSpeed[1], EEE[1]) [Wed Mar 28 17:12:33 2018] tg3 :03:00.2 eth0: RXcsums[1] LinkChgREG[0] MIirq[0] ASF[1] TSOcap[1] [Wed Mar 28 17:12:33 2018] tg3 :03:00.2 eth0: dma_rwctrl[0001] dma_mask[64-bit] *[Wed Mar 28 17:12:33 2018] tg3 :03:00.2 eno3: renamed from eth0* [Wed Mar 28 17:12:33 2018] tg3 :03:00.3 eth0: Tigon3 [partno(629133-001) rev 5719001] (PCI Express) MAC address d8:9d:67:2c:ec:e3 [Wed Mar 28 17:12:33 2018] tg3 :03:00.3 eth0: attached PHY is 5719C (10/100/1000Base-T Ethernet) (WireSpeed[1], EEE[1]) [Wed Mar 28 17:12:33 2018] tg3 :03:00.3 eth0: RXcsums[1] LinkChgREG[0] MIirq[0] ASF[1] TSOcap[1] [Wed Mar 28 17:12:33 2018] tg3 :03:00.3 eth0: dma_rwctrl[0001] dma_mask[64-bit] *[Wed Mar 28 17:12:33 2018] tg3 :03:00.3 eno4: renamed from eth0* I should note that this server is now
Re: Open socket not connected to any real process
Well, crap. It turns out this isn't a problem. PAM is configured for LDAP authentication and so it opens a connection each time I log in, owned by my sshd process, even though it's not using LDAP authentication for root. And the other LDAP queries I'm seeing are being sent when users authenticate via sendmail. Case closed! On Wed, Mar 7, 2018 at 4:16 PM, David Parker <dpar...@utica.edu> wrote: > Hello, > > I have an SMTP server running Debian Wheezy (64-bit). A few weeks ago, I > stopped nscd on it, because it was holding a connection open to our LDAP > server and sending a ton of unnecessary queries to it. > > Even though nscd is not running, I am once again seeing nscd-type queries > on the LDAP server from this SMTP server, and a connection is open from the > SMTP server. But I can't seem to figure out what process is using that > connection. Every time I check using netstat or lsof, it just reports that > the socket is owned by my current sshd process. > > An example: > > root@smtp:~# netstat -anp | grep 389 > tcp0 0 :58786 :389ESTABLISHED > *10249/0* > > root@smtp:~# lsof -n -i :389 > COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME > sshd*10249 root*4w IPv4 86936230 0t0 TCP > :58786->:ldap (ESTABLISHED) > > root@smtp:~# ps -ef | grep 10249 > *root 10249 17111 0 15:49 ?00:00:00 sshd: root@pts/0* > root 10251 10249 0 15:50 pts/000:00:00 -bash > root 10286 10251 0 15:54 pts/000:00:00 grep 10249 > > So I log out and back in, and the PID for this socket changes to my new > sshd process: > > root@smtp:~# netstat -anp | grep 389 > tcp0 0 :58798 :389ESTABLISHED > *10288/0* > > root@smtp:~# lsof -n -i :389 > COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME > sshd*10288 root*4w IPv4 86936319 0t0 TCP > :58798->:ldap (ESTABLISHED) > > root@smtp:~# ps -ef | grep 10288 > *root 10288 17111 0 15:54 ?00:00:00 sshd: root@pts/0* > root 10290 10288 0 15:54 pts/000:00:00 -bash > root 10304 10290 0 15:55 pts/000:00:00 grep 10288 > > And all the while, LDAP queries continue to be sent over this connection. > Does anyone have any idea why I can't seem to track down the real process > which is holding this socket open? > > Thanks! > Dave > > -- > Dave Parker '11 > Database & Systems Administrator > Utica College > Integrated Information Technology Services > (315) 792-3229 > Registered Linux User #408177 > -- Dave Parker '11 Database & Systems Administrator Utica College Integrated Information Technology Services (315) 792-3229 Registered Linux User #408177
Open socket not connected to any real process
Hello, I have an SMTP server running Debian Wheezy (64-bit). A few weeks ago, I stopped nscd on it, because it was holding a connection open to our LDAP server and sending a ton of unnecessary queries to it. Even though nscd is not running, I am once again seeing nscd-type queries on the LDAP server from this SMTP server, and a connection is open from the SMTP server. But I can't seem to figure out what process is using that connection. Every time I check using netstat or lsof, it just reports that the socket is owned by my current sshd process. An example: root@smtp:~# netstat -anp | grep 389 tcp0 0 :58786 :389ESTABLISHED *10249/0* root@smtp:~# lsof -n -i :389 COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME sshd*10249 root*4w IPv4 86936230 0t0 TCP :58786->:ldap (ESTABLISHED) root@smtp:~# ps -ef | grep 10249 *root 10249 17111 0 15:49 ?00:00:00 sshd: root@pts/0* root 10251 10249 0 15:50 pts/000:00:00 -bash root 10286 10251 0 15:54 pts/000:00:00 grep 10249 So I log out and back in, and the PID for this socket changes to my new sshd process: root@smtp:~# netstat -anp | grep 389 tcp0 0 :58798 :389ESTABLISHED *10288/0* root@smtp:~# lsof -n -i :389 COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME sshd*10288 root*4w IPv4 86936319 0t0 TCP :58798->:ldap (ESTABLISHED) root@smtp:~# ps -ef | grep 10288 *root 10288 17111 0 15:54 ?00:00:00 sshd: root@pts/0* root 10290 10288 0 15:54 pts/000:00:00 -bash root 10304 10290 0 15:55 pts/000:00:00 grep 10288 And all the while, LDAP queries continue to be sent over this connection. Does anyone have any idea why I can't seem to track down the real process which is holding this socket open? Thanks! Dave -- Dave Parker '11 Database & Systems Administrator Utica College Integrated Information Technology Services (315) 792-3229 Registered Linux User #408177
Re: Grow an ext4 filesystem
Indeed it has! I upgraded to Jessie and all is well Thank you! # e2fsck -f /dev/sdb1 e2fsck 1.42.12 (29-Aug-2014) Pass 1: Checking inodes, blocks, and sizes Pass 2: Checking directory structure Pass 3: Checking directory connectivity Pass 4: Checking reference counts Pass 5: Checking group summary information /dev/sdb1: 45983/183140352 files (1.0% non-contiguous), 668815777/732530432 blocks # resize2fs /dev/sdb1 resize2fs 1.42.12 (29-Aug-2014) Resizing the filesystem on /dev/sdb1 to 1220884224 (4k) blocks. The filesystem on /dev/sdb1 is now 1220884224 (4k) blocks long. And now... root@tapesrv:~# df -h /dev/sdb1 Filesystem Size Used Avail Use% Mounted on /dev/sdb1 4.5T 2.5T 1.9T 58% /export Thanks again! On Fri, Jun 9, 2017 at 10:34 AM, Sven Joachim <svenj...@gmx.de> wrote: > On 2017-06-09 10:15 -0400, David Parker wrote: > > > I have a storage server running Debian 7.6 x64. It's an HP server with > 24 > > HDDs and a hardware RAID controller. It has a 2.9 TB ext4 filesystem > which > > resides on a RAID 5 volume, and I recently needed to grow this filesystem > > so I added more disks to the volume and then used parted to grow the > > partition to the new size of 5 TB, so the space is now available in that > > partition: > > > > # parted print /dev/sdb > > Model: HP LOGICAL VOLUME (scsi) > > Disk /dev/sdb: 5001GB > > Sector size (logical/physical): 512B/512B > > Partition Table: gpt > > > > Number Start End SizeFile system Name Flags > > 1 1049kB 5001GB 5001GB ext4 primary > > > > However, the filesystem is still stuck at the old size: > > > > # df -h /dev/sdb1 > > Filesystem Size Used Avail Use% Mounted on > > /dev/sdb1 2.7T 2.5T 104G 97% /export > > > > I cannot figure out how to resize the actual ext4 filesystem to use the > > added space. I have tried both resize2fs without any luck. When I try > > resize2fs, I get this error: > > > > # resize2fs /dev/sdb1 > > resize2fs 1.42.5 (29-Jul-2012) > > resize2fs: /dev/sdb1: The combination of flex_bg and > > !resize_inode features is not supported by resize2fs. > > > > In a potentially stupid move, I did indeed remove the resize_inode > feature > > from this filesystem in order to get parted to work with it, which > > ultimately proved unnecessary, but now I cannot add it back: > > > > # tune2fs -O resize_inode /dev/sdb1 > > tune2fs 1.42.5 (29-Jul-2012) > > Setting filesystem feature 'resize_inode' not supported. > > > > Is there a way I can resize this filesystem to use the additional 2 TB > > available to it? > > By using a newer e2fsprogs version, this particular problem has been > fixed in e2fsprogs 1.42.8[1]. > > Cheers, >Sven > > > 1. https://bugs.debian.org/696746 > > -- Dave Parker Database & Systems Administrator Utica College Integrated Information Technology Services (315) 792-3229 Registered Linux User #408177
Grow an ext4 filesystem
Hello, I have a storage server running Debian 7.6 x64. It's an HP server with 24 HDDs and a hardware RAID controller. It has a 2.9 TB ext4 filesystem which resides on a RAID 5 volume, and I recently needed to grow this filesystem so I added more disks to the volume and then used parted to grow the partition to the new size of 5 TB, so the space is now available in that partition: # parted print /dev/sdb Model: HP LOGICAL VOLUME (scsi) Disk /dev/sdb: 5001GB Sector size (logical/physical): 512B/512B Partition Table: gpt Number Start End SizeFile system Name Flags 1 1049kB 5001GB 5001GB ext4 primary However, the filesystem is still stuck at the old size: # df -h /dev/sdb1 Filesystem Size Used Avail Use% Mounted on /dev/sdb1 2.7T 2.5T 104G 97% /export I cannot figure out how to resize the actual ext4 filesystem to use the added space. I have tried both resize2fs without any luck. When I try resize2fs, I get this error: # resize2fs /dev/sdb1 resize2fs 1.42.5 (29-Jul-2012) resize2fs: /dev/sdb1: The combination of flex_bg and !resize_inode features is not supported by resize2fs. In a potentially stupid move, I did indeed remove the resize_inode feature from this filesystem in order to get parted to work with it, which ultimately proved unnecessary, but now I cannot add it back: # tune2fs -O resize_inode /dev/sdb1 tune2fs 1.42.5 (29-Jul-2012) Setting filesystem feature 'resize_inode' not supported. Is there a way I can resize this filesystem to use the additional 2 TB available to it? The output of dumpe2fs is below (not including the data about the 22,355 groups in the filesystem): dumpe2fs 1.42.5 (29-Jul-2012) Filesystem volume name: Last mounted on: /export Filesystem UUID: 0306070a-6d39-48da-8235-aa99c9e48141 Filesystem magic number: 0xEF53 Filesystem revision #:1 (dynamic) Filesystem features: has_journal ext_attr dir_index filetype needs_recovery extent flex_bg sparse_super large_file Filesystem flags: signed_directory_hash Default mount options:user_xattr acl Filesystem state: clean Errors behavior: Continue Filesystem OS type: Linux Inode count: 183140352 Block count: 732530432 Reserved block count: 36626521 Free blocks: 63964655 Free inodes: 183094383 First block: 0 Block size: 4096 Fragment size:4096 Blocks per group: 32768 Fragments per group: 32768 Inodes per group: 8192 Inode blocks per group: 512 Flex block group size:16 Filesystem created: Thu Sep 18 14:40:07 2014 Last mount time: Fri Jun 9 09:46:28 2017 Last write time: Fri Jun 9 09:46:28 2017 Mount count: 5 Maximum mount count: -1 Last checked: Thu Jun 8 11:51:32 2017 Check interval: 0 () Lifetime writes: 17 TB Reserved blocks uid: 0 (user root) Reserved blocks gid: 0 (group root) First inode: 11 Inode size: 256 Required extra isize: 28 Desired extra isize: 28 Journal inode:8 Default directory hash: half_md4 Directory Hash Seed: 81bb6e96-1eea-44c2-8dbd-f3b046f9b2a9 Journal backup: inode blocks Journal features: journal_incompat_revoke Journal size: 128M Journal length: 32768 Journal sequence: 0x020ee1a8 Journal start:1 Any help is greatly appreciated. Thanks! -- Dave Parker Database & Systems Administrator Utica College Integrated Information Technology Services (315) 792-3229 Registered Linux User #408177
Re: Getting a serial console to work on Jessie
Hello, Thanks for all the clarification. I now find myself in need of doing this again on another server running Jessie, and I just want to make sure I'm clear on what the best procedure is. As I understand it, I should copy /lib/systemd/system/serial-getty@.service to /etc/systemd/system/serial-getty@ttyS0.service, then edit serial-getty@ttyS0.service to include the following: [Service] ExecStart= ExecStart=-/sbin/agetty -8 --noclear %I 9600 vt100 ... Is that correct? Thanks! Dave On Sun, Sep 6, 2015 at 9:52 PM, Stephen Powellwrote: > On Sun, 06 Sep 2015 16:06:35 -0400 (EDT), Michael Biebl wrote: > > Am 06.09.2015 um 21:04 schrieb Stephen Powell: > >> ... > >>[Service] > >>ExecStart=-/sbin/agetty -8 --noclear %I 38400 ibm3151 > >> > >> But when I restart the service, I get the following error: > >> > >> systemd[1]: serial-getty@ttyS0.service: Service has more than one > ExecStart= setting, which is only allowed for Type=oneshot services. > Refusing. > >> > >> I want to override "ExecStart", not add a new one. What am I doing > wrong? > > > > By default, systemd will simply merge all drop-ins. > > In your case, ExecStart is a setting which can not be specified more > > then once. So you need to "clear" it first. The following should do the > > trick: > > > > [Service] > > ExecStart= > > ExecStart=-/sbin/agetty -8 --noclear %I 38400 ibm3151 > > > > > > The "ExecStart=" resets the existing setting. > > > > ... > > That works. This is definitely a better solution than copying > serial-getty@.service from /lib/systemd/system to /etc/systemd/system > and then editing the copy in /etc/systemd/system to change the ExecStart > value. It is better for two reasons: > > (1) When systemd is serviced, I don't need to recopy and reedit the file > in order to keep my changes synced up with changes to the file made by > service to systemd. > > (2) It allows two different serial ports to have different ExecStart values > for two different terminal types, for example. Using my original method, > both serial ports would be locked into the same terminal type. > > I shall change my documentation accordingly. Thanks, Michael and Sven > for your suggestions and help. > > Regards, > > -- > .''`. Stephen Powell > : :' : > `. `'` >`- > > -- Dave Parker Systems Administrator Utica College Integrated Information Technology Services (315) 792-3229 Registered Linux User #408177
Re: Getting a serial console to work on Jessie
Thanks. I actually found that site in a Google search, and it's where I found the tip on copying the /lib/systemd/system/serial-getty@.service template file to customize the baud rate, etc. Specifically, I found the info I needed at: http://users.wowway.com/~zlinuxman/serial.htm#Systemd Thanks! On Tue, Sep 1, 2015 at 6:43 PM, Stephen Powell <zlinux...@wowway.com> wrote: > On Tue, 01 Sep 2015 12:13:56 -0400 (EDT), David Parker wrote: > > > > I have a bunch of Debian Wheezy servers set up with the console available > > via the serial port. Generally, I just add this line to /etc/inittab: > > ... > > That's all fine and good, but when I try to do this on my desktop PC > > running Jessie, it doesn't work. > > ... > > I realize that you already have a resolution to your problem, but if you're > using serial consoles on Debian Linux, you might find some useful > information here: > >http://users.wowway.com/~zlinuxman/serial.htm > > -- > .''`. Stephen Powell<zlinux...@wowway.com> > : :' : > `. `'` >`- > > -- Dave Parker Systems Administrator Utica College Integrated Information Technology Services (315) 792-3229 Registered Linux User #408177
Getting a serial console to work on Jessie
Hello, I have a bunch of Debian Wheezy servers set up with the console available via the serial port. Generally, I just add this line to /etc/inittab: co:2345:respawn:/sbin/getty -L ttyS0 9600 vt102 And then run "kill -HUP 1" and the serial console works (I could also use "telinit q" or "init q" instead of kill -HUP"). I just did this on a Wheezy server to make sure, and checked the getty processes prior to making the change: # ps -ef | grep getty root 2660 1 0 Jul24 tty1 00:00:00 /sbin/getty 38400 tty1 root 2661 1 0 Jul24 tty2 00:00:00 /sbin/getty 38400 tty2 root 2662 1 0 Jul24 tty3 00:00:00 /sbin/getty 38400 tty3 root 2663 1 0 Jul24 tty4 00:00:00 /sbin/getty 38400 tty4 root 2664 1 0 Jul24 tty5 00:00:00 /sbin/getty 38400 tty5 root 2665 1 0 Jul24 tty6 00:00:00 /sbin/getty 38400 tty6 And then after: # ps -ef | grep getty root 2660 1 0 Jul24 tty1 00:00:00 /sbin/getty 38400 tty1 root 2661 1 0 Jul24 tty2 00:00:00 /sbin/getty 38400 tty2 root 2662 1 0 Jul24 tty3 00:00:00 /sbin/getty 38400 tty3 root 2663 1 0 Jul24 tty4 00:00:00 /sbin/getty 38400 tty4 root 2664 1 0 Jul24 tty5 00:00:00 /sbin/getty 38400 tty5 root 2665 1 0 Jul24 tty6 00:00:00 /sbin/getty 38400 tty6 root 31705 1 0 11:33 ttyS000:00:00 /sbin/getty -L ttyS0 9600 vt102 And there's the getty on ttyS0 as expected. That's all fine and good, but when I try to do this on my desktop PC running Jessie, it doesn't work. My PC is running an X server, Gnome, etc., whereas the servers are not. Also, on Wheezy, /sbin/getty and /sbin/agetty seem to be two copies of the same file, wheras on Jessie, /sbin/getty is a symlink to /sbin/agetty. The PC is using the default /etc/inittab file. When I check the list of getty processes after a clean reboot, there's only this: # ps -ef | grep getty root 2092 1 0 11:50 tty1 00:00:00 /sbin/agetty --noclear tty1 linux If I access the virtual consoles via CTRL-ALT-F1, etc., they show up in the process list only after they have been accessed: # ps -ef | grep getty root 2092 1 0 11:50 tty1 00:00:00 /sbin/agetty --noclear tty1 linux root 2998 1 0 11:56 tty2 00:00:00 /sbin/agetty --noclear tty2 linux root 3001 1 0 11:56 tty3 00:00:00 /sbin/agetty --noclear tty3 linux And still not in the same way that they appear on Wheezy ("/sbin/getty 38400 tty1", etc.). If I add the line for the serial console to /etc/inittab and reload the init deamon, or even reboot the PC, it simply does nothing. No getty process shows up on ttyS0, and no serial console is available. I know the serial port itself works, because I can connect to it from my laptop, then do "screen /dev/ttyS0 9600" on the PC and see characters in the screen session as I type them on the laptop. So the serial port works, and I/O seems to work, but I can't seem to start a persistent getty process on that port and access the console through it. Any ideas or suggestions are very much appreciated. Thanks! Dave -- Dave Parker Systems Administrator Utica College Integrated Information Technology Services (315) 792-3229 Registered Linux User #408177
Sendmail greeting delay
Hello, We have an SMTP server running Sendmail 8.14.4-4 on Debian 7 64-bit. We're using the file /etc/mail/access for access control and rate limiting, and this is enabled via the following lines in /etc/mail/sendmail.cf: Kaccess hash -TTMPF /etc/mail/access # FEATURE(`access_db', `hash -TTMPF /etc/mail/access', `skip')dnl For some reason, I just can't get it to not pause when greeting external (non-localhost) connections. I was testing SSL/TLS connectivity when I discovered the delay, using openssl s_client -connect smtp-server:465. If I run this command from the SMTP server, it connects and then prints all of the SSL and certificate information immediately. But if I test from another PC on our network, it connects, pauses for 5 seconds, and then prints the SSL information. My /etc/mail/access file is pasted below. The PC I'm testing from is on the 10.x.x.x network, which should be allowed to connect with no delay. I have also tried setting the default GreetPause to 0 but it still made no difference. Connect:localhost RELAY GreetPause:localhost 0 ClientRate:localhost 0 ClientConn:localhost 0 Connect:127 RELAY GreetPause:127 0 ClientRate:127 0 ClientConn:127 0 Connect:IPv6:::1 RELAY GreetPause:IPv6:::1 0 ClientRate:IPv6:::1 0 ClientConn:IPv6:::1 0 Connect:10 RELAY GreetPause:10 0 ClientRate:10 0 ClientConn:10 0 # Defaults Connect: REJECT GreetPause: 5000 ClientRate: 10 ClientConn: 10 # Whitelisted users Spam:postmaster@ FRIEND Spam:abuse@ FRIEND Spam:spam@ FRIEND # Blacklisted users reject@ REJECT # Block invalid IPs Connect:169.254 REJECT Connect:192.0.2 REJECT Connect:224 REJECT Connect:255 REJECT Any help would be greatly appreciated. Thanks! -- Dave Parker Systems Administrator Utica College Integrated Information Technology Services (315) 792-3229 Registered Linux User #408177
Re: Sendmail greeting delay
Thanks for the replies. The system is not using tcpwrappers, and it's also not a DNS issue. The client PC does have a reverse DNS entry. A tcpdump packet capture on the server shows the initial connection from the client followed by a bunch of DNS traffic, all within the same second. Then nothing happens for exactly 5 seconds, then the server sends data back to the client. Just to be extra sure, I added an entry for it in /etc/hosts so DNS wouldn't even be needed. Still made no difference. Thanks, Dave On Mon, Jan 12, 2015 at 4:21 PM, Chris Davies chris-use...@roaima.co.uk wrote: David Parker dpar...@utica.edu wrote: We have an SMTP server running Sendmail 8.14.4-4 on Debian 7 64-bit. Kaccess hash -TTMPF /etc/mail/access # FEATURE(`access_db', `hash -TTMPF /etc/mail/access', `skip')dnl For some reason, I just can't get it to not pause when greeting external (non-localhost) connections. [...] if I test from another PC on our network, it connects, pauses for 5 seconds, and then prints the SSL information. Does your PC have an rDNS entry, and if not could this delay be a DNS lookup timeout? Chris -- 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/rfqdobx8se@news.roaima.co.uk -- Dave Parker Systems Administrator Utica College Integrated Information Technology Services (315) 792-3229 Registered Linux User #408177
Re: Sendmail greeting delay
Thanks, but it looks like the IDENT setting was the culprit. I just had to change this setting in sendmail.cf: O Timeout.ident=5s Changing it from 5s to 0s resolved the problem immediately. Thanks again, everyone! On Tue, Jan 13, 2015 at 3:07 PM, Jonathan Siegle jsie...@psu.edu wrote: On 2015-01-13 at 12:38, David Parker wrote: Hello, My /etc/mail/access file is pasted below. The PC I'm testing from is on the 10.x.x.x network, which should be allowed to connect with no delay. I have also tried setting the default GreetPause to 0 but it still made no difference. Connect:localhost RELAY GreetPause:localhost 0 ClientRate:localhost 0 ClientConn:localhost 0 Connect:127 RELAY GreetPause:127 0 ClientRate:127 0 ClientConn:127 0 Connect:IPv6:::1 RELAY GreetPause:IPv6:::1 0 ClientRate:IPv6:::1 0 ClientConn:IPv6:::1 0 Connect:10 RELAY GreetPause:10 0 ClientRate:10 0 ClientConn:10 0 Dave, I'm struggling with a reference beyond my own work. Please try putting a second and maybe a third octet on your GreetPause: 10 line. Also, please verify you are issuing a kill -HUP on sendmail. We never got sendmail greetpause to work with a single octet. Normally we do 3 octets for all the RFC1918 addresses we use. -Jonathan -- Dave Parker Systems Administrator Utica College Integrated Information Technology Services (315) 792-3229 Registered Linux User #408177
Re: Sendmail greeting delay
Just for the sake of completeness, this wasn't actually an issue with the GreetPause option or anything else in the access file. The problem was that sendmail was attempting an IDENT query to the client, with a 5-second timeout. The access file wasn't even checked until after the timeout expired. In retrospect, I guess it makes sense because I was testing this by connecting with openssl, which is just looking for the SSL/TLS info at the beginning of the connection, and doesn't need to wait for the greeting. The GreetPause values work as expected for actual client connections on port 25, 465, or 587. Thanks! On Tue, Jan 13, 2015 at 3:27 PM, David Parker dpar...@utica.edu wrote: Thanks, but it looks like the IDENT setting was the culprit. I just had to change this setting in sendmail.cf: O Timeout.ident=5s Changing it from 5s to 0s resolved the problem immediately. Thanks again, everyone! On Tue, Jan 13, 2015 at 3:07 PM, Jonathan Siegle jsie...@psu.edu wrote: On 2015-01-13 at 12:38, David Parker wrote: Hello, My /etc/mail/access file is pasted below. The PC I'm testing from is on the 10.x.x.x network, which should be allowed to connect with no delay. I have also tried setting the default GreetPause to 0 but it still made no difference. Connect:localhost RELAY GreetPause:localhost 0 ClientRate:localhost 0 ClientConn:localhost 0 Connect:127 RELAY GreetPause:127 0 ClientRate:127 0 ClientConn:127 0 Connect:IPv6:::1 RELAY GreetPause:IPv6:::1 0 ClientRate:IPv6:::1 0 ClientConn:IPv6:::1 0 Connect:10 RELAY GreetPause:10 0 ClientRate:10 0 ClientConn:10 0 Dave, I'm struggling with a reference beyond my own work. Please try putting a second and maybe a third octet on your GreetPause: 10 line. Also, please verify you are issuing a kill -HUP on sendmail. We never got sendmail greetpause to work with a single octet. Normally we do 3 octets for all the RFC1918 addresses we use. -Jonathan -- Dave Parker Systems Administrator Utica College Integrated Information Technology Services (315) 792-3229 Registered Linux User #408177 -- Dave Parker Systems Administrator Utica College Integrated Information Technology Services (315) 792-3229 Registered Linux User #408177
Re: Sendmail greeting delay
Yes! That seems to be the culprit. I ran an strace on the sendmail process and that's exactly what happens: [ ... ] 4007 15:09:08.386921 connect(5, {sa_family=AF_INET, sin_port=htons(113), sin_addr=inet_addr(10.3.1.40)}, 16 unfinished ... 3792 15:09:13.386272 ... select resumed ) = 0 (Timeout) [ ... ] Where 10.3.1.40 is the IP of the client PC. So now I just need to dig into the config and figure out how to stop it. Thanks! On Tue, Jan 13, 2015 at 3:16 PM, Joe j...@jretrading.com wrote: On Tue, 13 Jan 2015 20:12:11 + Joe j...@jretrading.com wrote: On Tue, 13 Jan 2015 14:27:42 -0500 David Parker dpar...@utica.edu wrote: Thanks for the replies. The system is not using tcpwrappers, and it's also not a DNS issue. The client PC does have a reverse DNS entry. A tcpdump packet capture on the server shows the initial connection from the client followed by a bunch of DNS traffic, all within the same second. Then nothing happens for exactly 5 seconds, then the server sends data back to the client. Just to be extra sure, I added an entry for it in /etc/hosts so DNS wouldn't even be needed. Still made no difference. Is it asking for an ident from the connecting server (TCP port 7)? This is an old-fashioned custom, when computers with MTAs also ran ident servers, which provided some fairly harmless information. Exim4 can certainly ask for an ident, and does nothing for a configurable timeout unless one is received, or the sender address is whitelisted. It is a simple anti-spam measure, as practically nothing runs ident servers today, and most malware will give up before a thirty-second timeout expires, whereas a legitimate MTA will wait for that long. OK, where did the 7 come from? Should be port 113. I saw it just as the mouse button clicked... -- Joe -- 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/20150113201613.0b84c...@jresid.jretrading.com -- Dave Parker Systems Administrator Utica College Integrated Information Technology Services (315) 792-3229 Registered Linux User #408177
SFTP chroot and FileZilla question
Hello, I have set up a Debian Wheezy box as a simple SFTP server. I have created an SFTP-only user account and configured SSH to jail the account to its home directory with the following in sshd_config: Subsystem sftp internal-sftp Match group radius ChrootDirectory /home X11Forwarding no AllowTcpForwarding no ForceCommand internal-sftp Where radius is the primary group for the SFTP user account. All of this works fine when I connect using OpenSSH from another Linux box. I land in the /home directory, but running pwd in the SFTP session shows that the working directory is / and then I cannot navigate any further up the filesystem tree. That's exactly what I would expect However, if I connect using FileZilla, I see that I am in /home and I can freely navigate the rest of the filesystem. What's up with that? I would really like for this user account to be jailed regardless of the client, and it seems to me like it should be, since this is a server-side configuration. Any help or insight would be greatly appreciated. Thanks! -- Dave Parker Systems Administrator Utica College Integrated Information Technology Services (315) 792-3229 Registered Linux User #408177
Accessing Glipper in testing (Jessie)
Hello, I was running Wheezy for a while, with a little bit of tweaking, I came to enjoy the new Gnome interface (I had been a KDE fan for years until I upgraded to Wheezy). In installed the Glipper clipboard manager and could access it by placing the mouse cursor into the lower right corner of the screen. It was otherwise hidden, and I thought the whole thing was very slick. I recently upgraded to testing, and Glipper disappeared. It's still installed, but I can no longer access it like I used to. The only way I can find to access Glipper is to open the Gnome Tweak Tool and enable the Window list extension. This enables a traditional task bar at the bottom of the screen which shows the currently open windows, a workspace switcher, and at the very end on the right it has a blue circle with a 1 on it. If I click on that blue circle, a gray bar slides up and shows the Glipper icon, which I can then click on. I don't care for this solution, because the task bar takes up space at the bottom of the screen and I can't seem to hide it, and I also have to click the blue circle in order to get to Glipper. I neither need nor want the window list or workspace switcher, so to have it there simply for the puspose of accessing Glipper is irksome. It was much nicer when I could simply move the cursor to the lower right corner without clicking on anything. Is there something I can do to get this old behavior back? Thanks in advance. - Dave P.S. Yes, I do realize that I can use CTRL-ALT-C to pop up Glipper anytime, and that's what I'm doing right now, but I really liked the mouse-only solution I had before. -- Dave Parker Systems Administrator Utica College Integrated Information Technology Services (315) 792-3229 Registered Linux User #408177
Long delays caused by rpcinfo
Hello, I recently set up a VM running Debian Wheezy (amd64) to be used as an NFS server. I noticed that running /etc/init.d/nfs-kernel-server start would hang for about 60 seconds while starting nfsd, but if I started nfsd directly, there was no problem. After a lot of strace adventures and Google searches, I eventually traced the problem to the rpcinfo command. I commented out the following lines from the nfs-kernel-server init script, everything started working: $PREFIX/bin/rpcinfo -u localhost nfs 3 /dev/null 21 || RPCMOUNTDOPTS=$RPCMOUNTDOPTS --no-nfs-version 3 Indeed, running rpcinfo -u localhost nfs 3 causes a long pause before it finally outputs the following: rpcinfo: RPC: Port mapper failure - Timed out program 13 version 3 is not available Running rpcinfo -p localhost causes the same long pause, and then outputs this: rpcinfo: can't contact portmapper: RPC: Remote system error - Connection timed out Running showmount --exports results in the long pause, and then outputs this: clnt_create: RPC: Port mapper failure - Timed out However, running rpcinfo -p without specifying the host returns immediately: program vers proto port service 104 tcp111 portmapper 103 tcp111 portmapper 102 tcp111 portmapper 104 udp111 portmapper 103 udp111 portmapper 102 udp111 portmapper 1000241 udp 42629 status 1000241 tcp 56434 status I have confirmed that rpc.statd is running, which I believe is the port mapper in newer distributions. Any idea why I would be seeing this behavior? Is there a configuration option I'm missing? Any help would be greatly appreciated. Thanks! Dave -- Dave Parker Systems Administrator Utica College Integrated Information Technology Services (315) 792-3229 Registered Linux User #408177
Re: Long delays caused by rpcinfo
Thanks for the reply. Unfortunately, it looks like rpcbind is not the culprit. I verified that rpcbind installed and running: root@test-vm-1:~# ps -ef | grep bind root 1538 1 0 11:23 ?00:00:00 /sbin/rpcbind -w root 28002 2289 0 15:17 pts/000:00:00 grep bind I restarted the rpcbind service just to make sure... root@test-vm-1:~# service rpcbind stop [ ok ] Stopping rpcbind daemon root@test-vm-1:~# ps -ef | grep bind root 28227 2289 0 15:18 pts/000:00:00 grep bind root@test-vm-1:~# service rpcbind start [ ok ] Starting rpcbind daemon root@test-vm-1:~# ps -ef | grep bind root 28254 1 0 15:18 ?00:00:00 /sbin/rpcbind -w root 28288 2289 0 15:18 pts/000:00:00 grep bind ... but the problem persisted: root@test-vm-1:~# rpcinfo -p localhost LONG PAUSE rpcinfo: can't contact portmapper: RPC: Remote system error - Connection timed out Anything else I can look into? FWIW, an strace shows that rpcbind gets stuck when trying to connect to a socket on the loopback interface. The relevant portion of the strace output is below: socket(PF_INET, SOCK_STREAM, IPPROTO_TCP) = 3 getsockname(3, {sa_family=AF_INET, sin_port=htons(0), sin_addr=inet_addr(0.0.0.0)}, [16]) = 0 bind(3, {sa_family=AF_INET, sin_port=htons(944), sin_addr=inet_addr(0.0.0.0)}, 16) = 0 getsockname(3, {sa_family=AF_INET, sin_port=htons(944), sin_addr=inet_addr(0.0.0.0)}, [16]) = 0 getsockopt(3, SOL_SOCKET, SO_TYPE, [1], [4]) = 0 setsockopt(3, SOL_TCP, TCP_NODELAY, [1], 4) = 0 rt_sigprocmask(SIG_SETMASK, ~[RTMIN RT_1], [], 8) = 0 getrlimit(RLIMIT_NOFILE, {rlim_cur=1024, rlim_max=4*1024}) = 0 mmap(NULL, 200704, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7fdfa4cfb000 getpeername(3, 0x7fff62295d00, [128]) = -1 ENOTCONN (Transport endpoint is not connected) connect(3, {sa_family=AF_INET, sin_port=htons(111), sin_addr=inet_addr(127.0.0.1)}, 16) = -1 ETIMEDOUT (Connection timed out) rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0 close(3)= 0 write(2, rpcinfo: can't contact portmappe..., 83rpcinfo: can't contact portmapper: RPC: Remote system error - Connection timed out ) = 83 exit_group(1) The long pause happens after this call: connect(3, {sa_family=AF_INET, sin_port=htons(111), sin_addr=inet_addr(127.0.0.1)}, 16) Which eventually results in = -1 ETIMEDOUT (Connection timed out) and moves on. As always, any help will be greatly appreciated! - Dave On Tue, Sep 24, 2013 at 3:02 PM, Bob Proulx b...@proulx.com wrote: David Parker wrote: I have confirmed that rpc.statd is running, which I believe is the port mapper in newer distributions. AFAIK rpc.statd is not a portmapper replacement. The two portmapper equivalents that I am aware of are: portmap - RPC port mapper rpcbind - converts RPC program numbers into universal addresses The 'portmap' package is the older one. I think in newer releases it has been replaced with 'rpcbind'. I don't know what is different between them. Try installing rpcbind. I think that will solve your problem. Bob -- Dave Parker Systems Administrator Utica College Integrated Information Technology Services (315) 792-3229 Registered Linux User #408177
Re: Long delays caused by rpcinfo
root@test-vm-1:~# cat /etc/hosts 127.0.0.1localhostlocalhost 192.168.25.200 testbed.utica.edu testbed 192.168.25.201 test-vm-1.utica.edu test-vm-1 192.168.25.202 test-vm-2.utica.edu test-vm-2 192.168.25.203 test-vm-3.utica.edu test-vm-3 192.168.25.204 test-vm-4.utica.edu test-vm-4 /etc/hosts.allow and /etc/hosts.deny are the Debian-delivered versions; they only contain comments, no actual rules. Thanks, Dave On Tue, Sep 24, 2013 at 3:41 PM, Mark Neyhart mark.neyh...@akleg.govwrote: David Parker wrote: Thanks for the reply. Unfortunately, it looks like rpcbind is not the culprit. I verified that rpcbind installed and running: Anything else I can look into? FWIW, an strace shows that rpcbind gets stuck when trying to connect to a socket on the loopback interface. The relevant portion of the strace output is below: Maybe rpcbind is not listening on the loopback interface. What are the contents of /etc/hosts, /etc/hosts.deny and /etc/hosts.allow? Mark -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/5241eaf4.20...@akleg.gov -- Dave Parker Systems Administrator Utica College Integrated Information Technology Services (315) 792-3229 Registered Linux User #408177
Re: Long delays caused by rpcinfo
Hello, Thanks for the suggestions. The combination of checking /etc/network/interfaces and verifying that rpcbind was listening on 127.0.0.1 led me in the right direction, and boy do I feel silly... Somehow, my interfaces file was missing the loopback entry, so the loopback interface showed in the ifconfig output but it wasn't actually up. I added these lines: auto lo iface lo inet loopback Then, after ifup lo, everything just worked. I think I wrote the interfaces file from scratch and copied it over the original, and of course, I didn't include the loopback interface. *Sigh*. Thanks again! - Dave On Tue, Sep 24, 2013 at 9:52 PM, Tom H tomh0...@gmail.com wrote: On Tue, Sep 24, 2013 at 3:02 PM, Bob Proulx b...@proulx.com wrote: David Parker wrote: I have confirmed that rpc.statd is running, which I believe is the port mapper in newer distributions. AFAIK rpc.statd is not a portmapper replacement. The two portmapper equivalents that I am aware of are: portmap - RPC port mapper rpcbind - converts RPC program numbers into universal addresses The 'portmap' package is the older one. I think in newer releases it has been replaced with 'rpcbind'. I don't know what is different between them. rpcbind uses ti-rpc rather than sunrpc and can handle nfsv4 and ipv6. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CAOdo=SwGGBU=lyjyhxh0tfbddoobogbgkzdexeuvka2eog+...@mail.gmail.com -- Dave Parker Systems Administrator Utica College Integrated Information Technology Services (315) 792-3229 Registered Linux User #408177
Re: Long delays caused by rpcinfo
And for the sake of completeness, yes, NFS clients were able to mount the exported volume on this server once the nfs-kernel-server startup completed. And that makes a lot of sense to me now, because the entire issue was in rpcbind's attempt to verify that it could connect to 127.0.0.1, which doesn't matter for remote mounts. On Tue, Sep 24, 2013 at 11:38 PM, David Parker dpar...@utica.edu wrote: Hello, Thanks for the suggestions. The combination of checking /etc/network/interfaces and verifying that rpcbind was listening on 127.0.0.1 led me in the right direction, and boy do I feel silly... Somehow, my interfaces file was missing the loopback entry, so the loopback interface showed in the ifconfig output but it wasn't actually up. I added these lines: auto lo iface lo inet loopback Then, after ifup lo, everything just worked. I think I wrote the interfaces file from scratch and copied it over the original, and of course, I didn't include the loopback interface. *Sigh*. Thanks again! - Dave On Tue, Sep 24, 2013 at 9:52 PM, Tom H tomh0...@gmail.com wrote: On Tue, Sep 24, 2013 at 3:02 PM, Bob Proulx b...@proulx.com wrote: David Parker wrote: I have confirmed that rpc.statd is running, which I believe is the port mapper in newer distributions. AFAIK rpc.statd is not a portmapper replacement. The two portmapper equivalents that I am aware of are: portmap - RPC port mapper rpcbind - converts RPC program numbers into universal addresses The 'portmap' package is the older one. I think in newer releases it has been replaced with 'rpcbind'. I don't know what is different between them. rpcbind uses ti-rpc rather than sunrpc and can handle nfsv4 and ipv6. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CAOdo=SwGGBU=lyjyhxh0tfbddoobogbgkzdexeuvka2eog+...@mail.gmail.com -- Dave Parker Systems Administrator Utica College Integrated Information Technology Services (315) 792-3229 Registered Linux User #408177 -- Dave Parker Systems Administrator Utica College Integrated Information Technology Services (315) 792-3229 Registered Linux User #408177
NFS Failover
Hello, I'm wondering if there is a way to set up a highly-available NFS share using two servers (Debian Wheezy), where the shared volume can failover if the primary server goes down. My idea was to use two NFS servers and keep the exported directories in sync using DRDB. On the client, mount the share via autofs using the Replicated Server syntax. For example, say I have two servers called server1 and server2, each of which is exporting the directory /export/data via NFS, and /export/data is a synced DRDB filesystem shared between them.On the client, set up an autofs map file to mount the share and add this line: /mnt/dataserver1,server2:/export/data This is close, but it doesn't do what I'm looking to do. This seems to round-robin between the two servers whenever the filesystem needs to be mounted, and if the selected server isn't available, it then tries the other one. What I'm looking for is a way to have the client be aware of both servers, and gracefully failover between them. I thought about using Pacemaker and Corosync to provide a virtual IP which floats between the servers, but would that work with NFS? Let's say I have an established NFS mount and server1 fails, and the virtual IP fails over to server2. Wouldn't there be a bunch of NFS socket and state information which server2 is unaware of, therefore rendering the connection useless on the client? Also, data integrity is essential in this scenario, so what about active writes to the NFS share which are happening at the time the server-side failover takes place? In full disclosure, I have tried the autofs method but not the Pacemaker/Corosyn HA method, so some experimentation might answer my questions. In the meantime, any help would be greatly appreciated. Thanks! Dave -- Dave Parker Systems Administrator Utica College Integrated Information Technology Services (315) 792-3229 Registered Linux User #408177
Re: NFS Failover
On Wed, Jun 26, 2013 at 3:20 PM, Adrian Fita adrian.f...@gmail.com wrote: On 06/26/2013 09:11 PM, David Parker wrote: What I'm looking for is a way to have the client be aware of both servers, and gracefully failover between them. I thought about using Pacemaker and Corosync to provide a virtual IP which floats between the servers, but would that work with NFS? Let's say I have an established NFS mount and server1 fails, and the virtual IP fails over to server2. Wouldn't there be a bunch of NFS socket and state information which server2 is unaware of, therefore rendering the connection useless on the client? Also, data integrity is essential in this scenario, so what about active writes to the NFS share which are happening at the time the server-side failover takes place? I have also studied NFS fail-over with Pacemaker/Corosync/DRBD and it could work with NFSv3; NFSv4 uses TCP which makes things very hard. But even with NFSv3 I stumbled over strange situations, the likes of which I don't really remember, but the bottom line I have decided that NFS NFS fail-over is too fiddly and hard to control reliably. Now I'm studying using Gluster for replicating data between nodes and mounting the gluster volumes on the clients via glusterfs - this seems like a much better, simpler and more robust approach. I suggest you take a look at Gluster, it's an exceptionally good technology. Thank you for the information and suggestions. Dan, thanks for the link, it exactly describes what I'm trying to do. As you both pointed out, it would be easier and safer to use a clustered filesystem instead of NFS for this project. I'll check out GlusterFS, it looks like a great option. Thanks! -- Dave Parker Systems Administrator Utica College Integrated Information Technology Services (315) 792-3229 Registered Linux User #408177
Re: what's your Debian uptime?
I have a box running Etch that hasn't been rebooted in 1,589 days: irp:~# uptime 12:09:06 up 1589 days, 18:23, 1 user, load average: 0.00, 0.01, 0.03 irp:~# I swear this is real. :-) On Sun, Apr 21, 2013 at 6:32 PM, Vincent Lefevre vinc...@vinc17.net wrote: On 2013-04-20 19:24:00 -0600, Bob Proulx wrote: Vincent Lefevre wrote: That's theory. In practice, old machines get no longer supported... I submitted a bug report (and a patch), but AFAIK the bug has never been fixed. I upgraded everything except the kernel, without being sure I could boot it again (udev incompatibilities...). That's why the machine was no longer rebooted. And if you get into a situation where the machine reboots whether you desire it or not? Power, cosmic ray hit, dead cooling fan, other? It was a laptop, so that power wasn't a problem. A hardware failure wuld have meant that the machine would be probably dead anyway (after the last boot the laptop was already more than 8 year old). This is actually what happened a few months ago: strange noises from the disk and I/O errors... It happens. Even with UPS mains and redundant power supplies. Hardware doesn't last forever. Will it boot? If so then great. If not then you have a nasty problem to sort out and the machine is down until you do. I would rather know about it on my schedule rather than its schedule. Even if there were a software problem, I wouldn't have wasting my time to try to fix it for a machine that was almost no longer used (mainly just for portability testing), in particular if the machine couldn't boot. -- Vincent Lefèvre vinc...@vinc17.net - Web: http://www.vinc17.net/ 100% accessible validated (X)HTML - Blog: http://www.vinc17.net/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: http://lists.debian.org/20130421223223.gg9...@xvii.vinc17.org -- Dave Parker Systems Administrator Utica College Integrated Information Technology Services (315) 792-3229 Registered Linux User #408177
Debian Squeeze ext4 corruption under VMware
Hello, We have several Debian Squeeze servers running in VMs under VMware ESXi 4.1.0 (build 502767 if that matters) with the latest VMware Tools bundle installed. We're using the ext4 filesystem on each of these servers. We have had a few crashes of our VMware infrastructure, and each time, the Debian servers have all suffered filesystem corruption. The problem seems to be that VMware attempts to freeze each VM when something goes wrong, and depending on the circumstances, it tries to move each VM to another VMware server. This works fine for our Windows servers, but the Debian servers get all messed up. Each VM remains in a running state, but the root filesystem is mounted read-only, and the console shows a ton of filesystem errors. In most cases, the corruption has been recoverable by booting the VM to a Knoppix live CD and running fsck on the unmounted filesystem. We've tried forcing fsck to run on boot, but for some reason it will not repair the filesystem, hence why we need to boot to a live CD. In a few isolated cases, we have ended up with serious filesystem damage resulting in a huge number of files in /lost+found, and we've just rebuilt the VMs. I'm just wondering if anyone else has seen this, or if anyone knows a way to make Debian deal with VMware's shenanigans more smoothly. We do have a planned upgrade to VMware ESXi 5.0 in the next few months, and we're looking to get a new SAN solution (our SAN has been the source of at least two of these crashes), but I'd really like to get a handle on this issue sooner in case we have another problem. I've Googled this problem, but I'm not finding much useful information. Thanks! - Dave -- Dave Parker Systems Administrator Utica College Integrated Information Technology Services (315) 792-3229 Registered Linux User #408177 -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4fb2604f.9050...@utica.edu
Re: [OT] Nagios question
- Original Message - From: Brad Alexander stor...@gmail.com Date: Friday, August 26, 2011 6:07 pm Subject: [OT] Nagios question To: Debian-user List debian-user@lists.debian.org There is a nagios plugin called check_ubc, which checks for increasing /proc/user_beancounters. This is an indication of a spec that needs to be tuned for the vm. In any case, I can run the check_ubc from the command line on both machines, but on the original server, hornet, when I run it from nrpe on the nagios server: # /usr/local/nagios/libexec/check_nrpe -H hornet -c check_ubc OK. On the new server, built two days ago, same configuration, I get # /usr/local/nagios/libexec/check_nrpe -H akagi -c check_ubc NRPE: Command 'check_ubc' not defined I have the check_ubc script in /usr/local/nagios/libexec/nrpe_local on both, the command is defined in/usr/local/nagios/etc/nrpe_local/override.cfg with an include in /usr/local/nagios/etc/nrpe.cfg. Everything is the same on both servers. Why does the command work on one but not the other? Just to clarify, the configs are *exactly* the same? Are these two machines different architectures (32-bit vs. 64-bit, etc.)? - Dave
Re: [OT] Nagios question
- Original Message - From: Brad Alexander stor...@gmail.com Date: Friday, August 26, 2011 8:13 pm Subject: [Spam: 5.2] Re: [OT] Nagios question To: David Parker dpar...@utica.edu On Fri, Aug 26, 2011 at 6:41 PM, David Parker dpar...@utica.edu wrote: - Original Message - From: Brad Alexander stor...@gmail.com Date: Friday, August 26, 2011 6:07 pm Subject: [OT] Nagios question To: Debian-user List debian-user@lists.debian.org There is a nagios plugin called check_ubc, which checks for increasing /proc/user_beancounters. This is an indication of a spec that needs to be tuned for the vm. In any case, I can run the check_ubc from the command line on both machines, but on the original server, hornet, when I run it from nrpe on the nagios server: # /usr/local/nagios/libexec/check_nrpe -H hornet -c check_ubc OK. On the new server, built two days ago, same configuration, I get # /usr/local/nagios/libexec/check_nrpe -H akagi -c check_ubc NRPE: Command 'check_ubc' not defined I have the check_ubc script in /usr/local/nagios/libexec/nrpe_local on both, the command is defined in/usr/local/nagios/etc/nrpe_local/override.cfg with an include in /usr/local/nagios/etc/nrpe.cfg. Everything is the same on both servers. Why does the command work on one but not the other? Just to clarify, the configs are *exactly* the same? Are these two machines different architectures (32-bit vs. 64-bit, etc.)? Nope. Both are Dell PE 1850s with dual 3.2GHz Xeons. The only differing factor is that one has 2GB of RAM and the other has 6GB. That's really strange. This may seem obvious, but are the permissions on the config file correct, and is it readable by the user who is running this command? Also, is the Nagios version the same on the two boxes? Does strace show anything? Try: strace -o strace.out /usr/local/nagios/libexec/check_nrpe -H akagi -c check_ubc Then check strace.out and see if it shows anything along the lines of permissions errors, parsing errors, etc. - Dave
Re: Serial Console Access
In a nut-shell, this is what is how my Debian box is configured (for serial console) root@leviathan:~# setserial -g /dev/ttyS[0123] /dev/ttyS0, UART: 16550A, Port: 0xdc00, IRQ: 16 /dev/ttyS1, UART: 16550A, Port: 0xdc00, IRQ: 16 /dev/ttyS2, UART: unknown, Port: 0x03e8, IRQ: 4 /dev/ttyS3, UART: unknown, Port: 0x02e8, IRQ: 3 root@leviathan:~# grep -e tty -e serial /etc/default/grub GRUB_CMDLINE_LINUX='console=tty0 console=ttyS0,115200n8' GRUB_TERMINAL=serial GRUB_SERIAL_COMMAND=serial --speed=115200 --unit=0 --word=8 --parity=no --stop=1 #GRUB_CMDLINE_LINUX='console=ttyS1 console=ttyS1,38400n8' #GRUB_TERMINAL=serial #GRUB_SERIAL_COMMAND=serial --speed=38400 --unit=0 --word=8 --parity=no --stop=1 root@leviathan:~# grep ttyS /etc/inittab #T0:23:respawn:/sbin/getty -L ttyS0 19200 vt100 #T1:23:respawn:/sbin/getty -L ttyS1 19200 vt100 T0:2345:respawn:/sbin/getty -L ttyS0 115200 vt100 #T0:2345:respawn:/sbin/getty -L ttyS1 38400 vt100 #T3:23:respawn:/sbin/mgetty -x0 -s 57600 ttyS3 root@leviathan:~# grep ttyS /etc/securetty ttyS0 #ttyS1 root@leviathan:~# Now, the one part that could be causing a problem on the server but I can't tell is setserial's output, which is noteworthy. The motherboards COM header is expressly disabled in the bios (as I don't have the header to physically put in this box), but I do have a Serial Card and many working null modem cables. The serial card is: 01:09.0 Serial controller: NetMos Technology PCI 9835 Multi-I/O Controller (rev 01) Was your onboard serial port disabled in the BIOS at the time you installed Debian? If it was, then the first port on your serial card should be mapped to /dev/ttyS0. If not, then udev may have picked up the onboard port as /dev/ttyS0 and made your card /dev/ttyS1 (or another number). I have two Debian 4 boxes with the serial console working. It has been quite a while since I set this up, but I'm pretty sure that I just added this line to /etc/inittab and then restarted init: co:2345:respawn:/sbin/getty -L ttyS0 9600 vt102 I think the co may have something to do with it. Sorry I can't be more help, I'm really rusty on this. I did this 5 years ago and I've never had to do it again. Hope this helps. - Dave
Re: Quiet option for ifup/ifdown (dhcp)
dhclient has a quiet option but because ifup/ifdown calls it I haven't been able overide this. ifup must get called from a script, so you could probably just edit the script and suppress the output from ifup. - Dave
Re: Programming question
- Original Message - From: Alexander Samad a...@samad.com.au Date: Friday, May 14, 2010 9:35 pm Subject: Programming question To: Debian User List debian-user@lists.debian.org Hi I was wondering if it is possible to decode this javascript from the command line var serializer = new Serializer() serializer.deserialize('B64ENCe30=') can't find any reference on how serialize works and can't find any cmdline tools to help Alex Hi Alex, I'm not an expert, but my understanding is that serialization is a process which converts various data types into a byte stream which can be stored and transmitted like a string. If you had some serialized data stored in a file and you knew what scheme was used to serialize the data, you might be able to use a tool such as dd to decode it. I'm not sure if there is a standard serialization encoding scheme, though, or if it is implemented differently across various programming languages. The Wikipedia article on serialization might answer some questions: http://en.wikipedia.org/wiki/Serialization Hope this helps. - Dave
Re: bind9 rndc reload problem
- Original Message - From: Jari Fredriksson ja...@iki.fi Date: Wednesday, March 31, 2010 9:24 pm Subject: bind9 rndc reload problem To: Debian Users list debian-user@lists.debian.org When I command rndc reload, this will be written to daemon.log Apr 1 04:13:17 spitfire named[19287]: received control channel command 'reload' Apr 1 04:13:17 spitfire named[19287]: loading configuration from '/etc/bind/named.conf' Apr 1 04:13:17 spitfire named[19287]: using default UDP/IPv4 port range: [1024, 65535] Apr 1 04:13:17 spitfire named[19287]: using default UDP/IPv6 port range: [1024, 65535] Apr 1 04:13:17 spitfire named[19287]: reloading configuration succeeded Apr 1 04:13:17 spitfire named[19287]: reloading zones succeeded All seems good. But no, if I have changed, or modified the zone records,for example added or removed an address, the changes do not show! Using Debian Lenny, BIND 9.6.1-P3 I tried to google, but could not find a suitable solution. The new configuration comes alive if I do a restart for bind, but that reload does not make it. The configuration files are as follows: /etc/bind/named.conf | /etc/bind/named.conf.local | /etc/bind/myzone.hosts I think this is how it is supposed to be in Debian. So. 1. I change a zone file 2. I add one to serial in the zone file 3. I command rndc reload 4. rndc connects to named, and all seems good 5. changes do not show up :( Any ideas? Hello, Are you changing the serial number in the zone file? Generally, a good way to create the serial number is to use the format of: MMDDNN Where: Y = Year M = Month D = Day N = revision number starting at 00 So if you edit the file on March 31, 2010, you would make the serial number 2010033100. If you edit it again on the same day, you would just increment the last digit. You should update the serial number in any zone file you edit before running rndc reload. - Dave
Re: connecting to WPA wireless network with ipw2100
Whoops. /sbin/iwscan list Sorry, that command should be: /sbin/iwlist scan - Dave
Re: connecting to WPA wireless network with ipw2100
- Original Message - From: Seb levi.vi...@gmail.com Date: Wednesday, March 31, 2010 8:32 pm Subject: connecting to WPA wireless network with ipw2100 To: debian-user@lists.debian.org Hello all! I just aquired an IBM Thinkpad X31 laptop and have to work out the wireless (amongst other things). The firmware (firmware-ipw2x00) and drivers are installed and working (I think). dojo:~# lspci | grep -i wireless 02:02.0 Network controller: Intel Corporation PRO/Wireless LAN 2100 3B Mini PCI Adapter (rev 04) I'm using wicd from the lenny-backports since I had very good experiences with wicd on my other machines. However, if I try and connect to my wireless - WPA-TKIP, Mixed mode (B and G) - I keep getting the message: Connection failed: Could not contact the wireless access point. I'm positive the WAP is up and running since I'm writing this here from my other machine through it. Syslog contains some dhclient messages that look like this: 00:57:52 dhclient: Listening on LPF/eth2/00:04:23:96:55:2a 00:57:52 dhclient: Sending on LPF/eth2/00:04:23:96:55:2a 00:57:52 dhclient: Sending on Socket/fallback And that's all that sticks out to me... Any hints/tips/clues much appreciated, let me know if you need any more info. TIA, Sebi Hello, Proving that your wireless card can communicate with your access point would be a good first step. You can see if your card is picking up the access point by installing the wireless-tools package and then running this command: /sbin/iwscan list You should see information about every access point within an acceptable range of your laptop. If your access point shows up, then at least you know that it is not a driver problem. If it does not show up, or if you can't even get iwscan to work, then you might have a driver problem or some bad hardware. I have a laptop with an Intel Corporation PRO/Wireless 2200BG wireless card and it works fine on my WPA-TKIP wireless network using the ipw2200 driver. (AP is a Linksys WAP54G). Hope this helps. - Dave
Re: samba query
Hi, How can I make samba only accept log ins, if the password supplied by the client, matches that username on the server? eg. blank or wrong passwords shouldn't be allowed access to the server, so how do I enablethis? It seems samba by default accepts blank passwords, and lets the client mount the share, or even if the password is wrong. Also, will this behaviour that I am asking about be compatible with win xp? I'll add a user on the linux server, with the same user name as the xp one, will the xp client be able to connect? Thanks, Dan. This works fine for me. You might simply be missing a line in your config file or something. In your smb.conf: # Guest account guest account = smbguest # Security mode security = user # Passwords encrypt passwords = true smb passwd file = /etc/samba/smbpasswd unix password sync = Yes passwd program = /usr/bin/passwd %u passwd chat = *New*password* %n\n *Retype*new*password* %n\n *passwd:*all*authentication*tokens*updated*successfully* pam password change = yes # User authentication username map = /etc/samba/smbusers obey pam restrictions = yes # Anonymous users mapped to guest user map to guest = bad user In your smbusers file, map Linux usernames to Windows usernames: smbguest = guest myuser = My User So the Windows user My User would get mapped to the Linux user myuser. You can specify passwords for the Samba users using smbpasswd: smbpasswd -c /etc/samba/smb.conf myuser And just replace /etc/samba with the path to your smb.conf file if it is different. This works fine for me from Windows XP. When I access a Samba share I get prompted for the password, and if I put in an incorrect password then I get re-prompted a few times and eventually locked out (technically I get mapped to the Samba guest user, but my guest user has no access). If I put in the correct password then itall works fine. Hope this helps. - Dave
Re: Domain server on linux
Need some help, i just want to know, is linux can be a domain server ?? in my office, we already have 2 server, it is DHCP server and domain server. both of it using windows. i want to change the domain server with linux, but don't know how?? may be some body have some experience to share.. Hello, Are you talking about Active Directory? Have you looked at Samba? http://www.samba.org/samba/docs/man/Samba-HOWTO-Collection/samba-pdc.html#id2562489 Samba can act as a domain controller, but if you are looking to get rid of Windows completely then you would also need to implement an LDAP system and migrate your AD accounts over to it. - Dave
Re: Suggestions for video/tv capture?
- Original Message - From: David Parker dpar...@utica.edu Date: Tuesday, September 29, 2009 8:08 pm Subject: Re: Suggestions for video/tv capture? To: debian-user@lists.debian.org I have had great luck with my Hauppauge PVR-350 and PVR-150 cards, but they are getting harder to find these days. They use the ivtv drivers under Linux, and the manufacturer's drivers under Windows work quite well. - Dave - Original Message - From: Dennis Wicks w...@mgssub.com Date: Tuesday, September 29, 2009 8:03 pm Subject: Suggestions for video/tv capture? To: debian-user@lists.debian.org Greetings; I have a lot of VHS tapes that I would like to put on CDs or DVDs. Any suggestions for a decent capture card? I would prefer one that is O/S neutral so I can run it on Deb or XP, but that isn't an absolute requirement. Grateful for any help! TIA! Dennis And sorry everyone for top-posting! It was an accident! - Dave
Re: Suggestions for video/tv capture?
I have had great luck with my Hauppauge PVR-350 and PVR-150 cards, but they are getting harder to find these days. They use the ivtv drivers under Linux, and the manufacturer's drivers under Windows work quite well. - Dave - Original Message - From: Dennis Wicks w...@mgssub.com Date: Tuesday, September 29, 2009 8:03 pm Subject: Suggestions for video/tv capture? To: debian-user@lists.debian.org Greetings; I have a lot of VHS tapes that I would like to put on CDs or DVDs. Any suggestions for a decent capture card? I would prefer one that is O/S neutral so I can run it on Deb or XP, but that isn't an absolute requirement. Grateful for any help! TIA! Dennis -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: AMD64 in vmware
Thanks everyone for the reply. On Mon, 16 Mar 2009 11:06:48 -0400, David A. Parker wrote: You are asking if you can run a 64bit VM guest on a 32bit host? Sorry. Can't do it. Even if you have a 64bit processor, if you only have a 32bit host it won't work. I thought this was possible Interesting, IIRC, launching AMD64 apps under chroot in i386 won't work, is this still true? I don't think the chroot will work, but VMware will run a 64-bit guest on a 32-bit host if your CPU has VT support. as long as the physical CPU has VT support enabled and the BIOS supports it as well. How can I tell? $ grep -i vt /proc/cpuinfo || echo no no Does it means that my CPU has no VT support? I'm not sure if there is a way to tell from the CPU flags in cpuinfo. If you can reboot the machine, the VT option should be somewhere in the BIOS if it is supported. - Dave
Re: Forward System Messages to SSH
Now and then, messages are output to the tty display, such as USB devices being plugged in, etc. Is there a way to have those messages sent to an SSH terminal? I'm using OpenSSH. I believe you can change where those messages go by editing your /etc/syslog.conf file, specifically these lines (found at the bottom): daemon.*;mail.*;\ news.err;\ *.=debug;*.=info;\ *.=notice;*.=warn |/dev/xconsole I have never tried redirecting those messages to an SSH terminal, though. I think it would need to be bound to a named pipe in order for syslog to send messages to it. Again, I've never tried it so I could be very wrong about that. - Dave
Re: tv/radio card
There are a lot of TV tuner cards that work in Linux, either with native drivers or with drivers like ivtv. I have a Debian Etch box running MythTV with two TV tuner cards in it, a Hauppauge PVR-350 and a Hauppauge PVR-150, both of which use the ivtv drivers. The PVR-350 supports MPEG encoding and decoding, so it can be used for recording and playback. It also comes with a remote control and IR sensor which work very well using lirc, and it has an on-board FM tuner which I have not personally used, but I believe does work under Linux. The PVR-150 is only an encoder and can only be used for recording. These two cards are fairly old, though, and I'm sure there are better options out there now. I have read a lot of Would you have any reason not to buy a PVR-350 card? Since from if I understand you correctly, it will both record and allow me to watch tv? Is this a usb or a card you put in your motherboard? The PVR-350 and PVR-150 are both internal PCI cards. In my experience, the PVR-350 works very well and would be a good choice if you need both recording and playback functionality. The encoder and decoder on the card are separate, which means you can record one show and watch an already-recorded show at the same time. With the PVR-150 in the box, I can simultaneously record two things and watch something else, which is really nice. I have been very happy with these cards, but they fell out of favor with the maintainers of MythTV a while ago because of the lack of vendor support for Linux. My understanding is that the first few versions of MythTV explicitly supported and recommended these cards, but in later versions they ran into some glitches while implementing new features, and Hauppauge would not provide any support for the cards under Linux. The ivtv drivers are generic drivers for the Conexant chipset used on the Hauppauge cards, so they aren't supported by the vendor. Nvidia came out with a series of hardware encoding/decoding chipsets and also provided native Linux drivers and support for them, so the MythTV devs started recommending those instead. I have only used the two Hauppauge cards, though, so I don't know much about the other options. Ok. If I got remote support working, would I be able to do most things just with the remote eg, change channel, adjust volume, and enable recording? Yes. If you are using lirc, you can create a config file which maps the buttons on the remote to functions in the software you are using. MythTV comes with a stock config for the Hauppauge remote, and I'm sure other such projects do as well. Channel selection, volume control, playback functions (play, pause, fast-forward, rewind, stop) all work. The MythTV forums might be a good place to look, since tuner cards are a big topic of discussion, and a lot of people mention other TV and radio programs, too. Cool I'll take a look. Thanks very much for the reply, No problem. - Dave
Re: tv/radio card
I'm wanting to buy a tv tuner for my computer, but before I do I have a couple of questions: - Do internal tv cards or usb tv cards work best? - What models/brands are well supported? - Does Remote control support work? - Do any allow for reccording of tv? - Do any supported cards come with a built in fm radio tuner? If so what card should I get. Finally, once my card is working, what programs should I use to controlthe radio and tv? I found gnomeradio which seems to work with orca (I am blind, so I need a program that is either gtk or command line based), but does anyone know of a program that could control the tv? (that isn't qt based). Finally these cards will allow me to pick up standard tv like my normaltv would won't it? Thanks for any info, Daniel Hi, There are a lot of TV tuner cards that work in Linux, either with native drivers or with drivers like ivtv. I have a Debian Etch box running MythTV with two TV tuner cards in it, a Hauppauge PVR-350 and a Hauppauge PVR-150, both of which use the ivtv drivers. The PVR-350 supports MPEG encoding and decoding, so it can be used for recording and playback. It also comes with a remote control and IR sensor which work very well using lirc, and it has an on-board FM tuner which I have not personally used, but I believe does work under Linux. The PVR-150 is only an encoder and can only be used for recording. These two cards are fairly old, though, and I'm sure there are better options out there now. I have read a lot of praise for Nvidia's TV tuner cards as well. MythTV may not fit your needs as it is based on Qt, and that's all I have personally used with these tuner cards so I'm afraid I can't make any recommendations about software, but I'm sure there are several available. The MythTV forums might be a good place to look, since tuner cards are a big topic of discussion, and a lot of people mention other TV and radio programs, too. I hope this helps. - Dave
Re: error in script
- Original Message - From: David Parker [EMAIL PROTECTED] Date: Thursday, September 4, 2008 10:30 pm Subject: Re: error in script To: L.V.Gandhi [EMAIL PROTECTED] Cc: debian-user debian-user@lists.debian.org Try echoing the value of $i each time through the loop. I wonder if the exit 0 when $i = 0 is the problem. Oops. I meant to say when $i = 20. Sorry. - Dave
Re: error in script
- Original Message - From: L.V.Gandhi [EMAIL PROTECTED] Date: Thursday, September 4, 2008 9:50 pm Subject: error in script To: debian-user debian-user@lists.debian.org I have a script as follows #!/bin/bash rm -f ~/stock/flstock.csv grep FUTSTK ~/stock/today/$1 |grep 25/09/2008|cut -s -d, -f9|sort -nr temp i=0 for trv in $(cat temp) do grep $trv ~/stock/today/$1 ~/stock/flstock.csv i=$((i+1)) if [ $i -eq 20 ] then exit 0 fi done rm -f temp cat ~/stock/flstock.csv |cut -s -d, -f2|sort ~/stock/fliquidstocks.txt Last line is not getting executed . But if I run last line afterwards in console, it works. Can someone throw somelight why it happens. Try echoing the value of $i each time through the loop. I wonder if the exit 0 when $i = 0 is the problem. - Dave
Re: udev z25_persistent-net.rules problem
Thanks. The post that said this was fixed in the forcedeth driver in testing, any idea what this file is called so I can download it and get it installed? The driver is part of the linux-image-2.6.25.2 kernel package. - Dave
Re: udev z25_persistent-net.rules problem
- Original Message - From: Account for Debian group mail [EMAIL PROTECTED] Date: Friday, July 25, 2008 10:43 pm Subject: udev z25_persistent-net.rules problem To: debian-user@lists.debian.org The next time it boots up the machine does not recognize eth0 and there is a eth1 added to the above file. If I change the /etc/network/interfaces file to eth1 and do a ifup -a there is the Internet. Each time the machine is booted up the number climbs eth1 eth2 eth3 ... etc. Hi, This is a problem with the forcedeth driver in etch. See this post: http://lists.debian.org/debian-user/2007/10/msg02402.html I hope this helps. - Dave
Re: sound on ibm netvista
I bought a used IBM Netvista machine and alsaconf cannot find the on board sound card. I really need a lot of help. You might need to compile a driver (I had to for my onboard Intel audio chipset in Etch). The lspci command might yield some better information about what the sound hardware is. Check out the alsa vendor/driver list and see if there's something that will work with your hardware: http://www.alsa-project.org/main/index.php/Matrix:Main I hope this helps. - Dave -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Gigabyte M61P-S3 and wild MAC address of ethernet interface
Problem solved! :-D Thank you for your help. I am still wondering why this kind of problem is possible. Is the problem the hardware, the driver or the kernel? Or is it just the property that I am not aware of? Tero Mäntyvaara Hello, I have this exact same motherboard, and I experienced this same problem. As I understand it (through several Google searches), the main cause of the problem is that the onboard Nvidia NIC is not supported correctly by the forcedeth driver in Etch. Basically, the driver isn't able to correctly query the NIC for the MAC address. Because it's not able to get a real MAC address from NIC, it assigns a random one instead, which causes some bizarre behavior. The specific problem that I was having was that the device number of the NIC would change each time I rebooted (since the MAC address was different), so it was eth0, then eth1, then eth2, etc. Another person also had problems with this NIC and the forcedeth driver. That post is here: http://lists.debian.org/debian-user/2007/10/msg02402.html Hope this helps. - Dave
Re: The previous nonsense
The computer, a Toshiba Satellite A30 with 1.2 gig ram and a 40 gig hard drive was originally dual boot MS-Debian 3.1. Windows quit. Who knows why. Printer: HP officejet 4110 all-in-one - cupsys installed and set up according to the information I found but still non- functional. However, it will copy and send faxes. It will copy and send faxes from Debian, or from the all-in- one's control interface on the unit itself? (Printing is still way too hard, in Linux, Windows, and Mac OS/X.) Hmmm... CUPS (cupsys) is installed, but are the drivers? You could try installing them if they're not already (as root): apt-get install foomatic-filters foomatic-filters-ppds hpijs linuxprinting.org-ppds Speaker is dead. It does work using the live Kubuntu disc As someone mentioned, what's the output of lsmod and of groups? Try something like: lsmod | grep snd_ , but before I screw with the hard disk there are some pictures of my wife, who recently died, I'm very sorry to hear that. I'm curious, do you have a USB thumbdrive or some other media you could back thing up on? USB support in Debian is pretty good these days, and if you run into problems, I'm sure we could help you out. Sorry if this message is formatted or or wrapped funny. The client I'm using right now does not handle replies very well. - Dave
Re: Getting Thunderbird to use Firebird as default browser
<[EMAIL PROTECTED]> frans <[EMAIL PROTECTED]> wrote: Also thanks: I discovered by your information that the command:ln -s /usr/bin/mozilla /etc/alternatives/gnome-www-browserworked fine!!! The true Debian Way (tm) would be: #update-alternatives --config gnome-www-browser This will give you a list of possible browsers to choose from. I installed Firefox from the tarball and not the Debian package a few months ago, and was not able to use update-alternatives because it did not recognize Firefox as satisfying the gnome-www-browser requirements. In this case, I discovered you have to run gconf-editor and set the http and https handler to your Firefox binary manually. Then all was well. - Dave
Re: trouble getting my wireless stuff to work
- Original Message -From: tom arnall <[EMAIL PROTECTED]>Date: Tuesday, April 11, 2006 6:02 pmSubject: trouble getting my wireless stuff to workTo: debian-user@lists.debian.org i am a linux newbie having trouble getting my wireless stuff to work. i am running debian on a toshiba satellite laptop. the wireless card is a d-link dwl-g650. i am looking for info on the latest debian methods for dealing with this technology. thanks, tom arnall north spit, ca -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]Hello,I had great luck just a few days ago with ndiswrapper and wpa_supplicant. I am now using a Linksys WPC54G wireless card with an old Acer laptop running Debian and it works just fine. You will likely need to compile both of them, but it was very easy to do and once they were compiled, the instructions on their respective pages were very easy to follow. ndiswrapper allows you to use the Windows driver for almost any device in Linux. wpa_supplicant allows you to define connections that use WPA.http://ndiswrapper.sourceforge.net/http://hostap.epitest.fi/wpa_supplicant/ Good Luck, Dave
Re: A Question
When you boot up with the promise card in, does it show on your screen (the next page after it shows all your drives)? This is one of the weirder parts of the problem. The Promise BIOS comes up after the POST, but it says no drives are detected. However, when Debian booted, the drive was then found as hde (as it should be) and this would be follwed by a whole bunch of CRC check failures. The fact that Debian found the drive and assigned it to a device, and usually even mounted it, tells me that the card must be working. It doesn't explain why the card's BIOS says there is no drive attached, though. I'm going to hook the machine back up tonight, and I'll be able to post the actual errors tomorrow. These CRC check errors continued to spew out into /var/messages several times per minute while the box was running, even with the drive mounted and working fine. What about the BIOS? On the page where it gives your boot options, do you have 'SCSI listed? SCSI isn't an option in the BIOS for this box. It's an old Dell Optiplex GX1, completey IDE-based, and the only options for a boot device are PXE (Network), CD, HDD, and floppy. I don't mean to offend you with these stupid questions if you already know this stuff! g No offense taken! If you don't start with the basics, you'll never find the cause of a problem. This is all stuff I should have mentioned before, anyway. Also, I got your e-mail with the links, and they were helpful. It looks like most people are using this card with sarge just fine, which makes me wonder about mine. I would like to know the name of that driver if you have it, though. Thanks for all the help. - Dave -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]