Fatdog64-600 Final and 601 (July 2012)

[James C]

Still running Fatdog64-600 from multi-session DVD with basically no problems. Great job.

[Яadiøaktive TΣknik]

I have managed to persuade Fatdog to run on my desktop computer but as with other Puppy versions it doesn't pick up the raid0 array. Coincidentally I discovered that a version of the dmraid pet was uploaded to the nluug Fatdog repository earlier today which I have downloaded and installed. However the dm-mod kernel module does not load and with my insufficient knowledge I have been unable to see why. Has anyone else tried this pet yet or can anyone give me any clue as to why dm-mod refuses to load? This machine has to run Windows as well (for my better half!) so I am stuck with the requirement to use dmraid as there is a ton of data on the raid array that I need to access. I had no problems making dmraid work in Lucid but I would rather use Fatdog as my main OS.

I have used jamesbond's new compile of dmraid [the one now available as a .pet] and it mounts my raid0 without any problems. dmraid reports that it can mount the following controllers / arrays:

asr : Adaptec HostRAID ASR (0,1,10)
ddf1 : SNIA DDF1 (0,1,4,5,linear)
hpt37x : Highpoint HPT37X (S,0,1,10,01)
hpt45x : Highpoint HPT45X (S,0,1,10)
isw : Intel Software RAID (0,1,5,01)
jmicron : JMicron ATARAID (S,0,1)
lsi : LSI Logic MegaRAID (0,1,10)
nvidia : NVidia RAID (S,0,1,10,5)
pdc : Promise FastTrack (S,0,1,10)
sil : Silicon Image(tm) Medley(tm) (0,1,10)
via : VIA Software RAID (S,0,1,10)
dos : DOS partitions on SW RAIDs

This is working with both my RAID controllers. I also have a Silicon Image on I've yet to try. The command which mounts my Intel RAID array is embarrassingly simple:

Code: Select all

 dmraid -ay 

If that doesn't work for you, then I'd advise mounting the RAID however it worked in other puppy[s]. dmraid should work the same across distros I think? Unless I'm not understanding your problem.

[jamesbond]

Actually I figured out the problem, it's that they were not installed with the package manager, although in other Puppies all installed packages show up.

All installed packages show up. In my earlier post, at least two installed programs shown were not installed by package manager.

Jim1911 is right. You can manually check whether the "missing" packages are registered correctly - just open the file /root/.packages/user-installed-packages. If they are found inside but is not shown by the package manager, then it's a bug, let me know (please send the file to me). If they are not listed in that file to begin with ... well, try to install again and then check the file again, are they inside after that? If still not, let me know which package exactly and I'll try to duplicate that.

I had already deleted that save file although I have the same problem on two other save files on different ext4 partitions, sda2 and sdb2. Sda2 was formatted using FD64-600's version of gparted. Both save files are working properly.

Thanks Jim. Apparently guess_fstypes is not reliable for checking savefile. I will update the tool to use disktype instead.

It appears the problem may have been caused by the 23oz theme. Once removed all worked fine.

Thanks, that sounds good.

Another day another fatdog install.

You seem to have the knack to find interesting wallpapers

Still running Fatdog64-600 from multi-session DVD with basically no problems. Great job.

Thank you

However the dm-mod kernel module does not load

dm-mod module is built-in to the kernel and is automatically loaded at each boot. You don't need to load that manually. Яadiøaktive TΣknik can probably help you further than I can.


cheers!

[Billtoo]

Another day another fatdog install.

You seem to have the knack to find interesting wallpapers

I find them at:

http://www.desktopnexus.com/

Here's a good one I think.

[mini-jaguar]

Wow, I think I know that place and have drunk coffee there several times. Is it in Gambetta?

[jamesbond]

Hi Jamesbond and Kirk,
just been reminded of icon drive wobble.
FYI
fresh boot drive icons - ok
2,3,5,6,7,8,9,10,11,12 (4 was a extended partition)

open gparted
2,3,5,9,12,7,11,6,8,10 - mounted drives 2 and 3 did not move

close and reopen gparted
2,3,12,8,9,5,6,11,7,10
etc

DC

The wobble can be fixed by going to Control Panel -> Display -> Event Manager and changing the icon-size values from 64 to 63. I will make it 63 as the default in when I release consolidated fixes.

[irishrm]

When booting fatdog from USB install my savefile on occasion is not being loaded (doesn't happen that often)

Trying to follow the instructions in the faq's I did the following.

label fatdog
kernel vmlinuz
initrd initrd
append search
devwait=5

i.e. added devwait=5 as above.
Is this correct.

Thanks.

irishrm.

[rcrsn51]

Instead of searching for the savefile, open the Control Panel > Utilities and run the Savefile Argument Builder. It will create the correct boot argument so Fatdog doesn't have to search.

Also "waitdev=5" should probably be on the end of the append line. And it's NOT "devwait".

[irishrm]

rcrsn51:

Thanks again for the reply.

You really must concentrate when making changes.

I will delete my entry to syslinux file and go with your first suggestion.

irishrm.

[rcrsn51]

You may also need the waitdev=5 argument.

[irishrm]

Did this so far:

label fatdog
kernel vmlinuz
initrd initrd
append search waitdev=5

on rebooted the 5 second delay showed on screen.

Will try the savefile argument builder next.

irishrm.

[rcrsn51]

initrd initrd
append search waitdev=5

This should all be on one line

Code: Select all

append initrd=initrd waitdev=5 ...

Why not use Grub4Dos Bootloader Config? It would set this up for you.

[irishrm]

In case I haven't been clear, waitdev-5 is working well. no mishap so far.

I've been taking the easy way out by doing my USB installs through windows using unetbootin.exe.
I've installed quite a number of puppies this way so far, its so easy.

I've just tried the savefile argument builder and it gave me this:
"savefile=ram:uuid:SCANDISK:/fd64save.ext4"

However having appended it in the syslinux file it failed to find the savefile on numerous boots.
That is with and without waitdev=5.

So I'm back with waitdev=5 and that's working fine.
l wonder why the filesave argument didn't work?

irishrm

[rcrsn51]

I've just tried the savefile argument builder and it gave me this:

Code: Select all

savefile=ram:uuid:SCANDISK:/fd64save.ext4

The UUID of a flash drive should be a string of digits like

Code: Select all

4AC0-1596

I don't know how it could be a word like SCANDISK.

Assuming that the flash drive is sdb1, open a console and type

Code: Select all

blkid /dev/sdb1

What do you get?

Please post your full syslinux.cfg file.

[irishrm]

Sleep time intervened:

SCANDISK is the name of the USB stick o.k.

sh: blkid/dev/sdb1: No such file or directory
Obviously something amiss here.

default fatdog
display help/boot.msg
prompt 1
timeout 50

F1 help/boot.msg
F2 help/help.msg
F3 help/savefile.msg
F4 help/startnet.msg
F5 help/basesfs.msg

label fatdog
kernel vmlinuz
initrd initrd
append search waitdev=5

irishrm.

[rcrsn51]

sh: blkid/dev/sdb1: No such file or directory

When you type a command, you need to leave a space in the middle, between the "blkid" and the "/dev/sdb1"

SCANDISK is the name of the USB stick o.k.

I see the problem. SCANDISK is the stick's LABEL, not its UUID. The Savefile Argument Builder is getting confused.

Please install the new version below and test again. It should give you the same UUID as with the "blkid" command above.

[irishrm]

I'm afraid I'll never make a coder!!!!

/dev/sdb1: LABEL="SCANDISK" UUID="5AA8-245E" TYPE="vfat"

savefile=direct:device:sdb1:/fd64save.ext4

these results look right?

testing now.

irishrm.

Edit:
Rebooted and it went straight to sdb1 and loaded instantly so that's a success.

Thanks for your time and patience.

[rcrsn51]

savefile=direct:device:sdb1:/fd64save.ext4

Note that this new entry doesn't contain the UUID value. That's because you chose "Hard Drive" instead of "USB" in Step 4.

This is not necessarily a bad thing. It means that FD will treat the flash drive like a regular hard drive and automatically write data back to the savefile. So there is no pause when you shut down.

If you want your flash drive to work like in other Puppies, where data is only written back periodically, select USB instead.

[Яadiøaktive TΣknik]

savefile=direct:device:sdb1:/fd64save.ext4

Note that this new entry doesn't contain the UUID value. That's because you chose "Hard Drive" instead of "USB" in Step 4.

This is not necessarily a bad thing. It means that FD will treat the flash drive like a regular hard drive and automatically write data back to the savefile. So there is no pause when you shut down.

If you want your flash drive to work like in other Puppies, where data is only written back periodically, select USB instead.

It seems you've helped solve irishrm's troubles. It brings to mind a few things I've experienced with FD64. I installed mine on a USB stick using Universal USB Installer, which was how I actually downloaded my first version of FD64 as well - it has a built in ISO fetcher.

http://www.pendrivelinux.com/universal- ... -as-1-2-3/

Didn't see where posting links is forbidden or even frowned upon but I could be wrong. If so, sorry but this one is very relevant, very linux and very good. The tool did everything to get me running and not hassle with optical media, which I dislike.

Fatdog64 did the rest. On my first shutdown, I was asked two or maybe three painless questions about how I wanted sessions and in fact the personality of my install to be stored and it has worked flawlessly ever since. I have seven hard drives connected.

Three of them are in RAID, which is now recognized - thanks to dmraid .pet Others are archive storage and an SSD I'm working with. I found that FD64 and other puppies can take a moment to examine these, especially if connected drive contains a linux ext* fs.

I had one slow, old hard drive attached for some testing and any puppy version would stall for quite a while at boot examining that drive, perhaps looking for savefiles. My current boot is quick as lightning with fast, new hard drives connected though.

I'd like to define my storage drive permanently so that FD64 does not have to look around for the savefile location, especially if I have some ancient beast hard drive connected for testing or just to hear the old clicky rattling, which I kind of like.

Anyways, I think I've got it now based on this thread. I've read in other places that puppy differentiates between the way it handles savefiles for hard drive -vs- usb or optical media for time and also because excessive writes can prematurely end the life of a usb.

I'm using a KODAK 1GB USB stick to boot FD64 and I'm proud of that, especially since it still has 800MB free! It has a blue indicator light showing activity and it never blinks once during a heavy linux session. Not even a little at shutdown! I'm constantly amazed with this OS.

[kickstart]

kickstart wrote:
However the dm-mod kernel module does not load

dm-mod module is built-in to the kernel and is automatically loaded at each boot. You don't need to load that manually. Яadiøaktive TΣknik can probably help you further than I can.

I thought dm-mod wasn't loaded as it didn't show up with lsmod command. However with a little help from Яadiøaktive TΣknik I have my raid0 working just fine. What had me fooled as well is that your pet cuts out a lot of the manual configuration required with the previous pet I used with Lucid, it's much more plug & play. Many thanks for uploading it, coincidentally on the same day as I was struggling to get access to my raid array.