can't find display controls, synaptic broken filter is broken.

[Capricorny]

Can you tell exactly why you post this in the "News" section? Why do you think this has any generality for Knoppix 7.6.1? "General support" is a much better place for this, IMHO.

1. on one of my systems I run a laptop display and a wide external monitor. Windows 8.x has no problem automatically sizing both displays. But in Knoppix, the external monitor is only showing a portion of the desktop. I've looked all over, and haven't been able to find a tool to adjust the screen resolution or otherwise fit the desktop to the screen. the result is that I have to fish blindly for the start icon, and I can't see the bottom taskbar, and basically the desktop is chopped off on all sides.

Is there I tool I haven't recognized that can help me with this?

You must try out all possibilities in ARandR, the program behind the monitor icon on the taskbar, first. That's the default resolution manager - remember to 'Layout,Apply' the choices you make. Maybe you already have, but you must tell us about it. Also details about the hardware are useful. Did you try googling for 'ARandR' plus your hardware setup?

2. I tried to install UFRaw using synaptic, and it laboured for hours!, and finally presented me with the news that the attempt had failed, and that there were now two broken items that I had to find using the "broken filter." Unfortunately, the "broken filter" doesn't find anything, and so it seems synaptic itself is now broken.

Is there a fix?

I've run into other problems too, but two are probably already enough to get me branded as "troll" again.

First, whenever you suspect something risky ahead, start Knoppix w/o persistence, cheatcode noimage. You can then try out actual changes before committing them to persistent store.
Also, keep a backup of the last working version of your persistent store.

I just tried, from command line

sudo apt-get install ufraw
sudo apt-get install gimp-ufraw

No problems whatsoever. But then, I had issued

sudo apt-get update

in beforehand. In synaptic, you always start with the 'Reload' button. Because Knoppix is a mixture of different Debian release versions, this is particularly important to do. (Not apt-get upgrade!)
My advice is that you start with a new install, but keep a backup of the pristine setup this time.
Also, I have discovered that Knoppix nowadays often leaves the persistence file system with errors.
You should (from somewhere else) try

sudo e2fsck -fy KNOPPIX/knoppix-data.img

and look at the output.
If you regularly find that it is left in a broken state upon normal shutdown, that is very interesting news, I would like you to post about it in this subforum!
Good luck!

[Capricorny]

You should (from somewhere else) try

sudo e2fsck -fy KNOPPIX/knoppix-data.img

and look at the output.
If you regularly find that it is left in a broken state upon normal shutdown, that is very interesting news, I would like you to post about it in this subforum!
Good luck!

"Somewhere else" here means that you should (of course) NOT try to check/fix a mounted file system, i.e. do it from within a Knoppix session using that persistent store. In practice, you can also do it from within Knoppix though, starting it without mounting persistent image (cheatcode "noimage"). And if the file system of the persistent image is broken, you may have to start without it. After fixing, it may (in my experience will ofte) work correctly again, but there is no guarantee.

[utu]

I have discovered that Knoppix nowadays often leaves the persistence file system with errors.

I also note that persistence files can occasionally get corrupted; usually in my case, from imperfect
shut-downs. It helps to have a pristine backup of persistence files, just in case.
I find it useful to occasionally examine what dmesg has to say in this regard:

dmesg | grep -i corrupt

This will not only find problems with persistence, it will uncover similar problems
which may have crept into Windows and data partitions.

An additional technique I use is to make cloop overlays of well-developed persistence files
as additional fat32-partition-KNOPPIX[n] files which are pretty much immune to shut-down corruption.
After adding such an overlay, I immediately use gparted to create a new 'empty' (reiser)
persistence file for additional changes which I might make to my Knoppix LiveUSB.

I try to minimize whatever is left to additional read/write persistence. After I get my Knoppix
'immunized' somewhat in this way, I consider on-going r/w persistence as 'temporary' and just
resurrect from notes any losses due to imperfect shut-downs.
A minimalistic back-up of small r/w persistence files is an obvious alternative I might use here.

[Capricorny]

I also note that persistence files can occasionally get corrupted; usually in my case, from imperfect
shut-downs. It helps to have a pristine backup of persistence files, just in case.
I find it useful to occasionally examine what dmesg has to say in this regard:

dmesg | grep -i corrupt

This will not only find problems with persistence, it will uncover similar problems
which may have crept into Windows and data partitions.

An additional technique I use is to make cloop overlays of well-developed persistence files
as additional fat32-partition-KNOPPIX[n] files which are pretty much immune to shut-down corruption.
After adding such an overlay, I immediately use gparted to create a new 'empty' (reiser)
persistence file for additional changes which I might make to my Knoppix LiveUSB.

I try to minimize whatever is left to additional read/write persistence. After I get my Knoppix
'immunized' somewhat in this way, I consider on-going r/w persistence as 'temporary' and just
resurrect from notes any losses due to imperfect shut-downs.
A minimalistic back-up of small r/w persistence files is an obvious alternative I might use here.

I wonder what is the reason for this. I thought is was confined to running KNOPPIX under kvm, because I first detected it there. But it is not. So I have put a small script, fix_fs, in /usr/local/bin, to check the persistence file systems. Turns out they have to be fixed most of the time nowadays. I'm pretty sure it wasn't like this before. I'm not talking about crashes or emergency halts. This happens with all standard methods of shutdown that I have tried.

Perhaps we should pursue the "read-on-startup" and "write-on-exit" method, I think some distros have adopted it.
Seems that mainstream Linux is turning into ever more of a buggy beast these days. Maybe not entirely coincidental.