Puppy Linux Discussion Forum

[disciple]

[mikeslr]

Hi disciple,

As I, a layman. understand it, pae --Physical Address Extension-- is something built into a kernel, or not. Essentially, if built in, it enables a 32-bit computer to access more than 4 Gb of RAM. But, unless the "No Execute" feature is also builtin*, it results in a performance penalty.

Think of driving thru a one-lane tunnel, but still having to constantly check to your left and right because you've been programmed to do so to take into consideration what the cars in other lanes are doing.

A fairly thorough discussion of pae vs. no pae was had on this thread stared by Q5sys: http://murga-linux.com/puppy/viewtopic.php?p=686274#686274. On that thread I mentioned a professional lab's tests. They can be found here: http://www.phoronix.com/scan.php?page=article&item=ubuntu_32_pae&num=1

Further information can be had on the Wikka, http://puppylinux.org/wikka/PAE.

* Not answered on Q5sys's thread were questions such as whether "No Execute" instructions were built into any Pup using a Pae kernel? and which Pups? and what exactly the "No Execute" instructions do? Although their name and the context they were referred to suggest they have something to do with how PAE operates, do they? And if all they do is turn off instructions to "check RAM beyond 4 Gbs" haven't they just done nothing more than convert a Pae-kernel to one which functions like a non-Pae kernel [of course, using computer resources to do so]?

To top it all off, I have yet to find a 32-bit Pup which under any circumstance had occasion to use 4 Gb of RAM, let alone a need for more than 4 Gb of RAM.

It always come down to a question of the most efficient use of resources.

Until 5 years ago, few PCs were manufactured to support 64-bit operating systems. Fewer still were sold with more than 4 Gb of RAM. Subsequently, even if the version of Windows which came with a new computer was a 32-bit system, the computer itself was manufactured to be capable of running a 64-bit OS, and into which more than 4 Gb of RAM could be installed. From an manufacturer's standpoint, one facility manufacturing/assembling one 64-bit capable CPU and motherboard computer is more efficient than two facilities: one for 64-bit computers and one for 32-bit computers.

mikesLr

[mikeslr]

Hi All,

Edit:
It appears that this thread presents a solution to a problem which doesn't exist. See Cat&Dogs's post: http://murga-linux.com/puppy/viewtopic.php?p=865738#865738

I'll leave the following as it may provide newbies with some insight into How Puppies Work and their flexibility in doing so.

It has occurred to me that there may be a workaround for any potential limitations of a loop-booted Pup. It should be possible to install pets “temporarily”. The initial step of installing a Pet (deb or tgz/txz) copies it into RAM. [In a Pup using a SaveFile, the new App does not become a permanent part of the OS until a Save is performed. But this may take place automatically; so you may be unaware that there are two steps]. Once in RAM, restarting X --Menu>Shutdown>Restart X-- will cause Pup to recognize its presence.

Of course, once you reboot or shutdown, whatever is in RAM will be cleared. An easily reached location to store pets (debs and tgz/txzs) would seem prudent.

To get an idea of why I think the above and the following should work, and their limitations, see my post setting out my layman's view of Puppy's "Merge-file-System": http://murga-linux.com/puppy/viewtopic.php?p=862192#862192.

A Pup's native ability to make use of SFSes provides other options.
“loop-booted” Pups should be able to load SFSes-on-the-fly: Menu>Setup>SFS-load. If so, than you should be aware that RSH's PaDS pet, http://murga-linux.com/puppy/viewtopic.php?p=658359&sid=01ffb810f87f7a31a8da938ef68340d8#658359 can be use to convert any pet, deb or tgz/txz into an SFS.
And if “loop-booted” Pups can create SaveFiles, the following technique can be used to convert such a SaveFile into an SFS:

1) Create a folder with a unique name: for convenience, I suggest a date, such as Aug282015, making it easy to “update” future changes by creating a new dated SFS. For purpose of illustration, I'll use Aug282015 as the name chosen. The folder should be in an otherwise empty temporary folder and, as you're probably running your Pup from an ntfs partition, it will have to be in RAM, such as at /root.
Browse to /root and (if using Rox) right-click>New>Directory, name it such as Aug282015.
2) Open a second file-browser window and browse until you see your Savefile.
3) Left-click it (which mounts it) and then “Show hidden files”: Using Rox, just left-click the “eye”.
4) Click an empty space in the mounted SaveFile folder (to make sure your next action will apply to that folder) and then press Ctl-A. All the files in that folder –including the previously hidden files-- should now be “highlighted”.
5) Click and hold-down the mouse-cursor on any file. If other files are no longer highlighted start again with the Ctl-A instructions.
6) If all the files are still highlighted, drag the file you're clicked-on into the “Aug282015” folder and select “copy”. All the highlighted files should have tagged-along with the file you had selected.
7) Left-click your SaveFile again to unmount it.
8 ) Browse to /root. You should now see your folder named Aug282015. Right-click an empty space and select Window>Terminal Here.
9) Type the following command: dir2sfs Aug282015. An SFS with the name Aug282015.sfs will be created in /root.
10) Move Aug282015.sfs to your hard-drive or USB-Key, otherwise, along with everything else in RAM it will be extinguished when you shut-down/reboot.

Such SFS may not be as effective as an actual SaveFile since a SaveFile and its contents have priority while other SFSes don't. But it should --at a minimum-- enable you to quickly load-on-the-fly your standard settings/configurations. This is because no other SFSes will contain files which will be copied to the settings locations in the "merge-file-system". Restarting X may be necessary for SFSes to take effect.

