picore documents and tutorials

[Captain.Midnight]

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

[Misalf]

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

[CentralWare]

@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.

[Captain.Midnight]

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.

[Misalf]

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.

[Misalf]

Oh, yes. Also the FAQ, of course:
http://tinycorelinux.net/faq.html

[Captain.Midnight]

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.

[CentralWare]

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

[Misalf]

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)

[Captain.Midnight]

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.

[Misalf]

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

[patrikg]

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.

[bmarkus]

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

[Captain.Midnight]

I think I take centralware's suggestion and try tiny from a USB stick for a while.

[CentralWare]

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!)