Frugal install to SSD (Bionicpup64) [SOLVED]
I today tried to do a frugal install of Puppy to a Samsung EVO 850 (120GB) SSD.
The installation options for this are not reasonably clear, which should be considered a bug. 
The options provided under Menu>Setup>Puppy Installer are:-
Universal Installer or Install to Flash Drive... I choose Universal Installer
Next, the options are:-
(a) Internal IDE/SATA/SCSI hard drive
(b) Internal IDE/SATA Flash drive (ex: CF card, SD memory card)
This should say clearly which option is suitable for SSD since they are confusable with Flash. What is an internal flash drive if not an SSD, I do not know. Also the term "ex" is non-idiomatic and could be taken to mean either "for example" (which should be written e.g.) or "excluding"... opposite meanings. Might be better to write it out in full.
It is obscure why the first selection is "Universal Installer" or "Install to Flash Drive" but then "SATA Flash drive" is nested under "Universal Installer"
I chose (a) since I am using an Internal SATA hard drive.
but (a) does not work. (b) MUST be selected for the SSD to boot.
if I understand correctly this might depend on the BIOS... i.e. something along the lines that the BIOS arbitrarily flags SSD hard disks as either "flash" or "idehdd". If so, this is a serious impediment to Puppy's installer and (imo) needs a warning. SSDs have been around for some long time now so maybe it is one of these areas where BIOSes now mostly act in a standard way so a good default option could be offered by the Puppy Installer tool but with a warning about older BIOSes.
The installer soon afterward calls GParted. I create a single ext4 partition, set the 'boot' flag ('eps' flag is also autoselected).
(A problem with Gparted is that it offers about 10 different partition tables, with no explanation, most of which will not work properly. I choose MS-DOS since my disk is only 120gb but this is counterintuitive if I am trying to install Linux - they need some more text or a pop-up here).
I then am returned into the puppy installer. Puppy is installed and Gparted now shows the SSD space as unallocated.
I think the problem occurred at this stage. I had definitely remembered to "Apply changes" at each stage in Gparted and it showed as properly formatted before reverting to unallocated grey space after Grub4dos was done.
So what I did was I opted to install Grub4dos using default options.
The disk then booted with the following prompt:-
wee 0> find --set-root /grldr
wee 15> /gldr
wee 17>
It would be useful to know what this means. It is mentioned online but the old forum says it is "down for maintenance" and the other places give no information.
There is a cursor and I can type and enter commands but I do not know if this is any sort of BASH shell or whatever.
The disk can no longer be detected by Windows (possibly due to being ext4) or Ubuntu (more worryingly). Booting back into Puppy, the disk can no longer be mounted or accessed via Gparted. This initially made me think the SSD had been bricked. However for some reason it can be accessed via Puppy Installer and Gparted called from there, and I found it was necessary to start again and reformat it. It would be nice to know if there is some command that might have made the system bootable, or if these messages are showing that in fact the hard drive had not been formatted correctly.
I in the end manually edited a working menu.lst. It always annoys me that puppy linux sets up the savefile location to a logical drive (e.g. sda1) but this can make the system non-bootable if for some reason the PC puts the drive on another device point (or irq or whatever the proper term is, e.g. it puts it to sdb1 on bootup and then puppy can't find it) so I like to use the blkid command and find the right UUID for the specific disk where my savefile is, and make a menu.lst entry like:-
Code: Select all
title bionicpup64 8.0 (SSD)
uuid fd3d3422-8533-4574-aefe-9bf81ab40a44
kernel /vmlinuz pmedia=ataflash
initrd /initrd.gzI then go through some weird set of stages I can't remember like copying all the puppy files from the USB to the SSD, then these do not boot (because the idehdd flag was chosen wrongly, and then do a new install with the ataflash option but it detects the idehdd install and thankfully! knows to only overwrite the four or five boot files, the ones like initrd.gz and vmlinuz.
To a user it feels as if there is a disjunct between making a bootable puppy linux media and the actual puppy. Once the media is bootable I find it easier to copy the savefile and .sfs'es from some other puppy and they normally just work. I guess this is mainly that Gparted and Grub4dos are generally-used and third-party tools outside of puppy - and they are godawful for inexperienced users. Making some media bootable shouldn't be an artform.
====
I noticed,
Puppy's boot parameters at http://wikka.puppylinux.com/BootParamet ... edirect=no include:-
usbflash usbhd usbcd ideflash idehd idecd idezip satahd satacd scsihd
but the one actually used by puppy's Grub4dos tool and which works is not mentioned: pmedia=ataflash, this is missing from the documentation
Related to the above, SSD is confusable between ideflash, satahd and now also ataflash.
There must be something to give the user a steer which to choose, "e.g. if the BIOS is more recent than 2014 try this one"
If it is something that will inherently be trial-and-error (for most users) due to BIOSes handling the hardware differently, that should be in a message
I suspect though this is again the general problem that most of the options offered by the installer plus GParted will not remotely function. And the user doesn't necessarily know how to choose the (possibly only one) option that will successfully boot for their system.
===
With the process of cloning a puppy from a USB to an SSD there are some headaches for Firefox and Thunderbird
These applications are not built to work in memory and want to save a lot of files in a .cache folder on a hard disk.
(To recap) In the case of Puppy, this .cache folder is placed inside our savefile on the sfs (squashed filesystem)
And during use .cache gets too big, so at some point early on when setting puppy linux up we want to move this folder outside of our savefile and make a symlink.
So in the savefile there is now a tiny symlink and then the .cache folder is on the storage outside of the .SFS
But the .cache folder is hidden, and hidden files aren't shown by default. So when a puppy is copied from one media to another (in this case external USB to internal SSD) probably we miss this .cache folder. Somewhat stupidly, Firefox and Thunderbird (but not Tor) then are unable to recover from this folder (which when not in use is <2Mb of random unimportant cruft) being missing and they provide 
no useful error messages about this! Opening them from launchers the applications are just dead (until the folder is located and copied across), but opening firefox -P in terminal gives a mysterious error like "unable to create folder {PATH...}/.cache" which is the clue that it means "unable to locate folder".
There are also some strange bugs with Veracrypt dismounting auto-mounted partitions on the SSD that it didn't used to on the USB, but these aren't stopping the system working. Basically it works if I let Veracrypt auto-mount the container where all my stuff is, and then leave it alone as a background process. If I want to next mount a bunch of other containers it will now dismount the auto-mounted one causing most of my installed programs to stop working. But if I need to copy files between containers probably I would do that on a Windows PC as that version of Veracrypt is usually better/more stable with their Linux version always being left behind.