Welcome! Log In Create A New Profile

Advanced

Follow up: A fresh attempt at 4.12.1 install on another pogo-plug v

Posted by craigcoffman 
Follow up: A fresh attempt at 4.12.1 install on another pogo-plug v
September 27, 2017 10:01AM
OK. Took another pogo-plug that runs 3.14 currently as the victim.

Output of fw_printenv on that box (printed while booted on 3.14 fs & kernel)

root@whiterabbit:~# fw_printenv
baudrate=115200
bootcmd_mmc=run mmc_init; run set_bootargs_mmc; run mmc_boot
bootcmd_sata=run sata_init; run set_bootargs_sata; run sata_boot;
bootcmd_usb=run usb_init; run set_bootargs_usb; run usb_boot;
bootdelay=10
console=ttyS0,115200
device=0:1
ethact=egiga0
led_error=orange blinking
led_exit=green off
led_init=green blinking
mainlineLinux=yes
mmc_boot=mw 0x800000 0 1; run mmc_load_uimage; if run mmc_load_uinitrd; then bootm 0x800000 0x1100000; else bootm 0x800000; fi
mmc_init=mmc rescan
mmc_load_uimage=ext2load mmc $device 0x800000 /boot/uImage
mmc_load_uinitrd=ext2load mmc $device 0x1100000 /boot/uInitrd
mmc_root=/dev/mmcblk0p1
mtdids=nand0=orion_nand
partition=nand0,2
preboot_nc=run if_netconsole start_netconsole
rootdelay=10
rootfstype=ext3
sata_boot=mw 0x800000 0 1; run sata_load_uimage; if run sata_load_uinitrd; then bootm 0x800000 0x1100000; else bootm 0x800000; fi
sata_init=ide reset
sata_load_uimage=ext2load ide $device 0x800000 /boot/uImage
sata_load_uinitrd=ext2load ide $device 0x1100000 /boot/uInitrd
sata_root=/dev/sda1
set_bootargs_mmc=setenv bootargs console=$console root=$mmc_root rootdelay=$rootdelay rootfstype=$rootfstype $mtdparts
set_bootargs_sata=setenv bootargs console=$console root=$sata_root rootdelay=$rootdelay rootfstype=$rootfstype $mtdparts
set_bootargs_usb=setenv bootargs console=$console root=$usb_root rootdelay=$rootdelay rootfstype=$rootfstype $mtdparts
stderr=serial
stdin=serial
stdout=serial
usb_boot=mw 0x800000 0 1; run usb_load_uimage; if run usb_load_uinitrd; then bootm 0x800000 0x1100000; else bootm 0x800000; fi
usb_init=usb start
usb_load_uimage=ext2load usb $device 0x800000 /boot/uImage
usb_load_uinitrd=ext2load usb $device 0x1100000 /boot/uInitrd
usb_root=/dev/sda1
ethaddr=00:25:31:05:66:bd
usb_rootfstype=ext3
mtdparts=mtdparts=orion_nand:2M(u-boot),3M(uImage),3M(uImage2),8M(failsafe),112M(root)
serverip=192.168.2.12
ipaddr=192.168.2.6
if_netconsole=ping $serverip
start_netconsole=setenv ncip $serverip; setenv bootdelay 10; setenv stdin nc; setenv stdout nc; setenv stderr nc; version;
preboot=run if_netconsole start_netconsole
arcNumber=3960
bootcmd=run bootcmd_mmc; run bootcmd_usb; run bootcmd_sata; run bootcmd_pogo; reset
bootcmd_pogo=if ubi part root 2048 && ubifsmount ubi:rootfs && ubifsload 0x800000 uboot.mtd0.dockstar.original.kwb ; then go 0x800200; fi
machid=F78

Newly created 4.12.1 file system particulars:
root@sirguy:/# lsblk -f /dev/sdc1
NAME FSTYPE LABEL  UUID                                 MOUNTPOINT
sdc1 ext3   rootfs cb9fd5ca-830e-41a8-8de1-ae0bf8d67735 /media/craig/rootfs
root@sirguy:/# lsblk -f -o label  /dev/sdc1
LABEL
rootfs

it's fstab:

# /etc/fstab: static file system information.
#
# <file system> <mount point>   <type>  <options>       <dump>  <pass>
LABEL=rootfs    /               ext3    noatime,errors=remount-ro 0 1
tmpfs          /tmp            tmpfs   defaults          0       0


