(old)Puppy Linux Discussion Forum

Idea is to add tools and a selector GUI to FatDogArm (Raspberry Version) to replace the functionality of very useful BerryBoot2 with even MORE useful FatDogArm.

download zip here: PENDING...

Core to idea is a copy ONLY install methodology [ just like my Grub4EFI.zip ] to protect the SDcard Flash chips from abuse and leave them in FACTORY formatted condition for improved speed and write-balancing

Reserved

First success.. loading FatDogArm into RAM to freeup SDcard <which can be removed from a running Raspberry Pi2B, to boot other Raspberry Pis, I am cheap SDcards are NOT >
Here is my cmdline.txt to do so This includes setting up a usb harddrive to save back changes in single SquashFS files per session. in this its sda3 which is my default NTFS D: as seen in my windows8 & 10 laptop drives.

I am using ezDISK EZ520 USB3.0 hard drive enclosure 2.5inch Couple Edition from Amazon to provide raw laptop drives (with screws removed) to reuse the windows8 laptop hard drive. Still under 10USD for two set of 'holders'
I am not linking here since I did that before and the price bumped up almost 2 USD

http://www.newegg.com/Product/Product.a ... 6T62T65264

same product/price at newegg.



I do not shop much at newegg anymore, since, I had a defective product and cost me 10USD to return, months of emails later finally got refund without shipping covered.RaspBerryPi HATES the EZdisc, had to backfeed anyway, bummer.

Originally wanted this:


but the reviews where LOW stars. I will play with the other product from same manufacturer for a few months before getting this, reason is able to back-feed 5V to USBs plugs to make a multi-laptop harddrive 'RaspPi' server NOT bog down rest of 5V line due to high current draw via normal poly-fuse.
This version I currently use does NOT have the normal USBmicro plug I use with other usb hard-drives which I have a cable to backfeed 5V to keep stuff stable on RaspBerryPi2B+

Second success: reusing BerryBoot2s image files and having them load into FatDogArm layered system.

Simple for those who want to play along and provide feedback and wish lists.

Copy from BerryBoot image directory and rename .img files to USB harddrive adding .sfs to the end of copied file.

Clicking on renamed file opens it to view.

one thing I think is happening with BerryBoot and not a method used with FatDogArm is a overlying layer for compatibility, not generally needed when running a sandbox copy of slaco32.sfs or a duplicated sandbox of fatdog64s squash file.

TODO CEC control enable in FatDogARM..
at a stopping point and wanted to recall correctly if BerryBoot supported using the TV remote via HDMI as a selection 'mouse'. it does and really impressed with kodi playback AGAIN. 1080p with lots of action oh so nice.

Downloaded newest raspBerryPi version with kodi, unzipped it and used kpartx -ar to mount image, copied files to base of FAT formatted SDcard and it run beautifully, used the SYSTEM file which is a squashedFS as fatdogarm renamed and tried to boot it but FarDogArm did not like the missing getty application.
So re-renamed it to kodi.sfs, replaced fatdogarm original file and currently rebooted back into FatDogArm. Copied kodi.sfs (called SYSTEM normally ) into /tmp and at a stopping point, tired eyes, lost my train of thought.
Plan to try to mount /proc /sys etc.... and chroot, but forgot all the steps. So on hold for now...

kodi.sfs is very small just over 100M so hopeful to run both FatDogArm and Kodi.sfs distro together all within RAM.

Is removing the sdcard very useful??

____________________________________

It is to me... can't crash/corrupt it if its not part of the mix. FatDogArm does come with a sandbox.sh, it did take my kodi.. and I tried it with startx and BAMP locked up, no mouse or touch pad available, so yes its useful since I will have to kill the RaspBerryPi by janking the power..
Also same SDCard in the adapter that came with it booted my computer I am typing this ( FatDog64 ran same way 100% in RAM, no install )

Well its dead Jim, or is that James ( McCoy ) Bond... lol frozen screen finally turned off HDMI so that part of the X windows still worked trying blind control D , Control D DDDDD to drop the chroot but not being active. bummer, learned all I can, time to pull the power and reset the environment.. Starting again.
First layer sandbox attempt = FAILURE! locked box.

Well reviewed the sandbox.sh scripts and saw that my SFS file could only be an option if its was right click loaded not just openned. But right click load overlaid orginal FatDogArm files and when I tried to restart X. It froze again without sandbox.sh, so its not sandboxes issue its X. or to different of an X / kernel or some other issue.
Will play with sandbox more to see if I can pass it an umounted SFS file seems to support such an occurrence, but not see it as an option. Second try ends in locked X as well.

did not remove the SDcard before second lockup... corrupted it




oh well time to rebuild from backups... if I remember where I last backed this SDcard upto. its just files and copy should restore most lost last two + days.

See @DON, did not remove SDcard and it got fried!!! Not like I knew better.

Picked the right backup harddrive, found backup files, I am in good shape.. last touched Jun 2015.

Back to where I was before corrupted SDcard, going to call it a day and play with Kodi again, without FatDog this time.

To Ted Dog..

I thought about a reason to remove a SDcard...

If there was a classroom of 30 raspberry pi computers, each one with a
SDcard in its slot needed to run debian Raspi ,
there would be a temptation for the students to steal the SD card.

Alternatively if fatdog arm was run in RAM the teacher would need only
one SD card and be in full control.

_______________________________________________

don570 wrote:To Ted Dog..

I thought about a reason to remove a SDcard...

If there was a classroom of 30 raspberry pi computers, each one with a
SDcard in its slot needed to run debian Raspi ,
there would be a temptation for the students to steal the SD card.

Alternatively if fatdog arm was run in RAM the teacher would need only
one SD card and be in full control.

_______________________________________________

As a teacher that had mouseball stolen so unprepared students could get out of work.. that is EXACTLY my purpose. Also a cost reduction. My long range view is to expand this selection of distros to individual packaged class projects. It will be more apparent as I go. Each student will have their own usb flashdrives ( was being done decade ago for English at my school ) to store work and take home to finish as needed.

Second is loading SDcards or preloading microSD cards while RPie is in use, can't do that today. Also since FatdogArm is a single sfs file makes that easy. When working what I plan the FatdogARM is preloaded and running. With crontab we can close the open distro students are using ( FatdogARM maybe running in a sandbox like any other distro but base FatdogARM is still running under other distro. ) This will allow time based automatically shutdown and starting next classes project to occur without teacher or student needing to load much. That has always been a unproductive time waste.