How to change extensions to "copy2fs" via CLI?

[drtebi]

Good job drtebi,

It's interesting to hear that piCorePlayer does not use copy2fs. I feel safer using it... although I have noticed quite a longer boot time now (which makes sense... since a bunch of stuff is copied into RAM at boot time now).

Personally, I really like the idea of using copy2fs and do from time to time. But working with a team means you have a decision process to follow. We haven't had many people complaining about SD card corruptions but do get a lot of "How do I make pCP boot faster?".

regards
Greg

That makes a lot of sense... I figure that, as mentioned by Misalf, there is very little writing going on, so piCorePlayer does not really face the problem of data corruption.

[drtebi]

Here are a few pictures of the process... I hope this is not unorthodox to post here, as this is not directly related to piCore...

First the "milling" of the ears of the faceplate. It worked, but I don't recommend doing it this way. Either use a proper mill for this, or, if only woodworking tools at hand, a router with a carbide bit can be used, as long as the aluminum is very well secured.





Here a picture of the circle jig I made to cut the counter-bore for the large hole (on a test piece).


The electro etching is a bit more elaborate. I use "Press-n-Peel Blue Transfer Film" to transfer the printed image to the aluminum. Any spots are touched up with nail polish, or simply taped. Then I build a sort of cage around the print, glued down with hot glue. For the actual etching process, I added a vinegar and salt solution, then connected the test piece to the positive of battery charger, and the negative to a copper piece that is suspended in the solution above the print. I etched for four minutes.




The result will look somewhat like this. Note that it needs to be sanded again, usually the etching bites at least a little into some areas that aren't supposed to be etched.




It's a lot of work, but a hell lot of fun

Eventually I will post one big blog post on my website with more images. At this time though, I have to figure out how to get the green LED in there, and then find some matching paint for the case (not the front, of course). I am also thinking about nickel-plating the frontplate, since aluminum is a bit sensitive to fingerprints etc.

[Rich]

Hi drtebi
Some very creative solutions, especially how you accomplished the counter-bore. Vinegar and salt, very low tech, I like it.

... First the "milling" of the ears of the faceplate. It worked, but I don't recommend doing it this way. ...

As long as you keep the cuts light you should be OK.

... if only woodworking tools at hand, a router with a carbide bit can be used, as long as the aluminum is very well secured. ...

You can also use HSS bits if you control your RPMs to keep the SFM in the 100 to 200 range.

[drtebi]

Hi drtebi
Some very creative solutions, especially how you accomplished the counter-bore. Vinegar and salt, very low tech, I like it.

... First the "milling" of the ears of the faceplate. It worked, but I don't recommend doing it this way. ...

As long as you keep the cuts light you should be OK.

... if only woodworking tools at hand, a router with a carbide bit can be used, as long as the aluminum is very well secured. ...

You can also use HSS bits if you control your RPMs to keep the SFM in the 100 to 200 range.

Vinegar, salt and electricity that is Nickel plating is done in a similar way... I thought I will try that rather than anodizing, which requires a bunch of "ugly" chemicals, temperature checks etc.

Yes, you are totally right, routing aluminum with a woodworking router should be done in very small steps, light cuts. It works very nicely though.

I am actually not sure what the slowest speed is on my drill press. I believe the cutters I used for the ears were both HSS. But I didn't particularly like the setup... it wasn't dangerous, but just not stiff enough to get smooth results. If I had made a jig to hold the aluminum, and then routed it, I am sure I could have gotten a bit more perfection...

[drtebi]

And by the way... I should give this guy some credit; for my etching, I followed for the most part exactly what he did in his video:
https://www.youtube.com/watch?v=bOMRcqxZe4I

He explains every detail. Only that he does it on some kind of pistol grip or something... oh well

[sodface]

Awesome work drtebi 

[bmarkus]

@drtebi

Please do not hijack topics! What you posted has nothing to do with piCore!

It will be moved out. Next time will be deleted without notice.

Thank you for understanding.

Béla

[drtebi]

@drtebi

Please do not hijack topics! What you posted has nothing to do with piCore!

It will be moved out. Next time will be deleted without notice.

Thank you for understanding.

Béla

I did hijack my own topic... as I am the OP. But I understand nevertheless, and I apologize for getting into non-related piCore stuff.

Someone asked questions about the case work... so I posted some pictures. It would have been a bit rude not to answer.

[Rich]

Hi drtebi

Someone asked questions about the case work... so I posted some pictures. It would have been a bit rude not to answer.

That was my fault. Sorry about that.

[san.gh]

Also, if you want to make it even less likely to corrupt itself when pulling the power (and make the SDCard last for several years longer (since they generally support far far more read cycles than write cycles)) you may want to do everything in: http://forum.tinycorelinux.net/index.php/topic,21821.0.html
Cheers.

[drtebi]

Also, if you want to make it even less likely to corrupt itself when pulling the power (and make the SDCard last for several years longer (since they generally support far far more read cycles than write cycles)) you may want to do everything in: http://forum.tinycorelinux.net/index.php/topic,21821.0.html
Cheers.

Thanks, that's helpful.

Can you explain what is being done there, or rather, why that is the better way? I thought once the SD card is unmounted, it would be safe.

[san.gh]