list of /boot contents:

drwxr-xr-x 21 root root    4096 Feb 16  2015 ..
drwxr-xr-x  2 root root    4096 Jul 15 17:14 dts
-rw-r--r--  1 root root  153501 Jul 15 22:21 config-4.12.1-kirkwood-tld-1
-rwxr-xr-x  1 root root 3821528 Jul 15 23:42 zImage-4.12.1-kirkwood-tld-1
-rw-------  1 root root 3821528 Jul 16 02:43 vmlinuz-4.12.1-kirkwood-tld-1
-rw-------  1 root root 2504031 Jul 16 02:43 System.map-4.12.1-kirkwood-tld-1
-rw-r--r--  1 root root 8435004 Jul 16 03:06 linux-headers-4.12.1-kirkwood-tld-1_1.0_armel.deb
-rw-r--r--  1 root root 3821592 Jul 20 03:11 uImage.stock.4.12.1
-rw-r--r--  1 root root 7245632 Jul 23 19:15 initrd.img-4.12.1-kirkwood-tld-1
-rw-r--r--  1 root root 7245696 Jul 23 19:18 uInitrd.stock.4.12.1
-rwxr-xr-x  1 root root 3831812 Sep 27 09:13 zImage.fdt
-rw-r--r--  1 root root 3831876 Sep 27 09:14 uImage.4.12.1
-rw-r--r--  1 root root 7245696 Sep 27 09:15 uInitrd.4.12.1
-rw-r--r--  1 root root 3831876 Sep 27 09:15 uImage
drwxr-xr-x  3 root root    4096 Sep 27 09:15 .
-rw-r--r--  1 root root 7245696 Sep 27 09:15 uInitrd

boot output as received by netconsole:

U-Boot 2014.07-tld-1 (Jul 18 2014 - 00:59:45)
Pogoplug V4
gcc (Debian 4.6.3-14) 4.6.3
GNU ld (GNU Binutils for Debian) 2.22
Hit any key to stop autoboot:  0 

MMC rescan: current device # 0 initialized OK
3831876 bytes read in 1435 ms (2.5 MiB/s)
7245696 bytes read in 1969 ms (3.5 MiB/s)
## Booting kernel from Legacy Image at 00800000 ...
   Image Name:   Linux-4.12.1-kirkwood-tld-1
   Created:      2017-09-27  14:13:55 UTC
   Image Type:   ARM Linux Kernel Image (uncompressed)
   Data Size:    3831812 Bytes = 3.7 MiB
   Load Address: 00008000
   Entry Point:  00008000
   Verifying Checksum ... OK
## Loading init Ramdisk from Legacy Image at 01100000 ...
   Image Name:   initramfs-4.12.1-kirkwood-tld-1
   Created:      2017-09-27  14:14:53 UTC
   Image Type:   ARM Linux RAMDisk Image (gzip compressed)
   Data Size:    7245632 Bytes = 6.9 MiB
   Load Address: 00000000
   Entry Point:  00000000
   Verifying Checksum ... OK


Starting kernel ...


behavior as with other attempts. hangs there. light remains orange (not blinking)

EDIT: pasted in wrong uboot boot output at first.



Edited 1 time(s). Last edit at 09/27/2017 10:05AM by craigcoffman.
Re: Follow up: A fresh attempt at 4.12.1 install on another pogo-plug v
September 27, 2017 08:02PM
craigcoffman,

Problem was nicely captured in this post!

Everything looks OK so far until here.

list of /boot contents:

