What GRUB error code are you getting?don922 wrote: Why doesn't it boot?
Is this a 64-bit computer? Have you run previous Fatdogs on it?
What GRUB error code are you getting?don922 wrote: Why doesn't it boot?
During the boot of Fatdog the computer crashes and locks up. I don't see any GRUB error code. How do I find it?rcrsn51 wrote:What GRUB error code are you getting?
rcrsn51 wrote:Is this a 64-bit computer? Have you run previous Fatdogs on it?
The lm in the second line of this code indicates that this is a 64bit computer. I have not run any previous Fatdogs on it.[color=green]grep flags /proc/cpuinfo[/color] wrote:flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 syscall nx mmxext fxsr_opt pdpe1gb rdtscp *lm* 3dnowext 3dnow constant_tsc up nonstop_tsc extd_apicid pni monitor cx16 popcnt lahf_lm svm extapic cr8_legacy abm sse4a misalignsse 3dnowprefetch osvw ibs skinit wdt
For what it's worth,here's my menu.lst entry for Legacy Grub and Fatdog 621...in sda10,no directory , everything just in /mnt/home/ .don922 wrote:I downloaded the Fatdog64-621.iso and the MD5sum is correct.
Using ISOMaster iso file editor I have extracted the following files from the Fatdog64-621.iso and put them in a new directory /mnt/home/puppy-fatdog-621:In a frugal installation the menulist is as follows:
- fatdog.png
fix-usb.sh
initrd
vmlinuzInitrd is shown as initrd.gz in Puppy 528.005 & Puppy 529. Fatdog 621 calls it just initrd.
- title Puppy 528.005
rootnoverify (hd0,0)
kernel /puppy528.005/vmlinuz pmedia=satahd psubdir=puppy528.005 pfix=fsck nosmp
initrd /puppy528.005/initrd.gz
title Puppy 529
rootnoverify (hd0,0)
kernel /puppy529/vmlinuz pmedia=satahd psubdir=puppy529 pfix=fsck nosmp
initrd /puppy529/initrd.gz
title Fatdog 621
rootnoverify (hd0,0)
kernel /puppy-fatdog-621/vmlinuz pmedia=satahd psubdir=puppy-fatdog-621 pfix=fsck nosmp
initrd /puppy-fatdog-621/initrd
The directories for Puppy 528.005 & Puppy 529 were prepared the same as Fatdog 621 and work fine.
What is wrong with what I've done with Fatdog 621? Why doesn't it boot?
Code: Select all
title Fatdog 64 621 in sda10
root (hd0,9)
kernel /vmlinuz nouveau.noaccel=1
initrd /initrd
Code: Select all
kernel /puppy-fatdog-621/vmlinuz nouveau.noaccel=1
621 and previous versions have XFS support right now, but the one I'm running is not. It is a choice because right now XFS conflicts with User Namespaces (that's the only filesystem left with a conflict, all others were resolved in 3.9). I will probably choose XFS over User Namespace for a public release. Waiting for 3.11 to go gold.DrDeaf wrote:Maybe not the interest you wanted, but I am interested in XFS support.jamesbond wrote:This is what we have in the Fatdog-Next as of today. Still using the 600 as the base. I have this running for quite a while now. Let me know if anyone is interested.
Fatdog64-Next Release Notes
Changes from 621:
Updates:
-------------------
- Linux 3.9.4 with lxc support but without XFS support
-------------------
Would that be possible?
The entry in menu.lst "blacklist=nouveau" has cleared up much of the booting from a frugal install problem.jamesbond wrote:don922, just open the isolinux.cfg on the CD and you'll see the command to eliminate nouveau (it's "blacklist=nouveau"). Copy that into your boot loader config and that should work.
For GeForce 6150 SE I think you'll need to install the nvidia_legacy driver, but to be sure please check nvidia website.
I am willing to wait as well. This is an enduring project for me. I am puzzled by the reference to earlier XFS support. Although I did not change to 621 since it was a bug fix release and I had no bugs I was concerned about, I have posted earlier about XFS and you were helpful to post attr-2.4.46-8.pet (Thanks again!)jamesbond wrote:621 and previous versions have XFS support right now, but the one I'm running is not. It is a choice because right now XFS conflicts with User Namespaces (that's the only filesystem left with a conflict, all others were resolved in 3.9). I will probably choose XFS over User Namespace for a public release. Waiting for 3.11 to go gold.DrDeaf wrote:Maybe not the interest you wanted, but I am interested in XFS support.jamesbond wrote:This is what we have in the Fatdog-Next as of today. Still using the 600 as the base. I have this running for quite a while now. Let me know if anyone is interested.
Fatdog64-Next Release Notes
Changes from 621:
Updates:
-------------------
- Linux 3.9.4 with lxc support but without XFS support
-------------------
Would that be possible?
Just added to the repo: http://distro.ibiblio.org/fatdog/pets/6 ... .8-622.pet, only because you asked, GregJustGreg wrote:There was a good mpg file header editor, Easytag, that was available under Lucid. The pets (easytag and library files) do not work with Fatdog.
Every so often, I need to edit the file header to include the track number in the title. I have found mpeg audio players sort the songs based on the title information. This prevents one from hearing the songs as on the album.
Is there a pet available for Fatdog that can edit the mpg audio file header information? Thanks for any help in advance!
Please post screenshots with icons positions "where it works" and "where it doesn't work".Snail wrote:I tried your suggestion, to leave the mouse hovering over the green box after clicking. It has no effect. As noted in my previous post you get a Rox window every time you click but no unmount, even after pointer "hovering" over the box for 20 seconds. Moving the icon a quite small distance restores normal behaviour, this was at Smokey01's suggestion.
Moving the icon back to the bottom left corner causes the problem to come back. You don't have to be totally precise in positioning the icon there to reinstate the odd behaviour but you do have to be quite close.
That's expected behaviour if you move the Download folder outside the savefile.I have a windows partition frugal install, set up by Fatdog's installer. When using webmail, I initially thought that you can't attach files from the windows partition, except for the Spot folder. The file Open Window behaves as if /mnt/sda2 is not mounted. Then I realised that, on the other hand, mnt/home, which is the same thing surely, works just fine. It's a bit confusing for a poor snail.
Yeah, there are just so many variations in wifi signalling I sometimes have to kill the dhcpcd task manually and restart them to get the IP address :pwpa-gui has a slightly odd behaviour. I'm in a hotel at the moment. When booting, it seems to be trying to connect to the correct wifi adapter but it stays stuck on "scanning". Disconnecting and reconnecting doesn't help. It took an awful lot of trying things before, quite by accident, I discovered that Manage Networks/Edit then Save(without changing anything since the network has already been set up) is enough to clear the logjam. Once this is done, connection takes a second or so and DHCP a few seconds more. The network is WPA2-PSK/TKIP+CCMP and the signal is good to excellent,
I'm not sure I get what you mean.Another minor quirk is that closing the window by using it's tile bar or the menu is NOT what you want to do. You must just hide the window using the taskbar icon. This is a bit of a trap for us idiots.
I think I already answered that a couple of times. /usr/lib is a mirror image of /usr/lib64. In a more technical terms /usr/lib is a bind-mount of /usr/lib64. The reason we use bind-mount instead of mere symlink is because symlink can be accidentally erased.Snail wrote:A while ago, I asked a dumb question about why /usr/lib and /usr/lib64 seemed to be identical. Of course, if I had opened /usr in Rox the fact that lib64 was just a symlink would have been bleedingly obvious. However, the reason that I was confused is that gdmap shows the two using up space in /usr, one is displayed above the other. Surely gdmap shouldn't do that?
You are right, it shouldn't do that. How exactly did you do to zip the stuff again? "zip" command line or "xarchive"?Anyway, as I was confused, I decided to check further. As gtkhash doesn't do directories, I tried to zip them and hash the zipfiles. This caused the file system to fill up and eventually trashed the savefile. Why would xarchive do that? Shouldn't temp be located separately from the savefile, since it's never saved?
The process/steps to carry out these task; could you share them. Or, is there a script which might do same?jamesbond wrote:Yeah, there are just so many variations in wifi signalling I sometimes have to kill the dhcpcd task manually and restart them to get the IP address :p ...wpa-gui has a slightly odd behaviour. I'm in a hotel at the moment. When booting, it seems to be trying to connect to the correct wifi adapter but it stays stuck on "scanning". ...
Here they are jamesbond. As you can see, the amount of movement involved is subtle, within the precision that I can place the icons anyway.Please post screenshots with icons positions "where it works" and "where it doesn't work".