antiX-16-b2.1-full available - Page 4

SamK · posted: 2016-04-29 18:30

anticapitalista wrote:We can fix conky, but you auto connect now, yes?

I have been thinking about the test because I'm not sure the results are valid.

At the time of your post asking for the test to be run, the system was already booted using the nosavestate boot parameter to prevent the existing stored values being used. When you mentioned that I need not explicitly save the values, and before I shut down the system, I went in search of what was already saved and found it in /live/boot-dev/antiX/state/general/files/ etc/network/interfaces.

The saved value was identical to the one you requested. It had previously been saved automatically. Presumablby that happened when I had manually set up eth1 via ceni some hours earlier and then rebooted. In every reboot thereafter eth1 never automatically connected despite the saved setting.

Because the value you wanted was already saved, I did not create it as requested. I just rebooted the system without the nosavestate parameter. It did not automatically connect. This was in line with all previous experiences.

The system was rebooted again, this time using the savestate parameter. It did automatically connect. Those are the results I reported. My doubt is about how this will work when a USB stick has been created and booted for the very first time. If the boot parameter savestate, is required to use the setting, it will not exist at that time.

How do the nosavestate/savestate parameters work?
e.g. if the nosave parameter is given is the use of saved settings prevented for that single boot-up, or for every boot-up until the save parameter is given?

Is this stuff documented somewhere?

Tomorrow I will create a fresh USB antiX and test that.

dolphin_oracle · posted: 2016-04-29 18:34

SamK wrote:
anticapitalista wrote:We can fix conky, but you auto connect now, yes?
I have been thinking about the test because I'm not sure the results are valid.

At the time of your post asking for the test to be run, the system was already booted using the nosavestate boot parameter to prevent the existing stored values being used. When you mentioned that I need not explicitly save the values, and before I shut down the system, I went in search of what was already saved and found it in /live/boot-dev/antiX/state/general/files/ etc/network/interfaces.

The saved value was identical to the one you requested. It had previously been saved automatically. Presumablby that happened when I had manually set up eth1 via ceni some hours earlier and then rebooted. In every reboot thereafter eth1 never automatically connected despite the saved setting.

Because the value you wanted was already saved, I did not create it as requested. I just rebooted the system without the nosavestate parameter. It did not automatically connect. This was in line with all previous experiences.

The system was rebooted again, this time using the savestate parameter. It did automatically connect. Those are the results I reported. My doubt is about how this will work when a USB stick has been created and booted for the very first time. If the boot parameter savestate, is required to use the setting, it will not exist at that time.

How do the nosavestate/savestate parameters work?
e.g. if the nosave parameter is given is the use of saved settings prevented for that single boot-up, or for every boot-up until the save parameter is given?

Is this stuff documented somewhere?

Tomorrow I will create a fresh USB antiX and test that.

you can just delete the save state folders to save you making a fresh stick.

I think this will work. all we are doing is putting the additional info for your eth1 in the interfaces file, now matter how it gets there. ceni doesn't do anything magically, its just an editor for the interfaces file at the end of the day.

the real question is does the additional information conflict anything. possibly, but i doubt it since you are able to configure your network manually in ceni already. I've had no problems so far booting with additional (non functional) entires in my etc/network/interfaces.

Jerry · posted: 2016-04-29 18:37

Is this stuff documented somewhere?

They're not (yet) in the BitJam's list:
========= SCRAPER REMOVED AN EMBEDDED LINK HERE ===========
url was:"http://mepiscommunity.org/wiki/system/boot-parameters"
linktext was:"http://mepiscommunity.org/wiki/system/boot-parameters"
====================================

dolphin_oracle · posted: 2016-04-29 18:40

SamK wrote:
anticapitalista wrote:We can fix conky, but you auto connect now, yes?
I have been thinking about the test because I'm not sure the results are valid.

At the time of your post asking for the test to be run, the system was already booted using the nosavestate boot parameter to prevent the existing stored values being used. When you mentioned that I need not explicitly save the values, and before I shut down the system, I went in search of what was already saved and found it in /live/boot-dev/antiX/state/general/files/ etc/network/interfaces.

The saved value was identical to the one you requested. It had previously been saved automatically. Presumablby that happened when I had manually set up eth1 via ceni some hours earlier and then rebooted. In every reboot thereafter eth1 never automatically connected despite the saved setting.

Because the value you wanted was already saved, I did not create it as requested. I just rebooted the system without the nosavestate parameter. It did not automatically connect. This was in line with all previous experiences.

The system was rebooted again, this time using the savestate parameter. It did automatically connect. Those are the results I reported. My doubt is about how this will work when a USB stick has been created and booted for the very first time. If the boot parameter savestate, is required to use the setting, it will not exist at that time.

How do the nosavestate/savestate parameters work?
e.g. if the nosave parameter is given is the use of saved settings prevented for that single boot-up, or for every boot-up until the save parameter is given?

Is this stuff documented somewhere?