drwxr-xr-x 21 root root    4096 Feb 16  2015 ..
drwxr-xr-x  2 root root    4096 Jul 15 17:14 dts
-rw-r--r--  1 root root  153501 Jul 15 22:21 config-4.12.1-kirkwood-tld-1
-rwxr-xr-x  1 root root 3821528 Jul 15 23:42 zImage-4.12.1-kirkwood-tld-1
-rw-------  1 root root 3821528 Jul 16 02:43 vmlinuz-4.12.1-kirkwood-tld-1
-rw-------  1 root root 2504031 Jul 16 02:43 System.map-4.12.1-kirkwood-tld-1
-rw-r--r--  1 root root 8435004 Jul 16 03:06 linux-headers-4.12.1-kirkwood-tld-1_1.0_armel.deb
-rw-r--r--  1 root root 3821592 Jul 20 03:11 uImage.stock.4.12.1
-rw-r--r--  1 root root 7245632 Jul 23 19:15 initrd.img-4.12.1-kirkwood-tld-1
-rw-r--r--  1 root root 7245696 Jul 23 19:18 uInitrd.stock.4.12.1
-rwxr-xr-x  1 root root 3831812 Sep 27 09:13 zImage.fdt
-rw-r--r--  1 root root 3831876 Sep 27 09:14 uImage.4.12.1
-rw-r--r--  1 root root 7245696 Sep 27 09:15 uInitrd.4.12.1
-rw-r--r--  1 root root 3831876 Sep 27 09:15 uImage
drwxr-xr-x  3 root root    4096 Sep 27 09:15 .
-rw-r--r--  1 root root 7245696 Sep 27 09:15 uInitrd

I did not see uImage.orig in here. Is uImage.stock.4.12.1 the original uImage?

The zImage.fdt indicates that you have appended DTB to zImage to produce uImage. But why do these pairs have different timestamp? are they identical?

uImage.4.12.1
uImage

uInitrd.4.12.1
uInitrd


Quote

>
> Starting kernel ...
>
> behavior as with other attempts. hangs there.
> light remains orange (not blinking)
>

This is good observation. It means the rootfs mounting has not happened yet. Solid Orange LED means the kernel has stopped booting before the rootfs mounting was attempted. So the suspect is the kernel files.

Usually, we would see the exact reason in serial console. But we can't see it. So it is going to be educated guesses whether the kernel files are good or bad.

-----

Could you describe how you install the kernel 4.12 and append DTB to uImage? were you in the box while kernel 4.4 is running? .... or post that snipet of log of the session here?

-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)
Re: Follow up: A fresh attempt at 4.12.1 install on another pogo-plug v
September 28, 2017 07:58AM
Hi bodhi, thanks for the response.

Quote

I did not see uImage.orig in here. Is uImage.stock.4.12.1 the original uImage?

correct. I decided *.orig was not a super-helpful name & that things could get confusing
without just sticking with using the version in the name. Especially once I start trying to "upgrade" kernels.

Quote

The zImage.fdt indicates that you have appended DTB to zImage to produce uImage. but why do these pairs have different timestamp? are they identical?

