Fatdog64-611 Final (Updated 12-14-2012)

A home for all kinds of Puppy related projects
Message
Author
Sage
Posts: 5536
Joined: Tue 04 Oct 2005, 08:34
Location: GB

#31 Post by Sage »

What ho, pre!
No, neither of those boot codes originate from Puppies, although I've seen the vga=normal suggested somewhere about six months or more ago on this Forum. They were codes I used to use with Knoppix 1.0.0 ! But it was said somewhere that these are common to the Linux kernel. Any road up, they don't do any harm and I have had them work occasionally in the situations you describe.
As for the 754, - No. Mind you, I've had endless trouble with 939 BIOSes. Had to unsolder one once with an electric paint stripper, flash it externally using the /F (force) switch on an alien board, fit a socket and put the BIOS chip in that. It worked for a while, but it gradually dawned on me that the 939 is a design disaster, probably a stop-gap until the Phenom and multiple cores arrived. Not like AMD to pull a fast one like that. Shame really because the multiple core designs are an even bigger disaster, some of Intel's latest are devouring 120W. So much for their lies about running cooler. That is one dud company that has never conquered the thermal issues associated with faster, smaller and thinner - sometimes I even wonder if there's anyone there familiar with Ohm's/Kichoff's/ all-those-other-guys-Laws in school physics?!
The big attraction of 754 and 939 is they have two IDE ports. I was reading elsewhere today the old urban myths about SATA being trotted out again. Now, I'm not sure about SATAIII, but there is NO actual speed gain between ATA100 (ATA133 is like hen's teeth) and SATAI&II. If one reads very very carefully. it's the spec. for SATA that's a lot faster - real drives barely manage ATA transfer rates. It's the old rotating machinery paradox. In principal, SSSD s should be faster, but only if the bus can handle it and their lifetimes in terms of read-write cycles might be uncertain? Early flash memory was suspect in that regard, although I've had no problems with multiple writes. Perhaps we won't know for some years yet?

ggg

#32 Post by ggg »

.

DrDeaf
Posts: 69
Joined: Sat 30 Dec 2006, 14:10

#33 Post by DrDeaf »

No known issues with 610. Everything works well, and 601 did as well. No optical drive installed, but this machine is booted clean from ISO to RAM.

I edited the hardware report extensively for brevity, but I'll post any further info if anyone wants. Again, this is just to say, no problems known with this hardware.

Processors-
Intel(R) Core(TM) i7-3520M CPU @ 2.90GHz : 1200.00MHz
Intel(R) Core(TM) i7-3520M CPU @ 2.90GHz : 1200.00MHz
Intel(R) Core(TM) i7-3520M CPU @ 2.90GHz : 1200.00MHz
Intel(R) Core(TM) i7-3520M CPU @ 2.90GHz : 2901.00MHz

Memory-
Total Memory : 16130616 kB
Free Memory : 15092068 kB
Buffers : 55536 kB
Cached : 461268 kB
Cached Swap : 0 kB
Active : 523404 kB
Inactive : 445112 kB
Active(anon) : 478944 kB
Inactive(anon) : 67188 kB
Active(file) : 44460 kB
Inactive(file) : 377924 kB

