astlinux-devel Mailing List for AstLinux (Page 2)

sk3 home # ls -ld /oldroot /oldroot/mnt /oldroot/mnt/asturw
drwxr-xr-x   16 root     root         1024 Oct 23 15:55 /oldroot
drwxr-xr-x    4 root     root         1024 Oct 23 15:55 /oldroot/mnt
drwxr-xr-x   12 root     root         4096 Sep 29 15:55 /oldroot/mnt/asturw

sk3 home # ls -ld / /home /mnt /mnt/kd /mnt/kd/*home*/foobar
drwxr-xr-x    1 root     root         4096 Oct 20 21:07 /
lrwxrwxrwx    1 root     root           12 Oct 23 15:55 /home -> 
/mnt/kd/home
drwxr-xr-x    1 root     root         4096 Oct 15 14:54 /mnt
drwxrwxrwx   18 root     root         4096 Oct 23 14:15 /mnt/kd
drwxr-sr-x    2 foobar   foobar       4096 Oct 23 19:02 /mnt/kd/home/foobar


Philip Prindeville wrote:
> On 10/23/2009 01:00 PM, Ron Byer wrote:
>   
>> Anyone seen this behavior before ?
>>
>> sk3 etc # ls -l /home
>> lrwxrwxrwx    1 root     root           12 Oct 22 16:53 /home -> 
>> /mnt/kd/home
>> sk3 etc # ls -l /mnt/kd
>> ...
>> drwxrwxrwx    5 root     root         4096 Oct 23 14:40 home
>> ...
>> sk3 kd # adduser foobar
>> Changing password for foobar
>> New password:
>> Retype password:
>> Password for foobar changed by root
>>
>> sk3 kd # ls -l /mnt/kd/home
>> drwxr-sr-x    2 foobar   foobar       4096 Oct 23 14:35 foobar
>> sk3 kd #
>>
>> sk3 kd # su foobar
>> su: chdir(/): Permission denied
>> sk3 kd # logout
>> This is sk3 (Linux i586 2.6.27.29-astlinux) 14:49:26
>> sk3 login: foobar
>> Password:
>> login: chdir(/):
>> This is sk3 (Linux i586 2.6.27.29-astlinux) 14:49:33
>> sk3 login: root
>> Password:
>> sk3 ~ #
>>
>> sk3 ~ # cat </etc/passwd
>> root:x:0:0:root:/root:/bin/sh
>> sshd:x:22:22:sshd:/dev/null:/bin/false
>> ftp:x:21:21:ftp user:/home/ftp:/bin/false
>> nobody:x:1000:1000:no one:/dev/null:/bin/false
>> foobar:x:1001:1001:Linux User,,,:/home/foobar:/bin/sh
>>
>>
>> I've been over the directory permissions to no avail... Any clues ?
>>
>>   
>>     
>
>
> % ls -ld / /home /mnt /mnt/kd /mnt/kd/foobar
>
> % ls -ld /oldroot /oldroot/mnt /oldroot/mnt/asturw
> /oldroot/mnt/asturw/mnt /oldroot/mnt/asturw/mnt/kd
>
>
> ------------------------------------------------------------------------------
> Come build with us! The BlackBerry(R) Developer Conference in SF, CA
> is the only developer event you need to attend this year. Jumpstart your
> developing skills, take BlackBerry mobile applications to market and stay 
> ahead of the curve. Join us from November 9 - 12, 2009. Register now!
> http://p.sf.net/sfu/devconference
> _______________________________________________
> Astlinux-devel mailing list
> Ast...@li...
> https://lists.sourceforge.net/lists/listinfo/astlinux-devel
>
> Donations to support AstLinux are graciously accepted via PayPal to pa...@kr....
>
>   

On 10/23/2009 01:00 PM, Ron Byer wrote:
> Anyone seen this behavior before ?
>
> sk3 etc # ls -l /home
> lrwxrwxrwx    1 root     root           12 Oct 22 16:53 /home -> 
> /mnt/kd/home
> sk3 etc # ls -l /mnt/kd
> ...
> drwxrwxrwx    5 root     root         4096 Oct 23 14:40 home
> ...
> sk3 kd # adduser foobar
> Changing password for foobar
> New password:
> Retype password:
> Password for foobar changed by root
>
> sk3 kd # ls -l /mnt/kd/home
> drwxr-sr-x    2 foobar   foobar       4096 Oct 23 14:35 foobar
> sk3 kd #
>
> sk3 kd # su foobar
> su: chdir(/): Permission denied
> sk3 kd # logout
> This is sk3 (Linux i586 2.6.27.29-astlinux) 14:49:26
> sk3 login: foobar
> Password:
> login: chdir(/):
> This is sk3 (Linux i586 2.6.27.29-astlinux) 14:49:33
> sk3 login: root
> Password:
> sk3 ~ #
>
> sk3 ~ # cat </etc/passwd
> root:x:0:0:root:/root:/bin/sh
> sshd:x:22:22:sshd:/dev/null:/bin/false
> ftp:x:21:21:ftp user:/home/ftp:/bin/false
> nobody:x:1000:1000:no one:/dev/null:/bin/false
> foobar:x:1001:1001:Linux User,,,:/home/foobar:/bin/sh
>
>
> I've been over the directory permissions to no avail... Any clues ?
>
>   


% ls -ld / /home /mnt /mnt/kd /mnt/kd/foobar

% ls -ld /oldroot /oldroot/mnt /oldroot/mnt/asturw
/oldroot/mnt/asturw/mnt /oldroot/mnt/asturw/mnt/kd

in 0.6 we would get a generated dnsmasq.conf and a resolv.conf file in 
/tmp/etc, symlinked back to /etc.
the resolv.conf would have the nameservers specified in the DNS env 
variable from /etc/rc.conf

in 0.7, we get a generated dnsmasq.conf file that looks the same as 0.6. 
The dnsmasq.conf file references the resolv.conf file, but there is no 
resolv.conf generated.

I can see that /etc/init.d/network is significantly changed from 0.6, 
and the section that generates the resolv.conf file is essentially gone, 
so I figure I'm about to get an education here.

Thanks, guys.


BTW, I've made the assumption that these type of questions belong here 
[devel] vs the users page. If that's not a good assumption, let me know 
and I will switch over.

rb

Anyone seen this behavior before ?

sk3 etc # ls -l /home
lrwxrwxrwx    1 root     root           12 Oct 22 16:53 /home -> 
/mnt/kd/home
sk3 etc # ls -l /mnt/kd
...
drwxrwxrwx    5 root     root         4096 Oct 23 14:40 home
...
sk3 kd # adduser foobar
Changing password for foobar
New password:
Retype password:
Password for foobar changed by root

sk3 kd # ls -l /mnt/kd/home
drwxr-sr-x    2 foobar   foobar       4096 Oct 23 14:35 foobar
sk3 kd #

sk3 kd # su foobar
su: chdir(/): Permission denied
sk3 kd # logout
This is sk3 (Linux i586 2.6.27.29-astlinux) 14:49:26
sk3 login: foobar
Password:
login: chdir(/):
This is sk3 (Linux i586 2.6.27.29-astlinux) 14:49:33
sk3 login: root
Password:
sk3 ~ #

sk3 ~ # cat </etc/passwd
root:x:0:0:root:/root:/bin/sh
sshd:x:22:22:sshd:/dev/null:/bin/false
ftp:x:21:21:ftp user:/home/ftp:/bin/false
nobody:x:1000:1000:no one:/dev/null:/bin/false
foobar:x:1001:1001:Linux User,,,:/home/foobar:/bin/sh


I've been over the directory permissions to no avail... Any clues ?

Hi list,

I just got this error message and Asterisk crashed without any 
running call or operation:

Oct 23 14:38:51 pbx5501 user.info kernel: asterisk[2595]: segfault at 
8 ip 400a721f sp be3fbb74 error 4 in 
libuClibc-0.9.28.so[4006f000+44000]

It's an net5501 with Astlinux 0.7-3358, HFC BRI card mISDN. But it 
does not look like it is mISDN related (this time).

After starting Asterisk again it seems to run fine again.

Michael

Lonnie,

Thanks. That is certainly possible. I have a couple of net5501s here 
I've been playing with, and enough CF cards to be dangerous.

I've added the "remove the persistent-rules file" to my list of notes.

Thanks again.

Ron

