My goflex net seems to have burped up a Hairball.
I have the rescue system in place, and via netcat I can see what went wrong... it says the "ramdisk" is corrupt.
So, since it boots off of the hard disk - that means the uinit file is bad?... the /boot directory needs replacing?
I believe it has been running Jessie (maybe early version of buster)

Is there a fix that can be done either by booting off of a thumb drive? Or by plugging drive into a laptop?

Help?

rmleonard,

> My goflex net seems to have burped up a Hairball.

First, for problem like this, you need to tell us what did you have installed on this box? i.e. which u-boot version? which installation procedure did you use to install initially from stock?

> I have the rescue system in place, and via netcat
> I can see what went wrong... it says the "ramdisk"
> is corrupt.

Please post the netconsole log here.


> So, since it boots off of the hard disk
- that
> means the uinit file is bad?... the /boot
> directory needs replacing?

Not really. It could a few different problems that caused this.

> I believe it has been running Jessie (maybe early
> version of buster)

So now I know it is Debian. It'll make it a little bit easier to fix.

>
> Is there a fix that can be done either by booting
> off of a thumb drive? Or by plugging drive into a
> laptop?
>
> Help?

Sure. As soon as I can see the netconsole log I will be able to suggest what to do.

Most likely it can be fixed if you can mount the HDD on another Linux, where you have root access.

The worst case is you need to create a new USB rootfs to boot with it. And this is where u-boot version and u-boot envs info on you box will be needed (you can get that in netconsole).

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

Attached is bootcap.log, a copy of what happens when unit boots, -- I noticed that the file rebuild dates are this evening.. every month or so the system runs an updater script that finishes by rebuilding the bootfiles --- the attached script file rebuild_uinit.sh is the copy that runs on another goflex-net. (It should be identical to script on now 'sleeping' goflex.)

The bootcap shows the version of the loader..
The boot process
The Hairball (probably caused by my updater script)
(But it had been working.....??)
I checked the shelf where hardware is located...
3 inches of dust... check
No mouse footprints/scat... check
No other types of prints or scat... check
All power/network cables attached/untouched... check
All other servers/'pooters working and filled with magic smoke... check
The other goflex on the shelf is running Jesse, it updated today as well, and booted / rebooted fine (current uptime-almost 6 hours) and I believe it uses same scripts.

Senile SOB w/bad knees and migraine... check

