topic title: antiX-17-b2-full available for public testing
Posts: 1,308
BitJam
Joined: 31 Aug 2009
#16
psalmson, please start a new thread with your problem. This thread is not for support; it is for debugging problems in antiX-17-beta-2.
Posts: 1,308
BitJam
Joined: 31 Aug 2009
#17
I tracked the long delay in starting the network to the 64-bit kernel. There is no delay with the 32-bit kernel. I did a diff of the configs and my guess is the problem is in the 64-bit config:

Code: Select all

CONFIG_IPV6=y
In the 32-bit config it is a module. IIRC, you can get a similar long delay if you add a line like this to /etc/networking/interfaces:

Code: Select all

   iface eth0 inet6 dhcp
so the timescale does indicate the problem might be related to ipv6.

I have not tested on ipv6. Has anyone? Does it suffice to default to ipv4 on the live system?
Posts: 452
Jerry
Joined: 12 Sep 2007
#18
I'm in, and it's terrific! Installed on my testing machine, switched to Space-Fluxbox (style: antiXblue-Medium, which goes better with wallpaper IMO), eliminated conky. All working well so far--will dive down later this weekend:

Code: Select all

$ inxi -F
System:    Host: aao722 Kernel: 4.10.5-antix.1-amd64-smp x86_64 (64 bit)
           Desktop: Fluxbox 1.3.5 Distro: antiX-17.b2_x64-full keerfa 28 July 2017
Machine:   Device: laptop System: Acer product: AO722 v: V1.08
           Mobo: Acer model: JE10-BZ BIOS: Acer v: V1.08 date: 12/06/2011
Battery    BAT1: charge: 36.5 Wh 89.0% condition: 41.0/44.0 Wh (93%)
CPU:       Dual core AMD C-60 APU with Radeon HD Graphics (-MCP-) cache: 1024 KB 
           clock speeds: max: 1000 MHz 1: 1000 MHz 2: 1000 MHz
Graphics:  Card: Advanced Micro Devices [AMD/ATI] Wrestler [Radeon HD 6290]
           Display Server: X.Org 1.19.2 drivers: ati,radeon (unloaded: modesetting,fbdev,vesa)
           Resolution: 1366x768@60.02hz
           GLX Renderer: Gallium 0.4 on AMD PALM (DRM 2.49.0 / 4.10.5-antix.1-amd64-smp, LLVM 3.9.1)
           GLX Version: 3.3 Mesa 13.0.6
Audio:     Card-1 Advanced Micro Devices [AMD/ATI] Wrestler HDMI Audio
           driver: snd_hda_intel
           Card-2 Advanced Micro Devices [AMD/ATI] SBx00 Azalia (Intel HDA)
           driver: snd_hda_intel
           Sound: Advanced Linux Sound Architecture v: k4.10.5-antix.1-amd64-smp
Network:   Card-1: Qualcomm Atheros AR8152 v2.0 Fast Ethernet driver: atl1c
           IF: eth0 state: down mac: b8:88:e3:02:80:53
           Card-2: Qualcomm Atheros AR9485 Wireless Network Adapter driver: ath9k
           IF: wlan0 state: up mac: 44:6d:57:28:e0:a3
Drives:    HDD Total Size: 320.1GB (0.9% used)
           ID-1: /dev/sda model: WDC_WD3200BPVT size: 320.1GB
Partition: ID-1: / size: 72G used: 2.8G (5%) fs: ext4 dev: /dev/sda2
Sensors:   System Temperatures: cpu: 64.0C mobo: N/A gpu: 64.0
           Fan Speeds (in rpm): cpu: N/A
Info:      Processes: 132 Uptime: 14 min Memory: 442.9/3683.0MB
           Client: Shell (bash) inxi: 2.3.21
Nice going, people.
Posts: 2,238
dolphin_oracle
Joined: 16 Dec 2007
#19
BitJam wrote:I tracked the long delay in starting the network to the 64-bit kernel. There is no delay with the 32-bit kernel. I did a diff of the configs and my guess is the problem is in the 64-bit config:

Code: Select all

