new kernel 3.2 does not boot on the dockstar

[kmihelich]

Installing a new kernel that replaces a previous version also replaces all of the files that the old version provided, which includes modules.

I'm working on trying to narrow down the kmod failure on v5, v7h doesn't experience these issues. Otherwise, I have the kernel fixed for booting on Dockstar. When 3.2.1-2 goes into the repo, people shouldn't have problems with it.

[davygravy]

@ kmihelich : could you please describe what the nature of the problem was, and how you solved it? I'm still trying to get 3.2 to fully boot on my Dockstar - but - I'm using Debian. Certainly there are some differences... your packaging system is different, to be sure. But maybe you could supply your .config ? Perhaps spell out how you got around the compression problems?

tia, it would be greatly appreciated,

davy

[WarheadsSE]

gzip

lzma

bang.

[kmihelich]

Fundamentally, the packaging systems actually do the same exact things, just that Arch's isn't as convoluted.

Under the general settings in the config, you can switch the kernel from gzip compression (the default) to LZMA. That worked, I'm still having issues with GoFlex Net. Seems fixing one thing for Dockstar generally breaks another on GFN. This is just on part of a possible solution, not the solution.

Either way, the situation is isolated to Kirkwood. The v7 platforms don't have a problem.

[davygravy]

Any chance this some interaction w/ the custom uBoot many of us use?

----

Also, thanks, I looked at my config ... and to my surprise ... I already have LZMA selected ... Debian's stock kernel 3.1.8 (and my 3.2/3 efforts) have it set like this: $this->bbcode_second_pass_code('', '# General setup
#
CONFIG_EXPERIMENTAL=y
CONFIG_BROKEN_ON_SMP=y
CONFIG_INIT_ENV_ARG_LIMIT=32
CONFIG_CROSS_COMPILE=""
CONFIG_LOCALVERSION=""
# CONFIG_LOCALVERSION_AUTO is not set
CONFIG_HAVE_KERNEL_GZIP=y
CONFIG_HAVE_KERNEL_LZMA=y
CONFIG_HAVE_KERNEL_LZO=y
# CONFIG_KERNEL_GZIP is not set
CONFIG_KERNEL_LZMA=y
# CONFIG_KERNEL_LZO is not set')

Strange...

[kmihelich]

At this point in time I don't think it's U-Boot. Initially I suspected that because the Dockstar uses a somewhat aging version, but 1.1.4 on PPv4 isn't exactly new, and even after putting UBIT on the Dockstar things didn't change. I'm really not sure where this whole problem is starting from to be honest, but it's in the kernel. I've done about a hundred recompiles on 3.2, and even have a v5 chroot set up on my Pandaboard so that the kernels can build even faster.

Some interesting config notes.. pulling our 3.1.7 and using that as a base with no intentional changes will boot on the Dockstar and PPv4, but not GoFlex Net. Using the 3.2.1 config where I enabled more of the advanced embedded options boots on GFN and PPv4, but not Dockstar. Curiously, everything seems to work on PPv4, it's the back and forth with Dockstar/GFN that's killing me.

[davygravy]

I had this idea of putting my arcNumber back to the default ... rather than having it set as a Dockstar ... I remember reading a thread over at OpenWRT about someone commenting that a certain image wouldn't boot on his Dockstar when arcNumber was set to the Dockstar's # (2998, or something such)... but if it was set back at the default # , it booted it fine.


But time for some shut-eye now.

thanks for the tips,

davy

[kmihelich]

For the dockstar you can wobble back to sheeva at the expense of bad LED GPIOs, but it doesn't make a difference, already tried that

I don't track OpenWRT, but Dockstar has been mainline for a good minute now. There isn't really an excuse for it not to be booting with the correct ID pre-3.2. Myself and the devs here are a big fan of separating out platforms, assigning the IDs, and getting proper support programmed in instead of hacking around the issue. That's also why I'm still searching for the fundamental problem with 3.2 instead of pushing out something that works "somehow" or "amazingly." That doesn't fly with me.

U-Boot is still in the back of my mind though with the PPv4's seeming invincibility.

[cyberic]

kmihelich, wouldn't it possible to do a git bissect between 3.1.7 and 3.2 ?
Do you think that compiling the kernel in an ARM qemu would be faster?

[FullHD]

Well, in any case, I'm out of luck. I did a "pacman -Syu" today on my pink Pogoplug and now it won't boot anymore.
If I unplug the USB hard disk I can boot into the Pogoplug's stock Linux and replug the USB hard disk.
But rolling back to older packages is impossible because I can't extract the tar.xz files with the tar version that comes with the Pogoplug's version of busybox (1.7.0).

Any ideas (other than reinstalling everything from scratch)?

Thanks!