Installing fatdog64 800 to a: Acer Aspire R3-131T.

[mrpete]

NOTE: To forum members; if you have this particular device or a device that has similar characteristics, this might help.
Note to Administrators and moderators: This information may be redundant or in the wrong place.
Though, my intention(s) are meant for information specific to an Acer model netbook(Aspire R3-131T and like situations).
It is meant to be of relevance in light of all Puppy linux distributions and its child derivatives. Therefore, Ive chosen to
put it in trouble-shooting and the fatdog64 800a thread as it pertains to both subject matter. Please let me know
if I've placed this in error.
--------------------------------------------------------------->

The information contained below does not deal with a dual-boot situation with Fatdog64 720-800a on this model.
Instead, I deal with a fresh start scenerio in the case of an open-box architecture without an OS pre-installed. I'll
explain my reason for this by saying what everyone generally will discover one-way-or-another. The Windows 10
included with most of these models outgrow the initial (EMMC) SSD that it comes boxed in with constant UPDATES
over time without the end user being able to do anything about it.(from a root drive perspective). NEW people to
computers and the like might be saying: "What was that all about..... A drive without the capacity to see the life of
the net/notebook out!?!!?!?...".

Despite all of this and the fact that this particular note/netbook comes up in other post elsewhere on the internet with
linux install problems of sorts. It still has good functionality as a device and in the case of Fatdog64 it works excellent from the start.
Besides, why get rid of it for the sake of a Windows only system..

Many issues that i've read on this forum and other forum sites that are dedicated to problems booting with this particular device or it's derivatives.
Touch on the fact that BOOT loader(s) such as: GRUB 2.02/rEFIn(d) are used to start the initial boot process and when/or if a problem occur.
Give extra support options to aid getting the boot loader to hand off the root partition or a secondary partition to start the kernel process going.
From there in theory, the kernel should take over and load up. In LIVE BOOT situations off USB/CD(<--CD becoming less) there's usually no probs.

The 'Aspire R3-131T' doesn't work in the sense of normal BOOT scenerios. After reading many forum responses from puppy and other distro
sites. Most situations were solved by a normal passing of extra kernel or loading options given by a particular distro at BOOT time.
However, when trying to install various Puppy and other Linux distro's on the primary drive in UEFI-no SECURE mode with a 'Aspire R3-131T'.
It would fail no matter what after the boot loader got the main kernel files going(initrd and vmlinuz)... Again, this is solely from frugal installs from
LIVE USB's since most puppies want this type of install because its ez of use.

The primary problem in the case of the LIVE-USB puppy installs that I tried on the primary device of the 'Aspire R3-131T'. Is that most distro kernel setups
are expecting the hardware device module(s) (specifically the drive map-out) to be ready before-hand. Or, should I say before the kernel setup has
started. This is shown by the fact-that Fatdog64 takes a different approach to it's distribution setup in line of other puppy and linux distributions alike.

I'll give reference to this at the end of this post along with other puppy's I tried with this particular net/notebook model: But for now I'll explain
installing on Fatdog64-800a. I know it's very new as to the date of this post but It still supports the option before this version. But I don't know for sure
as to the version prior to Fatdog64 7.20. Regardless, it should install using 7.20 and above on the Aspire R3-131T.

