H2O not booting

[tshering]

Originally Posted by frostschutz

A default of the programs you use perhaps...

Thank you! I think I understand it now a little better. Any file in a tar created by 7-zip under windows has the permission set to 777 (This seems to be the default at least. I do not know whether one can change this).
The second thing, is that any file on the user partition of the reader is evidently treated as having permission 755. Since I transferred my files to the system partition by KoboRoot.tgz or by simply copying them from the user partition, it happens that those files have permission 777 or 755.

[boriar]

how to know whats files must be 777 or 755?

[tshering]

I guess, since there is only the root user, it does not matter whether executable files have 777 or 755 permission.

Did you already open your device?

[boriar]

Then if i use 7zip all permissions go well for de/compress?

About open the device, I'm a bit scary because the frostschutz's report about the blend of frontlight and IR screen. That don't will be the first device i open but like i have already my warranty first i will try with it. If not go well... i suppose will open it.
I tell you something in a days.

[tshering]

Originally Posted by boriar

Then if i use 7zip all permissions go well?

I would say, if you use it under Windows yes. Under linux, i think, 7-zip will respect the set permissions.

But in your current situation, this will not help you I guess. Since you have to get your reader running before it can un-tar anything. And to get it running you have to change the permissions of rcS on your internal sd. Right? Or do you have it already running again?

[boriar]

Originally Posted by tshering

I would say, if you use it under Windows yes. Under linux, i think, 7-zip will respect the set permissions.

But in your current situation, this will not help you I guess. Since you have to get your reader running before it can un-tar anything. And to get it running you have to change the permissions of rcS on your internal sd. Right? Or do you have it already running again?

Your are complete right! My solution isn't immediately. In any case all that is for future situations and experiments.
Thanks both tshering and frostschutz for your considerations. I hope be operative as soon as posible.

[davidfor]

Originally Posted by frostschutz

I don't think tapping works on the H2O (if it works for you, a short youtube tutorial would be great). Factory reset with the pinhole only works with a working, and unmodified, rcS script when you're still seeing the startup squares (by pressing the reset whenever the squares show up, until it shows the factory reset screen instead).

According to Kobo, the tapping method should work on the Aura H2O. It was a question I asked when the Aura H2O was announced and I saw it only had one button and that is the way factory reset for the Mini works that way. Unfortunately, I don't have either device to test, but I have mentioned it a few times and no-one has said it doesn't work.

[frostschutz]

Originally Posted by davidfor

According to Kobo, the tapping method should work on the Aura H2O.

The only thing that works for me is hitting the reset button up to five times during the [ ] [ ] [ ]-bootup screen with the squares. But that's just part of the bootup scripts, no magic, and stops working once the bootup script (rcS) is broken or modified in a certain way.

There doesn't seem to be an alternative method. It's not in the kernel (no initramfs). It could be in the bootloader, but if it's there I haven't found it yet.

[davidfor]

Originally Posted by frostschutz

The only thing that works for me is hitting the reset button up to five times during the [ ] [ ] [ ]-bootup screen with the squares. But that's just part of the bootup scripts, no magic, and stops working once the bootup script (rcS) is broken or modified in a certain way.

There doesn't seem to be an alternative method. It's not in the kernel (no initramfs). It could be in the bootloader, but if it's there I haven't found it yet.

I hope to have a H2O in my hands at the end of the week, so I'll test then. In the meantime, I'll try and confirm it with Kobo.

[boriar]

Is it posible to make a program for windows to do a check of all that?
I think will be a good tool for developers with experience and amateurs also to prevent things like that.

[tshering]

Originally Posted by boriar

Is it posible to make a program for windows to do a check of all that?
I think will be a good tool for developers with experience and amateurs also to prevent things like that.

This sounds a little difficult. And what is "all that" that we should check for? I guess permissions. Under Windows the easy way to make a tar for our purpose is to use a file like 7-zip. If you do this, every file will be executable, a problem like yours cannot occur and there is no need to check the file permissions. Of course, the fact that "every" file is executable bears the danger that by some error in a script a file gets executed that was not intended for execution and causes damage.

If you therefore, choose to set the file permissions selectively, it is a little hard to check afterwards whether you did it correctly. One would have to read the starting bytes of every file in order to ascertain whether it is an ELF file or a script file (hoping that each script file identifies itself as being a script file). If one takes link files also into consideration ... Maybe there is another solution, but right now I cannot think of one.

And file permissions are not the only issue that can make a KoboRoot.tgz dangerous.

[NiLuJe]

And that doesn't help if the file gets corrupted during the transfer. Some kind of device-side integrity checking would seem the most basic of precautions, but, meh. I'm at least hoping it's done in some way by the Desktop client when you use that to handle official updates?

EDIT: Which is apparently what part of 3.12.1 is about, so, yay?

[frostschutz]

Well, there's a message in the u-boot bin at least:

Got dual finger touched!!
waittouch
ntxup waittouch [interval (ms)] [timeout (ms)] - polling touch each interval and wait until touch pressed .

Can't get it to work myself, though. Maybe I'm doing something wrong after all.

Or it's a timing problem. If u-boot does the tap detection, it has to do it before it loads the kernel. But the device boots fast; I'd be surprised if it even waited 1 second for a tap.

[tshering]

Originally Posted by boriar

I try the tapping method (where come that method???) but nothing happen

Maybe it is worth re-reading how the tapping method is supposed to work, and trying it again several times. Right timing and frequency might be of importance. Perseverance might pay off. And do not forget to certainly power off the device before each trial (in case of doubt hold the power slider longer than 20 seconds in the off position).

[boriar]

Originally Posted by tshering

Maybe it is worth re-reading how the tapping method is supposed to work, and trying it again several times. Right timing and frequency might be of importance. Perseverance might pay off. And do not forget to certainly power off the device before each trial (in case of doubt hold the power slider longer than 20 seconds in the off position).

Well, may be i do more test. Corss fingers!