I thought once the SD card is unmounted, it would be safe.

That is true.  I guess I wasn't that clear, but above when I said "even less likely" I meant to imply that the initial thing was already pretty good.

... why that is the better way?

Booting, having the OS mount in rw mode, and then unmounting has two (minor) problems:

• You can still loose power while booting (before it's unmounted) and corrupt the card (like when the power flicks on after a power outage or when someone plugs it in and then tries to quickly pull it out again, etc.).
• The OS might write to the filesystem when it mounts it in rw mode (access times, fsck dirty checks, etc.).  While this won't corrupt the card it will use up a write cycle, which will make the card fail sooner.  (Since most SD cards support far far far more reads than writes before they fail.)

So, if you make Linux only ever mount filesystems on the card in readonly mode, both the above problems are avoided.  That is the remastering thing (changing the mount flags in the compressed image) in that link.

Now that is pretty good and projects like piCorePlayer say they have thousands of users and never had a corruption, so it is likely good enough.  But even in that case the SD card can still corrupt itself because the SD card itself (that is, the hardware) sometimes rearranges it's internal sectors (maybe because some have gone bad and it is using some unused sectors or something) and if the power is cut while it is doing that it might (if you are really really unlucky) corrupt the data.

The other thing that xpector does in that link is use sdtool to change a bit in the hardware of the SD card to locked (read only mode).  When that is done the OS cannot mount anything on it as rw as writes will be blocked by the hardware of the SD card itself (as a note this is totally different than the little plastic switch on the side of regular-sized SD cards which don't change anything in the card itself, they just tell the reader to not write, which it can ignore).  Additionally some SD cards might use this internal setting to avoid rearranging sectors, or they might not, there isn't really any way to know.  I guess it just makes me feel better.

[Rich]

Hi san.gh

... Now that is pretty good and projects like piCorePlayer say they have thousands of users and never had a corruption, so it is likely good enough.  But even in that case the SD card can still corrupt itself because the SD card itself (that is, the hardware) sometimes rearranges it's internal sectors (maybe because some have gone bad and it is using some unused sectors or something) and if the power is cut while it is doing that it might (if you are really really unlucky) corrupt the data. ...

The other thing that xpector does in that link is use sdtool to change a bit in the hardware of the SD card to locked (read only mode).  When that is done the OS cannot mount anything on it as rw as writes will be blocked by the hardware of the SD card itself (as a note this is totally different than the little plastic switch on the side of regular-sized SD cards which don't change anything in the card itself, they just tell the reader to not write, which it can ignore).  Additionally some SD cards might use this internal setting to avoid rearranging sectors, or they might not, there isn't really any way to know.  I guess it just makes me feel better.

I'm afraid I'm going to have to question some of the content of those paragraphs. Correct me if I'm wrong, but this is the scenario
I see you describing:

1. Your SD card is always running in  Read Only  mode.
2. The cards internal logic detects one of its sectors reliability may have become questionable and wants to remap it.
3. To prevent the possibility that a power glitch occurs at exactly the same time the card remaps that sector and
    corrupts the data, you want to prevent the card from remapping that sector.
4. You wait for the sector to fail and corrupt your data.

[san.gh]

Okay, though I don't understand what you are asking, exactly.  I also feels like you are conflating a few different cases (three kinds of "read only mode" and two failure scenarios), so I'm going to list them and then refer to them by names.

Read only modes:

• RO Mode 1:  Only the copy2fs flag is set, so the card (p2) is mounted readwrite on boot, the extensions are copied to ram, then at the end of boot (in bootlocal.sh) p2 is unmounted.
• RO Mode 2: The kernel images are remastered to never mount p2 readwrite on boot and mount it readonly the first time.  Then the extensions are copied out, and at this point it doesn't matter much if p2 is unmounted at the end of boot.
• RO Mode 3:  The SD card itself is locked in hardware, so the kernel cannot mount it readwrite even if it wants to (it will mount it readonly), and neither can the user (accidentally or otherwise).  (And of course it doesn't matter if it is unmounted in this mode.)

SD Card Failure modes:

• End of Life:  The SD card (or a sector on the card) has exceeded the number of reads or writes that the hardware is capable of and the hardware itself has failed.
• Corruption:  The data on the SD card is in an inconsistent state so the OS can't read or write to the filesystem properly, but the hardware itself is fine.

Okay, so corruption can happen either because the OS is in the middle of a write when the power is cut or because the SD itself was rearranging things when the power was cut.  End of Life is basically just based on the number of writes (barring physical damage).

There is no way to know or prevent the SD card from internally doing anything, different manufacturers do different things, etc., it's a black box.  Which is why above I said it basically just makes me feel better because I suspect (but do not know and cannot prove or even show that it is likely) that some manufactures will refrain from rearranging as much as they can if the hardware bit is set (since internally they can see that, whereas the card hardware can't know if the OS has it mounted readwrite or readonly).

The other issue is that in RO Mode 1 the card might or might not be written to on every boot.  If you don't care about power being cut while booting changing to RO Mode 2 or 3 (instead of RO Mode 1) is only about extending the time before End of Life (NOT about avoiding corruption).

Hopefully that helps clear up what I meant.  Does it?

[bmarkus]

Guys, you are missing an important element of the puzzle, file system and journaling.