I, myself, have been involved in software QA for, oh, well, ah, longer than I’d like to admit! and it just boggles my mind.
If we grant the possibility that different processor families will bend the code in particular directions. . . And if we grant the additional possibility that porting from processor “A” to processor “B” is a non-trivial task. . .
In any event - especially in the Linux world - maintaining even a “reasonably consistent” code base should not be hugely difficult. Especially when you compare it to the headaches and issues raised when you fork the code base like this. With a little care, you can run Linux distributions that are - at the very least - functionally compatible on everything from CERN’s supercomputers to a Raspberry Pi, to a wet pancake.
Sigh. . . .
So, how do I get from where I am to where I should be?
Does anybody know if gen 2 clouds are 4k or 64k code files. If 64k then fdisk from a gen 1 cloud could possibly copied to the gen 2 cloud. Missing libraries could be a problem. Otherwise a standard debian program could be copied to the gen 2 cloud.
In either case running fdisk on the gen 2 would just fail to run if it is the wrong version or is missing a library.
. : [ [[ alias bg break cd chdir command continue echo eval exec
exit export false fg getopts hash help jobs kill local printf
pwd read readonly return set shift source test times trap true
type ulimit umask unalias unset wait
The /bin directory:
root@Storage2 /bin # ls
addgroup delgroup ionice nice sleep
adduser deluser ipcalc passwd stat
ash df kill pidof tar
bash dmesg ln ping tinylogin
busybox dnsdomainname login ping6 touch
cat echo ls printenv true
chgrp egrep mkdir ps umount
chmod false mknod pwd uname
chown fgrep mktemp rm usleep
cp getopt more rmdir vi
date grep mount sed watch
dd hostname mv sh
root@Storage2 /bin #
Oh, and I just noticed. . . I can’t find a 'naffing on/of button on this beast! So, in order to power this beastie down, I have to log into its webmin page? (or the SSH shell?) Sheesh! (shaking head. . .)
As a guy I knew a long time ago used to say: “Not so, Buffalo Breath!”
This is true, and ONLY true, if you are lucky enough to have a system with the 4.n firmware in it. The newer 2.n firmware devices do not, repeat NOT, have the ability to safely shutdown the device at all!
I know this is way off topic, but it’s this kind of horse-hooey that makes me want to find whoever was responsible for this debacle, and CHOKE THE [snap!] OUT OF HIM!!
I have an ancient My Book World (blue rings edition) that, at the very least, has a power button. Of course, the Einsteins that developed the firmware for this beastie designed it so that the power lights go off first - making the user think it’s off - about two minutes before it has truly shut down. Result: Many borked My Book World systems, (including mine!), and a while slew of dissatisfied customers.
In my case, I solved the problem with a red LED wired across the +12v power to the hard drives in my device. When the LED is off, I can safely shut down power to it.
Just to be sure: have you tried the shutdown which is supposed to be possible from the ‘User’ ‘information icon’ at the top of the Dashboard (the head icon)? That’s what the user manual says is possible.
. . . the machine appears to shut down, but does not appear to cleanly unmount the filesystem first, resulting in a “Power” warning in the webmin page when you log in again, and it spends a while fsck’ing the system.
You don’t need to copy busybox. The gen 1 cloud does not have busybox. You would just copy fdisk from the gen 1 to the gen 2. Try to run it. If it works good.
If you look at the files in the /bin /sbin /usr/bin and /usr/sbin most will be a symbolic link to busybox. On the gen 1 they are all seperate files. The problem is that the gen 1 is compied wiht 64k page size. The standard Debian is compile with 4k page size. If you know someone with a gen 1 cloud get the fdisk from them and name it fdisk64k then get the standard fdisk and call it fdisk4k. Check each one. The thing that may happen is that you will have a missing library.
Completely nuking, (as in “dd if=/dev/zero of=/dev/sd[x] bs=8M”), repartitioning, and re-creating the ext4 filesystem solved the problem, (emoticon of smiley-face scratching head in wonder), and I think there’s more going on here than just a missing power switch.
I do not have the time right now to dig into this in the big way, however there should be (with the emphasis on the “should be” part), no reason why everybody and his uncle’s brother will mount a device, and the My Cloud won’t.
Obviously, more research, and perhaps a firmware update, is needed.
I’m being shipped overseas in almost exactly 48 hours, and I have to be “ready to deploy” by 0700 on Friday, so I might not get much more time to play with this until I’m feet-dry on the other side. That is, God willlin’ an’ the Creek Don’t Rise!
This thing is fun, and despite the fact that I want to STRANGLE both the Dev and QA teams, I am having fun with it. I have it bung-full with just short of 6T of stuff, and I’m bringing an empty 3T USB “outrigger” drive with it.
Massive Kudos and huge thanks to everyone who has helped, (make that read “put up with”), me during this odyssey.
This has been discussed before. While the v2.x user manual claims in two separate places that there is a shutdown button on the Dashboard. Fact is there is currently no shutdown button on the Dashboard. Stupid and something you’d figure they’d fix ASAP. But they haven’t.
When we last saw our Fearless Hero, he was commenting within the thread “Safe shutdown” about how to shut the My Cloud down without trashing the hard drives. . . .
As I noted there, there is a very cleverly hidden binary command called (drum-roll please!) “halt”. As in "smack your head with your palm “halt” "
If there was a “Doh!” emoticon, I’d be using it now.
The way you use it is from within a SSH shell - log in, and then type the command “halt”. Hit the enter key, and watch the lights on your My Cloud unit do their Death Dance as it (gracefully!) shuts itself down, without trashing the hard drives.
Once the front panel light goes off, the filesystems are unmounted, drives parked, power removed, and it’s ready and raring to be thrown into a duffel-bag and shlepped to God Only Knows Where.
p.s. Why they can’t link a button from the Webmin page, or from within the totally useless Windows app, to the obviously existing “halt” function is beyond me. When I get the chance, maybe there’s a way to edit the dashboard page to add a button that links to the halt command, 'eh?
Going back to the “not mounting USB drives with filesystem [ blah-blah ]” discussion. . . .
Looking at a drive that was successfully mounted on the My Cloud, discloses a hidden file named “.smbm.xml” in the root of that drive. Examination of that file discloses that it is apparently a fragment of a samba.conf configuration file for SMB. This file contains information about how the My Cloud will mount and expose the drive for use when plugged in.
I have not confirmed this, but there might be another explanation to the failure-to-mount issue:
What if, for whatever reason, the My Cloud does not have permission to write to the root of the USB device? In that case, it might not be able to create - or update - the smbm.xml file, and as a consequence it fails to mount the device. Even though normally it would be able to mount it just wonderfully.
Again, I do not know if this is true for a fact and I do not have time to experiment with it at the present time, though it would be interesting to play with.
One good test would be to take a drive that - for whatever reason - fails to mount, and then run a “chmod 777 [path to drive]” command. Or a “chown” to whatever the owner of the filesystem is. (or both?)
If anyone gets time to play with this, try it and let me know if that helps.
If it were only that simple. As I have discovered, something like 99.9999% of the software on the 2.n version systems is embedded in the firmware, within a write-only squashfs filesystem. With that the ability to make modifications to the filesystem are (virtually?) impossible.
In both the gen1 and gen2 system the software is embedded in the firmware. Only those things that other people
install in the gen1 is outside of the firmware. The gen1 uses a Debian system compiled with 4k page size on firmware version 3.xx. The firmware version 4.xx uses 64k page size. On the gen1 system the Linux commands are seperate programs. On the gen2 a lot of the Linux commands are built into a file called busybox. Also the gen2 systems have a limited number of libraries. One can copy a program from a standard Debian Linux system and copy it to a gen2 system. The odds of that program running are slim. Since the necessary libraries may not be installed.