Puppy Linux Discussion Forum

---------------- part II ---------------
In another posting I wrote about an incomplete installation of uPupBB to a dual-core PC & Samsung monitor.
The installation was incomplete - there appears to be a mis-match between the monitor and monitor driver or configuration.
That posting is incomplete and long: https://www.forum.puppylinux.com/viewtopic.php?t=5385
This posting carries on from there.

The account so far: When booting, the PC hardware only recognised the ps2 kbd socket but I used a usb kbd. Initially this denied access to Puppy's boot menu. With a ps2 kdb I have access to the full menu. I can choose to boot normally, without the pup-save file or for systems with 'severe video problems'. Etc. I have not opened the PC box; the ident of the mother-board is unknown. Generally it is a dual-core CPU. The bios date is 2008. The monitor in use is Samsung. The main problem appears to be a mis-match between the video driver and monitor. See next para.

I exchanged two monitors. I wanted to know this: was the woozy display (1) due to a fault in the monitor or (2) the driver card (hardware) or (3) a mis-match between the configuration and the card? Swapping a very old monitor - problem remains. Conclusion: Problem is almost certainly not the Samsung monitor.

I remind myself that when Windows was still on the HDD (yesterday) the screen appeared as expected.
So - if the hardware failed - it failed overnight. Possible, but unlikely.

Now
Booting[/b]. I solved the problem where the kbd did not work (at first). Now, with a working kbd, I could select any boot menu option. As expected, I chose this: "Boot a PC with severe video resolution problems."

The result: I see a terminal screen, with the terminal prompt character.
The font is small, but readable. The prompt is hard to the left of the screen, but I can live with that for the moment.
Commands like ls, cd, du, df work as expected.

Progress! Time to take a break. Will ask a Q or two in a new topic. Will be away for a few days. Can't wait to discover why the video config and Samsung don't match!

Are you certain the cable is not toast? If it remains the same quality/issue even when changing monitors (Make sure, make sure there are absolutely no magnets of any kind. Even raidios) that might be it.

Run xorgwizard in the terminal to try setting it up, as well as using lspci or lsusb to try identifying. If you have a graphical session, that is your desktop displaying then use Pup-SysInfo to determine the hardware.

Debugging an installation to an older PC - part IIb.
(continued from part II - see below).

Situation report at the end of the last posting: Booted from the menu option - for computers with severe video problems. That offered me the terminal/CLI/bash (or whatever you want to call it) and menus that set config. details. Typed a few lines in the CLI. Discovered that no drive was mounted. Asked the forum, how do I mount a partition from the kbd? Got an answer. Thanks @mikewalsh.
Poweroff - without saving.

Booted ... into CLI. repeated above ... poweroff with saving.
I'm pleased to have CLI/bash with a good text screen.

Booted ... selected menu option: RAM only, no pupsave.
Result ... uPupBB is running, monitor screen appears normal ... have desktop ... all good.
Shut-down via 'shutdown' button on desktop. Normal "first-time" shut-down.

Repeat above, but with one 'twist'. Renamed the save file (on sda3).
Shutdown ... all normal.

Booted ... as per the top item on the <select-boot-option> menu.
Now, (since I renamed the save-file) Puppy asked me to configure time-zone, kbd type, charcter set (UTF-8) and so on.
Network not configured. Everything on the desktop looks good.
Shutdown - and made a save file. All normal.
Now I had 2 save-files. One had a weird name like "old-bak-save" and the other a name that Puppy would recognize.
At this time I was pleased to have a working Puppy with a normal desktop. Messing with the pup-save file was a bad idea. I made a trap for myself (or Puppy) but I didn't understand I created a problem - until I booted the next time. Now read on ...

Now a report of a deviant Puppy.
Booted. I expected to see the desktop - and I did, plus.
I saw the desktop AND the configuration menu boxes. uPupBB wants to know about my kbd type, time-zone & so on ... How can that be? I made a save file. So Puppy isn't loading the save file on sda3. This is clearly deviant behaviour.

More than that! sda1, sda2, sda3 are not mounted! When I mount sda3, the save-file is visible as /mnt/sda3/uPupBB32-save (or something like that) but sda3 isn't mounted at first. There isn't a little grey house symbol marking the boot-drive icon!

Now for the weird stuff. Clicked 'shutdown'. Puppy asked if I wanted to make a save-file.
This means that Puppy is not aware of the save file. /mnt/sda3/uPupsomething-save.
Deleted the existing save file in preparation for making a new save file (again on sda3).
Puppy OS suggested I put the save file on /mnt/sda1/ - BUT this is only a 2GiB FAT32 partition and I rejected that option.

Went thru the process of making the save file. Power-off

Booted
Now the original problem has returned.
The uPupBB desktop is behind a static and white & mauve 'snowstorm'.

Will post at this point. In general, I wrote this (using Geany) and then pasted it to the forum.
Will assess the situation. One option would be to boot cold, re-partition and re-install.
That strategy won't identify the problem.
Will be away for some days and unable to respond.

