antiX-17-b3-full, base and core-libre versions available for public testing

Message
Author
User avatar
dolphin_oracle
Developer
Posts: 19923
Joined: Sun Dec 16, 2007 1:17 pm

Re: antiX-17-b3-full, base and core-libre versions available for public testing

#31 Post by dolphin_oracle »

here are a couple of syslog excerpts. I use "auto" in one and "allow-hotplug" in the other. In both versions the interfaces seem to come "up". However, dhcp does not complete on the allow-hotplug version, so I get the interesting situation of the conky network monitors coming up, but dns fails. to make matters worse, when eth0 is set to "auto", it hangs trying to get a ip address. Its like the system can't tell there isn't a cable plugged in.

this is with my thinkpad T530. I forgot to get the inxi -F info before I left this morning, but its all intel parts. e1000 ethernet driver and iwlwifi for the wlan0. Similar happens on the s21e, except it doesn't have an ethernet port so eth0 shows up as a non-functional "logical" interface in ceni.

*edit* this is on a 64 bit install
Last edited by dolphin_oracle on Mon Aug 28, 2017 11:52 am, edited 1 time in total.
http://www.youtube.com/runwiththedolphin
lenovo ThinkPad X1 Extreme Gen 4 - MX-23
FYI: mx "test" repo is not the same thing as debian testing repo.

User avatar
chrispop99
Global Moderator
Posts: 3171
Joined: Tue Jan 27, 2009 3:07 pm

Re: antiX-17-b3-full, base and core-libre versions available for public testing

#32 Post by chrispop99 »

Most web browsers will not now work on CPU's that don't support the SSE2 flag. This affects all P3 and Athlon 32-bit processors.

The native browser, and all the ones included in the Package Installer, with the exception of QupZilla, fail to launch or launch with a 'game over' error message. QupZilla will launch, and load a page but as soon as anything else is attempted it crashes. (This is with a P3 laptop.)

Should the minimum specification for antiX be raised? Or should there be information in the release notes about the limitations for web-browsing with this older hardware? Or something else?

Chris

Additional information from terminal when trying QupZilla:

Code: Select all

chris@antix1:~
$ qupzilla
using qt5ct plugin
AdBlockSubscription:: loadSubscription invalid format of adblock file "/home/chris/.config/qupzilla/profiles/default/adblock/customlist.txt"
QupZilla: 0 extensions loaded
custom style sheet is disabled
inotify_add_watch("/home/chris/.config/qt5ct/") failed: "No such file or directory"
D-Bus system tray: no
Illegal instruction
MX Facebook Group Administrator.
Home-built desktop - Core i5 9400, 970 EVO Plus, 8GB
DELL XPS 15
Lots of test machines

User avatar
mmikeinsantarosa
Developer
Posts: 2192
Joined: Thu May 01, 2014 10:12 am

Re: antiX-17-b3-full, base and core-libre versions available for public testing

#33 Post by mmikeinsantarosa »

btw - love the pier :happy:
LT: MX19.1 Quad Core model: Intel Core i7-6820HQ Kernel: 5.0.0-7.1-liquorix-amd64 x86_64

User avatar
anticapitalista
Developer
Posts: 4160
Joined: Sat Jul 15, 2006 10:40 am

Re: antiX-17-b3-full, base and core-libre versions available for public testing

#34 Post by anticapitalista »

chrispop99 wrote:Most web browsers will not now work on CPU's that don't support the SSE2 flag. This affects all P3 and Athlon 32-bit processors.

The native browser, and all the ones included in the Package Installer, with the exception of QupZilla, fail to launch or launch with a 'game over' error message. QupZilla will launch, and load a page but as soon as anything else is attempted it crashes. (This is with a P3 laptop.)

Should the minimum specification for antiX be raised? Or should there be information in the release notes about the limitations for web-browsing with this older hardware? Or something else?

Chris
antiX-17 ships with firefox-esr version 52.3 which is still supposed to work on PIII. According to this post, firefox 53 and later don't support PIII.

https://support.mozilla.org/en-US/kb/yo ... -supported
anticapitalista
Reg. linux user #395339.