CONFIG_IPV6=y
In the 32-bit config it is a module. IIRC, you can get a similar long delay if you add a line like this to /etc/networking/interfaces:

Code: Select all

   iface eth0 inet6 dhcp
so the timescale does indicate the problem might be related to ipv6.

I have not tested on ipv6. Has anyone? Does it suffice to default to ipv4 on the live system?

More problems with the 64 bit kernel: After BitJam's report above, I created a 64bit liveUSB out of beta 2. the touchpad on the lenovo s21e does not work. works with the 32 bit kernel and the debian-stretch default 4.9 kernels, as well as the default 64 bit kernel on antiX 16.2

Given BitJam's findings on the internet issues, and my touchpad, the evidence is pointing to the 64 bit kernel having some problems.
Posts: 1,308
BitJam
Joined: 31 Aug 2009
#20
dolphin_oracle wrote:More problems with the 64 bit kernel: After BitJam's report above, I created a 64bit liveUSB out of beta 2. the touchpad on the lenovo s21e does not work. works with the 32 bit kernel and the debian-stretch default 4.9 kernels, as well as the default 64 bit kernel on antiX 16.2
I diffed the kernel config files and noticed that the 64-bit kernel was lacking a lot of hardware support.
Posts: 452
Jerry
Joined: 12 Sep 2007
#21
In using this command:

Code: Select all

apt update && apt upgrade -y
...there is a roughly 20-sec lag between the execution of the two commands, tried multiple times and multiple times of day. Not the machine since it works normally on the MX-16 partition; using default repo setup. Anybody else seeing this?

BTW: I have that as a very handy alias:

Code: Select all

alias up="su -c 'apt update && apt upgrade'"
Posts: 1,308
BitJam
Joined: 31 Aug 2009
#22
Jerry, this article:
========= SCRAPER REMOVED AN EMBEDDED LINK HERE ===========
url was:"http://www.techrepublic.com/article/how-to-fix-the-slow-apt-get-update-issue-on-linux-machines/"
linktext was:"How to fix the slow apt-get update issue on Linux machines"
====================================
says:
It took quite some time to figure this one out, but the problem lies in IPv6. With IPv6 enabled, the recent network stack seems to stumble at times, especially when attempting to update with apt.
If you experience the delay on 64-bit but not 32-bit then that would be another clue pointing to ipv6. The article suggests a fix by creating/editing the file /etc/sysctl.conf so it contains:

Code: Select all

net.ipv6.conf.all.disable_ipv6 = 1
​net.ipv6.conf.default.disable_ipv6 = 1
​net.ipv6.conf.lo.disable_ipv6 = 1
I will try that fix here to see if it cures my long network delays on the 64-bit system which I suspect are also related to ipv6.

Also, you could try this command"apt update && echo got here && apt upgrade -y" to see if the delay is at the end of the update or at the start of the upgrade.
Posts: 88
kmathern
Joined: 25 Aug 2012
#23
The method mentioned here:
========= SCRAPER REMOVED AN EMBEDDED LINK HERE ===========
url was:"http://bruteforcelab.com/make-apt-get-use-ipv4-instead-ipv6.html#comment-9403"
linktext was:"http://bruteforcelab.com/make-apt-get-u ... mment-9403"
====================================
might work too.

The correct way to do it is:

Create a file in /etc/apt/apt.conf.d/99force-ipv4 or something with content:

Acquire::ForceIPv4 “true”;
Posts: 452
Jerry
Joined: 12 Sep 2007

06 Aug 2017, 23:12 #24

BitJam wrote:Jerry, this article:
========= SCRAPER REMOVED AN EMBEDDED LINK HERE ===========
url was:"http://www.techrepublic.com/article/how-to-fix-the-slow-apt-get-update-issue-on-linux-machines/"
linktext was:"How to fix the slow apt-get update issue on Linux machines"
====================================
says:
It took quite some time to figure this one out, but the problem lies in IPv6. With IPv6 enabled, the recent network stack seems to stumble at times, especially when attempting to update with apt.
If you experience the delay on 64-bit but not 32-bit then that would be another clue pointing to ipv6. The article suggests a fix by creating/editing the file /etc/sysctl.conf so it contains:

