On 26/11/12 21:29, Alexander Graf wrote:
On 26.11.2012, at 21:28, Ciaran Farrell wrote:
On 26/11/12 21:26, Alexander Graf wrote:
On 26.11.2012, at 21:23, Ciaran Farrell wrote:
On 26/11/12 21:21, Alexander Graf wrote:
On 26.11.2012, at 21:17, Ciaran Farrell wrote:
On 26/11/12 20:51, Bill Merriam wrote: > On Mon, 26 Nov 2012 16:15:33 -0300 > "Cristian Rodríguez" <crrodriguez@opensuse.org> wrote: > >> El 26/11/12 13:54, Cristian Rodríguez escribió: >>> El 26/11/12 13:28, Ciaran Farrell escribió: >>>> On 26/11/12 17:20, Alexander Graf wrote: >>>>> On 26.11.2012, at 17:20, Ciaran Farrell wrote: >>>>> >>>>>> Any idea what is causing this? >>> https://github.com/rabeeh/u-boot/commit/f826edd032af9082887bdd1a8f3e6653d219... >>> >>> >>> >> In short you need to have the latest u-boot from solidrun, dated Oct >> 3. >> >> http://download.solid-run.com/pub/solidrun/cubox/u-boot/2009.08_5.4.4_SR1/oc... >> > During the initial boot, the one where the initrd resizes the > partitions, it modifies u-boot environment variables and then tries to > save them. Something goes wrong. On subsequent boots u-boot finds a > bad checksum in the saved environment variables and uses default > values. That causes it to generate a random MAC address for the > ethernet adapter. Udev, finding a new MAC address, assigns it a new > device name. > > The immediate solution is to enter a "saveenv" command to u-boot. It > will then have a good checksum and won't create a new MAC address every > time. Then you have to fix your udev rules > in /etc/udev/rules.d/70-persistent-net.rules Could the resetenv in the uboot-setup script be causing this? I put it in there because it appeared to have helped me boot at all at first, but now I'm beginning to think it nukes the MAC address as well... I'm still wondering who even accepted that submit request :). But I guess it's up to you to fix it now - I don't have a device on me right now and also no time to look at the Cubox :)
Quite frankly, I'd assume the easiest would be to revert to the request you did last time and base on the generic boot script. Maybe just bumping the ramdisk load address up already gets you rolling. What would prevent me from taking your version (it boots into yast2-firstboot, by the way - I'm still configuring there, so I'll still need to see what happens after the first reboot), removing the resetenv and sr'ing? That would work too, but the former version was tested on a lot of boards and known to work, while the "short script" that's there now is not. So chances are higher more things break again later.
However, I consider contrib machines responsibilities of the respective contrib maintainers, so in this case that would be Max's call. Ok, understood. I'll try to mess around based on the original version and see what happens. I still haven't updated uboot on my CuBox - I'll hold off doing that for awhile to see if we can get the original generic code working. Another benefit of the original code was that it was almost identical to the one we use for generic platforms in Factory and 12.2. That means integration into the main project becomes easier later on :). I created sr#142958 to revert to revision 11. If somebody with the appropriate permission could check and approve that, it would be great.
Ciaran
Alex
-- Ciaran Farrell, Attorney at Law SUSE Linux Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, DE GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 16746 (AG Nürnberg) -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org