Philosophers have interpreted the world in many ways; the point is to change it.

antiX with runit - lean and mean.
https://antixlinux.com

User avatar
chrispop99
Global Moderator
Posts: 3171
Joined: Tue Jan 27, 2009 3:07 pm

Re: antiX-17-b3-full, base and core-libre versions available for public testing

#35 Post by chrispop99 »

anticapitalista wrote:
chrispop99 wrote:Most web browsers will not now work on CPU's that don't support the SSE2 flag. This affects all P3 and Athlon 32-bit processors.

The native browser, and all the ones included in the Package Installer, with the exception of QupZilla, fail to launch or launch with a 'game over' error message. QupZilla will launch, and load a page but as soon as anything else is attempted it crashes. (This is with a P3 laptop.)

Should the minimum specification for antiX be raised? Or should there be information in the release notes about the limitations for web-browsing with this older hardware? Or something else?

Chris
antiX-17 ships with firefox-esr version 52.3 which is still supposed to work on PIII. According to this post, firefox 53 and later don't support PIII.

https://support.mozilla.org/en-US/kb/yo ... -supported
Launching the shipped browser gives the standard Mozilla crash message. This is the terminal output:

Code: Select all

chris@antix1:~
$ firefox-esr
ExceptionHandler::GenerateDump cloned child 16385
ExceptionHandler::SendContinueSignalToChild sent continue signal to child
ExceptionHandler::WaitForContinueSignal waiting for continue signal...
Chris
MX Facebook Group Administrator.
Home-built desktop - Core i5 9400, 970 EVO Plus, 8GB
DELL XPS 15
Lots of test machines

User avatar
dolphin_oracle
Developer
Posts: 19923
Joined: Sun Dec 16, 2007 1:17 pm

Re: antiX-17-b3-full, base and core-libre versions available for public testing

#36 Post by dolphin_oracle »

dolphin_oracle wrote:here are a couple of syslog excerpts. I use "auto" in one and "allow-hotplug" in the other. In both versions the interfaces seem to come "up". However, dhcp does not complete on the allow-hotplug version, so I get the interesting situation of the conky network monitors coming up, but dns fails. to make matters worse, when eth0 is set to "auto", it hangs trying to get a ip address. Its like the system can't tell there isn't a cable plugged in.

this is with my thinkpad T530. I forgot to get the inxi -F info before I left this morning, but its all intel parts. e1000 ethernet driver and iwlwifi for the wlan0. Similar happens on the s21e, except it doesn't have an ethernet port so eth0 shows up as a non-functional "logical" interface in ceni.

*edit* this is on a 64 bit install
I'm starting to think there there is a problem with udev generating an event. I don't have an antiX pc at work, but isn't there some kind of net.agent script in eudev . I've seen some examples online, and there is this section:

Code: Select all

net_ifup() {
    check_program /sbin/ifup

    # exit if the interface is not configured as allow-hotplug
    if ! ifquery --allow hotplug -l | grep -q "^${INTERFACE}\$"; then
        exit 0
    fi

    if [ -d /run/systemd/system ]; then
        exec systemctl --no-block start $(systemd-escape --template ifup@.service $INTERFACE)
    fi

    if ps -C ifup ho args | grep -q "$INTERFACE"; then
        debug_mesg "Already ifup-ing interface $INTERFACE"
        exit 0
    fi

    wait_for_interface lo

    exec ifup --allow=hotplug $INTERFACE
}
and I'm wondering if the ifquery statement should be

Code: Select all

if ! ifquery --allow=hotplug -l | grep -q "^${INTERFACE}\$"; then
(added an "=" between allow and hotplug, like the ifup statment at thebottom of the script.
http://www.youtube.com/runwiththedolphin
lenovo ThinkPad X1 Extreme Gen 4 - MX-23
FYI: mx "test" repo is not the same thing as debian testing repo.

User avatar
BitJam
Developer
Posts: 2283
Joined: Sat Aug 22, 2009 11:36 pm

Re: antiX-17-b3-full, base and core-libre versions available for public testing

#37 Post by BitJam »

dolphin_oracle wrote:here are a couple of syslog excerpts. I use "auto" in one and "allow-hotplug" in the other. In both versions the interfaces seem to come "up". However, dhcp does not complete on the allow-hotplug version, so I get the interesting situation of the conky network monitors coming up, but dns fails. to make matters worse, when eth0 is set to "auto", it hangs trying to get a ip address. Its like the system can't tell there isn't a cable plugged in.
Thanks d.o! This was extremely useful information. I think I was able to track down the cause of the painfully long boot delay on 32-bit here. I had switched to "auto eth0" since the consensus was that "auto" worked better than "allow-hotplug". This would also explain why I was seeing delays when most other people were not since the default in antiX-17.b3 is still "allow-hotplug eth0".

Using "allow-hotplug eth0" with "auto wlan0" (using your patched ceni) seems to work well here. I could also get rid of the delay be enabling wicd. In antiX-16 and MX-16 "disable=l" disables wicd on desktops but not laptops. In antiX-17 and other versions of antiX and MX "disable=l" disables wicd on both. It was only the -16 releases that left it enabled on laptops.

BTW: on antiX-17 you can enable wicd with "disable=lxW". In general, lowercase disables and uppercase enables. Of course, you can enable everything with no disable cheat or an empty "disable=".

How does "allow-hotplug eth0" combined with "auto wlan0" work for you?

Does enabling/disabling wicd have an effect?

I noticed that "auto" enables ipv6 on your system as well as mine so this is not due to my network configuration. IMO this is a bug since the user is supposed to be able to have control over that with the interfaces file. I still don't understand why "allow-hotplug wlan0" works great here but fails for most people. Could this be related to running wicd?

Even though we might be close to a solution, I'm planning to make a few simple boot parameter changes to make it easier to work on this stuff:
  • have "disable=S" cheat enable rsyslog regardless of lean, mean (l, m) etc
  • add "netiface=auto", "netiface=allow-hotplug" "netiface=eth=auto" etc. Something like that.
"The first principle is that you must not fool yourself -- and you are the easiest person to fool."

-- Richard Feynman

User avatar
dolphin_oracle
Developer
Posts: 19923
Joined: Sun Dec 16, 2007 1:17 pm

Re: antiX-17-b3-full, base and core-libre versions available for public testing

#38 Post by dolphin_oracle »

BitJam wrote:
dolphin_oracle wrote:here are a couple of syslog excerpts. I use "auto" in one and "allow-hotplug" in the other. In both versions the interfaces seem to come "up". However, dhcp does not complete on the allow-hotplug version, so I get the interesting situation of the conky network monitors coming up, but dns fails. to make matters worse, when eth0 is set to "auto", it hangs trying to get a ip address. Its like the system can't tell there isn't a cable plugged in.
Thanks d.o! This was extremely useful information. I think I was able to track down the cause of the painfully long boot delay on 32-bit here. I had switched to "auto eth0" since the consensus was that "auto" worked better than "allow-hotplug". This would also explain why I was seeing delays when most other people were not since the default in antiX-17.b3 is still "allow-hotplug eth0".

Using "allow-hotplug eth0" with "auto wlan0" (using your patched ceni) seems to work well here. I could also get rid of the delay be enabling wicd. In antiX-16 and MX-16 "disable=l" disables wicd on desktops but not laptops. In antiX-17 and other versions of antiX and MX "disable=l" disables wicd on both. It was only the -16 releases that left it enabled on laptops.

BTW: on antiX-17 you can enable wicd with "disable=lxW". In general, lowercase disables and uppercase enables. Of course, you can enable everything with no disable cheat or an empty "disable=".

How does "allow-hotplug eth0" combined with "auto wlan0" work for you?

Does enabling/disabling wicd have an effect?

I noticed that "auto" enables ipv6 on your system as well as mine so this is not due to my network configuration. IMO this is a bug since the user is supposed to be able to have control over that with the interfaces file. I still don't understand why "allow-hotplug wlan0" works great here but fails for most people. Could this be related to running wicd?

Even though we might be close to a solution, I'm planning to make a few simple boot parameter changes to make it easier to work on this stuff:
  • have "disable=S" cheat enable rsyslog regardless of lean, mean (l, m) etc
  • add "netiface=auto", "netiface=allow-hotplug" "netiface=eth=auto" etc. Something like that.
I'll try those configurations tonight. I *think* my netbook was setup that way before, with allow-hotplug eth0 and auto wlan0 (which I configured in ceni by choosing the auto option rather than the default allow-hotplug), but that machine doesn't have an ethernet port. I'll try with the one that does tonight.
http://www.youtube.com/runwiththedolphin
lenovo ThinkPad X1 Extreme Gen 4 - MX-23
FYI: mx "test" repo is not the same thing as debian testing repo.

User avatar
BitJam
Developer
Posts: 2283
Joined: Sat Aug 22, 2009 11:36 pm

Re: antiX-17-b3-full, base and core-libre versions available for public testing

#39 Post by BitJam »

I still get a 10 second delay during boot on 32-bit with "allow-hotplug eth0" and "auto wlan0". This is much better than the 30 second to 2 minute delay I got with "auto eth0" "auto wlan0". OTOH, using "allow-hotplug" everywhere is still much faster here.

I made a live initrd that works antiX-17.b3 both 32-bit and 64-bit. It is available from dropbox: antiX-17.b3_all. It contains my latest changes including things like:

Code: Select all

 Fix ownership and permissions of /var/cache/apt/archives/partial
I made two changes today. The first change adds a disable=L option to keep rsyslog enabled even if disable=l is used. So "disable=lxL" is the standard default boot with the addition of starting rsyslog.

The second changes adds the "netiface=" cheat. For example, to ensure eth0 uses allow-hotplug and wlan0 uses auto then use:

Code: Select all

netiface=eth0=allow-hotplug,wlan0=auto
You can also use "eth" to set all ethN interfaces and "wlanN" to set all wlan interfaces. In addition you can use these single letter abbreviations:

Code: Select all

a = auto
h = allow-hotplug
w = wlan
e = eth
(note that things like w0 or e2 do not work).

So an abbreviated version that sets all wlan interfaces to auto and all eth interfaces to allow-hotplug is:

Code: Select all

netiface=e=h,w=a
The lines that get set (even if there is no change) are echoed to the screen when live-init runs and will be in the file /var/log/live/live-init.log. Of course, you can just "cat /etc/network/interfaces" to double-check. I hope this will help make testing easier and more convenient. It should also allow me to easily use "allow-hotplug wlan0" even if we set the default to "auto wlan0". Note that on live-usb-maker live-usbs, the /etc/network/interfaces file survives reboots so the changes you make with the netiface cheat will be sticky.
"The first principle is that you must not fool yourself -- and you are the easiest person to fool."

-- Richard Feynman

User avatar
BitJam
Developer
Posts: 2283
Joined: Sat Aug 22, 2009 11:36 pm

Re: antiX-17-b3-full, base and core-libre versions available for public testing

#40 Post by BitJam »

I tested antiX-16.2 and I get exactly the same behavior as I get on antiX-17.b3. If I use "allow-hotplug" everywhere then there is no delay when the network is initialized during boot and there are no ipv6 connections. When I use "auto wlan0" then I get a 10 or 15 second delay and I see ipv6 connections in the output of ifconfig. The default in antiX-16.2 is to use "allow-hotplug" everywhere. Therefore the main/only change from antiX-16.2 to antiX-17b3 is that on some/most systems (but not on any of mine) "allow-hotplug wlan0" no longer connects automatically at boot-time.

Instead of focusing on "auto wlan0" which seems like an inferior solution since it enables ipv6, wouldn't we be better off trying to find out why "allow-hotplug wlan0" is broken for some/most people on antiX-17? This is hard for me to pursue because I get exactly the same behavior on 16.2 and 17.b3. My three test machines have different wireless chips and drivers.
"The first principle is that you must not fool yourself -- and you are the easiest person to fool."

-- Richard Feynman

Post Reply

Return to “antiX”