Lonnie Abelbeck wrote:
> Ron,
>
> It is like you booted the CF card in one net5501 (with 0.7), and  
> later, booted the CF card in a different net5501 (with 0.7).  That  
> would make sense.
>
> Great feedback... we were concerned this could be a problem for users,  
> basically if a CF card is moved you need to remove the
> /etc/udev/rules.d/70-persistent-net.rules file before you relocate the  
> CF card.
>
> Of course, it is a nice feature to easily assign interface names by  
> MAC address, and have the ordering fixed even if an additional NIC is  
> added at a later time.
>
> Thanks,
> Lonnie
>
>
> On Oct 22, 2009, at 4:02 PM, Ron Byer -- Lists wrote:
>
>   
>> Hi Lonnie,
>>
>> I did the shell arno upgrade on the first boot from the console.
>>
>> The persistent-rules file is included below.  Interestingly enough,   
>> both eth0-3 and eth4-7 are well represented.
>>
>> Eth4-7 are not getting created, because the ifconfig statements in / 
>> etc/init.d/network are for eth0 and eth2 Those ifconfig commands are  
>> both failing with SIOCSIFADDR no such device errors. However, if I  
>> manually substitute eth4 for eth0, then the interfaces are created.
>>
>> As you suggested, I whacked the persistent-rules file and it was  
>> recreated correctly, and the interfaces are set properly.
>> I rebooted again, and it stayed correct.
>>
>> Weird, but fixed, or at least worked around. Thanks!
>>
>> Ron
>>
>>
>> cat 70-persistent-net.rules
>> # This file was automatically generated by the /lib/udev/ 
>> write_net_rules
>> # program run by the persistent-net-generator.rules rules file.
>> #
>> # You can modify it, as long as you keep each rule on a single line.
>>
>> # PCI device 0x1106:0x3053 (via-rhine)
>> SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address} 
>> =="00:00:24:cc:15:5c", ATTR{type}=="1", KERNEL=="eth*", NAME="eth0"
>>
>> # PCI device 0x1106:0x3053 (via-rhine)
>> SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address} 
>> =="00:00:24:cc:15:5d", ATTR{type}=="1", KERNEL=="eth*", NAME="eth1"
>>
>> # PCI device 0x1106:0x3053 (via-rhine)
>> SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address} 
>> =="00:00:24:cc:15:5f", ATTR{type}=="1", KERNEL=="eth*", NAME="eth3"
>>
>> # PCI device 0x1106:0x3053 (via-rhine)
>> SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address} 
>> =="00:00:24:cc:15:5e", ATTR{type}=="1", KERNEL=="eth*", NAME="eth2"
>>
>> # PCI device 0x1106:0x3053 (via-rhine)
>> SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address} 
>> =="00:00:24:cb:d0:f8", ATTR{type}=="1", KERNEL=="eth*", NAME="eth4"
>>
>> # PCI device 0x1106:0x3053 (via-rhine)
>> SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address} 
>> =="00:00:24:cb:d0:fa", ATTR{type}=="1", KERNEL=="eth*", NAME="eth5"
>>
>> # PCI device 0x1106:0x3053 (via-rhine)
>> SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address} 
>> =="00:00:24:cb:d0:f9", ATTR{type}=="1", KERNEL=="eth*", NAME="eth6"
>>
>> # PCI device 0x1106:0x3053 (via-rhine)
>> SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address} 
>> =="00:00:24:cb:d0:fb", ATTR{type}=="1", KERNEL=="eth*", NAME="eth7"
>> sk3 rules.d #
>>
>>
>> Lonnie Abelbeck wrote:
>>     
>>> Ron,
>>>
>>> Before we get to the ethN issue, I assume you when from a 0.6 to a  
>>> 0.7
>>> configuration.
>>>
>>> To Upgrade from AstLinux 0.6 to 0.7...
>>>
>>> Web Interface Method:
>>> ==============
>>> Install 0.7 build from SVN
>>>
>>> ... wait for reboot...
>>>
>>> Network tab -> Firewall sub-tab -> {Save Settings}
>>>
>>> Firewall sub-tab -> {Restart Firewall}
>>>
>>> ...displays the firewall supporting files need upgrading...
>>>
>>> Firewall sub-tab -> {Upgrade/Restart Firewall} |x| Confirm
>>> ---
>>>
>>> Shell Method:
>>> =========
>>> Install 0.7 build from SVN
>>>
>>> $ reboot
>>>
>>> ssh back to box...
>>>
>>> $ upgrade-arno-firewall upgrade
>>>
>>> $ vi /mnt/kd/rc.conf (hand edit Arno 0.8.x to 0.9.x format)
>>>
>>> $ gen-rc-conf
>>>
>>> $ arno-iptables-firewall restart
>>> ---
>>>
>>> OK, with Arno upgraded, let's look at the interface ordering.  New in
>>> 0.7 is a file:
>>> /etc/udev/rules.d/70-persistent-net.rules
>>>
>>> This file assigns the network interface names by MAC address, you may
>>> edit this file if you wish.
>>>
>>> Ron, are you saying this file is assigning eth4-7 ?
>>>
>>> Try deleting this file and reboot and see if you get the expected
>>> eth0-3 in the same auto-generated file.
>>>
>>> This should not be effected by runnix or NDEV.  I am a little puzzled
>>> by what you are seeing...
>>>
>>> Lonnie
>>>
>>>
>>>
>>>
>>> On Oct 22, 2009, at 10:26 AM, Ron Byer -- Lists wrote:
>>>
>>>
>>>
>>>       
>>>> Greetings,
>>>>
>>>> I pulled a version of 0.7 (3370) recently, built it, and ran it on a
>>>> net5501.
>>>>
>>>> My compliments to you fellows for how cleanly this came up. I  
>>>> expected
>>>> some time spent sorting out issues, but I believe I have only one
>>>> issue,
>>>> which maybe you have seen.
>>>>
>>>> When I boot on 0.6, runnix comes up and assigns eth0-4, and then
>>>> astlinux does the same.
>>>>
>>>> When I boot on 0.7, runnix comes up and assigns eth0-4, but then
>>>> astlinux comes up and assigns eth4-7. This, of course annoys arno to
>>>> no
>>>> end.
>>>>
>>>> In reading throught the recent archives, I thought that commenting  
>>>> out
>>>> NDEV=eth0 in the default.conf would address the issue, but it had
>>>> little
>>>> effect.
>>>>
>>>> Here are the relevant bits of the boot log:
>>>>
>>>> runnix
>>>> via-rhine.c:v1.10-LK1.4.3 2007-03-06 Written by Donald Becker
>>>> eth0: VIA Rhine III (Management Adapter) at 0xa0004000,
>>>> 00:00:24:cb:d0:f8, IRQ .
>>>> eth4: MII PHY found at address 1, status 0x786d advertising 05e1
>>>> Link 0021.
>>>> eth0: VIA Rhine III (Management Adapter) at 0xa0004100,
>>>> 00:00:24:cb:d0:f9, IRQ .
>>>> eth6: MII PHY found at address 1, status 0x7849 advertising 05e1
>>>> Link 0000.
>>>> eth0: VIA Rhine III (Management Adapter) at 0xa0004200,
>>>> 00:00:24:cb:d0:fa, IRQ .
>>>> eth5: MII PHY found at address 1, status 0x786d advertising 05e1
>>>> Link 45e1.
>>>> eth0: VIA Rhine III (Management Adapter) at 0xa0004300,
>>>> 00:00:24:cb:d0:fb, IRQ .
>>>> eth7: MII PHY found at address 1, status 0x7849 advertising 05e1
>>>> Link 0000.
>>>> geode-aes: GEODE AES engine enabled.
>>>> AMD Geode RNG detected
>>>>
>>>> .......
>>>>
>>>> astlinux
>>>> via-rhine.c:v1.10-LK1.4.3 2007-03-06 Written by Donald Becker
>>>> eth0: VIA Rhine III (Management Adapter) at 0xa0004000,
>>>> 00:00:24:cb:d0:f8, IRQ .
>>>> eth4: MII PHY found at address 1, status 0x786d advertising 05e1
>>>> Link 0021.
>>>> eth0: VIA Rhine III (Management Adapter) at 0xa0004100,
>>>> 00:00:24:cb:d0:f9, IRQ .
>>>> eth6: MII PHY found at address 1, status 0x7849 advertising 05e1
>>>> Link 0000.
>>>> eth0: VIA Rhine III (Management Adapter) at 0xa0004200,
>>>> 00:00:24:cb:d0:fa, IRQ .
>>>> eth5: MII PHY found at address 1, status 0x786d advertising 05e1
>>>> Link 45e1.
>>>> eth0: VIA Rhine III (Management Adapter) at 0xa0004300,
>>>> 00:00:24:cb:d0:fb, IRQ .
>>>> eth7: MII PHY found at address 1, status 0x7849 advertising 05e1
>>>> Link 0000.
>>>> geode-aes: GEODE AES engine enabled.
>>>> AMD Geode RNG detected
>>>>
>>>>
>>>> Thanks for whatever direction you can point me in.
>>>>
>>>> Regards,
>>>>
>>>> Ron
>>>>
>>>>
>>>>         
>>> ------------------------------------------------------------------------------
>>> Come build with us! The BlackBerry(R) Developer Conference in SF, CA
>>> is the only developer event you need to attend this year. Jumpstart  
>>> your
>>> developing skills, take BlackBerry mobile applications to market  
>>> and stay
>>> ahead of the curve. Join us from November 9 - 12, 2009. Register now!
>>>
>>> http://p.sf.net/sfu/devconference
>>>
>>> _______________________________________________
>>> Astlinux-devel mailing list
>>>
>>> Ast...@li...
>>> https://lists.sourceforge.net/lists/listinfo/astlinux-devel
>>>
>>>
>>> Donations to support AstLinux are graciously accepted via PayPal to
>>> pa...@kr...
>>> .
>>>
>>>
>>>
>>>       
>> ------------------------------------------------------------------------------
>> Come build with us! The BlackBerry(R) Developer Conference in SF, CA
>> is the only developer event you need to attend this year. Jumpstart  
>> your
>> developing skills, take BlackBerry mobile applications to market and  
>> stay
>> ahead of the curve. Join us from November 9 - 12, 2009. Register now!
>> http://p.sf.net/sfu/devconference_______________________________________________
>> Astlinux-devel mailing list
>> Ast...@li...
>> https://lists.sourceforge.net/lists/listinfo/astlinux-devel
>>
>> Donations to support AstLinux are graciously accepted via PayPal to pa...@kr... 
>> .
>>     
>
>
> ------------------------------------------------------------------------------
> Come build with us! The BlackBerry(R) Developer Conference in SF, CA
> is the only developer event you need to attend this year. Jumpstart your
> developing skills, take BlackBerry mobile applications to market and stay 
> ahead of the curve. Join us from November 9 - 12, 2009. Register now!
> http://p.sf.net/sfu/devconference
> _______________________________________________
> Astlinux-devel mailing list
> Ast...@li...
> https://lists.sourceforge.net/lists/listinfo/astlinux-devel
>
> Donations to support AstLinux are graciously accepted via PayPal to pa...@kr....
>
>   