Tomorrow I will create a fresh USB antiX and test that.

the boot code cheats are documented in the antiX-faq.
========= SCRAPER REMOVED AN EMBEDDED LINK HERE ===========
url was:"http://download.tuxfamily.org/antix/docs-antiX-15/FAQ/boot-params.html#_new_for_antix_15"
linktext was:"http://download.tuxfamily.org/antix/doc ... r_antix_15"
====================================

kmathern · posted: 2016-04-29 18:45

dolphin_oracle wrote: sam,

I think what you are seeing is some leftover code. there is now a script in play that tries to figure out which broadcom driver to use for a given part. The script was originally written for MX, which does use network-manager.

On a liveUSB with persistence, please try the following.

Open /usr/local/bin/BroadcomStartup as root and comment out all entries for

service network-manager stop
service network-manager start

there are 3 of each.

Then delete

etc/bcm-ckd

and reboot. I think you'll see those error message go away. If so, this will be an easy tweak for the guys to make.

Would changing the network-manager stop/start lines to something like this help ?

[ -x /etc/init.d/network-manager ] && service network-manager stop

[ -x /etc/init.d/network-manager ] && service network-manager start

It would only do the stop/start if network-manager is installed.

Jerry · posted: 2016-04-29 18:51

@D_O: thanks, I'll just paste those in.

dolphin_oracle · posted: 2016-04-29 18:53

kmathern wrote:
dolphin_oracle wrote: sam,

I think what you are seeing is some leftover code. there is now a script in play that tries to figure out which broadcom driver to use for a given part. The script was originally written for MX, which does use network-manager.

On a liveUSB with persistence, please try the following.

Open /usr/local/bin/BroadcomStartup as root and comment out all entries for

service network-manager stop
service network-manager start

there are 3 of each.

Then delete

etc/bcm-ckd

and reboot. I think you'll see those error message go away. If so, this will be an easy tweak for the guys to make.
Would changing the network-manager stop/start lines to something like this help ?

[ -x /etc/init.d/network-manager ] && service network-manager stop

[ -x /etc/init.d/network-manager ] && service network-manager start
It would only do the stop/start if network-manager is installed.

yeah, and check statement on network-manager would work fine to eliminate that message.

SamK · posted: 2016-04-30 06:26

Jerry wrote:They're not (yet) in the BitJam's list:
========= SCRAPER REMOVED AN EMBEDDED LINK HERE ===========
url was:"http://mepiscommunity.org/wiki/system/boot-parameters"
linktext was:"http://mepiscommunity.org/wiki/system/boot-parameters"
====================================

dolphin_oracle wrote:the boot code cheats are documented in the antiX-faq.
========= SCRAPER REMOVED AN EMBEDDED LINK HERE ===========
url was:"http://download.tuxfamily.org/antix/doc"
linktext was:"http://download.tuxfamily.org/antix/doc"
====================================
... r_antix_15

Thanks for those.

Suggestions

If these are intended to be common it will be better if the documents are consistent with each other
Present all parameters in a single block/table within the document, together with a reference for each individual parameter in the block/table, to which distro version introduced it. This simplification will make it more readily apparent what is available and whether it is applicable to the particular case the user is researching. This will enhance any other sections in the document that provide more detailed information.

SamK · posted: 2016-04-30 07:56

kmathern wrote:Would changing the network-manager stop/start lines to something like this help ?
Code: Select all
[ -x / etc/init.d/network-manager ] && service network-manager stop

[ -x / etc/init.d/network-manager ] && service network-manager start

dolphin_oracle wrote:yeah, and check statement on network-manager would work fine to eliminate that message.

Confirmed that does resolve the problem.

Edited
/usr/local/bin/BroadcomStartup

Replaced 3 instances of
service network-manager stop
with
[ -x / etc/init.d/network-manager ] && service network-manager stop

Replaced 3 instances of
service network-manager start
with
[ -x / etc/init.d/network-manager ] && service network-manager start

Saved using root persistence

Edit
remove irrelevances

anticapitalista · posted: 2016-04-30 09:51

For changes to be saved in root persistence, it has to be running at boot. Since you first created the rootfs nothing will be saved.

SamK · posted: 2016-04-30 10:22

anticapitalista wrote:For changes to be saved in root persistence, it has to be running at boot. Since you first created the rootfs nothing will be saved.

OK, that clears it up. My misunderstanding. For clarity I'll remove those parts from the post.

Jerry · posted: 2016-04-30 10:34

Suggestions
1) If these are intended to be common it will be better if the documents are consistent with each other
2) Present all parameters in a single block/table within the document, together with a reference for each individual parameter in the block/table, to which distro version introduced it. This simplification will make it more readily apparent what is available and whether it is applicable to the particular case the user is researching. This will enhance any other sections in the document that provide more detailed information.

Good thoughts, thanks.

I added the antiX-15 new items for a short-term solution, but the ideal would be to avoid the duplication altogether. Not sure that's going to happen...

