Re: [Vyatta-users] Compaq DL360 G1 - cpqarray
Ah! Success, it worked! The drives are getting detected as expected on boot and I can fdisk them and such. The problem is now the install! When I am promted ton what drive to install the software on, it does not contain any thing... I found the following drives on your system: Install the image on? []: I tried to manualy set the drive /dev/ida/c0d0 at the prompt, but it looks like it just hangs. Any ideas? On Jan 13, 2008 1:52 PM, Max [EMAIL PROTECTED] wrote: Nope, still no dice :( It boots like it is supose to this time though. Any other recomendations? On Nov 29, 2007 9:15 PM, Robert Bays [EMAIL PROTECTED] wrote: It looks like it can't find or open the initramfs. In the initrd creation step try this instead. find . | cpio --quiet --dereference -o -H newc | gzip -9 ../tmpiso/boot/initrd.img Cheers, Robert. Max wrote: Well I followed your directions step by step and didn't have any problems until attempting to boot the CD. Check out the attached screen shot.. What do you recommend checking out? On Nov 27, 2007 5:39 PM, Max [EMAIL PROTECTED] wrote: That was more less what i was going to do. You saved me a good deal of work trying to figure out the right way to recreate the ISO. If this works out, I owe you a pint! :D On Nov 27, 2007 5:07 PM, Robert Bays [EMAIL PROTECTED] wrote: Max, To avoid building from scratch you could just edit the initrd. Try something like the following... 1. mount the iso to a loop device and copy the contents to a tmpdir mount -o loop ./livecd-vc3.iso ./dir cp -R ./dir/* ./tmpiso/ umount ./dir 2. extract the initrd.img mkdir tmpinitrd cd tmpinitrd gzip -cd ../tmpiso/boot/initrd.img.img | cpio -imd --quiet 3. remove the module rm ./lib/modules/2.6.20/kernel/drivers/scsi/sym53c8xx_2/sym53c8xx.ko 4. zip up the initrd and copy it into the temporary iso dir chmod -R 755 ../tmpiso rm ../tmpiso/boot/initrd.img find . | cpio --quiet -c -o | gzip -9 -n ../tmpiso/boot/initrd.img 5. create the iso cd ../tmpiso mkisofs -J -r -o ../livecd.iso -b boot/isolinux/isolinux.bin -c boot/isolinux/boot.cat -no-emul-boot -boot-load-size 4 -boot-info-table /home/rbays/tmpiso/ Should work... Cheers, Robert. Max wrote: No I have not had any time to fool with it these past few days... but from what I can tell the sym53c8xx module is loaded before the needed cpqarray module and thats what is causing the failure. I have tried unloading the modules and reloading cpqarray but don't seem to have any luck. My guess is the SCSI controller needs to be reset or what have you. I have not had any luck disabling the sym53c8xx module from the boot loader so I think the next step is to build a live CD from scratch. I've never built a live CD so its going to be a learning thing for me for sure. Maybe you will have better luck... Let me know if you find anything :) On Nov 26, 2007 11:46 PM, Cory B. Goleman [EMAIL PROTECTED] wrote: I'm having the same problem, trying to install Vyatta 3.0 to a DL 360 G1 with a RAID 1 configuration, have you made any progress on this? Regards Cory- ___ Vyatta-users mailing list Vyatta-users@mailman.vyatta.com http://mailman.vyatta.com/mailman/listinfo/vyatta-users ___ Vyatta-users mailing list Vyatta-users@mailman.vyatta.com http://mailman.vyatta.com/mailman/listinfo/vyatta-users ___ Vyatta-users mailing list Vyatta-users@mailman.vyatta.com http://mailman.vyatta.com/mailman/listinfo/vyatta-users
Re: [Vyatta-users] Compaq DL360 G1 - cpqarray
Well nevermind I figured it out after looking at the install-system script. I provided ida/c0d0 instead of /dev/ida/c0d0 Wish me luck :) On Jan 13, 2008 1:57 PM, Max [EMAIL PROTECTED] wrote: Ah! Success, it worked! The drives are getting detected as expected on boot and I can fdisk them and such. The problem is now the install! When I am promted ton what drive to install the software on, it does not contain any thing... I found the following drives on your system: Install the image on? []: I tried to manualy set the drive /dev/ida/c0d0 at the prompt, but it looks like it just hangs. Any ideas? On Jan 13, 2008 1:52 PM, Max [EMAIL PROTECTED] wrote: Nope, still no dice :( It boots like it is supose to this time though. Any other recomendations? On Nov 29, 2007 9:15 PM, Robert Bays [EMAIL PROTECTED] wrote: It looks like it can't find or open the initramfs. In the initrd creation step try this instead. find . | cpio --quiet --dereference -o -H newc | gzip -9 ../tmpiso/boot/initrd.img Cheers, Robert. Max wrote: Well I followed your directions step by step and didn't have any problems until attempting to boot the CD. Check out the attached screen shot.. What do you recommend checking out? On Nov 27, 2007 5:39 PM, Max [EMAIL PROTECTED] wrote: That was more less what i was going to do. You saved me a good deal of work trying to figure out the right way to recreate the ISO. If this works out, I owe you a pint! :D On Nov 27, 2007 5:07 PM, Robert Bays [EMAIL PROTECTED] wrote: Max, To avoid building from scratch you could just edit the initrd. Try something like the following... 1. mount the iso to a loop device and copy the contents to a tmpdir mount -o loop ./livecd-vc3.iso ./dir cp -R ./dir/* ./tmpiso/ umount ./dir 2. extract the initrd.img mkdir tmpinitrd cd tmpinitrd gzip -cd ../tmpiso/boot/initrd.img.img | cpio -imd --quiet 3. remove the module rm ./lib/modules/2.6.20/kernel/drivers/scsi/sym53c8xx_2/sym53c8xx.ko 4. zip up the initrd and copy it into the temporary iso dir chmod -R 755 ../tmpiso rm ../tmpiso/boot/initrd.img find . | cpio --quiet -c -o | gzip -9 -n ../tmpiso/boot/initrd.img 5. create the iso cd ../tmpiso mkisofs -J -r -o ../livecd.iso -b boot/isolinux/isolinux.bin -c boot/isolinux/boot.cat -no-emul-boot -boot-load-size 4 -boot-info-table /home/rbays/tmpiso/ Should work... Cheers, Robert. Max wrote: No I have not had any time to fool with it these past few days... but from what I can tell the sym53c8xx module is loaded before the needed cpqarray module and thats what is causing the failure. I have tried unloading the modules and reloading cpqarray but don't seem to have any luck. My guess is the SCSI controller needs to be reset or what have you. I have not had any luck disabling the sym53c8xx module from the boot loader so I think the next step is to build a live CD from scratch. I've never built a live CD so its going to be a learning thing for me for sure. Maybe you will have better luck... Let me know if you find anything :) On Nov 26, 2007 11:46 PM, Cory B. Goleman [EMAIL PROTECTED] wrote: I'm having the same problem, trying to install Vyatta 3.0 to a DL 360 G1 with a RAID 1 configuration, have you made any progress on this? Regards Cory- ___ Vyatta-users mailing list Vyatta-users@mailman.vyatta.com http://mailman.vyatta.com/mailman/listinfo/vyatta-users ___ Vyatta-users mailing list Vyatta-users@mailman.vyatta.com http://mailman.vyatta.com/mailman/listinfo/vyatta-users ___ Vyatta-users mailing list Vyatta-users@mailman.vyatta.com http://mailman.vyatta.com/mailman/listinfo/vyatta-users
[Vyatta-users] BGP Policy Generic Route Distribution
I have tested the Vyatta once again being an inch away from totally replacing my Cisco core router. BGP connection and route policy are working, but with a problem. It seems that the BGP routing table is redistributing my exact routes as specified in the policy configuration. = set policy policy-statement NAME term 1 from protocol connected set policy policy-statement NAME term 1 then action accept set policy policy-statement NAME term 2 from protocol static set policy policy-statement NAME term 2 then action accept = My router's function is to distribute routes to the 'world'. I am not wanting to redistribute my exact connected or static routes, but a generic class C distribution of all my owned subnets. Is it possible to modify what is being sent in the BGP routing table with out manually modifying all my connected and static routes? My upstream provider only allows X.X.X.X/24 BGP advertisements. Any help on this situation is appreciated and the world will be with one less Cisco router. Thanks, Shane McKinley Habersham EMC ___ Vyatta-users mailing list Vyatta-users@mailman.vyatta.com http://mailman.vyatta.com/mailman/listinfo/vyatta-users
[Vyatta-users] One VRRP group per interface
I seem to have ran into quite a snag... 102 Command failed Only one VRRP session is allowed per physical interface. After reading through the config guide I found this The implementation is currently restricted to one VRRP group per interface, regardless of whether the group is defined at the physical interface level or the vif level. This is going to keep us from using Vyatta in our environment. We are currently running a few openbsd/pf/pfsync/carp machines and they give us the redundancy required. Are there any plans to change this in the future? If so, any idea how many versions out? Vyatta looks fantastic, but with out the ability to have redundant routers I'm afraid its not going to work for us :( I am thinking perhaps bgp could be used, but I have not covered any of that ground yet. Thanks in advance guys :) ___ Vyatta-users mailing list Vyatta-users@mailman.vyatta.com http://mailman.vyatta.com/mailman/listinfo/vyatta-users
Re: [Vyatta-users] DHCP pool questions
Hi Mike,
As far as to why the DHCP server leases out IPs from the end of the block
rather than from the beginning, I'm not sure myself. I just signed up for the
ISC DHCP server mailing lists at
http://www.isc.org/index.pl?/sw/dhcp/dhcp-lists.php and plan to ask the people
on there this question as well.
If you added a second dhcp pool for eth2, but it did not appear in
'/opt/vyatta/config/dhcpd.conf', and you stil have the config and the
'dhcpd.conf' after that commit, then please include these files with your
message.
Thanks,
Marat
- Original Message -
From: silvertip257
To: Marat Nepomnyashy ; vyatta-users@mailman.vyatta.com
Sent: Sunday, January 13, 2008 6:54 PM
Subject: Re: [Vyatta-users] DHCP pool questions
Why cannot I take addresses out of the beginning of the block like I'd rather
it do? How can I (without rewriting/modifying source code)? That would really
stink to have to statically assign everything to make it the way (that it makes
sense). It's great and all that it actually does assign an address and ' works
', but why not start at the beginning?
From what Marat wrote, I understand that you've seen that behavior before -
confirmed. Now, can it be changed?
I won't try to start any wars here, but that would unfortunately be one
reason I would not want to use Vyatta. Well that and the WAN dhclient that's
in progress.
I could have sworn (oh and I did commit it) that I added a config for a
second dhcp pool (separate) for eth2, but voila it's gone when I check
dhcpd.conf...
Thanks,
Mike
On Jan 13, 2008 8:37 PM, Marat Nepomnyashy [EMAIL PROTECTED] wrote:
Hi Mike,
As far as I know, it is normal for the ISC DHCP server that the Vyatta
router is using to lease out addresses starting from the last address of the
DHCP lease block, I've seen this before. Not quite sure myself why ISC does it
this way, maybe there is an assumption that the IPs at the end of the block are
less likely to be already taken...
When you write I have discovered that various parts have been separated
from the main config, what do you mean?
The DHCP server configuration file is '/opt/vyatta/etc/dhcpd.conf', not
'/opt/vyatta/etc/dhcp.conf'. The configuration for eth2 should not show up
there if you did not configure any DHCP leases for any of the subnets to which
your the interface is connected.
If you have additional questions, please send us snippets of your router
configuration under hierarchies 'interfaces ethernet' and 'service
dhcp-server'. Please also send the contents of '/opt/vyatta/etc/dhcpd.conf'.
Thanks,
Marat
- Original Message -
From: silvertip257
To: vyatta-users@mailman.vyatta.com
Sent: Saturday, January 12, 2008 4:36 PM
Subject: [Vyatta-users] DHCP pool questions
I've set up a complete vyatta system a few times, even with two
versions (2.2 and 3.0).
I'm currently working with 3.0 and I'm getting the same behavior as the
last time.
I setup a DHCP server on eth1, but when it hands out addresses, it
always gives out the last address in the block (in this case 192.168.0.60
consistently).
When finding the configuration, I have discovered that various parts
have been separated from the main config - I don't know if it was that way in
previous versions, but thought I'd mention it.
Also, my DHCP server for eth2 does not show up in
/opt/vyatta/etc/dhcp.conf ;; that's another issue that I'll have to solve after
this one.
My config for the DHCP server:
shared-network Subnet1 {
subnet 192.168.0.32 netmask 255.255.255.224 {
not authoritative;
default-lease-time 86400;
max-lease-time 86400;
range 192.168.0.34 192.168.0.60;
}
Thanks,
Mike
--
// SilverTip257 //
==
~
· ·
/V\
// \\
/( )\
^`~´^
___
Vyatta-users mailing list
Vyatta-users@mailman.vyatta.com
http://mailman.vyatta.com/mailman/listinfo/vyatta-users
--
// SilverTip257 //
==
~
· ·
/V\
// \\
/( )\
^`~´^
--
// SilverTip257 //
==
~
· ·
/V\
// \\
/( )\
^`~´^ ___
Vyatta-users mailing list
Vyatta-users@mailman.vyatta.com
http://mailman.vyatta.com/mailman/listinfo/vyatta-users
Re: [Vyatta-users] DHCP pool questions
* Well that and the WAN dhclient that's in progress.
Dhcp client has already been committed to the development branch which
means itll be available in the next release (glendale) assuming the
testing goes well.
stig
_
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of silvertip257
Sent: Sunday, January 13, 2008 6:55 PM
To: Marat Nepomnyashy; vyatta-users@mailman.vyatta.com
Subject: Re: [Vyatta-users] DHCP pool questions
Why cannot I take addresses out of the beginning of the block like I'd
rather it do? How can I (without rewriting/modifying source code)? That
would really stink to have to statically assign everything to make it the
way (that it makes sense). It's great and all that it actually does
assign an address and ' works ', but why not start at the beginning?
From what Marat wrote, I understand that you've seen that behavior before
- confirmed. Now, can it be changed?
I won't try to start any wars here, but that would unfortunately be one
reason I would not want to use Vyatta. Well that and the WAN dhclient
that's in progress.
I could have sworn (oh and I did commit it) that I added a config for a
second dhcp pool (separate) for eth2, but voila it's gone when I check
dhcpd.conf...
Thanks,
Mike
On Jan 13, 2008 8:37 PM, Marat Nepomnyashy [EMAIL PROTECTED] wrote:
Hi Mike,
As far as I know, it is normal for the ISC DHCP server that the Vyatta
router is using to lease out addresses starting from the last address of
the DHCP lease block, I've seen this before. Not quite sure myself why
ISC does it this way, maybe there is an assumption that the IPs at the end
of the block are less likely to be already taken...
When you write I have discovered that various parts have been separated
from the main config, what do you mean?
The DHCP server configuration file is '/opt/vyatta/etc/dhcpd.conf', not
'/opt/vyatta/etc/dhcp.conf'. The configuration for eth2 should not show
up there if you did not configure any DHCP leases for any of the subnets
to which your the interface is connected.
If you have additional questions, please send us snippets of your router
configuration under hierarchies 'interfaces ethernet' and 'service
dhcp-server'. Please also send the contents of
'/opt/vyatta/etc/dhcpd.conf'.
Thanks,
Marat
- Original Message -
From: silvertip257 mailto:[EMAIL PROTECTED]
To: vyatta-users@mailman.vyatta.com
Sent: Saturday, January 12, 2008 4:36 PM
Subject: [Vyatta-users] DHCP pool questions
I've set up a complete vyatta system a few times, even with two versions
(2.2 and 3.0).
I'm currently working with 3.0 and I'm getting the same behavior as the
last time.
I setup a DHCP server on eth1, but when it hands out addresses, it always
gives out the last address in the block (in this case 192.168.0.60
consistently).
When finding the configuration, I have discovered that various parts have
been separated from the main config - I don't know if it was that way in
previous versions, but thought I'd mention it.
Also, my DHCP server for eth2 does not show up in
/opt/vyatta/etc/dhcp.conf ;; that's another issue that I'll have to solve
after this one.
My config for the DHCP server:
shared-network Subnet1 {
subnet 192.168.0.32 netmask 255.255.255.224 {
not authoritative;
default-lease-time 86400;
max-lease-time 86400;
range 192.168.0.34 192.168.0.60;
}
Thanks,
Mike
--
// SilverTip257 //
==
~
· ·
/V\
// \\
/( )\
^`~´^
_
___
Vyatta-users mailing list
Vyatta-users@mailman.vyatta.com
http://mailman.vyatta.com/mailman/listinfo/vyatta-users
http://mailman.vyatta.com/mailman/listinfo/vyatta-users
--
// SilverTip257 //
==
~
· ·
/V\
// \\
/( )\
^`~´^
--
// SilverTip257 //
==
~
· ·
/V\
// \\
/( )\
^`~´^
___
Vyatta-users mailing list
Vyatta-users@mailman.vyatta.com
http://mailman.vyatta.com/mailman/listinfo/vyatta-users