correct re: production of uImage. Using the concatenated dtb file method since I wanted to make no changes to uboot. (hate to brick one of these.. I only paid $9 each & don't figure they are worth the time it would take to make up the serial cable).

I named the output of both mkimage commands to uImage.4.12.1 & uInitrd.4.12.1 respectively, again to keep things straight. I then simply copied the files to uImage & uInitrd. Slight delay is from making the ramdisk after the kernel image. BUT, notice uImage.4.12.1 & uImage are the same size, same for the uInitrd.4.12.1 & uInitrd.

Quote

>Could you describe how you install the kernel 4.12 and append DTB to uImage?

This was a fresh un-tarring of the 4.12.1 rootfs kit... onto a blank SD card. (sorry I didn't make that more clear) nothing else on that card. Trying to eliminate variables you know.
Also, to re-iterate, this was on a different pogoplug device than the one where I had erroneously entered (& subsequently removed) the fw env variables for booting without the concatenated dts file. Again, just to eliminate variables.

To make the images, I simply followed the directions:

cp -a zImage-4.12.1-kirkwood-tld-1 zImage.fdt

cat dts/kirkwood-pogoplug_v4.dts >> zImage.fdt

mkimage -A arm -O linux -T kernel -C none -a 0x00008000 -e 0x00008000 -n Linux-4.12.1-kirkwood-tld-1 -d zImage.fdt uImage.4.12.1

mkimage -A arm -O linux -T ramdisk -C gzip -a 0x00000000 -e 0x00000000 -n initramfs-4.12.1-kirkwood-tld-1 -d initrd.img-4.12.1-kirkwood-tld-1 uInitrd.4.12.1

Then copy the image & initrd to the correct filenames, as said.
I've done this enough times now to do it in my sleep. EXACT same procedure on a virgin 4.4.0 rootfs results in a booting kernel, but no so with 4.12.1

Quote

> were you in the box while kernel 4.4 is running? .... or post that snipet of log of the
> session here?

4.4 is on a separate SD card (again with a virgin file system). I can boot to that, but I'm not sure how that would help.... that fs has no other kernels installed (or attempted), but maybe I don't understand fully...

To sum up (yes, repeating data here). we have two fresh "installs" one with the 4.4.0 rootfs (& nothing else) & one with the 4.12.1 rootfs (& nothing else). Same procedure for producing the kernel image & ramdisk results in a booting 4.4.0 box, but not so with 4.12.1

here's the contents of /boot when booted up on the 4.4.0 rootfs/kernel/sd card:

drwxr-xr-x  3 root root    4096 Sep 27 15:13 .
drwxr-xr-x 21 root root    4096 Feb 16  2015 ..
-rw-------  1 root root 2240040 Jan 25  2016 System.map-4.4.0-kirkwood-tld-1
-rw-r--r--  1 root root  140949 Jan 25  2016 config-4.4.0-kirkwood-tld-1
drwxr-xr-x  2 root root    4096 Jan 26  2016 dts
-rw-r--r--  1 root root 7179871 Feb 18  2016 initrd.img-4.4.0-kirkwood-tld-1
-rw-r--r--  1 root root 7511582 Jan 25  2016 linux-headers-4.4.0-kirkwood-tld-1_1.0_armel.deb
-rw-r--r--  1 root root 3165142 Sep 27 15:13 uImage
-rw-r--r--  1 root root 3165142 Sep 27 15:13 uImage.4.4.0
-rw-r--r--  1 root root 3154896 Feb 18  2016 uImage.stock.4.4.0
-rw-r--r--  1 root root 7179935 Sep 27 15:13 uInitrd
-rw-r--r--  1 root root 7179935 Sep 27 15:13 uInitrd.4.4.0
-rw-r--r--  1 root root 7179935 Feb 18  2016 uInitrd.stock.4.4.0
-rw-------  1 root root 3154832 Jan 25  2016 vmlinuz-4.4.0-kirkwood-tld-1
-rwxr-xr-x  1 root root 3154832 Jan 25  2016 zImage-4.4.0-kirkwood-tld-1
-rwxr-xr-x  1 root root 3165078 Sep 27 15:12 zImage.fdt
Re: Follow up: A fresh attempt at 4.12.1 install on another pogo-plug v
September 28, 2017 11:08AM
small follow up & a question bodhi:

i noticed i have 4.12.1 running on my dockstar, even with this uboot version:
U-Boot 2014.04.R2-1 (May 15 2014 - 14:35:47) Arch Linux ARM
Seagate FreeAgent DockStar

i said I was running 4.4 on it as well.

the question:
i kind of hate to spend the time, but I was already spending time reading other threads here about various issues & I came back to my original question. Should I just bite the bullet & upgrade uboot to the latest & greatest? Am I just wasting your & my time by not doing that?

It certainly would eliminate some variables, yes? Off to go read some on that. Oh & did read in another thread you have a script for setting all the variables? That certainly would make the procedure easier.
Re: Follow up: A fresh attempt at 4.12.1 install on another pogo-plug v
September 28, 2017 05:50PM
craigcoffman,

Quote

> correct. I decided *.orig was not a super-helpful
> name & that things could get confusing
> without just sticking with using the version in
> the name. Especially once I start trying to
> "upgrade" kernels.

OK.

Quote

> correct re: production of uImage. Using the
> concatenated dtb file method since I wanted to
> make no changes to uboot. (hate to brick one of
> these.. I only paid $9 each & don't figure they
> are worth the time it would take to make up the
> serial cable).

OK.

Quote

> I named the output of both mkimage commands to
> uImage.4.12.1 & uInitrd.4.12.1 respectively, again
> to keep things straight. I then simply copied the
> files to uImage & uInitrd. Slight delay is from
> making the ramdisk after the kernel image. BUT,
> notice uImage.4.12.1 & uImage are the same size,
> same for the uInitrd.4.12.1 & uInitrd.

You can use the cp -a command, instead of cp. So that the timestamp will be identical.

It is much easier to know it's identical when they are sorted by time using ls -lart command.

Quote

> This was a fresh un-tarring of the 4.12.1 rootfs
> kit... onto a blank SD card. (sorry I didn't make
> that more clear) nothing else on that card.
> Trying to eliminate variables you know.
> Also, to re-iterate, this was on a different
> pogoplug device than the one where I had
> erroneously entered (& subsequently removed) the
> fw env variables for booting without the
> concatenated dts file. Again, just to eliminate
> variables.

OK.

To make the images, I simply followed the

> cat dts/kirkwood-pogoplug_v4.dts >> zImage.fdt

Was it a typo when you typed the post? the file name should be kirkwood-pogoplug_v4.dtb.

Note that it would have been better to see the actual log of the session while you are doing this so that I can spot any typo you might have made!

And the files should be listed in chrono order using
ls -lart

---------------

I did not see any error in your description of your rootfs creation session, other than the file extension was wrong. This should have been resulted in an error about "file not found".
> cat dts/kirkwood-pogoplug_v4.dts >> zImage.fdt

Without seeing the actual log of what you did in creating the rootfs, I can't really say for certainty that the rootfs was created correctly or not. But the description sounds good.

-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)
Re: Follow up: A fresh attempt at 4.12.1 install on another pogo-plug v
September 28, 2017 05:55PM
craigcoffman,

> It certainly would eliminate some variables, yes?
> Off to go read some on that. Oh & did read in
> another thread you have a script for setting all
> the variables? That certainly would make the
> procedure easier.

Definitely. Using my u-boot release would make everything simpler to troubleshoot.

And yes, perhaps it is time to use my script to reset your envs to the default envs, using netconsole. And then you don't have to append the DTB, just use the original 4.12.1 rootfs after untar it to the SD card..

-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)
Re: Follow up: A fresh attempt at 4.12.1 install on another pogo-plug v
September 28, 2017 05:55PM
Quote