Ron,

It is like you booted the CF card in one net5501 (with 0.7), and  
later, booted the CF card in a different net5501 (with 0.7).  That  
would make sense.

Great feedback... we were concerned this could be a problem for users,  
basically if a CF card is moved you need to remove the
/etc/udev/rules.d/70-persistent-net.rules file before you relocate the  
CF card.

Of course, it is a nice feature to easily assign interface names by  
MAC address, and have the ordering fixed even if an additional NIC is  
added at a later time.

Thanks,
Lonnie


On Oct 22, 2009, at 4:02 PM, Ron Byer -- Lists wrote:

> Hi Lonnie,
>
> I did the shell arno upgrade on the first boot from the console.
>
> The persistent-rules file is included below.  Interestingly enough,   
> both eth0-3 and eth4-7 are well represented.
>
> Eth4-7 are not getting created, because the ifconfig statements in / 
> etc/init.d/network are for eth0 and eth2 Those ifconfig commands are  
> both failing with SIOCSIFADDR no such device errors. However, if I  
> manually substitute eth4 for eth0, then the interfaces are created.
>
> As you suggested, I whacked the persistent-rules file and it was  
> recreated correctly, and the interfaces are set properly.
> I rebooted again, and it stayed correct.
>
> Weird, but fixed, or at least worked around. Thanks!
>
> Ron
>
>
> cat 70-persistent-net.rules
> # This file was automatically generated by the /lib/udev/ 
> write_net_rules
> # program run by the persistent-net-generator.rules rules file.
> #
> # You can modify it, as long as you keep each rule on a single line.
>
> # PCI device 0x1106:0x3053 (via-rhine)
> SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address} 
> =="00:00:24:cc:15:5c", ATTR{type}=="1", KERNEL=="eth*", NAME="eth0"
>
> # PCI device 0x1106:0x3053 (via-rhine)
> SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address} 
> =="00:00:24:cc:15:5d", ATTR{type}=="1", KERNEL=="eth*", NAME="eth1"
>
> # PCI device 0x1106:0x3053 (via-rhine)
> SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address} 
> =="00:00:24:cc:15:5f", ATTR{type}=="1", KERNEL=="eth*", NAME="eth3"
>
> # PCI device 0x1106:0x3053 (via-rhine)
> SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address} 
> =="00:00:24:cc:15:5e", ATTR{type}=="1", KERNEL=="eth*", NAME="eth2"
>
> # PCI device 0x1106:0x3053 (via-rhine)
> SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address} 
> =="00:00:24:cb:d0:f8", ATTR{type}=="1", KERNEL=="eth*", NAME="eth4"
>
> # PCI device 0x1106:0x3053 (via-rhine)
> SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address} 
> =="00:00:24:cb:d0:fa", ATTR{type}=="1", KERNEL=="eth*", NAME="eth5"
>
> # PCI device 0x1106:0x3053 (via-rhine)
> SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address} 
> =="00:00:24:cb:d0:f9", ATTR{type}=="1", KERNEL=="eth*", NAME="eth6"
>
> # PCI device 0x1106:0x3053 (via-rhine)
> SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address} 
> =="00:00:24:cb:d0:fb", ATTR{type}=="1", KERNEL=="eth*", NAME="eth7"
> sk3 rules.d #
>
>
> Lonnie Abelbeck wrote:
>> Ron,
>>
>> Before we get to the ethN issue, I assume you when from a 0.6 to a  
>> 0.7
>> configuration.
>>
>> To Upgrade from AstLinux 0.6 to 0.7...
>>
>> Web Interface Method:
>> ==============
>> Install 0.7 build from SVN
>>
>> ... wait for reboot...
>>
>> Network tab -> Firewall sub-tab -> {Save Settings}
>>
>> Firewall sub-tab -> {Restart Firewall}
>>
>> ...displays the firewall supporting files need upgrading...
>>
>> Firewall sub-tab -> {Upgrade/Restart Firewall} |x| Confirm
>> ---
>>
>> Shell Method:
>> =========
>> Install 0.7 build from SVN
>>
>> $ reboot
>>
>> ssh back to box...
>>
>> $ upgrade-arno-firewall upgrade
>>
>> $ vi /mnt/kd/rc.conf (hand edit Arno 0.8.x to 0.9.x format)
>>
>> $ gen-rc-conf
>>
>> $ arno-iptables-firewall restart
>> ---
>>
>> OK, with Arno upgraded, let's look at the interface ordering.  New in
>> 0.7 is a file:
>> /etc/udev/rules.d/70-persistent-net.rules
>>
>> This file assigns the network interface names by MAC address, you may
>> edit this file if you wish.
>>
>> Ron, are you saying this file is assigning eth4-7 ?
>>
>> Try deleting this file and reboot and see if you get the expected
>> eth0-3 in the same auto-generated file.
>>
>> This should not be effected by runnix or NDEV.  I am a little puzzled
>> by what you are seeing...
>>
>> Lonnie
>>
>>
>>
>>
>> On Oct 22, 2009, at 10:26 AM, Ron Byer -- Lists wrote:
>>
>>
>>
>>> Greetings,
>>>
>>> I pulled a version of 0.7 (3370) recently, built it, and ran it on a
>>> net5501.
>>>
>>> My compliments to you fellows for how cleanly this came up. I  
>>> expected
>>> some time spent sorting out issues, but I believe I have only one
>>> issue,
>>> which maybe you have seen.
>>>
>>> When I boot on 0.6, runnix comes up and assigns eth0-4, and then
>>> astlinux does the same.
>>>
>>> When I boot on 0.7, runnix comes up and assigns eth0-4, but then
>>> astlinux comes up and assigns eth4-7. This, of course annoys arno to
>>> no
>>> end.
>>>
>>> In reading throught the recent archives, I thought that commenting  
>>> out
>>> NDEV=eth0 in the default.conf would address the issue, but it had
>>> little
>>> effect.
>>>
>>> Here are the relevant bits of the boot log:
>>>
>>> runnix
>>> via-rhine.c:v1.10-LK1.4.3 2007-03-06 Written by Donald Becker
>>> eth0: VIA Rhine III (Management Adapter) at 0xa0004000,
>>> 00:00:24:cb:d0:f8, IRQ .
>>> eth4: MII PHY found at address 1, status 0x786d advertising 05e1
>>> Link 0021.
>>> eth0: VIA Rhine III (Management Adapter) at 0xa0004100,
>>> 00:00:24:cb:d0:f9, IRQ .
>>> eth6: MII PHY found at address 1, status 0x7849 advertising 05e1
>>> Link 0000.
>>> eth0: VIA Rhine III (Management Adapter) at 0xa0004200,
>>> 00:00:24:cb:d0:fa, IRQ .
>>> eth5: MII PHY found at address 1, status 0x786d advertising 05e1
>>> Link 45e1.
>>> eth0: VIA Rhine III (Management Adapter) at 0xa0004300,
>>> 00:00:24:cb:d0:fb, IRQ .
>>> eth7: MII PHY found at address 1, status 0x7849 advertising 05e1
>>> Link 0000.
>>> geode-aes: GEODE AES engine enabled.
>>> AMD Geode RNG detected
>>>
>>> .......
>>>
>>> astlinux
>>> via-rhine.c:v1.10-LK1.4.3 2007-03-06 Written by Donald Becker
>>> eth0: VIA Rhine III (Management Adapter) at 0xa0004000,
>>> 00:00:24:cb:d0:f8, IRQ .
>>> eth4: MII PHY found at address 1, status 0x786d advertising 05e1
>>> Link 0021.
>>> eth0: VIA Rhine III (Management Adapter) at 0xa0004100,
>>> 00:00:24:cb:d0:f9, IRQ .
>>> eth6: MII PHY found at address 1, status 0x7849 advertising 05e1
>>> Link 0000.
>>> eth0: VIA Rhine III (Management Adapter) at 0xa0004200,
>>> 00:00:24:cb:d0:fa, IRQ .
>>> eth5: MII PHY found at address 1, status 0x786d advertising 05e1
>>> Link 45e1.
>>> eth0: VIA Rhine III (Management Adapter) at 0xa0004300,
>>> 00:00:24:cb:d0:fb, IRQ .
>>> eth7: MII PHY found at address 1, status 0x7849 advertising 05e1
>>> Link 0000.
>>> geode-aes: GEODE AES engine enabled.
>>> AMD Geode RNG detected
>>>
>>>
>>> Thanks for whatever direction you can point me in.
>>>
>>> Regards,
>>>
>>> Ron
>>>
>>>
>>
>> ------------------------------------------------------------------------------
>> Come build with us! The BlackBerry(R) Developer Conference in SF, CA
>> is the only developer event you need to attend this year. Jumpstart  
>> your
>> developing skills, take BlackBerry mobile applications to market  
>> and stay
>> ahead of the curve. Join us from November 9 - 12, 2009. Register now!
>>
>> http://p.sf.net/sfu/devconference
>>
>> _______________________________________________
>> Astlinux-devel mailing list
>>
>> Ast...@li...
>> https://lists.sourceforge.net/lists/listinfo/astlinux-devel
>>
>>
>> Donations to support AstLinux are graciously accepted via PayPal to
>> pa...@kr...
>> .
>>
>>
>>
>
> ------------------------------------------------------------------------------
> Come build with us! The BlackBerry(R) Developer Conference in SF, CA
> is the only developer event you need to attend this year. Jumpstart  
> your
> developing skills, take BlackBerry mobile applications to market and  
> stay
> ahead of the curve. Join us from November 9 - 12, 2009. Register now!
> http://p.sf.net/sfu/devconference_______________________________________________
> Astlinux-devel mailing list
> Ast...@li...
> https://lists.sourceforge.net/lists/listinfo/astlinux-devel
>
> Donations to support AstLinux are graciously accepted via PayPal to pa...@kr... 
> .

