it looks like in samK's screen captures that removing the persistent-net-rules feature results in a condition where the interface names are not necessarily the same upon reboots. Notice his wired interface name changes between eth0 and eth1. The conky display fails when the system is at eth1 (likely because its coded to display info for eth0 and wlan0).
test2 fails because the setup has already been configured for eth0, but the interface name has changed to eth1.
His notes say he then reconfigured after test 2 . Test 3 maintained the same eth1 name, so the only thing that failed is the conky monitor.
samK, where you using the regular root persistence option or the"static" root persistence option. and please confirm all three test cases were the same machine and you did not use the liveusb on a different machine in between tests.
-
dolphin_oraclePosts: 2,238
- Joined: 16 Dec 2007
-
SamKPosts: 1,028
- Joined: 21 Aug 2011
#92
Perhaps not a clearly expressed as I intended. Re-phrasing for clarity"...networking can be successfully established via ceni, or sometimes by rebooting.". The reboot method was used not ceni.dolphin_oracle wrote:His notes say he then reconfigured after test 2 .
Regular root persistence.dolphin_oracle wrote:samK, where you using the regular root persistence option or the"static" root persistence option.
Confirmed.dolphin_oracle wrote:...please confirm all three test cases were the same machine
Confirmed.dolphin_oracle wrote:...you did not use the liveusb on a different machine in between tests.
-
dolphin_oraclePosts: 2,238
- Joined: 16 Dec 2007
#93
samK, one more question: did you shutdown and restart or do a reboot without powering down?
-
SamKPosts: 1,028
- Joined: 21 Aug 2011
#94
It is likely that test 1-->test 2 was a reboot without power-down.
Test 2-->3 no idea.
Unfortunately I cannot remember.dolphin_oracle wrote:...did you shutdown and restart or do a reboot without powering down?
It is likely that test 1-->test 2 was a reboot without power-down.
Test 2-->3 no idea.
-
dolphin_oraclePosts: 2,238
- Joined: 16 Dec 2007
#95
I cannot reproduce samK issues, but I do have a thought. note that his interfaces are eth0 and eth1 in all cases. While ok per spec, its not the usual naming convention for wireless devices that most people get (wlan0, wlan1, etc...).
so I'm thinking that whichever udev picks up as the first device, and my understanding is that this is not necessarily the same order everytime, gets the eth0 and the other gets eth1. If that is so, running with or without persistence enabled should show the same behavior on samk's hardware.
the 75-persistent-net-generator.rules attempts to compensate for this scenario by matching interface names to the mac address of the device. This is perfectly fine on installed systems, and as far as I can tell, on live systems using network-manager, which doesn't care what the interface name is, since network-manager assumes you might have all kinds of interfaces. wicd assumes you have 2, a wired and a wireless, and those need to be preconfigured. ceni writes its configuration to / etc/network/interfaces, so its design is static as well, but it CAN handle several interface names, even if it can't handle more than one wireless network id per interface like wicd can.
Here's an example of my live system, running static persistence so that the interface names are consistent (this is actually a bug, but useful for this analysis).
I changed machines. wlan0 is on a different machine than the one on which I'm currently connected. 70-persistent-net.rules in / etc/udev/rules.d currently has defintions for wlan0 and wlan1 that point to different devices by mac address. however, since I'm on the same wireless network, the connections work on subsequent reboots without problem as the interfaces are still defined.
samk's case is differnet though. he has an interface name that switches between different devices in the same machine (eth0 and eth1). since he was using the dynamic root persistence, which currently doesn't save changes to 70-persistent-net.rules, his interface names switch depening on which one udev finds first. Using static persistence in its current form on the a5 he would not see this problem, as the interface names would be mapped to mac addresses by udev. So in this case, the default udev interface nameing and mapping would be beneficial. removing the exclude in /usr/local/lib/antiX/antiX-excludes.sh would be a boon in samk's case.
admittingly, having wireless on ethX may be the exception rather than the rule these days, so this case may affect only a small number of users. but it will be frustrating for those people.
so I'm thinking that whichever udev picks up as the first device, and my understanding is that this is not necessarily the same order everytime, gets the eth0 and the other gets eth1. If that is so, running with or without persistence enabled should show the same behavior on samk's hardware.
the 75-persistent-net-generator.rules attempts to compensate for this scenario by matching interface names to the mac address of the device. This is perfectly fine on installed systems, and as far as I can tell, on live systems using network-manager, which doesn't care what the interface name is, since network-manager assumes you might have all kinds of interfaces. wicd assumes you have 2, a wired and a wireless, and those need to be preconfigured. ceni writes its configuration to / etc/network/interfaces, so its design is static as well, but it CAN handle several interface names, even if it can't handle more than one wireless network id per interface like wicd can.
Here's an example of my live system, running static persistence so that the interface names are consistent (this is actually a bug, but useful for this analysis).
Code: Select all
demo@antix1:~
$ sudo cat / etc/network/interfaces
[sudo] password for demo:
# interfaces(5) file used by ifup(8) and ifdown(8)
allow-hotplug eth0
iface eth0 inet dhcp
allow-hotplug wlan0
iface wlan0 inet dhcp
wpa-psk removed
wpa-ssid removed
allow-hotplug wlan1
iface wlan1 inet dhcp
wpa-psk removed
wpa-ssid removed
demo@antix1:~
samk's case is differnet though. he has an interface name that switches between different devices in the same machine (eth0 and eth1). since he was using the dynamic root persistence, which currently doesn't save changes to 70-persistent-net.rules, his interface names switch depening on which one udev finds first. Using static persistence in its current form on the a5 he would not see this problem, as the interface names would be mapped to mac addresses by udev. So in this case, the default udev interface nameing and mapping would be beneficial. removing the exclude in /usr/local/lib/antiX/antiX-excludes.sh would be a boon in samk's case.
admittingly, having wireless on ethX may be the exception rather than the rule these days, so this case may affect only a small number of users. but it will be frustrating for those people.
-
SamKPosts: 1,028
- Joined: 21 Aug 2011
#96
@dolphin_oracle
Thanks for doing the research and reporting. It is really helpful as I presently have little spare capacity to do it.
Thanks for doing the research and reporting. It is really helpful as I presently have little spare capacity to do it.
This particular rig is a Dell using only Dell shipped hardware, so the symptoms might be experienced by plenty of users.dolphin_oracle wrote:...this case may affect only a small number of users. but it will be frustrating for those people.
-
thrifteePosts: 604
- Joined: 27 Feb 2009
#97
I got some odd results, but identified why/when things get screwed up which way. I have a dual head Radeon 7000 card RV100/M6 and it adds permutations.
If I connect to the vga 15 pin on the right (according to knoppix 7.05 its VGA-0) I get the normal boot screen, then loading goes to 100%, then I get the black screen and cursor upper left, but everything stops there. nomodeset, vesa, safe, old 1024x768, xdrvr=radeon, nothing helps.
If I connect to the vga 15 pin on the left (i think its DVI-0), I get the graphics error. I can do the nomodeset, but if I do, the radeon driver won't load. I found that warning in the ati archwiki.
The fact that the machine is a Dell gx270 with built-in i915 graphics that doesn't work but can't be disabled completely in bios, and Radeon pci board actually doing the video makes it pretty oddball, so I'm not sure its worth worrying about, other than that other OS's like knoppix 7.05 don't have a problem regardless of which card I connect the monitor to. I'm sorry I can't be of more help.
BTW, On the boot help screen 14r4 it looks like F7 is there twice
Bitjam,BitJam wrote: Have you tried using"F5 Video Mode" -->"safe" or"F5 Video Mode" -->"vesa"? You can also try typing in"xdrvr=radeon" as a boot parameter. You may need to add"nomodeset" which is what F5 -->"safe" gives you. Use F12 to see the current boot parameters.
I suggest combining F5 -->"safe" with typing in"xdrvr=radeon".
I got some odd results, but identified why/when things get screwed up which way. I have a dual head Radeon 7000 card RV100/M6 and it adds permutations.
If I connect to the vga 15 pin on the right (according to knoppix 7.05 its VGA-0) I get the normal boot screen, then loading goes to 100%, then I get the black screen and cursor upper left, but everything stops there. nomodeset, vesa, safe, old 1024x768, xdrvr=radeon, nothing helps.
If I connect to the vga 15 pin on the left (i think its DVI-0), I get the graphics error. I can do the nomodeset, but if I do, the radeon driver won't load. I found that warning in the ati archwiki.
The fact that the machine is a Dell gx270 with built-in i915 graphics that doesn't work but can't be disabled completely in bios, and Radeon pci board actually doing the video makes it pretty oddball, so I'm not sure its worth worrying about, other than that other OS's like knoppix 7.05 don't have a problem regardless of which card I connect the monitor to. I'm sorry I can't be of more help.
BTW, On the boot help screen 14r4 it looks like F7 is there twice
-
SamKPosts: 1,028
- Joined: 21 Aug 2011
#98
antiX-14-a4-R_386-full.iso patched with a4-a5.delta
Tests conducted booting live USB with no persistence, using shipped defaults
Recording symptoms only (not investigated)
Tests show wireless networking issues.
Test 1
Boot param appended: None
Using Desktop=Default in boot screen (i.e. making no selection)
Network cable not connected to system (i.e. wireless only)
Manual network configuration=NoneResult
Wireless networking automatic set up fails
Test 2
Boot param appended: None
Using Desktop=Default in boot screen (i.e. making no selection)
Network cable not connected to system (i.e. wireless only)
Manual network configuration=Ceni
Result
Wireless networking set up via Ceni fails
Test 3
System rebooted
Boot param appended: None
Using Desktop=Default in boot screen (i.e. making no selection)
Network cable not connected to system (i.e. wireless only)
Manual network configuration=WICD
Result
Wireless networking set up via WICD successful
Summary
Wireless automatic set up fails
Wireless manually set up via Ceni fails due to"Module p80211 not found" although seems to be loaded
Wireless manually set up via WICD succeeds without manually loading any modules
Tests conducted booting live USB with no persistence, using shipped defaults
Recording symptoms only (not investigated)
Tests show wireless networking issues.
Test 1
Boot param appended: None
Using Desktop=Default in boot screen (i.e. making no selection)
Network cable not connected to system (i.e. wireless only)
Manual network configuration=None
Code: Select all
ip addr show
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default
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: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast state DOWN group default qlen 1000
link/ether 90:e6:ba:0c:b2:29 brd ff:ff:ff:ff:ff:ff
3: wlan0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group default qlen 1000
link/ether 00:25:d3:5a:a6:f6 brd ff:ff:ff:ff:ff:ff
inxi -c0 -n
Network: Card-1: Qualcomm Atheros AR8132 Fast Ethernet driver: atl1c
IF: eth0 state: down mac: 90:e6:ba:0c:b2:29
Card-2: Qualcomm Atheros AR9285 Wireless Network Adapter (PCI-Express)
driver: ath9k
IF: wlan0 state: down mac: 00:25:d3:5a:a6:f6Wireless networking automatic set up fails
Test 2
Boot param appended: None
Using Desktop=Default in boot screen (i.e. making no selection)
Network cable not connected to system (i.e. wireless only)
Manual network configuration=Ceni
Code: Select all
ip addr show
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default
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: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast state DOWN group default qlen 1000
link/ether 90:e6:ba:0c:b2:29 brd ff:ff:ff:ff:ff:ff
3: wlan0: <BROADCAST,MULTICAST> mtu 1500 qdisc mq state DOWN group default qlen 1000
link/ether 00:25:d3:5a:a6:f6 brd ff:ff:ff:ff:ff:ff
inxi -c0 -n
Network: Card-1: Qualcomm Atheros AR8132 Fast Ethernet driver: atl1c
IF: eth0 state: down mac: 90:e6:ba:0c:b2:29
Card-2: Qualcomm Atheros AR9285 Wireless Network Adapter (PCI-Express)
driver: ath9k
IF: wlan0 state: down mac: 00:25:d3:5a:a6:f6
ceni
Ceni requires root priviledges! Be careful!
Password:
Configuring interface wlan0=wlan0 (inet)
run-parts --exit-on-error --verbose / etc/network/if-pre-up.d
run-parts: executing / etc/network/if-pre-up.d/ethtool
run-parts: executing / etc/network/if-pre-up.d/linux-wlan-ng-pre-up
modprobe: FATAL: Module p80211 not found.
Failed to load p80211.ko.
run-parts: / etc/network/if-pre-up.d/linux-wlan-ng-pre-up exited with return code 1
Failed to bring up wlan0.
Press Enter key to continue ...
lsmod
Module Size Used by
af_packet 34646 2
parport_pc 30495 0
ppdev 12590 0
lp 16895 0
parport 35213 3 lp,ppdev,parport_pc
joydev 16847 0
iTCO_wdt 12727 0
iTCO_vendor_support 12585 1 iTCO_wdt
eeepc_wmi 12536 0
asus_wmi 22333 1 eeepc_wmi
arc4 12480 2
ath9k 84540 0
ath9k_common 21530 1 ath9k
ath9k_hw 384452 2 ath9k_common,ath9k
uvcvideo 69877 0
videobuf2_vmalloc 12720 1 uvcvideo
videobuf2_memops 12471 1 videobuf2_vmalloc
videobuf2_core 39091 1 uvcvideo
v4l2_common 12867 1 videobuf2_core
snd_hda_codec_realtek 53972 1
videodev 103684 3 uvcvideo,v4l2_common,videobuf2_core
snd_hda_codec_generic 53820 1 snd_hda_codec_realtek
media 17894 2 uvcvideo,videodev
snd_hda_intel 26011 1
coretemp 12708 0
psmouse 93985 0
ath 21707 3 ath9k_common,ath9k,ath9k_hw
pcspkr 12531 0
serio_raw 12737 0
snd_hda_controller 22115 1 snd_hda_intel
mac80211 321992 1 ath9k
lpc_ich 16616 0
snd_hda_codec 84872 4 snd_hda_codec_realtek,snd_hda_codec_generic,snd_hda_intel,snd_hda_controller
sg 29598 0
thermal 13247 0
cfg80211 198179 4 ath,ath9k_common,ath9k,mac80211
snd_hwdep 12906 1 snd_hda_codec
sparse_keymap 12730 1 asus_wmi
mfd_core 12537 1 lpc_ich
snd_pcm 70084 3 snd_hda_codec,snd_hda_intel,snd_hda_controller
acpi_cpufreq 12903 0
ac 12627 0
snd_timer 22010 1 snd_pcm
snd 55130 9 snd_hda_codec_realtek,snd_hwdep,snd_timer,snd_pcm,snd_hda_codec_generic,snd_hda_codec,snd_hda_intel
rfkill 18387 2 cfg80211,asus_wmi
evdev 17136 8
soundcore 12895 2 snd,snd_hda_codec
battery 13164 0
processor 23494 1 acpi_cpufreq
intel_agp 13136 0
atl1c 39978 0
rng_core 12704 0
ehci_pci 12432 0
uhci_hcd 30468 0
i915 781042 2
drm_kms_helper 63057 1 i915
drm 204183 4 i915,drm_kms_helper
intel_gtt 17584 2 i915,intel_agp
i2c_algo_bit 12640 1 i915
wmi 17147 1 asus_wmi
video 17745 2 i915,asus_wmi
button 12860 1 i915
fusbh200_hcd 39510 0
ehci_hcd 47854 1 ehci_pciWireless networking set up via Ceni fails
Test 3
System rebooted
Boot param appended: None
Using Desktop=Default in boot screen (i.e. making no selection)
Network cable not connected to system (i.e. wireless only)
Manual network configuration=WICD
Code: Select all
ip addr show
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default
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: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast state DOWN group default qlen 1000
link/ether 90:e6:ba:0c:b2:29 brd ff:ff:ff:ff:ff:ff
3: wlan0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
link/ether 00:25:d3:5a:a6:f6 brd ff:ff:ff:ff:ff:ff
inet 192.168.2.186/24 brd 192.168.2.255 scope global wlan0
valid_lft forever preferred_lft forever
inet6 fe80::225:d3ff:fe5a:a6f6/64 scope link
valid_lft forever preferred_lft forever
inxi -c0 -n
Network: Card-1: Qualcomm Atheros AR8132 Fast Ethernet driver: atl1c
IF: eth0 state: down mac: 90:e6:ba:0c:b2:29
Card-2: Qualcomm Atheros AR9285 Wireless Network Adapter (PCI-Express)
driver: ath9k
IF: wlan0 state: up mac: 00:25:d3:5a:a6:f6
lsmod
Module Size Used by
ctr 12807 1
ccm 17326 1
af_packet 34646 8
parport_pc 30495 0
ppdev 12590 0
lp 16895 0
parport 35213 3 lp,ppdev,parport_pc
uvcvideo 69877 0
iTCO_wdt 12727 0
iTCO_vendor_support 12585 1 iTCO_wdt
videobuf2_vmalloc 12720 1 uvcvideo
videobuf2_memops 12471 1 videobuf2_vmalloc
videobuf2_core 39091 1 uvcvideo
joydev 16847 0
v4l2_common 12867 1 videobuf2_core
eeepc_wmi 12536 0
videodev 103684 3 uvcvideo,v4l2_common,videobuf2_core
asus_wmi 22333 1 eeepc_wmi
media 17894 2 uvcvideo,videodev
arc4 12480 2
ath9k 84540 0
ath9k_common 21530 1 ath9k
ath9k_hw 384452 2 ath9k_common,ath9k
lpc_ich 16616 0
mfd_core 12537 1 lpc_ich
snd_hda_codec_realtek 53972 1
ath 21707 3 ath9k_common,ath9k,ath9k_hw
snd_hda_codec_generic 53820 1 snd_hda_codec_realtek
mac80211 321992 1 ath9k
snd_hda_intel 26011 1
sg 29598 0
coretemp 12708 0
pcspkr 12531 0
cfg80211 198179 4 ath,ath9k_common,ath9k,mac80211
snd_hda_controller 22115 1 snd_hda_intel
psmouse 93985 0
serio_raw 12737 0
snd_hda_codec 84872 4 snd_hda_codec_realtek,snd_hda_codec_generic,snd_hda_intel,snd_hda_controller
rng_core 12704 0
atl1c 39978 0
snd_hwdep 12906 1 snd_hda_codec
acpi_cpufreq 12903 0
snd_pcm 70084 3 snd_hda_codec,snd_hda_intel,snd_hda_controller
snd_timer 22010 1 snd_pcm
snd 55130 9 snd_hda_codec_realtek,snd_hwdep,snd_timer,snd_pcm,snd_hda_codec_generic,snd_hda_codec,snd_hda_intel
thermal 13247 0
intel_agp 13136 0
sparse_keymap 12730 1 asus_wmi
soundcore 12895 2 snd,snd_hda_codec
ac 12627 0
battery 13164 0
processor 23494 1 acpi_cpufreq
rfkill 18387 3 cfg80211,asus_wmi
evdev 17136 8
ehci_pci 12432 0
uhci_hcd 30468 0
i915 781042 2
drm_kms_helper 63057 1 i915
drm 204183 4 i915,drm_kms_helper
intel_gtt 17584 2 i915,intel_agp
i2c_algo_bit 12640 1 i915
wmi 17147 1 asus_wmi
video 17745 2 i915,asus_wmi
button 12860 1 i915
fusbh200_hcd 39510 0
ehci_hcd 47854 1 ehci_pciWireless networking set up via WICD successful
Summary
Wireless automatic set up fails
Wireless manually set up via Ceni fails due to"Module p80211 not found" although seems to be loaded
Wireless manually set up via WICD succeeds without manually loading any modules
-
dolphin_oraclePosts: 2,238
- Joined: 16 Dec 2007
#99
a couple of points to samk's notes on wireless.
1. there shouldn't be automatic connection of a wireless network, as association to a essid requires interaction. It does look like the correct driver was utilized in samk's tests.
2. connection with ceni has been shown to work previously by removal of the linux-wlan-ng package, which is the source of the offending module that interrupts ceni. the package is for older kernels and contains drivers for prism based wireless cards. research indicates that prism drivers are currently included in the mainline kernel. the prism2 firmware packages are apparently still required.
3. yep.
1. there shouldn't be automatic connection of a wireless network, as association to a essid requires interaction. It does look like the correct driver was utilized in samk's tests.
2. connection with ceni has been shown to work previously by removal of the linux-wlan-ng package, which is the source of the offending module that interrupts ceni. the package is for older kernels and contains drivers for prism based wireless cards. research indicates that prism drivers are currently included in the mainline kernel. the prism2 firmware packages are apparently still required.
3. yep.
-
SamKPosts: 1,028
- Joined: 21 Aug 2011
#100
In alpha5 what is the command to manually run the menu update process that is automatically started following an apt-get --install packagename command?
-
dolphin_oraclePosts: 2,238
- Joined: 16 Dec 2007
#101
the commands that run are shown in / etc/apt/apt.conf.d/99-update-menus .SamK wrote:In alpha5 what is the command to manually run the menu update process that is automatically started following an apt-get --install packagename command?
-
SamKPosts: 1,028
- Joined: 21 Aug 2011
#102
This a5 live no persistence.
Don't have thatdolphin_oracle wrote:the commands that run are shown in / etc/apt/apt.conf.d/99-update-menus .
Code: Select all
ls / etc/apt/apt.conf.d/
01autoremove 20apt-show-versions 70debconf 99synaptic-
dolphin_oraclePosts: 2,238
- Joined: 16 Dec 2007
#103
well, I did take that from the a4 liveCD, so maybe it was left out.
SamK wrote:Don't have thatdolphin_oracle wrote:the commands that run are shown in / etc/apt/apt.conf.d/99-update-menus .This a5 live no persistence.Code: Select all
ls / etc/apt/apt.conf.d/ 01autoremove 20apt-show-versions 70debconf 99synaptic
well, I did take that from the a4 liveCD, so maybe it was left out.
-
dolphin_oraclePosts: 2,238
- Joined: 16 Dec 2007
#104
I just found an"a5" liveusb. I ran without persistence, and 99-update-menus is present.
SamK wrote:Don't have thatdolphin_oracle wrote:the commands that run are shown in / etc/apt/apt.conf.d/99-update-menus .This a5 live no persistence.Code: Select all
ls / etc/apt/apt.conf.d/ 01autoremove 20apt-show-versions 70debconf 99synaptic
I just found an"a5" liveusb. I ran without persistence, and 99-update-menus is present.
-
SamKPosts: 1,028
- Joined: 21 Aug 2011
#105
Two power-down and reboot cycles later and 99-update-menus suddenly appeared on this rig in liveusb mode.
I can't explain the behaviour.
Thanks for doing that.dolphin_oracle wrote:I just found an"a5" liveusb. I ran without persistence, and 99-update-menus is present.
Two power-down and reboot cycles later and 99-update-menus suddenly appeared on this rig in liveusb mode.
I can't explain the behaviour.
- The md5sums check out OK
- There does not seem to be any corruption on the USB stick
- The hardware is in daily use and rock-solid with 13.2-Stable