Most Pups can only load 6 SFSes. But, if you search the forum, you'll find applications to combine SFSes. [Or you can use the manual technique above to combine several SFSes: just drag the contents of the 2nd, 3rd etc. mounted SFS to the folder you'll convert to an SFS]. Before doing this, run the SFSes at the same time to make certain they're compatible. When you merge SFSes, the files of the 2nd will overwrite files of the 1st, the 3rd overwrite previous and so on.

Lighthouse and JustLightHouse can load more than 6. I'm not certain whether there's any limitation.

mikesLr

[mikeslr]

Hi All,

Honestly, the primary purpose of this post is that although this thread been view 1929 times in the last month and a half --suggesting that newbies have some interest in its contents-- as there have been no recent posts to this thread it is now buried on page three.

Rather than our having to begin from scratch answering the questions newbies owning Windows 8/8.1 and 10 computer have in trying to run Puppies, this post will serve to bring it back to page one, just below the stickies.

Secondarily, this post notes that Billtoo recently installed Tahrpup64 to a USB-stick using PUI. He runs it on a macmini. http://murga-linux.com/puppy/viewtopic.php?p=865121#865121. By PUI, I think he is referring to Puppy Universal Installer which you'll find on every Pup: Menu>Setup>Puppy Installer.

The macmini boots using efi --mac's version of UEFI. TahrPup64's ISO does include those files needed to boot in "UEFI-mode". See http://murga-linux.com/puppy/viewtopic.php?p=860159#860159 for my definition of that phrase. But neither does the macmini AFAIK have anything similar to "Secure boot".

So it may be possible to install Pups via Puppy Universal Installer. But I would think on what were Window 8/8.1 --even if "upgraded" to Windows 10-- it would still be necessary to follow Steps 1 and 2 here: http://murga-linux.com/puppy/viewtopic.php?p=858159#858159

mikesLr

[mikeslr]

Hi All,

Just to call your attention to Cat&Dog's successful use of Ted Dog's "Ready-Made" UEFI Boot-files, enabling FatDog701 to be booted from a USB-Stick.

Cat&Dog provides a Step-by-Step explanation of what was done, including modifications of Grub. http://murga-linux.com/puppy/viewtopic.php?p=865706#865706

Note this method resulted in (what I referred to previously as) loop-booting FatDog701's ISO.

mikesLr

[cat&dog]

[bones01]

Mikeslr, thanks for putting all this together. I haven't had any trouble running Puppy on my Windows 10 laptop from a USB, but was really frustrated that I couldn't mount the Windows drive or access my files there because "windows had not shut down properly". Searching google and microsoft didn't help me find the answer, but your first post did.

And I'm a little embarrassed that the answer was really as simple as unchecking a box.

But I found the answer here, and for that I am grateful to you.

Enjoy your day.

Bones

[mikeslr]

Hi All,

Fortunately, cthisbear has some experience with Windows 10 and replied [2nd Post] on this thread: http://murga-linux.com/puppy/viewtopic.php?p=871098#871098.

Hopefully, the instructions pertain to Windows 10 installations beyond those on the ASUS notebook x205ta there involved.

mikesLr

[mikeslr]

Hi All,

Thanks to starhawks response to a question on the Beginners Forum this link, its procedure, and the downloadable bootimage were called to our attention:

http://blog.hansenpartnership.com/linux-foundation-secure-boot-system-released/

mikesLr

[starhawk]

Thanks for the cred, man!

[mikeslr]

Just a link to, as of this date, the last four posts on the Puppy Window Installer thread I considered worth knowing about. http://murga-linux.com/puppy/viewtopic.php?p=863935#863935

mikesLr

[mikeslr]

Hi All,

Just a link to more good information by cimarron regarding problems booting Windows 10 with possible solutions. http://murga-linux.com/puppy/viewtopic.php?p=878278&sid=36254fb8e54187b4f6828b6551c2dfd0#878278.

The link is to his last reply. So read the entire short thread to understand prior efforts and the context.

mikesLr

[mikeslr]

Hi All,

Just a reminder to turn off FAST Boot even if you can boot into your Pup. Fast Boot may still prevent you from accessing hard-drives. http://murga-linux.com/puppy/viewtopic.php?p=878902#878902. Thanks, vvvora, for the pointer.

mikesLr

[Wognath]

A bump for this topic, which has been very useful. Many thanks, mikeslr.

My daughter recently purchased a Toshiba Satellite C55-B5240X laptop with Windows 10. We used LICK 0.4 to install Fatdog 701 to the ntfs partition, and it worked very well. Once the trial period of the laptop was over, she wanted Linux on its own partition. It was a fairly simple process to do that and keep LICK as the bootloader.

All that was needed was to
-shrink the ntfs partition, make an ext4 partition (sda6)
-copy initrd, vmlinuz and fd64save.ext4 there.
-make a new entry in lickgrub.cfg (on the ntfs partition):

[mikeslr]

Thought Anyone whose computer uses UEFI should read this:

http://murga-linux.com/puppy/viewtopic.php?p=888675#888675

But don't stop there. Also read saintless's response next following and the references rufwoof then posted.

I'll echo rufwoof's comment about the discussion being over my head. I think, however, saintless has a valid point in questioning the source of the alleged incident.

Also particularly probative are the comments @ http://thenextweb.com/insider/2016/02/01/running-a-single-delete-command-can-permanently-brick-laptops-from-inside-linux/ from which I take two points:

1> The only report(s?) of the issue involved MSI laptops; and
2> It allegedly occurred when systemd deleted a directory which should not have been writable.

Which leads me to wonder whether UEFI had been builtin by the manufacturer of the computer or whether that computer originally was manufactured to use bios-to-bootloader/OS and retro-fitted to run as an UEFI machine?

As might be the case if someone "up-graded" a formerly XP or Windows 7 computer to Windows 10 or had that "up-grade" forced upon him?

mikesLr