Hi Lonnie,

I did the shell arno upgrade on the first boot from the console.

The persistent-rules file is included below.  Interestingly enough,  
both eth0-3 and eth4-7 are well represented.

Eth4-7 are not getting created, because the ifconfig statements in 
/etc/init.d/network are for eth0 and eth2 Those ifconfig commands are 
both failing with SIOCSIFADDR no such device errors. However, if I 
manually substitute eth4 for eth0, then the interfaces are created.

As you suggested, I whacked the persistent-rules file and it was 
recreated correctly, and the interfaces are set properly.
I rebooted again, and it stayed correct.

Weird, but fixed, or at least worked around. Thanks!

Ron


cat 70-persistent-net.rules
# This file was automatically generated by the /lib/udev/write_net_rules
# program run by the persistent-net-generator.rules rules file.
#
# You can modify it, as long as you keep each rule on a single line.

# PCI device 0x1106:0x3053 (via-rhine)
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", 
ATTR{address}=="00:00:24:cc:15:5c", ATTR{type}=="1", KERNEL=="eth*", 
NAME="eth0"

# PCI device 0x1106:0x3053 (via-rhine)
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", 
ATTR{address}=="00:00:24:cc:15:5d", ATTR{type}=="1", KERNEL=="eth*", 
NAME="eth1"

# PCI device 0x1106:0x3053 (via-rhine)
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", 
ATTR{address}=="00:00:24:cc:15:5f", ATTR{type}=="1", KERNEL=="eth*", 
NAME="eth3"

# PCI device 0x1106:0x3053 (via-rhine)
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", 
ATTR{address}=="00:00:24:cc:15:5e", ATTR{type}=="1", KERNEL=="eth*", 
NAME="eth2"

# PCI device 0x1106:0x3053 (via-rhine)
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", 
ATTR{address}=="00:00:24:cb:d0:f8", ATTR{type}=="1", KERNEL=="eth*", 
NAME="eth4"

# PCI device 0x1106:0x3053 (via-rhine)
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", 
ATTR{address}=="00:00:24:cb:d0:fa", ATTR{type}=="1", KERNEL=="eth*", 
NAME="eth5"

# PCI device 0x1106:0x3053 (via-rhine)
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", 
ATTR{address}=="00:00:24:cb:d0:f9", ATTR{type}=="1", KERNEL=="eth*", 
NAME="eth6"

# PCI device 0x1106:0x3053 (via-rhine)
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", 
ATTR{address}=="00:00:24:cb:d0:fb", ATTR{type}=="1", KERNEL=="eth*", 
NAME="eth7"
sk3 rules.d #


Lonnie Abelbeck wrote:
> Ron,
>
> Before we get to the ethN issue, I assume you when from a 0.6 to a 0.7  
> configuration.
>
> To Upgrade from AstLinux 0.6 to 0.7...
>
> Web Interface Method:
> ==============
> Install 0.7 build from SVN
>
> ... wait for reboot...
>
> Network tab -> Firewall sub-tab -> {Save Settings}
>
> Firewall sub-tab -> {Restart Firewall}
>
> ...displays the firewall supporting files need upgrading...
>
> Firewall sub-tab -> {Upgrade/Restart Firewall} |x| Confirm
> ---
>
> Shell Method:
> =========
> Install 0.7 build from SVN
>
> $ reboot
>
> ssh back to box...
>
> $ upgrade-arno-firewall upgrade
>
> $ vi /mnt/kd/rc.conf (hand edit Arno 0.8.x to 0.9.x format)
>
> $ gen-rc-conf
>
> $ arno-iptables-firewall restart
> ---
>
> OK, with Arno upgraded, let's look at the interface ordering.  New in  
> 0.7 is a file:
> /etc/udev/rules.d/70-persistent-net.rules
>
> This file assigns the network interface names by MAC address, you may  
> edit this file if you wish.
>
> Ron, are you saying this file is assigning eth4-7 ?
>
> Try deleting this file and reboot and see if you get the expected  
> eth0-3 in the same auto-generated file.
>
> This should not be effected by runnix or NDEV.  I am a little puzzled  
> by what you are seeing...
>
> Lonnie
>
>
>
>
> On Oct 22, 2009, at 10:26 AM, Ron Byer -- Lists wrote:
>
>   
>> Greetings,
>>
>> I pulled a version of 0.7 (3370) recently, built it, and ran it on a
>> net5501.
>>
>> My compliments to you fellows for how cleanly this came up. I expected
>> some time spent sorting out issues, but I believe I have only one  
>> issue,
>> which maybe you have seen.
>>
>> When I boot on 0.6, runnix comes up and assigns eth0-4, and then
>> astlinux does the same.
>>
>> When I boot on 0.7, runnix comes up and assigns eth0-4, but then
>> astlinux comes up and assigns eth4-7. This, of course annoys arno to  
>> no
>> end.
>>
>> In reading throught the recent archives, I thought that commenting out
>> NDEV=eth0 in the default.conf would address the issue, but it had  
>> little
>> effect.
>>
>> Here are the relevant bits of the boot log:
>>
>> runnix
>> via-rhine.c:v1.10-LK1.4.3 2007-03-06 Written by Donald Becker
>> eth0: VIA Rhine III (Management Adapter) at 0xa0004000,
>> 00:00:24:cb:d0:f8, IRQ .
>> eth4: MII PHY found at address 1, status 0x786d advertising 05e1  
>> Link 0021.
>> eth0: VIA Rhine III (Management Adapter) at 0xa0004100,
>> 00:00:24:cb:d0:f9, IRQ .
>> eth6: MII PHY found at address 1, status 0x7849 advertising 05e1  
>> Link 0000.
>> eth0: VIA Rhine III (Management Adapter) at 0xa0004200,
>> 00:00:24:cb:d0:fa, IRQ .
>> eth5: MII PHY found at address 1, status 0x786d advertising 05e1  
>> Link 45e1.
>> eth0: VIA Rhine III (Management Adapter) at 0xa0004300,
>> 00:00:24:cb:d0:fb, IRQ .
>> eth7: MII PHY found at address 1, status 0x7849 advertising 05e1  
>> Link 0000.
>> geode-aes: GEODE AES engine enabled.
>> AMD Geode RNG detected
>>
>> .......
>>
>> astlinux
>> via-rhine.c:v1.10-LK1.4.3 2007-03-06 Written by Donald Becker
>> eth0: VIA Rhine III (Management Adapter) at 0xa0004000,
>> 00:00:24:cb:d0:f8, IRQ .
>> eth4: MII PHY found at address 1, status 0x786d advertising 05e1  
>> Link 0021.
>> eth0: VIA Rhine III (Management Adapter) at 0xa0004100,
>> 00:00:24:cb:d0:f9, IRQ .
>> eth6: MII PHY found at address 1, status 0x7849 advertising 05e1  
>> Link 0000.
>> eth0: VIA Rhine III (Management Adapter) at 0xa0004200,
>> 00:00:24:cb:d0:fa, IRQ .
>> eth5: MII PHY found at address 1, status 0x786d advertising 05e1  
>> Link 45e1.
>> eth0: VIA Rhine III (Management Adapter) at 0xa0004300,
>> 00:00:24:cb:d0:fb, IRQ .
>> eth7: MII PHY found at address 1, status 0x7849 advertising 05e1  
>> Link 0000.
>> geode-aes: GEODE AES engine enabled.
>> AMD Geode RNG detected
>>
>>
>> Thanks for whatever direction you can point me in.
>>
>> Regards,
>>
>> Ron
>>     
>
> ------------------------------------------------------------------------------
> Come build with us! The BlackBerry(R) Developer Conference in SF, CA
> is the only developer event you need to attend this year. Jumpstart your
> developing skills, take BlackBerry mobile applications to market and stay 
> ahead of the curve. Join us from November 9 - 12, 2009. Register now!
> http://p.sf.net/sfu/devconference
> _______________________________________________
> Astlinux-devel mailing list
> Ast...@li...
> https://lists.sourceforge.net/lists/listinfo/astlinux-devel
>
> Donations to support AstLinux are graciously accepted via PayPal to pa...@kr....
>
>   

