Tiny Core Linux
Tiny Core Base => Raspberry Pi => Topic started by: Captain.Midnight on February 01, 2017, 11:22:00 PM
-
Would someone be kind enough to point me towards piCore docs and/or tutorials. Please note I said piCore and NOT tiny core unless it has pertinent information that can be gleaned by methods less esoteric as voodoo and the entrails of a chicken. The installation procedures are worlds apart for one thing. I takes more time to copy-and-paste the dd command than it takes for dd to finish writing to the sdcard. I'm not trying to run tinycore down, I plan to try it out in the future, but there is little that I have found to help me set up piCore.
You don't use a Toyota repair manual as a reference while working on a John Deere tractor. Sure, they both use infernal combustion engines, but nearly everything else is different.
Any help would be appreciated
-
I think the Core Book is a good starting point for learning about piCore, even though no written with piCore in mind, piCore is just Core with modifications for the Raspberry Pi.
http://tinycorelinux.net/book.html
Also the wiki holds information for both, Core and piCore.
http://wiki.tinycorelinux.net/
There isn't much coming to my mind that would differentiate piCore from Core, except for the installation procedure.
http://tinycorelinux.net/8.x/armv6/releases/RPi/IMPORTANT
http://tinycorelinux.net/8.x/armv6/releases/RPi/README
-
@Midnight: Bare in mind, it's not PiCore versus TinyCore (for example) where the manuals differ, it's the computer in which they're running on that's going to be your main difference.
Installing PiCore is more direct as you're writing the operating system right onto the "drive" which is going into your computer (RasPi) whereas with TinyCore, Debian, Windows or any OS people are more familiar with, this usually starts with a CD or DVD instead which has a bunch of guessing and scanning to tend to which tries to figure everything out FOR you whereas with RasPi's... we already know how much memory you have, what type of processor, etc. because they're all made identical.
Once the PiCore is installed ("burned" or "DD'ed" onto the SD card as some call it) and you boot your RasPi... virtually all of the book content regarding MicroCore is where you find yourself. There's very little "out of the box" pre-installed, but then again, that's one of the main points and highlights of Core... it's a clean slate and you decide what to turn it into.
* If you are not familiar with PiCore OR TinyCore, I STRONGLY recommend experimenting with CorePlus/TinyCore/MicroCore (such as a bootable USB pen, bootable CD or a virtual machine) - the learning curve for PiCore can be drastically reduced doing so.
-
Installation was simple, adding the gui the same once I discovered the white space that I did not notice on the webpage. What I'm really looking for is solid information on bootcode persistence options. I tried setting a persistent /home (I forget exact wording but I copied it from a tinycore-related page omitting only the word "tinycore".) A reboot caused it to hang indefinitely.
Should I include it next time, should I change it to "picore", or even "piCore"? The various combinations and permutations could have me re-installing endlessly. If somebody would care to teach this old dogs some new tricks, I'm open.
I did manage to find one page in French with specific piCore information that I could use AFTER I get the bootcodes set to my satisfaction as setting all these up and then having to re-install would make about as much sense as spending an hour getting your hair perfect, then putting on your motorcycle helmet and going for a ride.
http://bz31.tuxfamily.org/dokuwiki/doku.php?id=core:picore_rpi3 has some info on setting up ALSA, and a few other tidbits.
Thanks in advance.
-
Quite a lot of words in the wiki:
http://wiki.tinycorelinux.net/wiki:persistent_home
http://wiki.tinycorelinux.net/wiki:persistence_for_dummies
http://wiki.tinycorelinux.net/wiki:start#persistence
It's not easy to write easy to understand instructions. Personally I learn best by trial and error (or I haven't read much that was an easy fit to my way of thinking). I find the wiki still very helpful though.
If the wiki won't help you, just ask on the forum.
Specific information is gathered best by asking specific questions. ;)
-
Oh, yes. Also the FAQ, of course:
http://tinycorelinux.net/faq.html
-
Misalf:
Don't know how I missed the wiki. I just briefly scanned the links you provided, and I am using a USB hdd for home, there's stuff there that is bang on what I was looking for. Thank you.
Still need a bit of clarification on something, though. Where it says "restore={hda1|sda1|floppy} Specify saved configuration location" am I to create a specific folder and give the absolute path, or is it sufficient to just point it in the general direction of my USB hdd, and let it pick the final destination? The only sd card I could find to use for picore is 32 Gb, so there is more than enough room for my settings. Would I be able to save all my settings and create my /home directory there making use of the pi independent of the external drive in case I need it elsewhere, yet be able to just plug it in and still get easy access to my (example) videos?
I know that these questions may seem a bit noobish, but I'm a manic depressive which, contrary to popular belief, does not mean I'm sad. What it does mean is that my thinking gets a little foggy sometimes. Kind of like trying to figure something out while hung-over without the feeling crappy part.
Recommendations? I just realized the putting everything on the sd card part while writing this, and I think I'd rather use the sd card as home and use the external the same way I use it with my other computers, as a supplementary mass storage device, not an integral component.
Thanks again to all.
-
Directory Persistence
For tce, opt and home try the following:
First, we need to tag the drive/partition you want to use; which for RasPi devices this is usually only the SD card, but even that's not a guarantee (usb sticks, etc.) so TinyCore rules apply to piCore as well.
You have two options; using the UUID of the partition or by using a label. PiCore does not have the extension e2fsprogs installed by default, so if you want to "name" your partitions you'll need to install this first, otherwise use the drive's UUID.
The persistence command is:
home=UUID=(The drive's long UUID# found by calling blkid)
opt=UUID=(The drive's long UUID# found by calling blkid)
tce=UUID=(The drive's long UUID# found by calling blkid) <- this one is scanned for if it's not entered into the command line.
If you prefer to "name" your partitions, the same method applies:
home=label=(The drive's named you gave it using e2label)
opt=label=(The drive's named you gave it)
tce=label=(The drive's named you gave it)
See http://wiki.tinycorelinux.net/wiki:boot_codes_explained
-
Note that you do not need to put /home and /opt on a partition!
/home and /opt will be added to the backup file by default. Mine is 260KB on my RPi and 860KB on my netbook.
Backup is re/created by Shutdown or Rebbot from the desktop or by executing filetool.sh -b .
What is actually included in the backup is controlled by /opt/.filetool.lst .
This means you need to remove home and opt from that file if you have setup persistent /home and /opt . Otherwise your backup file will grow to a needlessly big size.
Would I be able to save all my settings and create my /home directory there making use of the pi independent of the external drive in case I need it elsewhere, yet be able to just plug it in and still get easy access to my (example) videos?
I have some big files / folders symlinked to my home directory so only the symlinks are included in my backup.
Also the restore= boot code doesn't need to be used if the backup file is at the default location (/etc/sysconfig/tcedir/mydata.tgz)
-
Well, I did ask for specifics and I must say that these few but quick replies have made it all much clearer. I think I have enough now to go on. Picore is/was supposed to be a precursor to eventually replacing my current OS, Arch Linux.
I chose the Core family in part for its modular nature. If my reasoning is correct this will sandbox each running app with them interacting only where and as needed. Its a security thing, don'tcha know. Systemd is another factor I considered. Now if only I could find a comprehensive tutorial on inotify for the totally brain dead with an eye toward recursion. I got fsniper to work - one time only.
During the last couple of days I've been experiencing odd results while using zsh as my default shell. This is the third time in six months zsh has borked out on me to the point where I can't even cd from the command line. I've gone back to using bash as my default shell and will revisit fsniper and other inotify-related software to see how well it goes. I know that many have great success with it, but I'm not sharing their joy.
Thanks again one and all for the intelligent and pertinent responses. I dread asking for help in the forums because I seem to get a lot of "What do you mean by" responses. What do I mean by pertinent information? Hey, I ain't asking the price of bananas in Hondurus, so if that's what you're pointing towards ----Pass.
-
If my reasoning is correct this will sandbox each running app with them interacting only where and as needed. Its a security thing, don'tcha know.
Well, kind of.
The fact that apps are packed in extensions won't prevent running processes from being compromised in memory. Also files that are copied to the filesystem in RAM (f.e. config files) could be modified.
But since extensions are read-only, the contained files will stay intact and a reboot would "cure" the system, apart from compromised files included in the user's backup.
However, what I like about Core is that it's quite difficult to destroy, either by accident or on purpose. :p
-
However, what I like about Core is that it's quite difficult to destroy, either by accident or on purpose. :p
This is why I love the tiny core and it's in just runs in ram, and when something happens just pull the power cord and boot up again.
I Don't need to take the linux system down correctly. The system don't need to do some fsck at disc at boot up afterwards.
-
However, what I like about Core is that it's quite difficult to destroy, either by accident or on purpose. :p
This is why I love the tiny core and it's in just runs in ram, and when something happens just pull the power cord and boot up again.
I Don't need to take the linux system down correctly. The system don't need to do some fsck at disc at boot up afterwards.
Ant it is why piCore is ideal for appliances, like music players, internet radios, etc. where your wife can simply unplug without typing 'sudo halt' and it will work next time :)
-
I think I take centralware's suggestion and try tiny from a USB stick for a while.
-
One thing to note (after re-reading this entire post)...
When using PERSISTENCE (such as /opt or /home) please bare in mind you will want to avoid "Just pull the plug" if you can... since these directories WILL write to the SD card (mmc0) or possibly a USB attached storage, etc. the same rules apply about killing the power and risking data corruption in a main-stream OS. (With ext2 as a file system on all of the USBs/SDs here, the /opt partition has only been damaged TWICE in a number of years of beating the ------ out of TinyCore from flash memory, and granted, I many times just hit the RESET button as opposed to keyboarding a reboot command (especially on headless units), but the two times it HAS happened still caused grief.)
Suggestions for persistence:
A) Create a total of FOUR partitions
1) MSDOS/BOOT (~40mb is what we use here, starting at the beginning as opposed to 1MB in.)
2) EXT2 labeled tcopt (~100mb is ours, but that's due to a large amount of custom static files)
3) EXT2 labeled tchome (This depends on usage and storage needs IF needed at all*)
4) EXT2 labeled tce (The remainder of the storage drive)
* For any partitions you don't need, such as home in many cases, simply scratch it from the above list
By creating separate partitions in this type of manner it's easier to enter into cmdline#.txt AND in the event of data corruption occurring, you reduce the chance of multiple areas being affected (eg: If home were corrupted, it's less likely to take /opt with it. It's not fool-proof... but any reduction helps!)
-
Suggestions for persistence:
A) Create a total of FOUR partitions
1) MSDOS/BOOT (~40mb is what we use here, starting at the beginning as opposed to 1MB in.)
2) EXT2 labeled tcopt (~100mb is ours, but that's due to a large amount of custom static files)
3) EXT2 labeled tchome (This depends on usage and storage needs IF needed at all*)
4) EXT2 labeled tce (The remainder of the storage drive)
* For any partitions you don't need, such as home in many cases, simply scratch it from the above list
Never ever use ext2.
-
I think you could have ext3 and ext4 with out the default journal system.
If that's the cause of you selecting ext2.
When creating/formatting the drive you could just add...
sudo mkfs.ext4 -O ^has_journal /dev/mmcblk0p2
Or you could use tunefs to disable the journal.
I think the first is the best options.
I think you couldn't change when you using the drive, haven't tried my self.
sudo tune2fs -O ^has_journal /dev/mmcblk0p2
And can be listed by.
sudo tune2fs -l /dev/mmcblk0p2 | grep features
-
Why to use a non journaling file system?
-
It has to do with the nand technology.
To minimize the amount of writes to the nand disc.
I think, then dealing with the nand technology to reduce and get the best of all worlds, is to
use the file systems that have the correct way of doing stuff to the nand tech.
I don't know if ext4 has that support yet.
Every one is talking about another file systems when dealing with nand discs.
I am not the best guy to talk about this, have using ext2 for my Guruplug for long time in a sandisc usb thumb drive and it's working very well.
Here is a some good text on the web:
http://free-electrons.com/blog/managing-flash-storage-with-linux/
http://elinux.org/images/d/de/Managing_nand_flash_elce.pdf
https://www.lip6.fr/public/2012-11-15_Boukhobza_Flash_Final.pdf
-
You can refer several articles, bologs, what ever you want. Bee practical. During 10 years using USB sticks and SD cards with ext4 file system it never happened to me that one of them died because of too wear out. But in every two month I would have loose all of my work without journaling on ext2. Thats all.
So, your advices are welcome. But please, not in the piCore documents and tutorials section, where using ext2 file system is strongly discuraged.
-
@Béla: PatrikG is correct, EXT2 was chosen (years ago) as the default file system due to the lack of journaling/indexing to limit write calls to flash based media. Not having a single TF die within a decade sounds like a blessing! In the same decade, we've likely melted no less than 100 USB/SD/uSD cards (our means to dispose of them when they begin failing). Mind you, for sensitive content we use USB Flash media in addition to storage hard drives for redundancy, but considering factory specs for both types of media AND the failure rates for both types we've endured personally, the easiest way to prove/disprove the concept is to monitor mmc0 write states with a persistent home/opt directory and then run the SD card through an SD testing application and see for yourself the numbers and then compare them against the lifetime expectations the factory sets out. (I imagine compiling a kernel a few times located in /opt/kern#.#.# should do the trick of giving the card a litte mileage :) ) This information would be FACTORY level... not a blog or a rumor. (One would "think" the people who build these chips might have a clue? Though I've met some who don't! :) )
Back in the day, the rule of thumb was "...1,000 writes per byte of storage multiplied by the total amount of bytes available, subtract 5% for error correction bytes (we use a 2% model) and you'll have a basic idea as to how many written bytes, maximum of storage the card will endure before failing or before being considered unsafe..." This math was done based on averages of how much content was written within a day's time for each workstation utilizing these cards/chips.
For our development clients (whose projects are uploaded onto flash based media for editing or review and random-dd-written afterward for security):
The brands of USB storage we've purchased: 14 USB2 and 3 USB3 lost since 05/2010
The brands of uSD storage we've purchased: 43 uSDHC and 7 uSDUHS lost since 05/2010 (which we use more frequently)
A few of these were due to physical damage (ie: USB connectors wearing/breaking) but at least 97% are due to disposal if/when flash block failure reaches 2% or exceeds the math above within 10% without detected failure.
Note: Since 2010, the number of lost hard drives has more than doubled compared to 2000-2009 regardless of file system. I have 80+GB Y2K IDE hard drives still in operation which have outlasted 1+TB SATA3 drives which were less than a couple years old. They truly don't make things like they used to.
@PatrikG: The ^has_journal switch - I will be looking into this throughout the week. Thank you.
-
Well, couldn't you just sh t (missing letters are 'o' and 'u' --maybe)
Finally decided that only fear and good-judgment were holding me back until I told myself that I would be using non-volatile data (i.e. easy to replace) to start with anyway and put piCore on my rpi a while ago. Remembering that no matter what keys I pressed would not cause the of some cute and furry species I started playing around with different boot codes and as far as I can tell, the world did not end. I really don't know what I was worried about. Everything so far is working just fine.
Sorry for joking around so much but I'm just coming out of my annual major depressive episode and I'm over-doing it a bit.