LinuxQuestions.org
Welcome to the most active Linux Forum on the web.
Go Back   LinuxQuestions.org > Forums > Linux Forums > Linux - Distributions > Debian
User Name
Password
Debian This forum is for the discussion of Debian Linux.

Notices


Reply
  Search this Thread
Old 08-29-2019, 02:39 PM   #16
Firerat
Senior Member
 
Registered: Oct 2008
Distribution: Debian sid
Posts: 2,683

Rep: Reputation: 783Reputation: 783Reputation: 783Reputation: 783Reputation: 783Reputation: 783Reputation: 783

Code:
cat /etc/udev/rules.d/70-persistent-net.rules
comment out each line
Code:
sed 's/SUBSYSTEM/#SUBSYSTEM/' /etc/udev/rules.d/70-persistent-net.rules
if the result looks good ( all lines start # )
Code:
sudo sed -i 's/^SUBSYSTEM/#SUBSYSTEM/' /etc/udev/rules.d/70-persistent-net.rules
the -i
Code:
-i[SUFFIX], --in-place[=SUFFIX]
 edit files in place (makes backup if SUFFIX supplied)
to revert
Code:
sudo sed -i 's/^#SUBSYSTEM/SUBSYSTEM/' /etc/udev/rules.d/70-persistent-net.rules


no ifconfig?

try
Code:
ip addr
man ip
 
Old 08-29-2019, 04:12 PM   #17
arvid001
LQ Newbie
 
Registered: Apr 2018
Posts: 22

Original Poster
Rep: Reputation: Disabled
Conflicting suggestions....which to use?

Code:
root@RadioRoom:/home/arv# ip addr
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host 
       valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
    link/ether d0:50:99:3c:48:ae brd ff:ff:ff:ff:ff:ffroot@RadioRoom:/home/arv# ip addr
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host 
       valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
    link/ether d0:50:99:3c:48:ae brd ff:ff:ff:ff:ff:ff
    inet 192.168.0.8/24 brd 192.168.0.255 scope global dynamic noprefixroute eth0
       valid_lft 57545sec preferred_lft 57545sec
    inet6 fe80::d250:99ff:fe3c:48ae/64 scope link noprefixroroot@RadioRoom:/home/arv# ip addr
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host 
       valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
    link/ether d0:50:99:3c:48:ae brd ff:ff:ff:ff:ff:ff
    inet 192.168.0.8/24 brd 192.168.0.255 scope global dynamic noprefixroute eth0
       valid_lft 57545sec preferred_lft 57545sec
    inet6 fe80::d250:99ff:fe3c:48ae/64 scope link noprefixroute 
       valid_lft forever preferred_lft forever
root@RadioRoom:/home/arv# ute 
       valid_lft forever preferred_lft forever
root@RadioRoom:/home/arv# 
    inet 192.168.0.8/24 brd 192.168.0.255 scope global dynamic noprefixroute eth0
       valid_lft 57545sec preferred_lft 57545sec
    inet6 fe80::d250:99ff:fe3c:48ae/64 scope link noproot@RadioRoom:/home/arv# ip addr
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00root@RadioRoom:/home/arv# ip addr
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host root@RadioRoom:/home/arv# ip addr
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host 
       valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
    link/ether d0:50:99:3c:48:ae brd ff:ff:ff:ff:ff:ff
    inet 192.168.0.8/24 brd 192.168.0.255 scope global dynamic noprefixroute eth0
       valid_lft 57545sec preferred_lft 57545sec
    inet6 fe80::d250:99ff:fe3c:48ae/64 scope link noprefixroute 
       valid_lft forever preferred_lft forever
root@RadioRoom:/home/arv# 
       valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
    link/ether d0:50:99:3c:48:ae brd ff:ff:ff:ff:ff:ff
    inet 192.168.0.8/24 brd 192.168.0.255 scope global dynamic noprefixroute eth0
       valid_lft 57545sec preferred_lft 57545sec
    inet6 fe80::d250:99ff:fe3c:48ae/64 scope link noprefixroute 
       valid_lft forever preferred_lft forever
root@RadioRoom:/home/arv# 
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host 
       valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
    link/ether d0:50:99:3c:48:ae brd ff:ff:ff:ff:ff:ff
    inet 192.168.0.8/24 brd 192.168.0.255 scope global dynamic noprefixroute eth0
       valid_lft 57545sec preferred_lft 57545sec
    inet6 fe80::d250:99ff:fe3c:48ae/64 scope link noprefixroute 
       valid_lft forever preferred_lft forever
root@RadioRoom:/home/arv# refixroute 
       valid_lft forever preferred_lft forever
root@RadioRoom:/home/arv#
Makes no sense to me. What is a "valid_lft"? What happened to IP-V4?

Should I go ahead with the system mods suggested by "fireat"?
Or, is there a problem with drivers for the Realtek Ethernet board as suggested by Thinknix?

Thanks
 
Old 08-29-2019, 04:42 PM   #18
arvid001
LQ Newbie
 
Registered: Apr 2018
Posts: 22

Original Poster
Rep: Reputation: Disabled
Correction...this is on the Buster boot

My last post was result using "ip addr" with a boot to the old kernel (I got confused).
This post shows "ip addr" output using the newest kernel with Debian Buster release.

Code:
arv@RadioRoom:~$ su
Password: 

root@RadioRoom:/home/arv# ip addr
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host 
       valid_lft forever preferred_lft forever

root@RadioRoom:/home/arv# ping localhost
PING localhost(localhost (::1)) 56 data bytes
64 bytes from localhost (::1): icmp_seq=1 ttl=64 time=0.036 ms
64 bytes from localhost (::1): icmp_seq=2 ttl=64 time=0.042 ms
64 bytes from localhost (::1): icmp_seq=3 ttl=64 time=0.042 ms
^C
--- localhost ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 34ms
rtt min/avg/max/mdev = 0.036/0.040/0.042/0.003 ms

root@RadioRoom:/home/arv# ping 192.168.0.1
connect: Network is unreachable
root@RadioRoom:/home/arv#
So, is the problem with naming of port interface, or is it with Realtek drivers?
Or...is it something else? Is the newest kernal not usable with the Buster release?

Next step...?
 
Old 08-29-2019, 04:48 PM   #19
Firerat
Senior Member
 
Registered: Oct 2008
Distribution: Debian sid
Posts: 2,683

Rep: Reputation: 783Reputation: 783Reputation: 783Reputation: 783Reputation: 783Reputation: 783Reputation: 783
for now just

cat /etc/udev/rules.d/70-persistent-net.rules

lets see if it is forcing drivers not in the newer kernel
 
Old 08-29-2019, 05:30 PM   #20
arvid001
LQ Newbie
 
Registered: Apr 2018
Posts: 22

Original Poster
Rep: Reputation: Disabled
Code:
# This file was automatically generated by the /lib/udev/write_net_rules
# program, run by the persistent-net-generator.rules rules file.
#
# You can modify it, as long as you keep each rule on a single
# line, and change only the value of the NAME= key.

# PCI device 0x10ec:0x8168 (r8169)
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="d0:50:99:3c:48:ae", ATTR{dev_id}=="0x0", ATTR{type}=="1", KERNEL=="eth*", NAME="eth0"
arv@RadioRoom:~$
Does this indicate that the r8169 driver is being used, or that that driver is needed but not being used?
 
Old 08-29-2019, 05:58 PM   #21
Firerat
Senior Member
 
Registered: Oct 2008
Distribution: Debian sid
Posts: 2,683

Rep: Reputation: 783Reputation: 783Reputation: 783Reputation: 783Reputation: 783Reputation: 783Reputation: 783
Quote:
Originally Posted by arvid001 View Post
Code:
# This file was automatically generated by the /lib/udev/write_net_rules
# program, run by the persistent-net-generator.rules rules file.
#
# You can modify it, as long as you keep each rule on a single
# line, and change only the value of the NAME= key.

# PCI device 0x10ec:0x8168 (r8169)
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="d0:50:99:3c:48:ae", ATTR{dev_id}=="0x0", ATTR{type}=="1", KERNEL=="eth*", NAME="eth0"
arv@RadioRoom:~$
Does this indicate that the r8169 driver is being used, or that that driver is needed but not being used?
it looks like when that file was generated it was the r8169 driver that was being used

comment out the SUBSYSTEM line ( use the sed or edit manually by starting line with #)

the worst that can happen is you will lose net on the old kernel, but we just need to change teh file back to what it was

after a reboot you may see enp instead of eth when using "ip address" command
 
Old 08-29-2019, 10:30 PM   #22
arvid001
LQ Newbie
 
Registered: Apr 2018
Posts: 22

Original Poster
Rep: Reputation: Disabled
Modified NAME="eth" to NAME="enp" with no change.

Code:
root@RadioRoom:/home/arv# cat /etc/udev/rules.d/70*
# This file was automatically generated by the /lib/udev/write_net_rules
# program, run by the persistent-net-generator.rules rules file.
#
# You can modify it, as long as you keep each rule on a single
# line, and change only the value of the NAME= key.

# PCI device 0x10ec:0x8168 (r8169)
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="d0:50:99:3c:48:ae", ATTR{dev_id}=="0x0", ATTR{type}=="1", KERNEL=="eth*", NAME="enp"
root@RadioRoom:/home/arv# 
root@RadioRoom:/home/arv# ip addr
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host 
       valid_lft forever preferred_lft forever
root@RadioRoom:/home/arv# 
root@RadioRoom:/home/arv# ping 192.168.0.1
connect: Network is unreachable
root@RadioRoom:/home/arv#
Okay...NAME="eth" changed to NAME="enp". Nothing seems to have changed.
Still no networking using latest kernel and Debian Buster.
This change to NAME="enp" made no change in the old kernel...networking there still works fine.

What next?
 
Old 08-30-2019, 08:06 AM   #23
Firerat
Senior Member
 
Registered: Oct 2008
Distribution: Debian sid
Posts: 2,683

Rep: Reputation: 783Reputation: 783Reputation: 783Reputation: 783Reputation: 783Reputation: 783Reputation: 783
sorry, that enp eth comment may have confused you.

change it back ( to eth* and eth0 )
and comment that line out
that will in effect delete that rule and let the system manage the network device itself
 
Old 08-30-2019, 10:47 AM   #24
arvid001
LQ Newbie
 
Registered: Apr 2018
Posts: 22

Original Poster
Rep: Reputation: Disabled
OK, restored the "NAME=" part and commented out that line in the file, as instructed.
Still no networking when using the latest kernel.

What next?
 
Old 08-30-2019, 10:59 AM   #25
Firerat
Senior Member
 
Registered: Oct 2008
Distribution: Debian sid
Posts: 2,683

Rep: Reputation: 783Reputation: 783Reputation: 783Reputation: 783Reputation: 783Reputation: 783Reputation: 783
hmm,
maybe I should go read that release notes thing, to see what it was saying.
in the meantime,

Code:
lspci -k|grep -A3 Ethernet\ con
will list your Ethernet controllers including the kernel driver/module in use
mine as example
Code:
04:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller (rev 01)
        Subsystem: ABIT Computer Corp. RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller
        Kernel driver in use: r8169
        Kernel modules: r8169
05:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller (rev 01)
        Subsystem: ABIT Computer Corp. RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller
        Kernel driver in use: r8169
        Kernel modules: r8169
--
07:06.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8169 PCI Gigabit Ethernet Controller (rev 10)
        Subsystem: Realtek Semiconductor Co., Ltd. RTL8169/8110 Family PCI Gigabit Ethernet NIC
        Kernel driver in use: r8169
        Kernel modules: r8169
yeah, Abit a blast from the past

do that both on new and old so we can compare
 
Old 08-30-2019, 12:19 PM   #26
Firerat
Senior Member
 
Registered: Oct 2008
Distribution: Debian sid
Posts: 2,683

Rep: Reputation: 783Reputation: 783Reputation: 783Reputation: 783Reputation: 783Reputation: 783Reputation: 783
after reviewing the release notes it seemed more concerned with networking scripts not picking up the new net device names ( ethX -> enpYsZ )

so,
after commenting out the udev rules your eth0 shoulld be enp1s0

you will edit all your network related scripts and replace eth0 with enp1s0

alternatively, you could try re-enabling the rule, and have it
Code:
# PCI device 0x10ec:0x8168 (r8169)
#SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="d0:50:99:3c:48:ae", ATTR{dev_id}=="0x0", ATTR{type}=="1", KERNEL=="eth*", NAME="eth0"
# PCI device 0x10ec:0x8168 (r8169)
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="d0:50:99:3c:48:ae", ATTR{dev_id}=="0x0", ATTR{type}=="1", KERNEL=="enp1s0", NAME="eth0"
but the release notes do say that may not work
 
Old 08-30-2019, 02:43 PM   #27
arvid001
LQ Newbie
 
Registered: Apr 2018
Posts: 22

Original Poster
Rep: Reputation: Disabled
Code:
root@RadioRoom:/home/arv# 
root@RadioRoom:/home/arv# cat ./test_results
WITH OLD KERNEL: Version 4.19.0-5 AMD64

root@RadioRoom:/home/arv# lspci -k|grep -A3 Ethernet\ con
01:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller (rev 11)
	Subsystem: ASRock Incorporation Motherboard (one of many)
	Kernel driver in use: r8168
	Kernel modules: r8168
root@RadioRoom:/home/arv# 

============================
WITH NEW KERNEL: Version 4.9.0-5 AMD64

root@RadioRoom:/home/arv# lspci -k|grep -A3 Ethernet\ con
01:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller (rev 11)
	Subsystem: ASRock Incorporation Motherboard (one of many)
	Kernel driver in use: r8168
	Kernel modules: r8168
root@RadioRoom:/home/arv# 

============================
Cat of /etc/udev/rules.d/70* Now modified to show KERNEL="enp1s0" and NAME="eth0"

# This file was automatically generated by the /lib/udev/write_net_rules
# program, run by the persistent-net-generator.rules rules file.
#
# You can modify it, as long as you keep each rule on a single
# line, and change only the value of the NAME= key.

# PCI device 0x10ec:0x8168 (r8169)
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="d0:50:99:3c:48:ae", ATTR{dev_id}=="0x0", ATTR{type}=="1", KERNEL=="enp1s0", NAME="eth0"

NETWORKING WITH NEW KERNAL:   It works!, It works!  8-)  8-)  