Also, when you get into the system, what do you have as eth0, etc? 
Anything?

You should only get relocated to eth4 (etc) if eth0-eth3 are already taken.


On 10/22/2009 10:44 AM, Lonnie Abelbeck wrote:
> Ron,
>
> Before we get to the ethN issue, I assume you when from a 0.6 to a 0.7  
> configuration.
>
> To Upgrade from AstLinux 0.6 to 0.7...
>
> Web Interface Method:
> ==============
> Install 0.7 build from SVN
>
> ... wait for reboot...
>
> Network tab -> Firewall sub-tab -> {Save Settings}
>
> Firewall sub-tab -> {Restart Firewall}
>
> ...displays the firewall supporting files need upgrading...
>
> Firewall sub-tab -> {Upgrade/Restart Firewall} |x| Confirm
> ---
>
> Shell Method:
> =========
> Install 0.7 build from SVN
>
> $ reboot
>
> ssh back to box...
>
> $ upgrade-arno-firewall upgrade
>
> $ vi /mnt/kd/rc.conf (hand edit Arno 0.8.x to 0.9.x format)
>
> $ gen-rc-conf
>
> $ arno-iptables-firewall restart
> ---
>
> OK, with Arno upgraded, let's look at the interface ordering.  New in  
> 0.7 is a file:
> /etc/udev/rules.d/70-persistent-net.rules
>
> This file assigns the network interface names by MAC address, you may  
> edit this file if you wish.
>
> Ron, are you saying this file is assigning eth4-7 ?
>
> Try deleting this file and reboot and see if you get the expected  
> eth0-3 in the same auto-generated file.
>
> This should not be effected by runnix or NDEV.  I am a little puzzled  
> by what you are seeing...
>
> Lonnie
>
>
>
>
> On Oct 22, 2009, at 10:26 AM, Ron Byer -- Lists wrote:
>
>   
>> Greetings,
>>
>> I pulled a version of 0.7 (3370) recently, built it, and ran it on a
>> net5501.
>>
>> My compliments to you fellows for how cleanly this came up. I expected
>> some time spent sorting out issues, but I believe I have only one  
>> issue,
>> which maybe you have seen.
>>
>> When I boot on 0.6, runnix comes up and assigns eth0-4, and then
>> astlinux does the same.
>>
>> When I boot on 0.7, runnix comes up and assigns eth0-4, but then
>> astlinux comes up and assigns eth4-7. This, of course annoys arno to  
>> no
>> end.
>>
>> In reading throught the recent archives, I thought that commenting out
>> NDEV=eth0 in the default.conf would address the issue, but it had  
>> little
>> effect.
>>
>> Here are the relevant bits of the boot log:
>>
>> runnix
>> via-rhine.c:v1.10-LK1.4.3 2007-03-06 Written by Donald Becker
>> eth0: VIA Rhine III (Management Adapter) at 0xa0004000,
>> 00:00:24:cb:d0:f8, IRQ .
>> eth4: MII PHY found at address 1, status 0x786d advertising 05e1  
>> Link 0021.
>> eth0: VIA Rhine III (Management Adapter) at 0xa0004100,
>> 00:00:24:cb:d0:f9, IRQ .
>> eth6: MII PHY found at address 1, status 0x7849 advertising 05e1  
>> Link 0000.
>> eth0: VIA Rhine III (Management Adapter) at 0xa0004200,
>> 00:00:24:cb:d0:fa, IRQ .
>> eth5: MII PHY found at address 1, status 0x786d advertising 05e1  
>> Link 45e1.
>> eth0: VIA Rhine III (Management Adapter) at 0xa0004300,
>> 00:00:24:cb:d0:fb, IRQ .
>> eth7: MII PHY found at address 1, status 0x7849 advertising 05e1  
>> Link 0000.
>> geode-aes: GEODE AES engine enabled.
>> AMD Geode RNG detected
>>
>> .......
>>
>> astlinux
>> via-rhine.c:v1.10-LK1.4.3 2007-03-06 Written by Donald Becker
>> eth0: VIA Rhine III (Management Adapter) at 0xa0004000,
>> 00:00:24:cb:d0:f8, IRQ .
>> eth4: MII PHY found at address 1, status 0x786d advertising 05e1  
>> Link 0021.
>> eth0: VIA Rhine III (Management Adapter) at 0xa0004100,
>> 00:00:24:cb:d0:f9, IRQ .
>> eth6: MII PHY found at address 1, status 0x7849 advertising 05e1  
>> Link 0000.
>> eth0: VIA Rhine III (Management Adapter) at 0xa0004200,
>> 00:00:24:cb:d0:fa, IRQ .
>> eth5: MII PHY found at address 1, status 0x786d advertising 05e1  
>> Link 45e1.
>> eth0: VIA Rhine III (Management Adapter) at 0xa0004300,
>> 00:00:24:cb:d0:fb, IRQ .
>> eth7: MII PHY found at address 1, status 0x7849 advertising 05e1  
>> Link 0000.
>> geode-aes: GEODE AES engine enabled.
>> AMD Geode RNG detected
>>
>>
>> Thanks for whatever direction you can point me in.
>>
>> Regards,
>>
>> Ron
>>     
>

Ron,

Before we get to the ethN issue, I assume you when from a 0.6 to a 0.7  
configuration.

To Upgrade from AstLinux 0.6 to 0.7...

Web Interface Method:
==============
Install 0.7 build from SVN

... wait for reboot...

Network tab -> Firewall sub-tab -> {Save Settings}

Firewall sub-tab -> {Restart Firewall}

...displays the firewall supporting files need upgrading...

Firewall sub-tab -> {Upgrade/Restart Firewall} |x| Confirm
---

Shell Method:
=========
Install 0.7 build from SVN

$ reboot

ssh back to box...

$ upgrade-arno-firewall upgrade

$ vi /mnt/kd/rc.conf (hand edit Arno 0.8.x to 0.9.x format)

$ gen-rc-conf

$ arno-iptables-firewall restart
---

OK, with Arno upgraded, let's look at the interface ordering.  New in  
0.7 is a file:
/etc/udev/rules.d/70-persistent-net.rules

This file assigns the network interface names by MAC address, you may  
edit this file if you wish.

Ron, are you saying this file is assigning eth4-7 ?

Try deleting this file and reboot and see if you get the expected  
eth0-3 in the same auto-generated file.

This should not be effected by runnix or NDEV.  I am a little puzzled  
by what you are seeing...