SamK · posted: 2016-04-30 12:41

dolphin_oracle wrote:you can just delete the save state folders to save you making a fresh stick.
[...]
I've had no problems so far booting with additional (non functional) entires in my etc/network/interfaces.

Thanks for the idea about the state files. For maximum certainty I decided to go with a fresh antiX live USB set up.

BOOT #1

Prior to any configuration

Code: Select all

cat /proc/cmdline
desktop=space-icewm vga=791 lang=en_GB quiet splash=off disable=lx
ls /live/boot-dev/antiX/state/general-state-files
/live/boot-dev/antiX/state/general-state-files
cat / etc/network/interfaces
# interfaces(5) file used by ifup(8) and ifdown(8)

allow-hotplug eth0
iface eth0 inet dhcp
inxi -n -c0
Network:   Card-1: Broadcom BCM4401-B0 100Base-TX driver: b44
           IF: eth1 state: down mac:*
           Card-2: Intel PRO/Wireless 2200BG [Calexico2] Network Connection driver: ipw2200
           IF: eth0 state: unknown mac: *
ifconfig | grep encap -A 1
eth0      Link encap:Ethernet  HWaddr * 
          inet6 addr: fe80::213:ceff:feb9:90bb/64 Scope:Link

lo        Link encap:Local Loopback  
          inet addr:127.0.0.1  Mask:255.0.0.0

eth1 wired network no connection

eth1 configure via ceni
completed successfully

After configuration

Code: Select all

cat / etc/network/interfaces
# interfaces(5) file used by ifup(8) and ifdown(8)

allow-hotplug eth0
iface eth0 inet dhcp

allow-hotplug eth1
iface eth1 inet dhcp
inxi -n -c0
Network:   Card-1: Broadcom BCM4401-B0 100Base-TX driver: b44
           IF: eth1 state: up speed: 100 Mbps duplex: full mac: *
           Card-2: Intel PRO/Wireless 2200BG [Calexico2] Network Connection driver: ipw2200
           IF: eth0 state: unknown mac: *
ifconfig | grep encap -A 1
eth0      Link encap:Ethernet  HWaddr *  
          inet6 addr: fe80::213:ceff:feb9:90bb/64 Scope:Link
--
eth1      Link encap:Ethernet  HWaddr *  
          inet addr:192.168.2.106  Bcast:192.168.2.255  Mask:255.255.255.0
--
lo        Link encap:Local Loopback  
          inet addr:127.0.0.1  Mask:255.0.0.0

eth1 wired network working connection
Reboot

BOOT #2

Code: Select all

cat /proc/cmdline
desktop=space-icewm vga=791 lang=en_GB quiet splash=off disable=lx
cat /live/boot-dev/antiX/state/general/files/ etc/network/interfaces
# interfaces(5) file used by ifup(8) and ifdown(8)

allow-hotplug eth0
iface eth0 inet dhcp

allow-hotplug eth1
iface eth1 inet dhcp
cat / etc/network/interfaces
# interfaces(5) file used by ifup(8) and ifdown(8)

allow-hotplug eth0
iface eth0 inet dhcp

allow-hotplug eth1
iface eth1 inet dhcp
inxi -n -c0
Network:   Card-1: Broadcom BCM4401-B0 100Base-TX driver: b44
           IF: eth1 state: up speed: 100 Mbps duplex: full mac: *
           Card-2: Intel PRO/Wireless 2200BG [Calexico2] Network Connection driver: ipw2200
           IF: eth0 state: unknown mac: *
ifconfig | grep encap -A 1
eth0      Link encap:Ethernet  HWaddr *  
          inet6 addr: fe80::213:ceff:feb9:90bb/64 Scope:Link
--
eth1      Link encap:Ethernet  HWaddr *  
          inet addr:192.168.2.106  Bcast:192.168.2.255  Mask:255.255.255.0
--
lo        Link encap:Local Loopback  
          inet addr:127.0.0.1  Mask:255.0.0.0

eth1 wired network working connection automatically established

It looks like the idea to ship with multiple entries in / etc/network/interfaces should work.

Edited
for privacy

anticapitalista · posted: 2016-04-30 12:47

SamK - for conky, is it simply enough to add an eth1 entry that is basically a copy of the eth0 one to .conkyrc?

SamK · posted: 2016-04-30 13:04

anticapitalista wrote:SamK - for conky, is it simply enough to add an eth1 entry that is basically a copy of the eth0 one to .conkyrc?

Yes that's basically it. The following is what I tested, placed between the eth0 and wlan0 sections in ~/.conkyrc.

Code: Select all

${if_up eth1}${color}eth1 up: $alignr${color3} ${upspeed eth1}
${color}$alignr${upspeedgraph   eth1 30,170 5599cc 5599cc}
${color}eth1 down: $alignr${color3} ${downspeed eth1}
${color2}$alignr${downspeedgraph eth1 30,170  5599cc 5599cc}${endif}