PCI Devices-
Host bridge : Intel Corporation Device 0154 (rev 09)
VGA compatible controller : Intel Corporation Device 0166 (rev 09) (prog-if 00 [VGA controller])
USB Controller : Intel Corporation Device 1e31 (rev 04) (prog-if 30)
Communication controller : Intel Corporation Device 1e3a (rev 04)
Ethernet controller : Intel Corporation Device 1502 (rev 04)
USB Controller : Intel Corporation Device 1e2d (rev 04) (prog-if 20 [EHCI])
Audio device : Intel Corporation Device 1e20 (rev 04)
PCI bridge : Intel Corporation Device 1e10 (rev c4) (prog-if 00 [Normal decode])
PCI bridge : Intel Corporation Device 1e12 (rev c4) (prog-if 00 [Normal decode])
PCI bridge : Intel Corporation Device 1e14 (rev c4) (prog-if 00 [Normal decode])
USB Controller : Intel Corporation Device 1e26 (rev 04) (prog-if 20 [EHCI])
ISA bridge : Intel Corporation Device 1e55 (rev 04)
SATA controller : Intel Corporation Device 1e03 (rev 04) (prog-if 01 [AHCI 1.0])
SMBus : Intel Corporation Device 1e22 (rev 04)
System peripheral : Ricoh Co Ltd Device e823 (rev 07) (prog-if 01)
Network controller : Realtek Semiconductor Co., Ltd. Device 8176 (rev 01)

USB Devices-
3.0 root hub

frankge
Posts: 2
Joined: Mon 03 Dec 2012, 02:33

desktop icons

#34 Post by frankge »

Many thanks for you patience with this new kennel member. I am trying to find out about the security and accessibility of windows 7 64-bit drives which are seen as icons on the desktop of fatdog64 601 booted from a live cd.
Could you please help me understand the following: Clicking on said icons, mounted or unmounted, then right-clicking "edit item", a "locked" check box appears. Just exactly what will be locked. Does it lock the win 7 drive only in linux or does it carry over to windows?
Are there other methods available in fatdog64 to limit acces of windows drives?
I'appreciate your reply

User avatar
rcrsn51
Posts: 13096
Joined: Tue 05 Sep 2006, 13:50
Location: Stratford, Ontario

Re: desktop icons

#35 Post by rcrsn51 »

frankge wrote:I am trying to find out about the security and accessibility of windows 7 64-bit drives
There is no such thing as a "64-bit drive". Instead, you should refer to them by their filesystem type. They are probably NTFS.
Clicking on said icons, mounted or unmounted, then right-clicking "edit item", a "locked" check box appears.
If you click on any other desktop icon, you will see the same Locked option. It refers to the behaviour of the icon itself, not to how the drive is treated.
Does it lock the win 7 drive only in linux or does it carry over to windows?
Neither.
Are there other methods available in fatdog64 to limit acces of windows drives?
Here is a trick to make NTFS partitions read-only in Fatdog.

1. Go to the folder /bin
2. Rename the file ntfs-3g as ntfs-3g-xxx
Last edited by rcrsn51 on Tue 04 Dec 2012, 17:20, edited 1 time in total.

kirk
Posts: 1553
Joined: Fri 11 Nov 2005, 19:04
Location: florida

#36 Post by kirk »

At prompt ran xorgwizard-old.

Next problem, tried this with and without graphics card, and never succeeded in configuring much of anything. I keep getting the defective report screen with resolution and refresh rates missing at the end.
Yep, xorgwizard-old is broke, I haven't used it for ages. Fatdog64 by default runs without an xorg.conf. We really don't want use a xorg.conf file. So I think we'll do away with xorgwizard and xorgwizard-old. Xorg determines which resolution to use based on the EDID data from the monitor, so if monitor doesn't report EDID data or reports it in correctly, Xorg has to guess about the resolution. For non vesa drivers (drivers that are xrandr compliant) resolution can be set with xrandr or the Display Properties in the control panel. I'll fix the pfix=vesa boot option to make an entry in /usr/X11R7/lib64/X11/xorg.conf.d/. That's where want to make changes to Xorg. Thanks for reporting this.
Can I get VESA to go beyond 1024x768 in FATDOG? If so, how?
Maybe, you'll need to find out if your card supports vesa modes of that resolution and if your monitor supports that resolution. You can look in /var/log/Xorg.0.log or run ddcprobe, which will list both. Then you'll need to make a file, /usr/X11R7/lib64/X11/xorg.conf.d/20-gpudriver.conf:

Code: Select all

Section "Monitor"
    Identifier             "Monitor0"