I think I have an adapter so I can plug the drive into my testbench (the drive is 'sealed' in one of those black plastic enclosures that don't seem to come apart without breaking) otherwise, I'll have to find one of the Seagate USB only connector foot doo-dads to plug drive into.

I think I've answered (albeit with unnecessary snark, pain does that, sorry)

I saw the article on updating Jessie to stretch .. will that still work to go from Jessie to buster? I'd like to update the other go-flexes...

rmleonard,

I see. This problem is easy to solve. You are running my released u-boot and rootfs/kernel.

But things got out of whack, because of that script is obsolete.

Bootlog

U-Boot 2017.07-tld-1 (Sep 05 2017 - 00:21:31 -0700)
Seagate GoFlex Home

<snip>

Found bootable drive on ide 0
loading uImage ...
3821592 bytes read in 734 ms (5 MiB/s)
loading uInitrd ...
11542986 bytes read in 1830 ms (6 MiB/s)
loading DTB /boot/dts/kirkwood-goflexhome.dtb ...
10603 bytes read in 110 ms (93.8 KiB/s)
## Booting kernel from Legacy Image at 00800000 ...
   Image Name:   Linux-4.12.1-kirkwood-tld-1
   Created:      2019-10-03  23:50:59 UTC
   Image Type:   ARM Linux Kernel Image (uncompressed)
   Data Size:    3821528 Bytes = 3.6 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:      2019-10-03  23:51:00 UTC
   Image Type:   ARM Linux RAMDisk Image (gzip compressed)
   Data Size:    11542922 Bytes = 11 MiB
   Load Address: 00000000
   Entry Point:  00000000
   Verifying Checksum ... Bad Data CRC
Ramdisk image is corrupt or invalid

Script

#!/bin/bash
pushd /boot
pwd
cp uInitrd uInitrd_$(date +%Y%m%d%H%M)
/usr/bin/mkimage \
	-A arm \
	-O linux \
	-T ramdisk \
	-C gzip \
	-a 0x00000000 \
	-e 0x00000000 \
	-n initramfs-4.4.0-kirkwood-tld-1 \
	-d initrd.img-4.4.0-kirkwood-tld-1 \
	uInitrd

This script tried to put the initrd back a few versions. So remove it on the good unit before it will screw up that box too.

================

Solution

Now to fix this problem, you need a SATA 22-pin to-USB connector to fix it using the good GoFlex, or a USB rootfs that you will boot this bad unit with.

With the SATA-22pin-to-USB connector, you will need to file off the edges in order to insert it into the GoFlex drive (this is a UTM, iirc, form factor, so the slot is deeper than usual).

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



Edited 2 time(s). Last edit at 10/04/2019 03:05AM by bodhi.

Mount the GoFlex HDD on another Linux, become root user (don't use sudo).

And assuming the drive is mounted as /media/sdb1.

cd /media/sdb1/boot
ls -lart *

And you will see the initrd file:

initrd.img-4.12.1-kirkwood-tld-1

Recreate the unInitrd

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

and

sync

That's it.

Unmount the HDD and bring it back to this bad unit and power up.

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

bodhi Wrote:
-------------------------------------------------------
> With the SATA-22pin-to-USB connector, you will need to file off the edges in order to insert it into the GoFlex drive (this is a UTM, iirc, form factor, so the slot is deeper than usual).
>
Similar to what I have done here. All I did was to file off some edges of the male port on a SATA 22P 7+15 Pin Male Plug To SATA 22Pin 7+15 Female Adapter, then use it along with any SATA cable to connect an enclosed GoFLEX NET SATA HDD to a host. You can do the same directly with a USB to SATA cable, too.

It me awhile to find the correct connector. That taken care of, <sigh>... it did not work.

Attached is the rebuild script file from the 'ill' drive..

Note: my script made a backup of the uinit file before rebuilding ..., switching to the backup file, it now comes up... I've disabled all 'automagic' updates..

The script on this goflex updates the uInitrd and the uImage

Looking at the backups, the last few uimage files are all the same size, the uInitrd files are growing in size from 9958948, 11472311(works), 11542986.

The current initrd.image.img------1 file is 11549222 in size (dated Oct 3)

So, I am operational, (yea! backups)... but can't proceed, until I update something....???

Thoughts?
(and THANK YOU - very very much)

rmleonard,

Start netconsole, plug in the HDD, power up, let it boot until no more output on the screen.

Copy and post the entire log here.

Log into Debian, and execute

dmesg
ls -lart /boot

And then copy and post the log here.

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

netcat.log - output from NC
dmesg.log - output from sudo dmesg
dir_of_boot.txt - output of ls -lart /boot

(And again - thanks)

rmleonard,

> netcat.log - output from NC
> dmesg.log - output from sudo dmesg
> dir_of_boot.txt - output of ls -lart /boot
>
> (And again - thanks)


It's all good! You can start using the box.

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

Grrrrrrrr.... it ate my message.....

Yes, box boots using the backup uInitrd file....
All attempts to rebuild / refresh /etc. the file - generates a “bad CRC” version that is roughly 100k larger than working file...

So, if my commands in the rebuild script (4 or so messages back) are correct, and my dyslexia didn’t cause any tweedled words..
And it worked at one time (at least) in the past....

What is broken? The source file? Something that is used to build the source file? Memory?

Confused and befuddled in Lower California,
And up far, far too late....

Rich.

rmleonard,

Your u-boot is good to boot with any new rootfs. So now the only thing you need to do is to recreate the rootfs and boot with it.

See the release thread:
https://forum.doozan.com/read.php?2,12096


Scroll down to

Quote

Updated 25 Aug 2019:

Basic Debian buster Kirkwood rootfs for most Kirwood plugs:

- tarball size: 209M
- install size: 536M
- The init system used in this rootfs is sysvinit . To boot with systemd, see note 2 below.
- Installed packages: nano, avahi, ntp, busybox-syslogd (log to RAM), htop, isc-dhcp-client, dialog, bzip2, nfs server/client, iperf, ethtool, sysvinit-core, sysvinit, sysvinit-utils, u-boot-tools, and mtd-utils.
- see LED controls in /etc/rc.local, and /etc/init.d/halt
- see some useful aliases in /root/.profile
- root password: root

Download at Dropbox:

Debian-5.2.9-kirkwood-tld-1-rootfs-bodhi.tar.bz2

md5:
cd8ad170aa1a9fdc2a0a1c43ab1c0721
sha256:
8ccbbced367b4c2bf3728262e882f8232aff0fecd1c0c767219a0cab49a0b9bf

And don't use the rebuild script or any script to update the rootfs. Just use this rootfs as is, until you need to upgrade kernel to a newer version.

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