antiX-17-b3-full, base and core-libre versions available for public testing
- 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
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
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.
lenovo ThinkPad X1 Extreme Gen 4 - MX-23
FYI: mx "test" repo is not the same thing as debian testing repo.
- 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
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:
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
Home-built desktop - Core i5 9400, 970 EVO Plus, 8GB
DELL XPS 15
Lots of test machines
- 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
btw - love the pier
LT: MX19.1 Quad Core model: Intel Core i7-6820HQ Kernel: 5.0.0-7.1-liquorix-amd64 x86_64
- 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
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.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
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
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
- 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
Launching the shipped browser gives the standard Mozilla crash message. This is the terminal output:anticapitalista wrote: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.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
https://support.mozilla.org/en-US/kb/yo ... -supported
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...
MX Facebook Group Administrator.
Home-built desktop - Core i5 9400, 970 EVO Plus, 8GB
DELL XPS 15
Lots of test machines
Home-built desktop - Core i5 9400, 970 EVO Plus, 8GB
DELL XPS 15
Lots of test machines
- 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
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: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
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
}
Code: Select all
if ! ifquery --allow=hotplug -l | grep -q "^${INTERFACE}\$"; then
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.
lenovo ThinkPad X1 Extreme Gen 4 - MX-23
FYI: mx "test" repo is not the same thing as debian testing repo.
Re: antiX-17-b3-full, base and core-libre versions available for public testing
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".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.
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
-- Richard Feynman
- 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
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.BitJam wrote: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".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.
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.
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.
lenovo ThinkPad X1 Extreme Gen 4 - MX-23
FYI: mx "test" repo is not the same thing as debian testing repo.
Re: antiX-17-b3-full, base and core-libre versions available for public testing
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:
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: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:(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:
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.
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
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
Code: Select all
a = auto
h = allow-hotplug
w = wlan
e = eth
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 first principle is that you must not fool yourself -- and you are the easiest person to fool."
-- Richard Feynman
-- Richard Feynman
Re: antiX-17-b3-full, base and core-libre versions available for public testing
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.
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
-- Richard Feynman