Code: Select all

net.ipv6.conf.all.disable_ipv6 = 1
​net.ipv6.conf.default.disable_ipv6 = 1
​net.ipv6.conf.lo.disable_ipv6 = 1
I will try that fix here to see if it cures my long network delays on the 64-bit system which I suspect are also related to ipv6.

Also, you could try this command"apt update && echo got here && apt upgrade -y" to see if the delay is at the end of the update or at the start of the upgrade.
Before:

Code: Select all

$ sudo apt update && echo got here && sudo apt upgrade -y
[sudo] password for jb: 
Hit:1 http://ftp.us.debian.org/debian stretch-updates InRelease
Hit:2 http://security.debian.org stretch/updates InRelease
Ign:3 http://ftp.us.debian.org/debian stretch InRelease                  
Hit:4 http://ftp.us.debian.org/debian stretch Release                    
Get:5 http://antix.daveserver.info/stretch stretch InRelease [20.7 kB]
Get:7 http://antix.daveserver.info/stretch stretch/main amd64 Packages [112 kB]
Fetched 133 kB in 2s (45.5 kB/s)   
Reading package lists... Done
Building dependency tree       
Reading state information... Done
All packages are up to date.
got here
Reading package lists... Done
Building dependency tree       
Reading state information... Done
Calculating upgrade... Done
0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
Added the 3 lines, rebooted, no change.

Also tried Kent's solution, still 20 secs.

Finally, ran reload in Synaptic: black box for ~20 secs.
Posts: 1,308
BitJam
Joined: 31 Aug 2009
#25
Jerry wrote:

Code: Select all

...
All packages are up to date.
got here
Reading package lists... Done
...
Sorry I was unclear. The idea of adding the echo was to see if the delay happened before or after"got here" was printed to the screen.
Posts: 2,238
dolphin_oracle
Joined: 16 Dec 2007
#26
I just tried live-kernel-updater after adding a kernel and doing a remaster. The routine fails with an"unable to mount" error after choosing the running live device.
Posts: 1,308
BitJam
Joined: 31 Aug 2009
#27
dolphin_oracle wrote:I just tried live-kernel-updater after adding a kernel and doing a remaster. The routine fails with an"unable to mount" error after choosing the running live device.
I just ran into that today as well. Change line 319 to:

Code: Select all

        IS_ENCRYPTED=$INITRD_ENCRYPTED
(add a dollar sign to the right of the equal sign).
Posts: 452
Jerry
Joined: 12 Sep 2007
#28
BitJam wrote:
Jerry wrote:

Code: Select all

...
All packages are up to date.
got here
Reading package lists... Done
...
Sorry I was unclear. The idea of adding the echo was to see if the delay happened before or after"got here" was printed to the screen.
Before.
Posts: 1,308
BitJam
Joined: 31 Aug 2009
#29
Jerry wrote:
BitJam wrote:Sorry I was unclear. The idea of adding the echo was to see if the delay happened before or after"got here" was printed to the screen.
Before.
Oh, that's interesting! That would explain why networking changes don't fix it. I use"apt-get update" and I don't see a delay. Do you get a delay when you run"apt-get update && echo got here"? I'm wondering if it is a problem with the"apt" command or if it is related to your system.

On 2nd thought, if it is only a 20 second delay then maybe I have just been thinking it was normal and ignoring it. I will let you know.

edit: I do *not* get a 20 second delay at the end of"apt-get update".
Posts 1,308
BitJam
Joined: 31 Aug 2009
#30
I've had no luck getting my wireless network to come up right away with the latest 64-bit kernels. Disabling ipv6 via /etc/sysconf.conf did not help. The latest 4.12 kernel did not help. Using the 32-bit kernel works and downgrading the kernel to 4.4.10-antix-sid.1-amd64-smp also worked. I can still test on other hardware and also see if the wired network comes up right away.

When I install a new kernel, three modules fail to recompile: broadcom, ndiswrapper, and virtualbox-guest. The compiler is unhappy with some of the code.