Lonnie




On Oct 22, 2009, at 10:26 AM, Ron Byer -- Lists wrote:

> Greetings,
>
> I pulled a version of 0.7 (3370) recently, built it, and ran it on a
> net5501.
>
> My compliments to you fellows for how cleanly this came up. I expected
> some time spent sorting out issues, but I believe I have only one  
> issue,
> which maybe you have seen.
>
> When I boot on 0.6, runnix comes up and assigns eth0-4, and then
> astlinux does the same.
>
> When I boot on 0.7, runnix comes up and assigns eth0-4, but then
> astlinux comes up and assigns eth4-7. This, of course annoys arno to  
> no
> end.
>
> In reading throught the recent archives, I thought that commenting out
> NDEV=eth0 in the default.conf would address the issue, but it had  
> little
> effect.
>
> Here are the relevant bits of the boot log:
>
> runnix
> via-rhine.c:v1.10-LK1.4.3 2007-03-06 Written by Donald Becker
> eth0: VIA Rhine III (Management Adapter) at 0xa0004000,
> 00:00:24:cb:d0:f8, IRQ .
> eth4: MII PHY found at address 1, status 0x786d advertising 05e1  
> Link 0021.
> eth0: VIA Rhine III (Management Adapter) at 0xa0004100,
> 00:00:24:cb:d0:f9, IRQ .
> eth6: MII PHY found at address 1, status 0x7849 advertising 05e1  
> Link 0000.
> eth0: VIA Rhine III (Management Adapter) at 0xa0004200,
> 00:00:24:cb:d0:fa, IRQ .
> eth5: MII PHY found at address 1, status 0x786d advertising 05e1  
> Link 45e1.
> eth0: VIA Rhine III (Management Adapter) at 0xa0004300,
> 00:00:24:cb:d0:fb, IRQ .
> eth7: MII PHY found at address 1, status 0x7849 advertising 05e1  
> Link 0000.
> geode-aes: GEODE AES engine enabled.
> AMD Geode RNG detected
>
> .......
>
> astlinux
> via-rhine.c:v1.10-LK1.4.3 2007-03-06 Written by Donald Becker
> eth0: VIA Rhine III (Management Adapter) at 0xa0004000,
> 00:00:24:cb:d0:f8, IRQ .
> eth4: MII PHY found at address 1, status 0x786d advertising 05e1  
> Link 0021.
> eth0: VIA Rhine III (Management Adapter) at 0xa0004100,
> 00:00:24:cb:d0:f9, IRQ .
> eth6: MII PHY found at address 1, status 0x7849 advertising 05e1  
> Link 0000.
> eth0: VIA Rhine III (Management Adapter) at 0xa0004200,
> 00:00:24:cb:d0:fa, IRQ .
> eth5: MII PHY found at address 1, status 0x786d advertising 05e1  
> Link 45e1.
> eth0: VIA Rhine III (Management Adapter) at 0xa0004300,
> 00:00:24:cb:d0:fb, IRQ .
> eth7: MII PHY found at address 1, status 0x7849 advertising 05e1  
> Link 0000.
> geode-aes: GEODE AES engine enabled.
> AMD Geode RNG detected
>
>
> Thanks for whatever direction you can point me in.
>
> Regards,
>
> Ron

Greetings,

I pulled a version of 0.7 (3370) recently, built it, and ran it on a 
net5501.

My compliments to you fellows for how cleanly this came up. I expected 
some time spent sorting out issues, but I believe I have only one issue, 
which maybe you have seen.

When I boot on 0.6, runnix comes up and assigns eth0-4, and then 
astlinux does the same.

When I boot on 0.7, runnix comes up and assigns eth0-4, but then 
astlinux comes up and assigns eth4-7. This, of course annoys arno to no 
end.

In reading throught the recent archives, I thought that commenting out 
NDEV=eth0 in the default.conf would address the issue, but it had little 
effect.

Here are the relevant bits of the boot log:

runnix
via-rhine.c:v1.10-LK1.4.3 2007-03-06 Written by Donald Becker
eth0: VIA Rhine III (Management Adapter) at 0xa0004000, 
00:00:24:cb:d0:f8, IRQ .
eth4: MII PHY found at address 1, status 0x786d advertising 05e1 Link 0021.
eth0: VIA Rhine III (Management Adapter) at 0xa0004100, 
00:00:24:cb:d0:f9, IRQ .
eth6: MII PHY found at address 1, status 0x7849 advertising 05e1 Link 0000.
eth0: VIA Rhine III (Management Adapter) at 0xa0004200, 
00:00:24:cb:d0:fa, IRQ .
eth5: MII PHY found at address 1, status 0x786d advertising 05e1 Link 45e1.
eth0: VIA Rhine III (Management Adapter) at 0xa0004300, 
00:00:24:cb:d0:fb, IRQ .
eth7: MII PHY found at address 1, status 0x7849 advertising 05e1 Link 0000.
geode-aes: GEODE AES engine enabled.
AMD Geode RNG detected

.......

astlinux
via-rhine.c:v1.10-LK1.4.3 2007-03-06 Written by Donald Becker
eth0: VIA Rhine III (Management Adapter) at 0xa0004000, 
00:00:24:cb:d0:f8, IRQ .
eth4: MII PHY found at address 1, status 0x786d advertising 05e1 Link 0021.
eth0: VIA Rhine III (Management Adapter) at 0xa0004100, 
00:00:24:cb:d0:f9, IRQ .
eth6: MII PHY found at address 1, status 0x7849 advertising 05e1 Link 0000.
eth0: VIA Rhine III (Management Adapter) at 0xa0004200, 
00:00:24:cb:d0:fa, IRQ .
eth5: MII PHY found at address 1, status 0x786d advertising 05e1 Link 45e1.
eth0: VIA Rhine III (Management Adapter) at 0xa0004300, 
00:00:24:cb:d0:fb, IRQ .
eth7: MII PHY found at address 1, status 0x7849 advertising 05e1 Link 0000.
geode-aes: GEODE AES engine enabled.
AMD Geode RNG detected


Thanks for whatever direction you can point me in.

Regards,

Ron

Philip Prindeville wrote:
> On 10/21/2009 10:40 AM, Michael Keuter wrote:
>>>> Hi list,
>>>>
>>>> I made a patch to include Russell's backport of func_devstate to 
>>>> Asterisk 1.4.
>>>> It's selected by activating "asterisk-backports" in make menuconfig.
>>>>
>>>> Michael
>>>>       
>>> Because the 2 existing backports (app_stack + func_odbc) don't apply 
>>> against the current Asterisk version, I made an additional Asterisk 
>>> sub-package for the func_devstate backport.
>>>
>>> Michael
>>>     
>> Here is the latest version of Russell Bryants func_devstate and (also 
>> the) func_extstate backports for Asterisk 1.4.
>> Func_devstate is a newer version than I posted to the list (it now 
>> has the same syntax as the 1.6 version).
>>
>> device_state is a very cool function: e.g. you can turn on a lamp on 
>> an IP Phone when a conference room is active and other nice things. 
>> With ext_state you can e.g. turn a lamp on (with a hint), when an 
>> extension, that dials 3 different SIP phone at the same time, is 
>> called.
>>
>> More infos on devive_state can be found here:
>>
>> http://www.asterisk.org/node/48325
>>
>> Michael
>>
> 
> 0.7 is now 1.6-based, right?  So it should already include that
> functionality.

0.7 will remain with Asterisk 1.4.x.  Failing to do so will result in 
issues with mISDN.  I don't yet know what the best solution is to mISDN 
with Asterisk 1.6.  It seems like a moving target.

Darrick

>On 10/21/2009 10:40 AM, Michael Keuter wrote:
>>>>  Hi list,
>>>>
>>>>  I made a patch to include Russell's backport of func_devstate to
>>>>  Asterisk 1.4.
>>>>  It's selected by activating "asterisk-backports" in make menuconfig.
>>>>
>>>>  Michael
>>>>      
>>>  Because the 2 existing backports (app_stack + func_odbc) don't apply
>>>  against the current Asterisk version, I made an additional Asterisk
>>>  sub-package for the func_devstate backport.
>>>
>>>  Michael
>>>    
>>  Here is the latest version of Russell Bryants func_devstate and (also
>>  the) func_extstate backports for Asterisk 1.4.
>>  Func_devstate is a newer version than I posted to the list (it now
>>  has the same syntax as the 1.6 version).
>>
>>  device_state is a very cool function: e.g. you can turn on a lamp on
>>  an IP Phone when a conference room is active and other nice things.
>>  With ext_state you can e.g. turn a lamp on (with a hint), when an
>>  extension, that dials 3 different SIP phone at the same time, is
>>  called.
>>
>>  More infos on devive_state can be found here:
>>
>>  http://www.asterisk.org/node/48325
>>
>>  Michael
>>
>
>0.7 is now 1.6-based, right?  So it should already include that
>functionality.