root@RadioRoom:/home/arv# ping 192.168.0.1
PING 192.168.0.1 (192.168.0.1) 56(84) bytes of data.
64 bytes from 192.168.0.1: icmp_seq=1 ttl=64 time=0.463 ms
64 bytes from 192.168.0.1: icmp_seq=2 ttl=64 time=0.425 ms
64 bytes from 192.168.0.1: icmp_seq=3 ttl=64 time=0.360 ms
^C
--- 192.168.0.1 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 56ms
rtt min/avg/max/mdev = 0.360/0.416/0.463/0.042 ms
root@RadioRoom:/home/arv# ping 8.8.8.8
PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data.
64 bytes from 8.8.8.8: icmp_seq=1 ttl=56 time=18.7 ms
64 bytes from 8.8.8.8: icmp_seq=2 ttl=56 time=19.0 ms
64 bytes from 8.8.8.8: icmp_seq=3 ttl=56 time=18.6 ms
^C
--- 8.8.8.8 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 5ms
rtt min/avg/max/mdev = 18.612/18.783/19.044/0.187 ms
root@RadioRoom:/home/arv#
Success at last. Thank you, thank you. Seems that the Kernal="enp1s0" change fixed everything.
Maybe a check could be put in the install script to test for this and automatically fix it if needed.

