On a Cubietruck -
# yum install policycoreutils-python --nogpgcheck
One of the configured repositories failed (Fedora 21 - armhfp), and yum doesn't have enough cached data to continue. At this point the only safe thing yum can do is fail. There are a few ways to work "fix" this:
I will fall back to 9/1 and test with that.
On Thu, Sep 4, 2014 at 3:33 PM, Robert Moskowitz rgm@htt-consult.com wrote:
On a Cubietruck -
# yum install policycoreutils-python --nogpgcheck
All packages should now be signed so you can drop the --nogpgcheck
One of the configured repositories failed (Fedora 21 - armhfp), and yum doesn't have enough cached data to continue. At this point the only safe thing yum can do is fail. There are a few ways to work "fix" this:
Is your date/time correct?
Peter
On 09/04/2014 11:15 AM, Peter Robinson wrote:
On Thu, Sep 4, 2014 at 3:33 PM, Robert Moskowitz rgm@htt-consult.com wrote:
On a Cubietruck -
# yum install policycoreutils-python --nogpgcheck
All packages should now be signed so you can drop the --nogpgcheck
good.
One of the configured repositories failed (Fedora 21 - armhfp), and yum doesn't have enough cached data to continue. At this point the only safe thing yum can do is fail. There are a few ways to work "fix" this:
Is your date/time correct?
It should have been via ntp. But I can't find where I put that SDcard to check it out. Too many SDcards sitting on my desk from all this testing. On a side note, I am 'inventing' an SDcard organizer for all the SDcards I have sitting around; the cubie's card reader will not allow space for a attaching a label.
So anyway, it looks like making a new SDcard and trying again.
On 09/04/2014 11:15 AM, Peter Robinson wrote:
On Thu, Sep 4, 2014 at 3:33 PM, Robert Moskowitz rgm@htt-consult.com wrote:
On a Cubietruck -
# yum install policycoreutils-python --nogpgcheck
All packages should now be signed so you can drop the --nogpgcheck
One of the configured repositories failed (Fedora 21 - armhfp), and yum doesn't have enough cached data to continue. At this point the only safe thing yum can do is fail. There are a few ways to work "fix" this:
Is your date/time correct?
I think it might be worst than date/time. I found the SDcard I was working with and booted up. No IP addresses on eth0, so no ntp, and why THAT yum message? Because date/time was essentially ZERO?
I never thought to check on the ethernet. I have only started working on my 1 Cubietruck, after getting 5 Cubieboard2 systems put into production. 4 running Redsleeve (with F19 uboot), and 1 F20. I have run F19 on this Cubietruck with no problems with ethernet. So something is broken on the Cubietruck uboot support.
Here is what I am seeing on ethernet on the serial console:
[ 36.360611] eth0: device MAC address 56:bb:b8:7a:b2:d6 [ 36.386336] No MAC Management Counters available [ 36.455808] No MAC Management Counters available [ 36.473714] IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready [ 40.418888] stmmaceth 1c50000.ethernet eth0: Link is Up - 10 0Mbps/Full - flow control off [ 40.433554] IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready
Last login: Thu Jan 1 00:00:49 on ttyS0 [root@localhost ~]# ip addr show 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 scope host lo valid_lft forever preferred_lft forever inet6 ::1/128 scope host valid_lft forever preferred_lft forever 2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000 link/ether 56:bb:b8:7a:b2:d6 brd ff:ff:ff:ff:ff:ff