No, it will stay 1.4.x based, as I understand. So it'ss nice to have 
those goodies too.

>-Philip

Michael

On 10/21/2009 10:40 AM, Michael Keuter wrote:
>>> Hi list,
>>>
>>> I made a patch to include Russell's backport of func_devstate to 
>>> Asterisk 1.4.
>>> It's selected by activating "asterisk-backports" in make menuconfig.
>>>
>>> Michael
>>>       
>> Because the 2 existing backports (app_stack + func_odbc) don't apply 
>> against the current Asterisk version, I made an additional Asterisk 
>> sub-package for the func_devstate backport.
>>
>> Michael
>>     
> Here is the latest version of Russell Bryants func_devstate and (also 
> the) func_extstate backports for Asterisk 1.4.
> Func_devstate is a newer version than I posted to the list (it now 
> has the same syntax as the 1.6 version).
>
> device_state is a very cool function: e.g. you can turn on a lamp on 
> an IP Phone when a conference room is active and other nice things. 
> With ext_state you can e.g. turn a lamp on (with a hint), when an 
> extension, that dials 3 different SIP phone at the same time, is 
> called.
>
> More infos on devive_state can be found here:
>
> http://www.asterisk.org/node/48325
>
> Michael
>

0.7 is now 1.6-based, right?  So it should already include that
functionality.

-Philip

On 10/21/2009 07:09 AM, Lonnie Abelbeck wrote:
> On Oct 20, 2009, at 11:17 PM, Philip Prindeville wrote:
>
>   
>> On 10/20/2009 09:04 PM, Lonnie Abelbeck wrote:
>>     
>>> On Oct 20, 2009, at 7:32 PM, Philip Prindeville wrote:
>>>
>>>
>>>       
>>>> I built a test box with an Intel Pro/1000 card in it, and rebooted.
>>>>
>>>> Interestingly, runnix came up with eth0 as the e1000 driver... which
>>>> was
>>>> a little unexpected.
>>>>
>>>> I'll see if there's a work-around for this, but it would probably
>>>> incur
>>>> platform-specific fixes and having multiple versions.  Not sure I  
>>>> want
>>>> to go down that road.
>>>>
>>>> -Philip
>>>>
>>>>         
>>> Yes, I have seen exactly this as well.  In fact my main net5501
>>> AstLinux box is configured as you describe.
>>>
>>> My simple solution was to comment out NDEV in /oldroot/cdrom/os/
>>> default.conf
>>>
>>> #NDEV="eth0"
>>>
>>> problem solved.  In fact all my boxes have NDEV commented out
>>> (disabling runnix network configuration) because in a cable modem
>>> environment this can cause many problems.  Forcing a DHCP lease when
>>> you don't want one or different MAC addresses between runnix and
>>> astlinux essentially disabling the astlinux interface to the cable
>>> modem.
>>>
>>> Lonnie
>>>       
>> That just turns it off, and I already knew how to do that.
>>
>> I'm worried about preserving the functionality for those who use it.
>>
>> -Philip
>>     
> Now that /etc/udev/rules.d/70-persistent-net.rules can change the  
> network interface ordering in astlinux, I see no practical way for  
> runnix to automatically keep in sync with the astlinux network  
> interface ordering.
>
> Since runnix was derived from astlinux, the modprobe ordering kept  
> things in sync, for the most part, for a couple of years.
>
> I suggest here (and have for some time) for our purposes, enabling  
> runnix NDEV by default causes more problems than it solves.  Should a  
> user want to enable runnix NDEV, then it is their responsibility to  
> match the the EXTIF interface with their runnix NDEV.
>
> Lonnie
>   

It may be as simple as ensuring that the modules listed in astlinux and
runnix occur in the same order so that they're probed in the same
order.  Note that built-in's (like via-rhine on the Soekris boards) are
already present, of course... so they would appear at the front of the
list on runnix.

-Philip

>>Hi list,
>>
>>I made a patch to include Russell's backport of func_devstate to 
>>Asterisk 1.4.
>>It's selected by activating "asterisk-backports" in make menuconfig.
>>
>>Michael
>
>Because the 2 existing backports (app_stack + func_odbc) don't apply 
>against the current Asterisk version, I made an additional Asterisk 
>sub-package for the func_devstate backport.
>
>Michael

Here is the latest version of Russell Bryants func_devstate and (also 
the) func_extstate backports for Asterisk 1.4.
Func_devstate is a newer version than I posted to the list (it now 
has the same syntax as the 1.6 version).

device_state is a very cool function: e.g. you can turn on a lamp on 
an IP Phone when a conference room is active and other nice things. 
With ext_state you can e.g. turn a lamp on (with a hint), when an 
extension, that dials 3 different SIP phone at the same time, is 
called.

More infos on devive_state can be found here:

http://www.asterisk.org/node/48325

Michael

Lonnie Abelbeck wrote:
> On Oct 20, 2009, at 11:17 PM, Philip Prindeville wrote:
> 
>> On 10/20/2009 09:04 PM, Lonnie Abelbeck wrote:
>>> On Oct 20, 2009, at 7:32 PM, Philip Prindeville wrote:
>>>
>>>
>>>> I built a test box with an Intel Pro/1000 card in it, and rebooted.
>>>>
>>>> Interestingly, runnix came up with eth0 as the e1000 driver... which
>>>> was
>>>> a little unexpected.
>>>>
>>>> I'll see if there's a work-around for this, but it would probably
>>>> incur
>>>> platform-specific fixes and having multiple versions.  Not sure I  
>>>> want
>>>> to go down that road.
>>>>
>>>> -Philip
>>>>
>>> Yes, I have seen exactly this as well.  In fact my main net5501
>>> AstLinux box is configured as you describe.
>>>
>>> My simple solution was to comment out NDEV in /oldroot/cdrom/os/
>>> default.conf
>>>
>>> #NDEV="eth0"
>>>
>>> problem solved.  In fact all my boxes have NDEV commented out
>>> (disabling runnix network configuration) because in a cable modem
>>> environment this can cause many problems.  Forcing a DHCP lease when
>>> you don't want one or different MAC addresses between runnix and
>>> astlinux essentially disabling the astlinux interface to the cable
>>> modem.
>>>
>>> Lonnie
>> That just turns it off, and I already knew how to do that.
>>
>> I'm worried about preserving the functionality for those who use it.
>>
>> -Philip
> 
> Now that /etc/udev/rules.d/70-persistent-net.rules can change the  
> network interface ordering in astlinux, I see no practical way for  
> runnix to automatically keep in sync with the astlinux network  
> interface ordering.
> 
> Since runnix was derived from astlinux, the modprobe ordering kept  
> things in sync, for the most part, for a couple of years.
> 
> I suggest here (and have for some time) for our purposes, enabling  
> runnix NDEV by default causes more problems than it solves.  Should a  
> user want to enable runnix NDEV, then it is their responsibility to  
> match the the EXTIF interface with their runnix NDEV.
> 
> Lonnie

Other option is to update runnix...

On Oct 20, 2009, at 11:17 PM, Philip Prindeville wrote:

> On 10/20/2009 09:04 PM, Lonnie Abelbeck wrote:
>> On Oct 20, 2009, at 7:32 PM, Philip Prindeville wrote:
>>
>>
>>> I built a test box with an Intel Pro/1000 card in it, and rebooted.
>>>
>>> Interestingly, runnix came up with eth0 as the e1000 driver... which
>>> was
>>> a little unexpected.
>>>
>>> I'll see if there's a work-around for this, but it would probably
>>> incur
>>> platform-specific fixes and having multiple versions.  Not sure I  
>>> want
>>> to go down that road.
>>>
>>> -Philip
>>>
>> Yes, I have seen exactly this as well.  In fact my main net5501
>> AstLinux box is configured as you describe.
>>
>> My simple solution was to comment out NDEV in /oldroot/cdrom/os/
>> default.conf
>>
>> #NDEV="eth0"
>>
>> problem solved.  In fact all my boxes have NDEV commented out
>> (disabling runnix network configuration) because in a cable modem
>> environment this can cause many problems.  Forcing a DHCP lease when
>> you don't want one or different MAC addresses between runnix and
>> astlinux essentially disabling the astlinux interface to the cable
>> modem.
>>
>> Lonnie
> That just turns it off, and I already knew how to do that.
>
> I'm worried about preserving the functionality for those who use it.
>
> -Philip

Now that /etc/udev/rules.d/70-persistent-net.rules can change the  
network interface ordering in astlinux, I see no practical way for  
runnix to automatically keep in sync with the astlinux network  
interface ordering.

Since runnix was derived from astlinux, the modprobe ordering kept  
things in sync, for the most part, for a couple of years.