Was it a typo when you typed the post? the file name should be kirkwood-pogoplug_v4.dtb.

Note that it would have been better to see the actual log of the session while you are doing this so that I can spot any typo you might have made!

transcription error I assure you. I auto-complete those thing typically of course. Yes, would've seen an error, AND, it would have been a no-op, so the file size would be the same as the original zImage file.
Re: Follow up: A fresh attempt at 4.12.1 install on another pogo-plug v
September 28, 2017 06:38PM
Quote

And yes, perhaps it is time to use my script to reset your envs to the default envs, using netconsole. And then you don't have to append the DTB, just use the original 4.12.1 rootfs after untar it to the SD card..

just to re-iterate a couple of points.

1. This on a DIFFERENT POGOPLUG, not the one I changed envs. it is pristine from the original uboot install, U-Boot 2014.07-tld-1

2. It (& all the other units) boot 4.4.0 perfectly fine when I use the exact same procedure, but that rootfs instead of 4.12.1
Re: Follow up: A fresh attempt at 4.12.1 install on another pogo-plug v
September 29, 2017 01:14AM
craigcoffman,

1. Use the tarball Debian-4.12.1-kirkwood-tld-1-rootfs-bodhi.tar.bz2 and create a new rootfs on a new USB thumb drive. No modification should be done to the rootfs after untaring and synching it (skip step 4).

2. Folllow the instruction in this post to populate the u-boot envs with default values for uboot.2016.05-tld-1 (it will work just fine for u-boot-2014.07):

https://forum.doozan.com/read.php?3,29362,29390#msg-29390

3. Before booting, set the envs to your box specifics, print out the envs, and then boot:

setenv devices 'usb'
setenv ethaddr '00:25:31:05:66:bd'
setenv dtb_file '/boot/dts/kirkwood-pogoplug_v4.dtb'
setenv mtdparts 'mtdparts=orion_nand:2M(u-boot),3M(uImage),3M(uImage2),8M(failsafe),112M(root)'
setenv ipaddr '192.168.2.6'
setenv serverip '192.168.2.12'
printenv
boot

Please post the entire netconsole log here.

Remember, the brand new rootfs will use DHCP to get dynamic IP address from the router. So what being done above for ipaddr and serverip is just for completeness.

-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)
Author:

Your Email:


Subject:


Spam prevention:
Please, enter the code that you see below in the input field. This is for blocking bots that try to post this form automatically. If the code is hard to read, then just try to guess it right. If you enter the wrong code, a new image is created and you get another chance to enter it right.
Message: