ok, here are my log files:
(1) from a successful boot, usb stick, select compatibility mode:

https://termbin.com/aofr

(2) from a fail boot, HDD, with horizontally challenged video:

https://termbin.com/7z97

<edit> added this effort:
(3) from a fail boot, usb, with horizontally challenged video:

https://termbin.com/n6qz

===========
Well, the first thing I notice is that the successful "compatibility" boot loads the vesa drivers, while the failed one loads nouveau.

<edit #2>
Now that I know the problem resides in the video driver,
when I look at inxi output in a compatibility-booted system,
it says the drivers are vesa running at 1024x768, and NOT nouveau.

That's my AHA! moment.

OK, how do I change the loaded video drivers
(a) from terminal, to see if it works
(b) in the configuration file when I boot from the HDD?
(c) or, how do I change the nouveau settings so that they work?
(d) does anyone in the Mint install community have interest in adjusting the installer to do a better job, or provide more choices?
...since installer thinks the nouveau driver is fine, when it's not.

Thank you, mrmazda... you are either up very early, or night owl.

<edit #3>
just for kicks, I tried booting from the HDD with an external VGA monitor. It's an old LCD display, with only a VGA connector, so it forces VGA modes (I think). Viola! EXTERNAL video is NOT horizontally challenged; however, half the background of the Mint desktop theme is missing. Windows can be created which use all the available screen space on the external monitor, so all the display memory is available. In this case, the LCD display is blank, so it is preferring to send all video to the external monitor.
Other notes: I tried adjusting the amount of video RAM in BIOS (choices are 32, 64, 128MB) and all of them gave horizontally challenged display on the LCD.
I hope this is helpful.

More progress:

I did not understand mrmazda's comment about 'grub stanzas' in his first reply.

Well, the 'grub stanzas' are the lines of code that appear after the Linux Mint boot choice options box appears, and the user then highlights the boot choice and THEN PRESSES <TAB>.

These lines are EDITABLE. Aha! I think I knew that, once upon a time, but I forgot.

Here's my choices:
boot options start Linux Mint, all defaults:
#
/casper/vmlinuz file=/cdrom/preseed/linuxmint.seed boot=casper initrd=/casper/initrd.lz quiet splash —-

boot options start Linux Mint, compatibility mode:
#
/casper/vmlinuz file=/cdrom/preseed/linuxmint.seed boot=casper xforcevesa nomodeset b43.blacklist=yes initrd=/casper/initrd.lz ramdisk_size=1048576 root=/dev/ram rw noapic noacpi nosplash irqpoll —

So, to boot from the usb stick in 'default' mode with good video I had to insert "xforcevesa nomodeset" AFTER the "boot=casper" statement in the first command line. I forgot that these are editable...

So now I can boot the usb stick with vesa drivers and the video chip is happy.

Now I need to experiment and find out how to install Linux to the HDD with xforcevesa nomodeset options enabled.

I have no experience using xforcevesa, and don't know what it does.

Please read about nomodeset here. Nomodeset is OK to use to get the installer to work, and for repairing configuration errors, but very rarely for normal use.

The VESA X driver, which the first log shows to be in use, is very crude and limiting. For most desktop uses it is wholly unsatisfactory.

In the other logs I see "resize called 2000 800". This suggests to me a problem, one which I've never encountered, that may well be responsible for the multiple images.

Boot parameters can be edited in similar manner for installer boots as can for installed system boots.

After several decades in the same home, I've been moving in recent weeks, which has been and remains very limiting of the time I can spend here.

mrmazda, thank you for holding my hand while I puzzle this one out.

For some reason, when I compare my two F700 units, the one with the Turion CPU runs the nouveau driver in 1280x800 just dandy, and the one with the Athlon CPU thinks the nouveau driver is fine, but somehow does not set the nvidia chip up properly, but vesa mode (1024x768) works.

More observational details: the icons are double height, so it looks like the horizontal interlace settings are not set correctly in this one computer with the Athlon CPU.

As far as I can tell, the nouveau settings are identical between the two computers, but the nouveau driver through the Athlon CPU unit doesn't set the nVidia chip correctly and horizontal sync is incorrect..

I presume the hardware works correctly, because Windows 7 display works just dandy, and the VESA drivers work just fine. So I conclude it's a nouveau software issue convolved with my hardware.

My task: learn how to adjust the grub files on the HDD so it loads the VESA rather than the nouveau drivers.

Given what's going on here at my end, my memory is being taxed near its limit to follow what's going on. Are you still trying to start an installation, or, are you attempting to repair a malfunctioning installation? Temporary editing of Grub for booting an installed system begins by striking the E key. For a persisting change once the desired parameters are confirmed, edit /etc/default/grub and regenerate /boot/grub/grub.cfg.

Unless you like low resolution (1024x768), I suggest you do your best to avoid the FBDEV and VESA drivers on an installed system. For installation, they're adequate for the variety of hardware being subjected to. Few like their results on an installed system.

If you do not have a failing GPU or video RAM, I expect the Modesetting DDX to support your GPU. Until you've tried it on an installed system, your job is not done. Like for the Nouveau DDX, nomodeset must not be used on the kernel command line for the Modesetting DDX to be supported. As already suggested, nouveau.config=NvMSI=0 might possibly be needed (though I somewhat doubt it) on the kernel command line, possibly with either the Nouveau DDX or the Modesetting DDX.

If the GPU is sharing system RAM, you should try reseating the RAM, and/or swapping RAM modules if more than one is installed. Multiple corrupt objects onscreen as you describe are often a consequence of GPU or RAM failure.

I have an even older GeForce 6150SE and no apparent trouble, like with your other laptops, though not with Mint, only with its Debian foundation:

mrmazda,

no rush... to your points, I'm trying to fix a wonky installation.

The Athlon-base F700 that I'm working on is happy with Windows 7, and VESA drivers for Mint 19.3, but unhappy with the nouveau drivers.

Now, I have an identical F700 system (save for the CPU) with the same mobo, same BIOS, and same nVidia chip ID which is happy with nouveau drivers (giving me 1280x800x32 display). See post #1 & #16.

So I conclude that it is NOT a hardware issue (badly seated RAM, malfunctioning chipset, etc).
I might be wrong; but the evidence seems to lean against hardware. BTW, I've already swapped RAM. No change.

Swapping CPUs between systems is on my list of "when all else fails".

While I can edit the grub stanzas when I boot from the usb stick, the Mint 19.3 installation to HDD gives me (apparently) no option to adjust display parameters. The file \etc\default\grub.cfg is read only, so I need to change permissions before I can edit that file. Then I need to run the process to create the actual grub boot file. I'm not quite that brave or determined (yet), but I'm getting there.

This installer assumes that everything the installer finds is hunky-dory, and makes it less that straightforward to adjust things. For starts, GRUB_TIMEOUT set to something >0, so I get options during HDD boot.

Anyway, this is an interesting little project for me to pursue while social distancing is being strongly enforced.

Good luck with moving house; and thanks for the advice you have sent my way. I do appreciate your effort on my behalf.

My hope was that someone like you would have had some experience, along the lines of "Oh, yeah, there were a batch of nVidia chips type thus-and-so that needed an extra tweak to perform to spec" and somehow make it work a treat. So somehow I've found a peculiarity.

Thank you again...

No permission as ordinary user, but as root user or with sudo it is RW:Make a copy of the file first, then edit or update grub to your heart's content.This seems to describe a normal condition, ability to use the E key when the Grub menu appears, due to a non-zero timeout.

Exact same BIOS settings and installed RAM size? How about swapping RAM between the two F700s? Have you run multiple passes (e.g. overnight) of memtest86 or memtest86+ on the problem F700?

Are you clear on the distinction between nouveau driver for kernel, and nouveau driver (DDX) for X? They are only related, but quite different. All competent FOSS DDXes (for NVidia GPUs, both Nouveau and Modesetting) depend on the nouveau kernel driver correctly providing KMS.

Let's call this partially-solved.

Use the steps described by mrmazda in post #22 and modify the grub configuration file /etc/default/grub

In Terminal:

sudo nano \etc\default\grub

Change the line with GRUB_CMDLINE_LINUX_DEFAULT to read

GRUB_CMDLINE_LINUX_DEFAULT="quiet nosplash nouveau.modeset=0"