EndSection

Section "Device"
    Identifier             "Device0"
    Driver                 "vesa" #Choose the driver used for this monitor
EndSection

Section "Screen"
    Identifier             "Screen0"  #Collapse Monitor and Device section to Screen section
    Device                 "Device0"
    Monitor                "Monitor0"
    DefaultDepth            16 #Choose the depth (16||24)
    SubSection             "Display"
        Depth               16
        Modes              "1024x768" #Choose the resolution
    EndSubSection
EndSection
    
After that make sure there's no /etc/X11/xorg.conf file. You may or may not have to use the nomodeset kernel boot option depending on your hardware, but nomodeset is a safe bet with vesa. We need to update our FAQs with this information. I expect most 64bit systems (probably less than 5 years old) to be EDID compliant and setting the resolution won't be needed for vesa. Well, hopefully we won't need vesa ether, usually that happens Nvidia or something really new.

Horst
Posts: 5
Joined: Sun 11 Oct 2009, 06:21

HowTo resize pupsafe file

#37 Post by Horst »

Hello,

I'm about to install Lazarus from debian packages and went out of space.
Freepascal ist already running fine.
Now i'm trying to find the program to resize pupsafe file.
I think i need new glasses ( already -17 dpt ) .

I'appreciate a reply

User avatar
rcrsn51
Posts: 13096
Joined: Tue 05 Sep 2006, 13:50
Location: Stratford, Ontario

Re: HowTo resize pupsafe file

#38 Post by rcrsn51 »

Horst wrote:Now i'm trying to find the program to resize pupsafe file.
Menu > Control Panel > System > Fatdog64 Savefile Tool

mini-jaguar
Posts: 597
Joined: Thu 13 Nov 2008, 13:45

#39 Post by mini-jaguar »

It works, but I would like to do this:
Put Fatdog64 in a folder, and have the .sfs and save files there too.

Now say I make a folder called "fatdog", put the vmlinuz and initrd files in there, I can easily add /fatdog/ to the lines in the grub text that load the above mentioned files and it works, I've already tried this and it works fine.

But the problem is that it won't load any save or .sfs files I put in the folder, as opposed to other Puppies where this works fine.

Is there any commands I can add to the grub to make it load the save and .sfs files placed in a folder and not the higher level of the directory?

User avatar
rcrsn51
Posts: 13096
Joined: Tue 05 Sep 2006, 13:50
Location: Stratford, Ontario

#40 Post by rcrsn51 »

mini-jaguar wrote:Is there any commands I can add to the grub to make it load the save
Menu > Control Panel > Utilities > Savefile Argument Builder.

Also, read the FAQS about boot options.

kirk
Posts: 1553
Joined: Fri 11 Nov 2005, 19:04
Location: florida

#41 Post by kirk »

Is there any commands I can add to the grub to make it load the save and .sfs files placed in a folder and not the higher level of the directory?
There is for the save file. See the Boot options page in the FAQs.

Example grub entry:

title Fatdog64-610 (on /dev/sda6)
rootnoverify (hd0,5)
kernel /610/vmlinuz savefile=direct:device:sda6:/610/fd64save.ext4
initrd /610/initrd


The savefile argument means to use a savefile named fd64save.ext4 located in /fd610 directory of /dev/sda6, save directly to it.

EDIT: Just saw rcrsn51's post. Ditto on the Menu > Control Panel > Utilities > Savefile Argument Builder.

User avatar
prehistoric
Posts: 1744
Joined: Tue 23 Oct 2007, 17:34

#42 Post by prehistoric »

kirk wrote:...Xorg determines which resolution to use based on the EDID data from the monitor, so if monitor doesn't report EDID data or reports it in correctly, Xorg has to guess about the resolution...
The monitor in question is a 21" perfectly-flat CRT manufactured by Sony and rebranded by SGI. It reports that it is a GDM-5411. Something in Fatdog 610 must recognize that it has 1600x1200 resolution because that is what leads to the microscopic fonts.

