- #Seagate dockstar usb monitor install
- #Seagate dockstar usb monitor update
- #Seagate dockstar usb monitor portable
- #Seagate dockstar usb monitor software
Update the mtd0 U-Boot and environment variables.
But I do not trust any executable from the cloudengines directory to not “phone home”, so I’m fine with disabling the whole script. It’s been mentioned that it’s better to just add a command to kill the offending process, so that other kernel modules can get loaded.
#Seagate dockstar usb monitor software
Knowing that, you could ssh into the DockStar with the default password, comment out the script command that runs the Pogoplug software (which retrieves the firmware update from the Internet) and save that back into flash memory. There is often a page from the mini web server in your router that lists out the IP addresses it has handed out, so that you can determine what IP address the DockStar received via DHCP. To prevent this, I disconnected my home router from the Internet, but had it still responding to DHCP requests. Out of the box, if you connect the DockStar to your network, it will retrieve firmware updates and disable ssh on the device. Prevent the DockStar from “phoning home”. This also frees up mtd3 for installing other things, like maybe a very small 219 MB Linux installation. So a one-time update to mtd0 sounds more reasonable. It’s true that writing to the mtd0 U-Boot has its risks, but mtd0 is being re-written anyway (on every boot) if the switching mechanism is used. If the USB boot fails, the USB drive can just be mounted on another machine and get fixed.Īlthough it’s been desired by all that mtd0 should not be updated on every boot, there were discussions on whether the old U-Boot bootloader at mtd0 should just be updated. Some users have opted to configure the boot sequence such that it always tries the USB drive, but does not change the bootloader variables in mtd0. Because of technical limitations, the installed mtd3 chained bootloader cannot be made to boot back into the mtd1 kernel if it fails to boot the USB drive. However, the bootloader environment variables are themselves stored somewhere in mtd0, so this switching approach may potentially be a cause of your device getting bricked (if something fails in the update to mtd0). To accommodate a fallback to the original Pogoplug environment in case the USB drive fails to boot, a “switching” approach was made to the bootloader environment variables – that is, at each boot, the variables would be changed between booting the mtd1 kernel and booting a USB drive kernel. The installed mtd3 bootloader can then check for USB drives and boot the Linux kernel from there. In essence, the bootloader environment variables are changed to cause the mtd0 bootloader to chain to another bootloader that gets installed at mtd3. Hacking the DockStar to boot a different Linux system from a USB drive all stemmed from the instructions initially posted at. The remaining partition mtd3 (219 MB) is unused. The second partition mtd1 (4 MB) contains a Linux kernel image, and the third partition mtd2 (32 MB) contains a Linux jffs2 file system. The first partition mtd0 (1 MB) contains a very old U-Boot bootloader. The factory setting has the NAND flash memory set into four partitions.
#Seagate dockstar usb monitor portable
It has 4 USB ports, and unlike other Plug Computers, the ports are powered so you can attach regular USB thumb drives as well as higher-capacity portable drives. The DockStar has 128MB of RAM and 256MB of flash memory.
I’m okay with Debian though, and Debian provides packages to this “armel” device even in their “squeeze” testing release.
#Seagate dockstar usb monitor install
I would have wanted something that I could install Ubuntu on, but Ubuntu does not provide support for the ARM v5 architecture.
What attracted me to this device was its size, its low price (compared to other Plug Computers), and support for a standard Linux Debian distribution. I bought a Seagate DockStar a couple of months ago.
0 kommentar(er)