Here is why I think the problem arose. First, when I partitioned the HDD I made 3 partitions.
sda1 == 2GiB as FAT 32 + a boot flag. Later, I put the Puppy OS files on sda1. Mistake!
sda2 == 160GiB as ext4. This is where I should put the Puppy OS files.
sda3 == about 200GiB as ext4

My prediction: I can boot uPupBB from a CD as 'boot w/out save file' and I'll see a working desk-top.
I predict I can run uPupBB and re-partition the HDD and re-install from the CD.
I predict this time the installation will work just like every other installation I have done.

If anyone here is interested in testing my hypothesis about why this installation failed, pls let me know.
MikeSLR's (@mikeslr is very functional, but I stuffed up when I put Puppy on sda1;
I must put the OS files (and the save file) on /mnt/sda2 (or 3).

Will be away for some days.
At the moment the deviant Puppy PC is packed away.

cobaka.

@Phoenix

Are you certain the cable is not toast? If it remains the same quality/issue even when changing monitors (Make sure, make sure there are absolutely no magnets of any kind. Even raidios) that might be it.

Answer: believe cable is OK. See posting below, where I give my hypothesis for what went wrong. I think it's 'my bad'. I'll take my shirt off and accept my punishment.

Didn't follow your direction below <Run xorgWizard>
I think the next posting below more or less answers many Qs.

In short I booted the PC several times and saw a normal desktop.
After that (when I had a normal desktop) I deleted a save file because Puppy asked me to create a new save file.
Now the original problem has returned.
My guess: I am doing something weird when installing.
Further to that point. Previously when I installed Puppy OS using MikeSLR's method I did not put the OS on /mnt/sda1 (whith limited space). It was somewhere else and the save file went to the recommended drive.
This time I put the Puppy files on /mnt/sda1. The save file went on a different partition (sda3).
Never done that before.

My Q for you Am I doing this to get a working installation or are we chasing some unusual bug in the installation process? I can get puppy installed OK. By that I mean I can correct the process of installing the OS.
If you wish to chase a bug (to eliminate it) I will continue to report.
Basically I'm creating the problem. I'm "confusing" the GRUB/Booting/menu.lst software with some unusual step in the installation.
I say again: I am creating the problem with some un-orthodox action when installing Puppy.
I believe @mikeslr installation method is reliable.
I believe the hardware is good. I believe the iso file isn't corrupted.

cobaka.

You do not need to delete the savefile because it asks to create one. It's probably being booted in RAM mode and then when you shutdown it asks. You can simply give it a name that isn't the previous one then and it will give you an option.

@Phoenix

You do not need to delete the save-file because it asks to create one. It's probably being booted in RAM mode and then when you shutdown it asks. You can simply give it a name that isn't the previous one then and it will give you an option.

Good observation! The lesson for me: Take more time to think each step in the process. I reacted to the 1min time limit available to make a save file. I should have let Puppy shut down w/out a save file.

More: I renamed a working save-file; that still exists. After that I deleted the second save-file. I definitely did not boot Puppy as "RAM only", but (I propose) it was as if I did that bec. (I guess) P/L did not find the save-file. This is part of the reason for my hypothesis. I can prove that by re-installing P/L (with a variation) and putting the previously re-named save file where P/L will find it. It may be useful to save my config. files also. If P/L cannot find the save file on booting , I think @bigpup and @666philb may be interested.

Will be away from the recalcitrant Linux box for several days.
May have access to the forum - depending

cobaka

Several thoughts:

I don't know what names you use when renaming a savefile.
I personally use savefolders and I think a certain part of the name must remain unchanged (to be found and mounted when booting).
Example for savefolder (red text must remain, blue can be changed):
bionicpup64save-chuck_norris

I also give care not to manipulate with save when it is currently used (i.e. when it is mounted during boot).
This mainly concerns copying, deletion and movement and probably also renaming.
I do these tasks "from outside" (either from another puppy or from other savefolder).
"pfix=ram" parameter can also be used.

@Feek

It seems I used incorrect terminology. You wrote:

I personally use savefolders and I think a certain part of the name must remain unchanged (to be found and mounted when booting). Example for savefolder (red text must remain, blue can be changed):
bionicpup64save-chuck_norris

I did save to a 'folder' - name is upupbbsave. Frugal installation. So I have a 'save' folder, not a save file. 'My bad'. (See, I'm nearly americanized!)

As for 'messing' with the save-file when it is in use - I consider that a big "no-no". This practice may (or may not) be good - but this is what I do. I consider it a kind of self-imposed 'locking' of the file.

Incidently (here I reveal my ignorance - although this will be no surprise to those who know me ...) Inside a folder called upupbbsave/initread I found an informative file called README.txt Lots of info there.

Thanks for your observations ...

cobaka

cobaka wrote:

'My bad'. (See, I'm nearly americanized!)

Totally!

Next lesson : when questioning something you have doubts about, use -> "what's up with that?"

Now if ever in Connecticut and you run into a friend,
change the greeting like: "Hey, what's up?" to : "Sup?"

If you find yourself near Boston, anything really good is : "wicked"
Used like = "wow, that's wicked cool"

Near New York City the word "f#$k" will have 2 meanings, it could mean really bad or really good.