The following will be layed out in the sense of an instructional with references to the Fatdog64 site, just follow the instructions in order.
If there is a mistake then please start over and try again with given emphasis to the fatdog64 site references. Especially, if one is NEW to the whole
puppy and net/notebook experience. For person(s) of the advance stature it won't take no time at all but please bare in mind of this writing being for
NEW experiences 1st(at least that's the intent).

NOTE: Again, this is for a single partition loadout of FATDOG64. NO WINDOWS 10,etc...NO DUAL-BOOT!!!!!!. Decide hard if one is tired or can't deal with
windows or wants a minimal Linux. Fatdog64 runs great on this piece of hardware out-of-box. So, it's a good choice to start with for basic needs.
At the end of this one should be able to boot from the internal eMMC device period!!!!

MODEL NAME: Acer Aspire R3-131T-C1YF
OS: Windows 10 Home
LCD: 11.6 Multi-touch HD LCD
Graphics: Intel HD Graphics
MEM: 2G DDR 3
STORAGE: eMMC 32GB
WLAN/802 11ac + BT
etc,etc...

1. Boot->Setup UEFI mode with Secure mode enabled. You'll HAVE TO set up a password for this. (F2) gets in on this model:Security-->Set Supervisor Password.
Make simple password save it then restart(exit Saving Changes).-->Main-->Touchpad=Set to basic.
2. (F2)-->F12 Boot Menu enabled--->Security->Erase all secure boot settings...-->Restore Secure Boot to Factory Default.
3. Clear TPM(TCM) state. Change TPM(TCM) State to Disabled. Erase all Secure Boot Setting:, Restore Secure Boot to Factory Default.---> Save Changes(this will restart).
[NOTE: TPM/TCM in general is a Window's security feature]. Erasing it and disabling it has no effect on the Fatdog64 install.
Clearing and disabling it is optional or a last resort. I did this to flush any and all of Windows security records stored. Its said to interfer with some Linux distros.

NOTE: I do the above for a total reset of the machine state. Some options do not need to be reset and others are for the ease of use. I won't assume the end
user got their device from a friend who has done who know's what to it, or was bought from the internet/store.

I also hooked a mouse to navigate through fatdog64.

Now the Fatdog64 reference:
(A.) http://distro.ibiblio.org/fatdog/web/fa ... drive.html
(B.) http://distro.ibiblio.org/fatdog/web/fa ... rive2.html

I did (B.) reference because I had a 2GB laying around that already had a GPT/UEFI setup on it. Again.. Legacy mode is not used in this setup only UEFI mode.
Basically: After the described setup these 4 files:

efiboot.img
vmlinuz
initrd
grub.cfg
fatdog.png

Open terminal and cd to the path that contains the file efiboot.img. Then type "filemnt efiboot.img". A Rox window will appear. Do not close the terminal window.
Copy all the files from this window to your FAT32 partition.
Type "filemnt efiboot.img" once again on the same terminal that you did step 6. The rox window should close.

http://distro.ibiblio.org/fatdog/web/fa ... -boot.html

This will give your USB device access to load from. It only has to be done once.

http://distro.ibiblio.org/fatdog/web/fa ... drive.html

GPART and format your drive (EMMC) in accordance to what has been mentioned in the reference. (generally, it will be seen as: mmcblk0p1.)
DO STEPS: 1-2. rEFInd is not needed on your harddrive but it won't hurt as long as it can launch the Grub2.02 setup.....(
INSTEAD OF MOVING TO STEP 3. STOP...DO THIS:

(B.) http://distro.ibiblio.org/fatdog/web/fa ... rive2.html

YEP, DO what you did in the original USB setup from above. I did (B.). Or, COPY your USB over to the 1st FAT32 partition of your drive (EMMC).
Verify after the copy is done; That 'grubx64.efi' or 'bootx64.efi' exists in the: EFI/BOOT/ folder or directory on the 1st partition of (EMMC)(dev/mmcblk0p1).
NOTE: There will be two partitions and your usb device's device listed on the desktop of fatdog64.
In general should be on the desktop: mmcblk0p1,mmcblk0p2,(USB device name...something like sda1,etc...)

In the 1st partition(mmcblk0p1) you will find a: 'grub.cfg' file.
Open it as a text file. Then change the menu entry 'Start Fatdog64' to this below:

menuentry "Start FATDOG64" {
linux /vmlinuz rootfstype=ramfs coldplug
initrd /initrd
}

Save 'Grub.cfg'.
Unmount the 'USB' and take it out.

Reboot. But DO NOT SAVE. It will not do you any good because you'll want to test if you done the steps rite in order to get to the grub boot loader
on the next reboot. You may have to register your grubx64.efi from your drive(not the USB) in your BIOS like you did your USB.
(F2)->Security->Select an UEFI file as trusted for executing.
YES it can be that picky about the situation. This is why SECURE BOOT HAS TO BE ENABLED AND DISABLED(at least on the Aspire I'm speaking of).
It has a very simple UEFI/BIOS setup. In fact, compared to motherboards and other devices of it's genre it's pretty simple.
If everything works well you'll finally disable 'SECURE BOOT' in your BIOS in the long-run.

Again, this is why 'F12' comes in handy. It's the Aspire's boot menu to boot devices. If not you'll have to adjust the boot order in BIOS.
If all is well, then you will boot into grub and select the :"Start FATDOG64" menu entry. If it fails something was not don't rite....

If it works then you will see a pre-hardware detection and mod probe. Something like this.

'Detecting hardware modules and loading.....'
(alias mod.....etc,etc.)

Until Fatdog64 loads into it's desktop. Once into it you can do all the changes test and play with settings etc,.
NOW, for the save session part.. Your second partition (mmcblk0p2) is where you want to save upon
reboot or shutdown. Not the (EFI) partition (mmcblk0p1). Why?,. Because 1G is not gonna be enough for
a conventional save in fatdog64. So, put it on the second partition with the practices stated by the
Fatdog64 developers(Jamebond,Kirk and others). You'll want to abid by the practices that the 1st partition
is your EFI boot drive. This is in practice with the UEFI/EFI standard talked about in the UEFI references.
Though, I have you place FATDOG64 on the 1st partition its just so that you may become familiar to what
is going on in this example. Fatdog64 will not grow on the EFI in it's basic config. But it's save file will exceed it
on the 1st save so don't do it.

*NOTE* When saving you'll run through a series of dialogs.. You get to a dialog stating: 'saving as what filesystem'.
select: 'ext4-no journal' There is an advance option explained in the FATDOG64 help guide about saving on (eMMC)SSD and on SSD's in general.

Yes, for new people and other's who want to know.

http://www.rodsbooks.com/refind/
And check this one out too..
https://www.gnu.org/software/grub/manual/grub/grub.html

*THIS ENDS THE TUTORIAL PART OF THE FATDOG64 INSTALL TO THE PRIMARY DRIVE OF THE Acer Aspire R3-131T:*

Ok, advance operator's and user's of Linux will know what I've just explained for this model of the net/notebook tablet. They even
know why........ Some might say...'Hey mrpete..,,,, there's nothing really special about this setup.....'. Perhaps, grub will work in
legacy etc,etc.

Now, I intentially went the long way on this description for a reason. Primarily, for new people as stated above.
I admit, it's long but informative to others.....

REMEMBER THIS excerpt from above:

"The primary problem in the case of the LIVE-USB puppy installs that I tried on the primary device of the 'Aspire R3-131T'. Is that most distro kernel setups
are expecting the hardware device module(s) (specifically the drive map-out) to be ready before-hand. Or, should I say before the kernel setup has
started. This is shown by the fact-that Fatdog64 takes a different approach to it's distribution setup in line of other puppy and linux distributions alike."

The Puppy distro's that I tried off LIVE USB/CD start up well or break between the kernel state......Or, did not do one thing at start and couldn't do another at
the end of their sessions!!!!!(With relative ease.. or not at all.) There were other's aside from the Puppy LIVE derivatives. Unfortunetly,
they produced the same results..

FATDOG64 does it's commands a bit different because of it's build.

http://distro.ibiblio.org/fatdog/web/fa ... tions.html

HERE:

Advanced Troubleshooting / Debug Parameters
These parameters are listed here for completeness. Do not use them unless, you understand what you are doing, or unless you are asked to for troubleshooting purposes. Some of them are harmless but others can cause improper functioning of Fatdog64.

**coldplug
Do hardware detection and driver/module loading as early as possible at boot-time. This option is automatically enabled if you use the net parameter - it is required to load the network drives (modules) before network can be started.

**loadmodules
This parameter is the opposite of blacklist. It tells Fatdog64 to load specific modules that are not automatically loaded, probably because it is not detected or because it has a conflict with others modules. This can be used to load any modules, although it is meant for loading modules required to access save devices (the device where the savefiles are located) - although if this is the case, coldplug may be a better option (at a cost of slightly longer boot time).

The syntax is: loadmodules=module1,module2,module3 and so on. Note: separate module names by comma, and there is no space in between. If the modules are not required during boot time, don't use this parameter. Put the module names in /etc/modules (one line at a time), or load the manually by adding the appropriate command to /etc/rc.d/rc.local instead.

Hardware detection (coldplug) is done twice (at least); n specifies how many seconds to wait between each round. The default is zero. This parameter only has effect when coldplug is being used.

**DRV_DEBUG
Show the summary of modaliases processed. Use DRV_DEBUG=verbose to display all the modaliases as they are being processed. This parameter only has effect when coldplug is being used.

**earlyshell
Get a shell as soon as it is possible to do so. You will be running in busybox environment at the beginning of the init process, just after modules have been loaded (after loadmodules/coldplug are processed), but before anything else have been done. Only /dev, /proc, and /sys are mounted. This is in contrast with earlier Fatdog / Puppy Linux "pfix=rdsh", which launches the shell after the stackable filesystem has been constructed (see below). Type "exit" to continue system startup.

Note: The shell you are running is not PID 1, you cannot switch_root inside it.

**lateshell
Get a shell just after the stackable filesystem has been setup. This enables you to modify the root-to-be filesystem, for example during troubleshooting. The root-to-be filesystem is located at /aufs/new_root. You will still be running in busybox environment, in the very final stages of init process. After this, the system to switch the root to the stackable filesystem. This option is roughly equivalent to Puppy Linux "pfix=rdsh" boot option. Type "exit" to continue system startup.

MY EXAMPLE: Just to highlight the: 'COLDPLUG'
menuentry "Start FATDOG64" {
linux /vmlinuz rootfstype=ramfs coldplug <----= Cold plug essentially, tells Fatdog64 to start hardware detection and module loading early. Before the **lateshell.
initrd /initrd
}

And This is why:

Cold plug essentially, tells Fatdog64 to start hardware detection and module loading early. I used it as a work-around before the **lateshell for debugging purposes and to prove a theory.
As Jamesbond,Kirk,and other's(the creator's of FATDOG64) state: 'coldplug' is used for networking setup's that want to run Fatdog64 in a network scheme.

From the reading of their site and their suggestion as an quicker alternative to 'mod' loading I used this option to test the fact that some distros are still used to doing
things thru the legacy style setup. Despite, being 64-bit in nature and using the new UEFI bios setup with bootloaders.

The reasoning again comes from these two links:

http://www.rodsbooks.com/refind/
https://www.gnu.org/software/grub/manual/grub/grub.html

BTW, the '**' above note the specifics that FATDOG64 offers for certain system configuration's. I used them as a workaround for this particular device:(Acer Aspire R3-131T)

In short, every distro other than fatdog64 that didn't offer this option couldn't load after 'initrd' or 'vmlinuz' initiated thru the boot loader(grub,rEFInd,or themselves,RAM,etc)
because their distro setup couldn't give or did not give the option to load hardware or module detection prior to reading or writing to the devices. At least, without a script!
Which,BTW, is DISTRO specific!. In otherwords, most of the distro's I tried(and only the few 64-bit one's I like for my personnel reasons) were expecting to pick this information up at anytime
when the kernel felt necessary because of the convenience of the legacy style system presenting this info at the initial startup(power-up). With the newer (UEFI) system it get's the kernel where it
needs in memory but leaves it up to the kernel to do the 'find everything else' out for itself....

What happens because of this...... Kernels break.....Because they can't find other parts to complete the loading process.
Or, they load everything and all is fine but their save file cannot be found at the beginning of the session(this would be do to loading everything into ram at start: or 'init' without storage device info).
Which was the only case with Fatdog64. Fatdog64 without the 'coldplug' command would always load up in pristine condition. When it came time to save a session it would but when it rebooted or
powered on, it would not load the 'fd64save.ext4'. Regardless, of passing of extra commands such as save file location,device, UUID,LABEL,BLKID(GPT or not)....
This also happened on the legacy side as well. The bootloader would install and bootup. The kernel would load but the save reload wouldn't be found after reboot.

Other LIVE distros unfortunetly, didn't have the same luck! Here they are below with a brief description as what happened.
Bare in mind, that I did try the included commands that where suggested by the distros. Some are not Puppy specific distros and other's I attempted to trick the bootloader with no success.

*Fatdog64-800a.iso:(I like this distro alot as 64 bit puppy) Works as stated above. Load's fine but cannot read save file with the 'coldplug' option after reboot or startup.
*xenialpup64-7.5-uefi.iso(I like this distro alot as a 64 bit puppy): Broke from live/USB/ when the kernel started looking for the (eMMC).
From CD it load's fine but breaks after install with same kernel start scenerio.
*xerus64-8.6.iso:Broke with same kernel load-in scenerio as above. I didn't try the CD equivalent.
*easy-0.9.4-amd64.img.gz: I got it on usb and it could never find itself through yumi(I believe). I know Barry has made a pristine live CD version just to evaluate
but I haven't downloaded it.
*Lubuntu64....... Broke from live/USB/ when the kernel started looking for the (eMMC). I didn't try the CD version.

!!!!When I say broke, I mean as a processor TRAP VIOLATION!. Which pointed to not finding the devices blk id and dumping the last processor state. I had to hold the power to shut-down.

In closing, I hope this helps someone not to give up on their old hardware because of this limitation. For fatdog64 the longway I explained can now be condensed into this type
of frugal install...

1.) Create EFI boot drive:
2.) Create secondary partition: (fat32,ext...,etc)
3.) Copy the Fatdog kernel files to the second partition.

vmlinuz
initrd

4.) Use 'coldplug' parameter then have grub point to files in the second partition. Fatdog64 at this point will find any saved files via itself or 'savefile' parameter.

MY EXAMPLE:
menuentry "Start FATDOG64" {
set root=(hd0,2) or set root=(hd0,gpt2)<---= This depends on your configuration.. On mine it looks in my secondary partition I made.(around 10GB).
linux /vmlinuz rootfstype=ramfs coldplug <----= Cold plug essentially, tells Fatdog64 to start hardware detection and module loading early. Before the **lateshell.
initrd /initrd
}
--------------------------------------------------------------->
How Fatdog64 800a worked with the Acer Aspire R3-131T.

Chrome worked good. Had to get GTK3 beforehand thru it's distro..
Hibernation:...???? Did not try.
Suspend:WORKS.
Touchpad:WORKS.
Basic included packages:WORK including the basic 3D stuff.
WIFI: worked out of the box. I was able to create a profile for my phone and use it immediately. Since I live in a rural-backwoods arena I was impressed.

Closing thoughts; I thought Fatdog64 rocked on this device.