Thanks again. I could not have done it without your help.
 
Old 08-30-2019, 02:55 PM   #28
arvid001
LQ Newbie
 
Registered: Apr 2018
Posts: 22

Original Poster
Rep: Reputation: Disabled
OOPS! I spoke to quickly. After a reboot on the 4.9.0-5 AMD64 kernal, networking is still broken.
Present guess is that I was confused about which kernal I was actually running. 8-(

THIS IS ON THE OLD KERNAL (running Debian 10/Buster but with the old kernal)
Networking works on this kernal.
Code:
[root@RadioRoom:/etc# cat ./os-release
PRETTY_NAME="Debian GNU/Linux 10 (buster)"
NAME="Debian GNU/Linux"
VERSION_ID="10"
VERSION="10 (buster)"
VERSION_CODENAME=buster
ID=debian
HOME_URL="https://www.debian.org/"

Are there any error logs that might shed some light on this situation?

Thanks.
 
Old 08-30-2019, 04:44 PM   #29
Firerat
Senior Member
 
Registered: Oct 2008
Distribution: Debian sid
Posts: 2,683

Rep: Reputation: 783Reputation: 783Reputation: 783Reputation: 783Reputation: 783Reputation: 783Reputation: 783
yeah, to be expected ( if I understand correctly )

the "new" udev rules are a just a hack to keep your network setup scripts happy
they will not work on the older kernel since udev fails to setup the network device ( no enp1s0 to rename ).

I would correct the network scripts, as per
https://www.debian.org/releases/bust...nterface-names

Code:
$ sudo rgrep -w eth0 /etc 
$ udevadm test-builtin net_id /sys/class/net/eth0 2>/dev/null
you don't need that udevadm one tbh,
we already know you need to replace eth0 with enp1s0

so for each file found with that rgrep
copy line and replace eth0 with enp1s0
comment out the old line, and comment on why
# 2019-08-30 pre-buster net device eth0 now enp1s0

and comment out the udev rule ( annotate that also )

I can't think of any reason would would need to boot the old kernel
It will probably be auto removed in a few months due to kernel updates.


It looks like I should do this myself, I still have the old /etc/udev/rules.d/70-persistent-net.rules , and I'm on Debian Sid.. It will probably break at some point in the future


Note you may need to fix other configs,
might be worth running that rgrep on ~/.config
 
Old 09-04-2019, 10:54 AM   #30
arvid001
LQ Newbie
 
Registered: Apr 2018
Posts: 22

Original Poster
Rep: Reputation: Disabled
Sorry about the delay.
After several days of peeking poking into why the latest kernal (4.19.0-5 AMD-64)and Debian-10 (Buster) breaks Debian-10, I have come to the conclusion that this latest kernal for Debian is just not compatible with much of the newer and faster hardware available from popular vendors. For this reason I decided to modify Grub-2 so that it boots to the prior kernal (4.9.0-9 AMD-64) and simply ignore the defective kernal release. Maybe later when a new kernal is released for Debian I can retry it to see if the problem has been fixed. Admittedly this solution is just kicking-the-can-down-the-road but it seems to be the best solution for right now.

Thanks for all the help and suggestions.
 
  


Reply

Tags
buster, debian, networking


Thread Tools Search this Thread
Search this Thread:

Advanced Search

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off



Similar Threads
Thread Thread Starter Forum Replies Last Post
Copying OS files without exiting the presently-running OS? Possible? RonCam Bodhi 1 03-10-2019 01:16 PM
LXer: Debian 11 "Bullseye" and Debian 12 "Bookworm" Are Coming After Debian 10 "Buster" LXer Syndicated Linux News 0 04-18-2018 12:26 PM
[SOLVED] Upgraded Stretch->Buster, lost network. How to set up simple DHCP connection? pepperslq Debian 7 02-26-2018 02:38 AM
my introduction, have presently no questions wstrickler Linux - Newbie 1 04-15-2014 06:55 PM

LinuxQuestions.org > Forums > Linux Forums > Linux - Distributions > Debian

All times are GMT -5. The time now is 01:20 PM.

Main Menu
Advertisement
My LQ
Write for LQ
LinuxQuestions.org is looking for people interested in writing Editorials, Articles, Reviews, and more. If you'd like to contribute content, let us know.
Main Menu
Syndicate
RSS1  Latest Threads
RSS1  LQ News
Twitter: @linuxquestions
Open Source Consulting | Domain Registration