Trying to Setup 32-bit Server Using Trusty -- Bad Sources. Please Help

[mhumm2]

I was using 13.04 until Snowhog informed me that the repositories are not available. He also turned me on to 14.04 since it's still being supported, but I'm getting the same sources.list errors that I did before. All of the default (new install) sources are erroring out or being ignored. Please advise.

[Snowhog]

Post your /etc/apt/sources.list

[mhumm2]

not that easy to do since it's a new server install with no software able to be installed. I'm limited to terminal only. So how do I get the output over to my (this) primary computer so I can post it?

[Snowhog]

Okay. Here, on my 14.04 (Desktop, but it won't matter), these are my /etc/apt/sources.list contents:

deb http://us.archive.ubuntu.com/ubuntu/ trusty main restricted
deb http://us.archive.ubuntu.com/ubuntu/ trusty-updates main restricted
deb http://us.archive.ubuntu.com/ubuntu/ trusty universe
deb http://us.archive.ubuntu.com/ubuntu/ trusty-updates universe
deb http://us.archive.ubuntu.com/ubuntu/ trusty multiverse
deb http://us.archive.ubuntu.com/ubuntu/ trusty-updates multiverse
deb http://us.archive.ubuntu.com/ubuntu/ trusty-backports main restricted universe multiverse
deb http://security.ubuntu.com/ubuntu trusty-security main restricted
deb http://security.ubuntu.com/ubuntu trusty-security universe
deb http://security.ubuntu.com/ubuntu trusty-security multiverse
deb http://archive.canonical.com/ubuntu trusty partner
deb http://extras.ubuntu.com/ubuntu trusty main
deb http://us.archive.ubuntu.com/ubuntu/ trusty-proposed main multiverse restricted universe

You can compare what you have to this.

[mhumm2]

mine are exactly like yours are. I had already deleted the src entries and added the trusty-partner and trusty proposed entries. I'm also still getting

ERR next to the first group then "W: Failed to fetch" and "W: Some index files failed to download. They have been ignored, or old ones used instead."

Strange. I know it's getting out to the internet because I can watch it, during the update, download the files. I think I'm going to put the server back to dhcp mode instead of static ip and see what that does.

[mhumm2]

okay, i'm back to dhcp and, for some reason, it made a difference. Most of the sources are updating, but some still do not. Here's an example of the ones that don't which still looks like the URL path is incorrect. I didn't type out the entire URL because they're the same as yours:

Ign ~ trusty-security InRelease
Ign ~ trusty-updates
Ign ~ trusty InRelease

Hit ~ trusty-security Release.gpg

Then I get the same error message at the bottom about some sources being ignored. I don't get it. How can yours update and mine do not?

[life0riley]

Is this a server ISO for Trusty or is this an upgrade from raring?


Sent from my iPhone using Tapatalk

[claydoh]

okay, i'm back to dhcp and, for some reason, it made a difference. Most of the sources are updating, but some still do not. Here's an example of the ones that don't which still looks like the URL path is incorrect. I didn't type out the entire URL because they're the same as yours:

Ign ~ trusty-security InRelease
Ign ~ trusty-updates
Ign ~ trusty InRelease

Hit ~ trusty-security Release.gpg

Then I get the same error message at the bottom about some sources being ignored. I don't get it. How can yours update and mine do not?

I think this (Ign) means that the index file on the server matches the index file on your computer, so it does not have to re-download the package data for that particular repo. This is quite normal to see.

[millusions]

if dhcp made a difference than its pointing to DNS and maybe inaccurate settings of such when in static ip mode?
in such case youd do a: nslookup www.google.com to see which name server your ip is using.

[mhumm2]

Okay. First of all this is a new build of Trusty, not an upgrade from Raring.

DHCP does make a difference! nslookup worked with google. Then I set the server for a static ip address by configuring /etc/network/interfaces

#loopback network interface
auto lo
iface lo inet loopback

#primary network interface
auto eth0
iface eth0 inet static
address 192.168.1.100
netmask 255.255.255.0
network 192.168.1.0  
broadcast 192.168.1.255
gateway 192.168.0.1     #this is the same ip address I use to access and configure my router from a browser.

Something has to be incorrect here because when I reboot (sudo /etc/init.d/networking restart does not work) the system dmesg progresses until it gets to "Configuring virtual networking devices... Waiting for network configuration... Waiting up to 60 more seconds for network configuration... finally the system completes its boot up without full networking. Then nslookup to google does not work. Obviously, I'm not setting something up correctly in the interfaces file.

[millusions]

it looks ok,
the problem could be the router where some routers need static ips to be outside the dhcp range,

dns is at /etc/resolve.conf

i would just manually set it up without reboots first, is this like a non gui install?

oh. i see it now, your gateway is on a different subnet and netmask excludes it, i'd go ifconfig eth0 192.168.0.100 netmask 255.255.255.0 broadcast 192.168.0.255 from memory

if unsure, you can always use google dns;
as in sudo nano /etc/resolve.conf
nameserver 8.8.8.8
nameserver 8.8.4.4

[mhumm2]

Yes, non-GUI because it's 14.04 (32-bit) server version. I'll try the setting you suggest millusions and I'll report back. Thank you so much for weighing in.

[mhumm2]

The header in etc/resolv.conf states that any changes made to the file will be overwritten by resolvconf(8). I have no idea what that is about. Should I just put the Google nameservers in the file anyway?

[mhumm2]

okay, I went back to dhcp and took a look at the output of ifconfig. With the server set to dhcp, nslookup works! So I used the same ip numbers as ifconfig displayed to set up static again and NO JOY!!! ifconfig shows the same numbers that the server used when setup for dhcp so why won't they work for a static ip setup? I don't get it.

I think it would be better to close this thread and open a new one (with a link to this one) with a more descriptive title. Obviously the sources are not the problem -- getting out to the repositories from the server set up for static IP is the problem.

[life0riley]

I haven't had this issue. I set the static IP on the router. The router reserves the IP for a particular MAC address.


Sent from my iPhone using Tapatalk