Fatdog64-600 Final and 601 (July 2012)

[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.

[irishrm]

rcrsn51:

Thanks for pointing out that I missed step 4. (rushing)

Having used this configuration for a while I think I'll stick with it, it boots and closes down so quickly.

I understand there can be consequences but I think its worth it.

I always move all my files to the computer hard-drive anyway as well as doing a second back up.

Also as soon as I'm happy with my savefile I'll save a copy so if or when the usb fails I should be up and running in very quick time.

I wonder is there many have had a usb fail for this reason?

irishrm.

[rcrsn51]

I wonder is there many have had a usb fail for this reason?

A while back, DaveS tested this by putting a regular Puppy flash drive in PUPMODE=12. This is the same setup as yours - immediate writes back to the savefile. It went for months with no failures.

However, you may want a combo savefile argument of the form

Code: Select all

savefile=direct:uuid:xxx-yyy:/fd64save.ext4

By using the UUID, you can safely move the flash drive to another computer where it might not still be sdb1.

[don570]

What is the wording when the following is typed in terminal
Is this the best way to get the puppy version when
installing software??

Code: Select all

cat /etc/puppyversion

___________________________________________

[irishrm]

rcrsn51:

Thanks for that piece of very useful information.

At the moment this is the only computer i have which is capable of running fatdog. I have made a note of the code and no doubt i will feel the urge to try it in the near future.

BTW:
If my usb explodes I'll let you know.

[rcrsn51]

@irishrm: And thank you for doing this testing. The LABEL vs UUID issue was a significant bug that needed fixing.

[smokey01]

jamesbond, I was just wondering why Geany-0.21 is used if FD64 when 1.22 is available. I compiled it and it seems to work fine. I have no idea what the benefits of 1.22 are over 0.21.

[Q5sys]

I may see if I can update fatdog to glibc 2.15. But that'll depend on if I get time over the next few weeks. Are you aware of any potential landmines I may be facing?

Sometimes you can do that without any problems, but everything is built against it, you could have problems.

Yea pretty much everything dies. Hopefully in the next version you guys do... you can include something a bit newer than 2.13.
If not, no worries.
I know you guys have TONS of work on your plate, so I dont want to lump anymore on you.

[irishrm]

Update:

Had a failure to load the savefile again so reverted to this:

label fatdog
kernel vmlinuz
initrd initrd
append search waitdev=5 savefile=direct:device:sdb1:/fd64save.ext4

Working so far.

irishrm.

[jamesbond]

What is the wording when the following is typed in terminal
Is this the best way to get the puppy version when
installing software??

Code: Select all

cat /etc/puppyversion

___________________________________________

For Fatdog, it is /etc/fatdog-version. Fatdog's devx has its own version in /etc/fatdog-devx-version. The numbers you will see is a cryptic hexadecimal number, not a nice number of 6.0 or anything like that - those numbers correspond to the "commit id" of the fossil revision control system we use (openly available in chiselapp.com). By looking at that number, we can instantly know when and which code is contained within that ISO. This is also the version number shown in Hardinfo.

jamesbond, I was just wondering why Geany-0.21 is used if FD64 when 1.22 is available. I compiled it and it seems to work fine. I have no idea what the benefits of 1.22 are over 0.21.

Because it was the latest when kirk rebuilt the majority of 600 the packages back in Feb. I just checked 1.22 release notes, apart from bug fixes there isn't any major end-user visible features.

[jamesbond]

One of the new "problem" I have in 600 is that openbox doesn't always bring up new windows to the top anymore. To illustrate the problem - I have "WinKey+e" mapped to open rox folders, Alt+F2 to open lxpanel launcher, and "WinKey+t" to open rxvt.

WinKey+t works fine, but opening rox/launcher doesn't always work. They *do* work in the sense that the windows/launcher are actually started, but they are not always brought to the top - one needs extra Alt-Tab to bring them to the top. Quite annoying, really.

This wasn't a problem with 521. My suspicion is that it has something to do with the new version of openbox in 600, because if I use obconf to disable "focus new window as they appear", then the rox/launcher windows are brought to the top as expected. Of course this also doesn't solve the problem - I still then need to do Alt+Tab or click the mouse to activate it.

I could replace lxpanel launcher with gexec, but I can't see any workarounds for rox. Any advice appreciated.

cheers!