It does report EDID data, just not the version you are expecting. A look at the history of EDID indicates the current version will not have a long product life. Windows can recognize it after drivers for nVidia or ATI are loaded. Prior to that it defaults to generic.

Aside: I use the old CRT because of the good dynamic range of the phosphors. This one can be calibrated to a known gamma for retouching work on photographs. Getting this on modern LCD displays can be hard, expensive or impossible. You can also find these CRTs still in use among various graphic designers.

One incidental side benefit is that any thief who makes off with it can be caught when he ruptures himself.

User avatar
don570
Posts: 5528
Joined: Wed 10 Mar 2010, 19:58
Location: Ontario

#43 Post by don570 »

I tested Fatdog64-521.iso with Right-click-6.0.2.pet
http://murga-linux.com/puppy/viewtopic.php?t=67013


My conclusion --->

It mostly works but needs mhwaveedit to be installed
and more icons need to be installed available.

____________________________________

kirk
Posts: 1553
Joined: Fri 11 Nov 2005, 19:04
Location: florida

#44 Post by kirk »

Something in Fatdog 610 must recognize that it has 1600x1200 resolution because that is what leads to the microscopic fonts.
If that's the highest supported resolution, then that's what we want. If the fonts are too small, switching to a lower resolution is not a good solution. Open the Control Panel, click on the Desktop tab and click on Set global font size. Select a higher dpi for your fonts and restart X to see what it looks like.

Or Xorg can automatically calculate the font size, maybe we will do that. You just delete or rename /root/.Xresources and restart X and see if that looks good.

User avatar
prehistoric
Posts: 1744
Joined: Tue 23 Oct 2007, 17:34

#45 Post by prehistoric »

@kirk,