I suggest here (and have for some time) for our purposes, enabling  
runnix NDEV by default causes more problems than it solves.  Should a  
user want to enable runnix NDEV, then it is their responsibility to  
match the the EXTIF interface with their runnix NDEV.

Lonnie

On 10/20/2009 09:04 PM, Lonnie Abelbeck wrote:
> On Oct 20, 2009, at 7:32 PM, Philip Prindeville wrote:
>
>   
>> I built a test box with an Intel Pro/1000 card in it, and rebooted.
>>
>> Interestingly, runnix came up with eth0 as the e1000 driver... which  
>> was
>> a little unexpected.
>>
>> I'll see if there's a work-around for this, but it would probably  
>> incur
>> platform-specific fixes and having multiple versions.  Not sure I want
>> to go down that road.
>>
>> -Philip
>>     
> Yes, I have seen exactly this as well.  In fact my main net5501  
> AstLinux box is configured as you describe.
>
> My simple solution was to comment out NDEV in /oldroot/cdrom/os/ 
> default.conf
>
> #NDEV="eth0"
>
> problem solved.  In fact all my boxes have NDEV commented out  
> (disabling runnix network configuration) because in a cable modem  
> environment this can cause many problems.  Forcing a DHCP lease when  
> you don't want one or different MAC addresses between runnix and  
> astlinux essentially disabling the astlinux interface to the cable  
> modem.
>
> Lonnie
>   


That just turns it off, and I already knew how to do that.

I'm worried about preserving the functionality for those who use it.

-Philip

On Oct 20, 2009, at 7:32 PM, Philip Prindeville wrote:

> I built a test box with an Intel Pro/1000 card in it, and rebooted.
>
> Interestingly, runnix came up with eth0 as the e1000 driver... which  
> was
> a little unexpected.
>
> I'll see if there's a work-around for this, but it would probably  
> incur
> platform-specific fixes and having multiple versions.  Not sure I want
> to go down that road.
>
> -Philip

Yes, I have seen exactly this as well.  In fact my main net5501  
AstLinux box is configured as you describe.

My simple solution was to comment out NDEV in /oldroot/cdrom/os/ 
default.conf

#NDEV="eth0"

problem solved.  In fact all my boxes have NDEV commented out  
(disabling runnix network configuration) because in a cable modem  
environment this can cause many problems.  Forcing a DHCP lease when  
you don't want one or different MAC addresses between runnix and  
astlinux essentially disabling the astlinux interface to the cable  
modem.

Lonnie

I built a test box with an Intel Pro/1000 card in it, and rebooted.

Interestingly, runnix came up with eth0 as the e1000 driver... which was
a little unexpected.

I'll see if there's a work-around for this, but it would probably incur
platform-specific fixes and having multiple versions.  Not sure I want
to go down that road.

-Philip

>  >I made a new startup script "/etc/init.d/ledcontrol" /
>>"/etc/runlevel/default/S99ledcontrol" which executes
>>"/stat/etc/rc.ledcontrol" where the configs are. If
>>"/mnt/kd/rc.ledcontrol" exists, it has priority over
>>"/stat/etc/rc.ledcontrol" (like sensors.conf).
>  >So you can configure the LEDs completely different if you like.

Hi all,
by advice of Lonnie, I simplified the patch a bit and stripped the 
new "ledcontrol" startup script and included the call to 
rc.ledcontrol directly into the existing errorled script.

Thanks Lonnie

Michael

Is this integrated into the SVN source for the Alix target or do I have to
apply the patch myself?  If not integrated then count my vote for adding it
to the mainline trunk (and 0.7 branch).
David



On Sun, Oct 18, 2009 at 5:03 PM, Michael Keuter <mk...@we...> wrote:

> Hi list,
>
> >I integrated some patches from the Voyage Linux project:
> >
> >leds_alix - LED control for Alix boards
> >ledtrig_netdev - LED control for the NIC (like on Soekris net5501)
> >ledtrig_morse - as the name says you can flash a LED with the Morse
> >Alphabet :-).
> >
> >I (pre)configured the LEDs for the Alix and WRAP boards with the
> >following settings:
> >
> >LED1 (left) = Normally Power LED, blinks now with a heartbeat will
> >go faster with more CPU load
> >LED2 (middle) = Error LED for booting and shutdown, plus shows IDE
> >disk activity after completely booted (like disk LED on Soekris)
> >LED3 (right) = Shows link status for eth0 NIC and flashes OFF on NIC
> >activity (like 5501)
> >
> >I made a new startup script "/etc/init.d/ledcontrol" /
> >"/etc/runlevel/default/S99ledcontrol" which executes
> >"/stat/etc/rc.ledcontrol" where the configs are. If
> >"/mnt/kd/rc.ledcontrol" exists, it has priority over
> >"/stat/etc/rc.ledcontrol" (like sensors.conf).
> >So you can configure the LEDs completely different if you like.
> >
> >More examples how to configure the LEDs for yourself you can find here:
> >
> http://svn.voyage.hk/repos/voyage/branches/voyage-live/0.6.0/config/chroot_local-includes/README
> >
> >Have fun
> >
> >Michael
>
> I forgot that - here is an example for morse code :-):
>
> echo morse > /sys/class/leds/alix:2/trigger
> echo "SOS" > /sys/class/leds/alix:2/message
>
> Michael
>
>
> ------------------------------------------------------------------------------
> Come build with us! The BlackBerry(R) Developer Conference in SF, CA
> is the only developer event you need to attend this year. Jumpstart your
> developing skills, take BlackBerry mobile applications to market and stay
> ahead of the curve. Join us from November 9 - 12, 2009. Register now!
> http://p.sf.net/sfu/devconference
> _______________________________________________
> Astlinux-devel mailing list
> Ast...@li...
> https://lists.sourceforge.net/lists/listinfo/astlinux-devel
>
> Donations to support AstLinux are graciously accepted via PayPal to
> pa...@kr....
>

Hi list,

>I integrated some patches from the Voyage Linux project:
>
>leds_alix - LED control for Alix boards
>ledtrig_netdev - LED control for the NIC (like on Soekris net5501)
>ledtrig_morse - as the name says you can flash a LED with the Morse 
>Alphabet :-).
>
>I (pre)configured the LEDs for the Alix and WRAP boards with the 
>following settings:
>
>LED1 (left) = Normally Power LED, blinks now with a heartbeat will 
>go faster with more CPU load
>LED2 (middle) = Error LED for booting and shutdown, plus shows IDE 
>disk activity after completely booted (like disk LED on Soekris)
>LED3 (right) = Shows link status for eth0 NIC and flashes OFF on NIC 
>activity (like 5501)
>
>I made a new startup script "/etc/init.d/ledcontrol" / 
>"/etc/runlevel/default/S99ledcontrol" which executes 
>"/stat/etc/rc.ledcontrol" where the configs are. If 
>"/mnt/kd/rc.ledcontrol" exists, it has priority over 
>"/stat/etc/rc.ledcontrol" (like sensors.conf).
>So you can configure the LEDs completely different if you like.
>
>More examples how to configure the LEDs for yourself you can find here:
>http://svn.voyage.hk/repos/voyage/branches/voyage-live/0.6.0/config/chroot_local-includes/README
>
>Have fun
>
>Michael

I forgot that - here is an example for morse code :-):

echo morse > /sys/class/leds/alix:2/trigger
echo "SOS" > /sys/class/leds/alix:2/message

Michael

Hi list,

I integrated some patches from the Voyage Linux project:

leds_alix - LED control for Alix boards
ledtrig_netdev - LED control for the NIC (like on Soekris net5501)
ledtrig_morse - as the name says you can flash a LED with the Morse 
Alphabet :-).

I (pre)configured the LEDs for the Alix and WRAP boards with the 
following settings:

LED1 (left) = Normally Power LED, blinks now with a heartbeat will go 
faster with more CPU load
LED2 (middle) = Error LED for booting and shutdown, plus shows IDE 
disk activity after completely booted (like disk LED on Soekris)
LED3 (right) = Shows link status for eth0 NIC and flashes OFF on NIC 
activity (like 5501)

I made a new startup script "/etc/init.d/ledcontrol" / 
"/etc/runlevel/default/S99ledcontrol" which executes 
"/stat/etc/rc.ledcontrol" where the configs are. If 
"/mnt/kd/rc.ledcontrol" exists, it has priority over 
"/stat/etc/rc.ledcontrol" (like sensors.conf).
So you can configure the LEDs completely different if you like.

More examples how to configure the LEDs for yourself you can find here:
http://svn.voyage.hk/repos/voyage/branches/voyage-live/0.6.0/config/chroot_local-includes/README

Have fun

Michael

PS: This patch includes also the changes for the WRAP board I sent 
yesterday. so do not apply the WRAP patch!