Ive been researching this all day. Check out what these guys did here to kill the process. I feel like i can barely understand but cant quite grasp.
This is CLEARLY a Gen1, which I have no practical experience with.
Does the Gen1 also have the busybox binary? If so, this might just be a weakness in umount on the system, and calling busybox’s umount instead might be more effective??
1 Like
No it does not have busybox. But as I said they don’t use fstab to mount the data disk.
I hate the busybox stuff. Every time I turn around I find another command that is not present. I keep having to compile up a version that works on the Gen2. Also found that if you build a new kernel with block trace enabled. The ufsd.ko and jnl.ko no longer load.
1 Like
A shame. Busybox is useful to have on hand, even when you have real management apps installed. (I have seen cases where umount is knackered bad, but busybox’s umount works fine-- or where mount is knackered, but busybox’s mount works fine. Usually on android devices though.)
Ok. The Gen2 has a filesystem check feature on the dashboard. Does the Gen1? Maybe we are trying to do this the hard way…
1 Like
Not that I could find. My thought is to change the name of the script that mounts the data disk. Just not sure if it will brick the device.
1 Like
Putting a # in front of the actual mount lines in the script temporarily would have the same effect, without giving a return error status >0 on init, which is dangerous, and what a failed call to a script would cause.
1 Like
I was thinking of changing the name of S15mountDataVolume.sh to s15mountDataVolume.sh That way it does not run.
1 Like
I have no practical experience with the Gen1 units, so I dont know if that will bork the unit up good or not…
1 Like
The gen1 is basically normal Linux with the exception of the 64k page size. Has all of the /etc/rcx.d folders.
1 Like
I was meaning, I dont know if preventing access to the data volume will halt access via ssh later or not. Without a means to access the unit, it would be an effective brick (Even if serial console is theoretically a valid way in… I dont want to tell the OP that they need to order a usb-serial 3v cable, and that they need to solder a 4pin header on the system board–all because we borked up the system’s startup sequence. At that point, I would just tell them to pop the drive into a computer, boot a linux liveCD, run fsck on the drive, and revert the changes we made to system files, pop it back into the shell, and go about his life.)
I am at a loss why the the kernel journaling handler is the process that wont let go of the drive, considering it is mounted RO. (Really, there is nothing for it to journal, because no writes are happening!!!) (Confused) A forced umount of sda4 should have let it all go, but nope-- silent failure. That’s why I suspect a weak/broken umount implementation, and why I was curious about busybox being present or not.
I know you are better equipped to rescind an experimental change like this (I recall that you already have a serial cable, and soldered on the headers), and that you have a Gen1, can you test if this process will bork up core system boot on your Gen1?
1 Like
I will try with my Gen1 since it has a serial interface. I also have a gen2 with a serial interface. Nice talking. But its 12:38AM here.
1 Like
Don’t change the name of S15mountDataVolume.sh script. It will cause the My Cloud to not allow SSH and Dashboard. It was accessable from the serial port.
1 Like
Did a little more checking. The S15mountDataVolume.sh does an fsck of the DataVolume. If there are failures they are logged. So he should check the log for mount errors. The easy way is to cd to /var/log Then grep mount * or grep failed *
or grep fsck * This will display any mount entries in the log and tell you which log.
1 Like
Thank you. When you say ‘cd’ to, do you mean enter the commands like I have been in ssh?
Yes. You ssh into the My cloud. Then cd /var/log Then grep mount *
then grep failed * then grep fsck *
These should show some kind of failure. You could also type dmesg
Understand you don’t type you just press the enter key.
Post bask the results of these commands.
1 Like
The grep mount * has so much data, it fills the whole thing up, many many pages, so many so that when I try to scroll back to the top, all of it isnt there. I dont know how I can share all of that data especially since, as I said, the first parts ‘fall off’ the browser. Same with grep failed. 20 or more pages I would say. the grep fsck * is not too bad.
How can I capture all of that data and how can I share it with you?
Here is a screen grab of part of each of those 3 outputs
The first screen shot shows that the fsck process ran out of memory.
1 Like
Indeed… He DOES have swap right? how much memory did fsck really need there? (I know the gen1 is memory constrained, but jeeze)
Hey John, can you give me the output of
cat /proc/swaps
and
free
please? It would be absurd if this thing is failing the fsck because it is out of memory, because swap ran out. If so, we might try disabling cloud access (to stop the indexer, which is a bloated memory hog) then rebooting.
1 Like
Your numbers match my Gen1 system. Except for the buffers. My number is 82,624.
We need to see your dmesg output.
PS I’ve noticed that you have a lot of mounts of /dev/sda4. Are all of the DSCF’s are they shares? Something is using almost double the buffers than my system.
1 Like
