(old)Puppy Linux Discussion Forum

irishrm wrote: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.

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.

irishrm wrote: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.

rcrsn51 wrote:

irishrm wrote: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 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.

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.

irishrm wrote: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 By using the UUID, you can safely move the flash drive to another computer where it might not still be sdb1.

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

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.

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

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.

kirk wrote:

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.

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.

don570 wrote: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.

smokey01 wrote: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.

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!

James try right click on Rox title bar and select layer then Always on top.

Mine seems to always be on top of other apps.

As a bread and butter user, I find Fatdog to be very good, it has the applications I use from the get go. The one minor fault I have is that the installed Samba will not connect to Windows 7, but XP and Linux do just fine. I don’t use Windows 7 much anyway.

I like having Qt configuration working, so, I added what was required to get it going from the larger qt4-472.pet.

The boot-up time is very good, less than 10 seconds on my semi slow 4 core computer. My son’s little bit quicker 6 core, loads in less than seven!

I have Fatdog 600 Seamonkey with Firefox added, running off of a vfat 32 partition, this is because of my older Mepis grub bootloader.

I am also, just using OpenBox and Lxpanel, I have white outed JWM and removed it from the menus because it does not work well with Xcompmgr and other numerous things. I believe it can be dropped from this OS all together and save a little space.

Over all really great job, Kirk and jamesbond.

PS: I am reversing my opinion on JWM, I compiled an older JWM 508, which is better able to handle xcompmgr. I than modified /usr/bin/jwm_menu_create to correct errors with the jwm -p test.

Kal wrote: The one minor fault I have is that the installed Samba will not connect to Windows 7

Are you talking about the Samba share mounting tool or the Samba server?

Get YASSM from Page 5. Run Samba share search from the Network menu.

Does your Win7 machine require authentication? If so, it will be listed as "hidden". On the next screen, you will enter the username, password and share name.

Yes, that got it cooking with Window 7 on my son’s machine. I was just using the shares program before. It only needed the share name (Downloads).

Thank You for the new pet, it worked .

Kal

I've attached a patched version of Xorg-server-1.11.4. This should fix the panning problem. Please test. You might have have to make a new savefile if things go bad.

P.S. The pet package is named wrong, but it is the one to try.