I think there is a misunderstanding here. I was talking about font sizes outside of the X window system. I know about adjusting font sizes under X. (In that case, adjusting icons, etc. is also necessary. Reducing the resolution may be a sensible option in some cases, even if it isn't in the case you are thinking about.)

Even when the frame buffer does not get messed up, the text console fonts, which were previously readable, suddenly become microscopic during the boot sequence, making it hard to tell what is going on when there is a problem in getting to X and a desktop, or in the reboot/shutdown sequence, when there is a failure to save.

The general problem I'm getting at is one of robustness when things go wrong. This applies not just to software, which can't anticipate every problem, but to the system of software, hardware and people dealing with issues. If I wanted software which does everything for me when things go right, and leaves me helpless when something goes wrong, I might have stayed with M$.

Puppy has always impressed me with the ability to fall back to some lower level of operation where it is possible to isolate a problem well enough that knowledgeable people can fix it quickly.

For example, Barry's Simple Network Setup was not the first try at that function, or even the second. It would not have come into existence without considerable preceding history. Even today, when things go wrong, I check on how Dougal's network setup handles it. At least this narrows the range of places to check for faults. Sometimes it works when SNS fails. Those cases are becoming rarer, but both tools remain available in 5.4.2. I've known experienced network people to become very frustrated while trying to make Windows automatic network tools work.

Losing the ability to fall back to text console video setup strikes me as a mistake.

kirk
Posts: 1553
Joined: Fri 11 Nov 2005, 19:04
Location: florida

#46 Post by kirk »

Even when the frame buffer does not get messed up, the text console fonts, which were previously readable, suddenly become microscopic during the boot sequence, making it hard to tell what is going on when there is a problem in getting to X and a desktop, or in the reboot/shutdown sequence, when there is a failure to save.
Again, this happens after KMS modules load which also load console frame buffer modules, though I haven't had any problems reading the font. If you don't want to use KMS for some reason you have to boot with nomodeset and probably use vesa.

Puppy has always impressed me with the ability to fall back to some lower level of operation where it is possible to isolate a problem well enough that knowledgeable people can fix it quickly.
This applies to Fatdog64 as well, but different knowledge is required. Fatdog64 has almost nothing to do with Puppy, nearly everything is different.

We would like to have Fatdog64 work on everything automatically. But of course that's not going to happen. We've made design choices which will work well on most hardware and not on others. Puppy has done the same. However the well supported hardware will vary between the two.

gcmartin

#47 Post by gcmartin »

Sage wrote:What ho, pre! ... but there is NO actual speed gain between ATA100 (ATA133 is like hen's teeth) and SATAI&II. If one reads very very carefully. it's the ...
Yeah, this has always been true for all known buses: the equipment is slower in most all cases, than the bus speed. In the case of parallel buses, the controllers will match bus speed when lock-on for transfer. It the case of serial buses, it protocol and unit dependent centered around the bus clock.

@Kirk and others, thanks for information on video setup. I'm sure all of the info presented will end up in FATDOGs documented files and FAQ soon.

Thanks

LateAdopter
Posts: 361
Joined: Fri 27 May 2011, 17:21
Location: Reading UK

#48 Post by LateAdopter »

Hello kirk

I hadn't considered the microscopic fonts after modeswitch, to be a Fatdog specific problem, since all puppies did it. Nor did I think it was particularly important.

But I notice that recent Woof built puppies (Precise & Slacko14) modeswitch to a font which is the normal width but squashed a bit vertically. It is more than twice the size of the font in Fatdog.

EDIT: I should say, this is with the Radeon r600g driver and a 1600x1200 monitor.

I guess that BarryK must have found a configuration setting that can change it.

Anyway Fatdog64 610 is working well for me. The things that you did: cpuid, msr and panning are still working, - and they don't in recent Woof built puppies!

Thank you for that.

jamesbond
Posts: 3433
Joined: Mon 26 Feb 2007, 05:02
Location: The Blue Marble

#49 Post by jamesbond »

kirk wrote:
Even when the frame buffer does not get messed up, the text console fonts, which were previously readable, suddenly become microscopic during the boot sequence, making it hard to tell what is going on when there is a problem in getting to X and a desktop, or in the reboot/shutdown sequence, when there is a failure to save.
Again, this happens after KMS modules load which also load console frame buffer modules, though I haven't had any problems reading the font. If you don't want to use KMS for some reason you have to boot with nomodeset and probably use vesa.
In addition, there are two more things you could do:
2. You can set try to set the video mode / resolution of your text console. How to do it is listed here: https://wiki.archlinux.org/index.php/Ke ... cing_modes and here http://nouveau.freedesktop.org/wiki/KernelModeSetting among other places.

BTW - the above should work for all puppies (or other distros too!) that uses KMS.

3. Use a large console font. The most popular one seems to be from here http://terminus-font.sourceforge.net/, the maximum size is 16x32 (double from standard 8x16).

I've attached here a new xorgwizard that myself and kirk is working on. Download the pet somewhere accessible from fatdog installation; boot with pfix=nox, then install the pet using "silent_petget /path/to/pet". Then start xorgwizard as usual (xorgwizard, not xorgwizard-old). Let me know whether it helps.

EDIT: I have also attached the big fonts. Same the new xorgwizard: after booting with pfix=nox, install the pet using silent_petget. Then run this: "setfont big" or "setfont bbig" (bbig stands for "bold and big"). That will install the Terminus 16x32 fonts. It looks very huge on my 1024x768 screen, but then I don't have 1600x1200 displays.

Let us know whether either/both the fonts and the new xorgwizard works, if they do, they will be included in the next release of Fatdog.

Note 1: The big fonts won't load unless you are using KMS with framebuffer console.
Note 2: Load the fonts using "setfont" only when you're at the console, not when you're using a terminal emulator (xterm, rxvt, sakura) inside the desktop.
Note 3: The big fonts I've attached only covers ISO-8859-1 character sets.

cheers!
Attachments
fonts-big.pet
big console fonts (Terminus 16x32)
(6.41 KiB) Downloaded 634 times
xorgwizard-new.pet
new xorgwizard
(3.22 KiB) Downloaded 616 times
Fatdog64 forum links: [url=http://murga-linux.com/puppy/viewtopic.php?t=117546]Latest version[/url] | [url=https://cutt.ly/ke8sn5H]Contributed packages[/url] | [url=https://cutt.ly/se8scrb]ISO builder[/url]

User avatar
prehistoric
Posts: 1744
Joined: Tue 23 Oct 2007, 17:34

#50 Post by prehistoric »

@Jamesbond,

Thanks for the xorgwizard-new pet! It will take me a day or so to test because I have to change video cards -- in the machine I am currently using for normal work -- to reproduce the problem. I don't want to shut it down until an unrelated crisis is over.

@all,

Let me make clear to kirk and all that I am not complaining that Fatdog 610 is unusable for me as it stands. I am typing this on 610 using the machine which had the problem. For me, slipping in an off-board graphics card I had lying around was no big deal. For others it would likely be a stumbling block. (I know plenty of people who freak out when I open the case of their machine.)

Last night I installed Fatdog 610 on yet another machine for someone I know. They were thrilled to see that VLC and Gimp were standard. (We had had an adventure while trying to install VLC on 5.4.2.) What I'm trying to get around is the need for experienced hand-holding to get started.

-----

Why wasn't I content with VESA? On a large CRT monitor the flicker from 60 Hz refresh is disturbing. I acquired such a monitor when others were fleeing to LCDs not just because of the accurate colors, but because it can go up to about 140 Hz, where eyestrain is negligible.

I also hope you will forgive me for reiterating: people with reduced visual acuity are all around you. I'm doing OK, but I have daily contact with others my age who are not. For them reducing the resolution can be a quick fix. To get a feel for the frustration they experience try to set up an installation wearing glasses with the wrong prescription. The clever work-arounds people suggest are a bit of a problem if you can't see what you're doing, which ends up as a call for help I have to answer.

(I still recall an auto repairman who didn't like any of the adjustments I made to get the most out of his Windows set up. He was ecstatic when I gave up and set the resolution to 800x600. At last he could see what was on the screen without squinting. There must be better solutions, but this was what I could do in the time available while picking up my car.)

------

I understand that the thrust of your development effort concentrates on machines produced in the last 5 years. If I go through the stack of motherboards removed from working machines around me, I think I can find at least 3 64-bit machines represented. These are likely older than 5 years. Inevitably, people on tight budgets will try Fatdog on such machines. These are the people ignored by commercial developers.

----

Aside: As a particularly galling example of the effect of market forces and monopoly power on software I present a gotcha in Windows 7 I just ran into when RAM prices dropped. Since I don't use Windows myself it had never bothered me before.

I am setting up a machine as a gift for friends. (It cannot be entirely a surprise, since I have borrowed their software to install on the new machine.) The goal was to migrate them to a more powerful machine without entirely losing compatibility with all their XP programs and user interface. A big plus for running bloated software is a surplus of RAM. I calculated that I could go to 32 GB. of RAM for $100 if I shopped carefully.

When I had this working under Fatdog, I went back to Windows 7 Home Premium. In the system information tab it told me I had "32 GB (16 GB usable)". It knows the RAM is there, but refuses to use it.

How to get around this? (No, thank you, I do not like W8.) Using "Windows anytime upgrade" I can go to W7 Pro for $89. This is more than I just paid for W7 Home Premium. I can get a legal reinstallation DVD with COA for W7 Professional for $75. This will wipe out my current installation, but it will leave me with the option of using W7 Home Premium on another machine, as this installation was never activated or registered.

This is the world people flee when they come to Puppy.

Post Reply