Save the edited file with <control>-o, <cr> , then <control>-x to exit nano.

Then run

sudo update-grub

Then reboot.

Now the system boots by default to the vesa driver set 1024x768x32. Satisfactory, but not optimal.
Linux Mint will complain that the system is running with no video hardware acceleration, but that's ok.

Because the system has perfectly steady display in vesa and Windows 7, there is something about the nouveau driver and this nVidia chip that misbehaves. Something about the nVidia driver for Windows 7 takes care of this. The 1280x800 mode works fine there.

Next step (maybe): find the proprietary Linux nVidia driver for the C67 chipset & try it.

FWIW, perusing forums, I find that many Linux installers report difficulties with the nouveau drivers for nVidia. Given the frequency of nVidia driver updates for Windows systems, I'm not surprised, since it seems that there may be many 'variants' of nVidia chips even with the same chip identifier.

Thank you!

Follow-up:

Perusing other forums, I found that the proprietary nVidia drivers for C67 chipset are 304.117, with a "beta" branch called 304.135 or 304.137. Release date is September 2017.

Here's the link:

https://www.nvidia.com/Download/driv...x/123709/en-us

They seem to have stopped working at Ubuntu 18.04 (2018) and the fault seems to have something with the way Xorg changed its display handling...

The README file Chapter 9 - Known Issues - subsection Problems That Will Not Be Fixed - makes for fun reading, particularly the paragraphs about Athlon chip motherboards CPU throttling having an effect on graphics timing.

So, it's not a bug, it's a feature :-/

Given that the laptop is 13 years old, it's not worth my effort to improve on the vesa display. The computer is now functional. Good enough to play with.

Thanks again for the help, mrmazda.

<edit #2> your post below (regarding Modesetting DDX) is beyond my Linux skill level at this point. Please assume I know very little. A post to a link to a Modesetting DDX tutorial which applies to any chipset, or at least doesn't exclude 13-year-old nVidia chips, is what I need. Plus, the problem occurs as soon as the boot loader switches from the lowest-common-denominator display driver to what it thinks is best (but ain't), and that seems a pretty deep dive into the Linux boot process. Beyond my skill level. My first foray at internet search brought me to discussions of Intel DDX, which seems to have no application to the nVidia chipset involved here. You have a ton of Linux experience more than I have, and (in other circumstances) I've been there, so I know it's a tough task to give the appropriate level of advice. I appreciate the pointers you have given so far. I thank you for them, sincerely. Right now, though, this problem is moved significantly down the priority list until another rainy day.

<edit #3> apparently, I am not alone with these kinds of issues; even folks with new hardware... examples:

https://www.linuxquestions.org/quest...ng-4175652905/

https://forums.linuxmint.com/viewtop...9&hilit=nvidia

https://forums.linuxmint.com/viewtop...?f=59&t=248059

Before you test with the Modesetting DDX, you can't know that. The Nouveau DDX may well be the problem, but the Modesetting DDX, which is the upstream default, may be your optimal (1280x800) solution. You cannot try the Modesetting DDX as long as either nomodeset or nouveau.modeset=0 is included on the kernel command line.

Yet another follow-up:
Same model (Compaq F700), same CPU, same mobo, same graphics chip ID.
Someone last year discovered that the nVidia 304.137 drivers will fix the issue.
(scroll to last 2 posts)

https://forums.linuxmint.com/viewtop...+f700#p1671039

I'll give this a try on the next rainy day.

Any particular reason for not following my recommendation to try the DDX that works for me, and which upstream has selected as default for all NVidia GPUs? No installation is required. It's already available simply by removing KMS blocking, and purging the reverse-engineered, old-tech xserver-xorg-video-nouveau package.

Good morning.

The sun is shining, so I have a raft of outside tasks that beckon.

They are on my list to try next rainy day, now that I have a bit of experience in grub management.

There is an alternate implementation method for configuring the Modesetting DDX, simply create a file:containing the following:If the file already exists, then it would need to be edited, keeping the existing identifier, while adding or changing the Driver line. Some might consider this file easier than adding or removing software, and it's available for most supported GPUs. Either way requires KMS be enabled.