Considering Frugal Install over a Hard Drive install.

[Kirby]

Hiyas Mates
I live out in the woods and we get alot of power interrupts. Trees falling across lines, squirrels in the transformers etc. I have already lost one of my Pups due to an improper shut down.

I have a Dell Dimension E510 Desktop computer.
Processor is a Intel Pentium 4, 3ghz
1 GB of Ram.

I find the file system with a full HD install easier to use as far as finding files, but I am getting better with Puppy so I don't think it's an issue any more.

The more I read the more it seems that Advanced users prefer Frugal installs. For the sake of stability when the power drops (which it does quite a bit) would it be safer to use a Frugal Install?

And if so what would be the best way to switch over?

Thanks for any advice
Kirby

[davesurrey]

Hi Kirby,
If you are saying you have a full install but want to migrate it to a frugal install then I am afraid to say I don't think there is any way to do that. They are very different beasts.

You'll have to save your data files and reinstall. You can of course install the frugal over the full and so have both installs in the same partition if you want to compare but if it's power outages that concern you then best to do a fresh format and install frugal on its own.

As to whether frugak or full is best there have been some heated and polarised debates over this and best to say it's a personal choice. For my part I used full intially as it was what I felt most comfortable with coming to Puppy from other installs that could only be done as a full. But I quickly saw advantages to frugal and use it almost exclusively now.

See for my take on things. http://www.murga-linux.com/puppy/viewto ... 818#377818

HTH
Dave

[JustGreg]

Krby, I will not repeat Davesurrey comments on full versus frugal installation. I agree with him.

I also live off the beaten track and have problems with power going off. I have found with Puppy version 4.3.1, one can restore the Puppy after improper shutdown by deleting all the files in /tmp directory. This has worked for me also with version 4.2. What I have seen after an improper shutdown (another car did not make the curve, but found a powe pole), is Puppy would start and then stop during the kernel loading. I boot from a live CDROM version of Puppy, usually the version I am using, and delete everything in /tmp directory and reboot. The hard disk installation starts up. You may get a screen asking whether or not to continue with the X windows startup. I just hit the continue button and it starts up. This has happen about three times last year.

You might want to look at this post. It may give you some additional information.
http://www.murga-linux.com/puppy/viewtopic.php?t=47668

I hope this helps.

[davesurrey]

You might want to look at this post. It may give you some additional information.
http://www.murga-linux.com/puppy/viewtopic.php?t=47668

Just a point but I think this only applies to Full installs.
Dave

[Kirby]

Hiyas Mates
Thanks for the advice. I have read up and understand better why folks prefer Frugal Install. I personally don't have a preference either way. I do really love the fact that Puppy gives me options though.

I have a few more questions before I decide.

In either case I am seeing the reason for using the disc check feature. The way I have it set up now is Puppy is on /sda6 and I have /sda7 as Home to store my music and pictures. When I once in a great while boot up Opensuse 11.2 it complains /sda7 has been mounted 502 times without a fchk or what ever and scans it.

I think I understand that in a Frugal there is no need for it on it's native partition but is there a way to have it scan /sda7 "Home" at boot up or shut down? (which ever would be more appropriate)

Same goes for Full Install.

Thank You for all your help.

Kirby

[Jim1911]

Since I play around with numerous frugal installations of puppy, I run a fsch at each boot by placing the code in my menu.lst as follows:

Code: Select all

# Linux bootable partition config begins
title Test (on /dev/sdb7) 
root (hd1,6)
kernel /Test/vmlinuz pfix=fsck pmedia=idehd pdev1=sdb7 psubdir=Test
initrd /Test/initrd.gz
# Linux bootable partition config ends 

You probably can add any number of partitions to the kernal line to check. However, I don't know if a flag is set that Opensuse 11.2 will recognize. The initial check will be slow, but subsequent checks are very fast.

[davesurrey]

Hi Kirby,
Well every time your Opensuse or Puppy or whatever you have installed to an ext3 file system is unmounted the "journaling" in ext3 is applied and the files are marked as clean. That's the theory at least. But if you get an unclean unmount, for whatever reason, then the partition is marked as unclean. If your partition is an ext2 one then there is no such journaling.

It depends on each distro but usually (a dangerous word) after 20 to 30 umnounts it automatically starts a clean up doing a fsck (file system check).
You can usually set the number of times it waits, for example

Code: Select all

tune2fs -c10 /dev/sda

if you want it to check after 10 unmounts.

You can also force an unmounted partition by

Code: Select all

fsck /dev/sda1

or ensure it does a check every boot by adding pfix=fsck to the grub boot stanza as Jim suggests. Just be careful never to run fsck on a mounted partition. It can do far more harm than good.

HTH
Dave

[Kirby]

Hiyas Mates
I decided to reformat /sda6 and installed a frugal of Stardust 009. The menu.list added is this...

Code: Select all

# Modified by YaST2. Last modification on Mon Feb  8 06:57:40 PST 2010
# THIS FILE WILL BE PARTIALLY OVERWRITTEN by perl-Bootloader
# Configure custom boot parameters for updated kernels in /etc/sysconfig/bootloader

default 2
timeout 8
##YaST - generic_mbr
gfxmenu (hd0,4)/boot/message
##YaST - activate

###Don't change this comment - YaST2 identifier: Original name: linux###
title SUSE LINUX 
    root (hd0,4)
    kernel /boot/vmlinuz root=/dev/disk/by-id/ata-Maxtor_6V160E0_V397B5MG_V397B5MG-part5    repair=1 resume=/dev/disk/by-id/ata-Maxtor_6V160E0_V397B5MG_V397B5MG-part8 splash=silent quiet showopts vga=0x317
    initrd /boot/initrd

###Don't change this comment - YaST2 identifier: Original name: failsafe###
title Failsafe -- SUSE LINUX 
    root (hd0,4)
    kernel /boot/vmlinuz root=/dev/disk/by-id/ata-Maxtor_6V160E0_V397B5MG_V397B5MG-part5 showopts apm=off noresume edd=off powersaved=off nohz=off highres=off processor.max_cstate=1 x11failsafe vga=0x317
    initrd /boot/initrd

###Don't change this comment - YaST2 identifier: Original name: Linux other 1 (/dev/sda6)###
   title Puppy Stardust 009 frugal
   rootnoverify (hd0,5)
   kernel /stardust009/vmlinuz pmedia=atahd psubdir=stardust009 nosmp
   initrd /stardust009/initrd.gz
    
###Don't change this comment - YaST2 identifier: Original name: windows###
title Windows
    rootnoverify (hd0,1)
    chainloader +1

I am still confused about how and where to slip the code in? Is the code that Jim1911 suggested an additional menu item and should be placed between Suse and Puppy?

Code: Select all

# Linux bootable partition config begins
title Test (on /dev/sdb7)
root (hd1,6)
kernel /Test/vmlinuz pfix=fsck pmedia=idehd pdev1=sdb7 psubdir=Test
initrd /Test/initrd.gz
# Linux bootable partition config ends

This is a learning experience for me and end up having more questions than answers. I think all I am after is a way to make sure my 2 main partitions I use (/sda6-puppy, and /sda7-home) get checked so I don't lose data from file corruption from power outages. (those comments were more for me to try and refocus about what I was after originally )

Thank You so much for all your help and patience!
Kirby

[RetroTechGuy]

Hi Kirby,
If you are saying you have a full install but want to migrate it to a frugal install then I am afraid to say I don't think there is any way to do that. They are very different beasts.

"Migrate" is probably not the correct description, but he can leave his existing full install, and simply place his pupsaves in a folder on one of those partitions (just don't use /tmp, as most Linux systems purge it on startup). Puppy doesn't care.

Hopefully he has saved the .pet, .deb, etc., files so he can simply reinstall them in the frugal.

Once the frugal is running, he can sort his user files into a location that is easily accessible to both OS.

You'll have to save your data files and reinstall. You can of course install the frugal over the full and so have both installs in the same partition if you want to compare but if it's power outages that concern you then best to do a fresh format and install frugal on its own.

Correct -- with grub installed, he can do a frugal install -- but it will be a "fresh install". He can still leave his machine as a dual-boot.

Re: power instabilities -- I would recommend getting a UPS. If you lose power, use the power buffer time to perform a clean shutdown.

I would regularly back up your pupsave -- if you trash something, it's an easy recovery to simply copy the backup over your corrupt "master" pupsave -- just make sure that you are not mounted on "master" when you do this (or perhaps better yet, rename the master to "corrupt", copy the backup to "master", and you can mount both and transfer any files from within the corrupted pupsave to the restored "master")

[Jim1911]

Hi Kirby,

I am still confused about how and where to slip the code in? Is the code that Jim1911 suggested an additional menu item and should be placed between Suse and Puppy?

I'm not sure what you are trying to do. Is Stardust booting properly using the menu.lst you posted?

If all you want to do is accomplish a fsck during boot, just add the code in quotation marks (leave quotation marks off) to your Stardust kernel line as follows:

Code: Select all

kernel /stardust009/vmlinuz pmedia=atahd "pfix=fsck pdev1=sda6" psubdir=stardust009 nosmp 

This code would be executed at every boot. If you don't want that to happen, you could create an entire new puppy entry with above code inserted to select only when you want to run fsck with a title such as Puppy Stardust 009 frugal with fsck.
Cheers,
Jim

[RetroTechGuy]

[quote="Jim1911"][/quote]

Y'know, I just have to say this...

"Don't dial 911, dial 1911 and let it ring several times!"

[jpeps]

Does pfix=fsck also get the pupsave file? I would think so, but I found inode errors right after running it. (maybe because it's located inside an ext 3 partition?? )

[RetroTechGuy]

Does pfix=fsck also get the pupsave file? I would think so, but I found inode errors right after running it. (maybe because it's located inside an ext 3 partition?? )

Yes. I set that option to run automagically in my puppy boot menu (I personally think that pfix=fsck should be the default operation for Puppy -- to help keep inexperienced users out of trouble).

What's nice about that frugal setup is that whatever pupsave I point the bootloader at, gets fscked before I load it...

[jpeps]

Does pfix=fsck also get the pupsave file? I would think so, but I found inode errors right after running it. (maybe because it's located inside an ext 3 partition?? )

Yes. I set that option to run automagically in my puppy boot menu (I personally think that pfix=fsck should be the default operation for Puppy -- to help keep inexperienced users out of trouble).

What's nice about that frugal setup is that whatever pupsave I point the bootloader at, gets fscked before I load it...

Interesting...I get the same inode corruption every shutdown, no matter what I do. I'll have to check it out further.

[RetroTechGuy]

Does pfix=fsck also get the pupsave file? I would think so, but I found inode errors right after running it. (maybe because it's located inside an ext 3 partition?? )

Yes. I set that option to run automagically in my puppy boot menu (I personally think that pfix=fsck should be the default operation for Puppy -- to help keep inexperienced users out of trouble).

What's nice about that frugal setup is that whatever pupsave I point the bootloader at, gets fscked before I load it...

Interesting...I get the same inode corruption every shutdown, no matter what I do. I'll have to check it out further.

It seems that Puppy uniformly fails to cleanly umount the pupsave (a known problem, but I don't know how to fix it). I traced it to a number of 4.xx versions (I didn't try the 3.xx versions, but it's likely to be there as well).

I had a series of failures where my pupsave was basically corrupted to "un-repairable". I now also keep regular backups of the pupsave (they're small, keep lots of them), so a "rebuild" is simply a copy/rename operation (and Puppy will query which pupsave to load, if there is more than one). But I haven't had a failure since I started "fsck"ing the pupsave before mount.

For this reason, as well as making Puppy "newbie friendly" (nothing like corrupting a newbie's file system to sour him on Puppy), I think that Puppy should always fsck the pupsave before mounting (make the experts turn it off, if they don't want the feature).

With a couple small fixes such as this, and I would easily rank Puppy among the best operating systems I've ever seen (well, I already do rank it among the best -- but not quite ready for "prime-time" -- some newbies would be frustrated).

Back to the immediate topic, if you're using grub, go to your "/boot/grub" folder and edit menu.lst. Add pfix=fsck into the kernel /puppy431/vmlinuz ... line.

On the next boot, you will see something like "scanning filesystem" on the line following your pupsave name.

[Bronco Billy]

Yes. I set that option to run automagically in my puppy boot menu (I personally think that pfix=fsck should be the default operation for Puppy -- to help keep inexperienced users out of trouble).

What's nice about that frugal setup is that whatever pupsave I point the bootloader at, gets fscked before I load it...

Interesting...I get the same inode corruption every shutdown, no matter what I do. I'll have to check it out further.

It seems that Puppy uniformly fails to cleanly umount the pupsave (a known problem, but I don't know how to fix it). I traced it to a number of 4.xx versions (I didn't try the 3.xx versions, but it's likely to be there as well).

I had a series of failures where my pupsave was basically corrupted to "un-repairable". I now also keep regular backups of the pupsave (they're small, keep lots of them), so a "rebuild" is simply a copy/rename operation (and Puppy will query which pupsave to load, if there is more than one). But I haven't had a failure since I started "fsck"ing the pupsave before mount.

For this reason, as well as making Puppy "newbie friendly" (nothing like corrupting a newbie's file system to sour him on Puppy), I think that Puppy should always fsck the pupsave before mounting (make the experts turn it off, if they don't want the feature).

With a couple small fixes such as this, and I would easily rank Puppy among the best operating systems I've ever seen (well, I already do rank it among the best -- but not quite ready for "prime-time" -- some newbies would be frustrated).

Back to the immediate topic, if you're using grub, go to your "/boot/grub" folder and edit menu.lst. Add pfix=fsck into the kernel /puppy431/vmlinuz ... line.

On the next boot, you will see something like "scanning filesystem" on the line following your pupsave name.

Have a Great Day with Your New Found Knowledge.....

[jpeps]

It seems that Puppy uniformly fails to cleanly umount the pupsave (a known problem, but I don't know how to fix it). I traced it to a number of 4.xx versions (I didn't try the 3.xx versions, but it's likely to be there as well).
....

Back to the immediate topic, if you're using grub, go to your "/boot/grub" folder and edit menu.lst. Add pfix=fsck into the kernel /puppy431/vmlinuz ...line.

good advice...I've seen regular corruption in other distros like TinyCore, where the developer actually removed fsck from base
his usual approach to handling bugs he can't fix.

[Bronco Billy]

Interesting...I get the same inode corruption every shutdown, no matter what I do. I'll have to check it out further.

It seems that Puppy uniformly fails to cleanly umount the pupsave (a known problem, but I don't know how to fix it). I traced it to a number of 4.xx versions (I didn't try the 3.xx versions, but it's likely to be there as well).

I had a series of failures where my pupsave was basically corrupted to "un-repairable". I now also keep regular backups of the pupsave (they're small, keep lots of them), so a "rebuild" is simply a copy/rename operation (and Puppy will query which pupsave to load, if there is more than one). But I haven't had a failure since I started "fsck"ing the pupsave before mount.

For this reason, as well as making Puppy "newbie friendly" (nothing like corrupting a newbie's file system to sour him on Puppy), I think that Puppy should always fsck the pupsave before mounting (make the experts turn it off, if they don't want the feature).

With a couple small fixes such as this, and I would easily rank Puppy among the best operating systems I've ever seen (well, I already do rank it among the best -- but not quite ready for "prime-time" -- some newbies would be frustrated).

Back to the immediate topic, if you're using grub, go to your "/boot/grub" folder and edit menu.lst. Add pfix=fsck into the kernel /puppy431/vmlinuz ... line.

On the next boot, you will see something like "scanning filesystem" on the line following your pupsave name.

Have a Great Day with Your New Found Knowledge.....

The Statements in the Bright Red Say it All....... Have A Great Day...

[RetroTechGuy]

Re: How Did You Discover This pfix=fsck Fix?

IIRC, one or more of our friends MikeB, Pizzasgood, or PaulBx1 pointed me to a solution. Thank you gentlemen!

If this Makes Frugal Installs Totally Stable... Then Why Would Anyone Use Unstable Full Installs?

I don't know if it makes it "totally stable", but it is vastly improved. Is it more or less stable than a full install? Unknown.

I still occasionally get the Xorg screen, forcing me to reset my video options (I can tell that something was corrupted when that happens -- undoubtably from the failure to get a clean umount).

From my reading, the main disadvantage of a pupsave (frugal) operation is that the Puppy system tends to become "grumpy" when the pupsave file gets too large (2GB? 4GB? -- note that some filesystems, e.g. Fat32 and older versions of ext2, have file limits at that point). A full install will not suffer this problem.

If, however, you are willing to store your various files outside of the pupsave (say, for example, create and use /mnt/home/music, rather than storing all of your music inside the pupsave), then you can easily avoid this file size limitation. In my case, I've kept my pupsave down at 256MB, with room to spare. Some find this method a little more complicated, and don't want to deal with it.

I prefer the frugal install as the entire core of the OS is parked in a single, small container. It can be easily backed up (simple copy), and easily "ported" to another computer... (and if I want to play with multiple versions, I can simply put the pupsaves in different directories)

BTW, rather than putting your questions in the subject lines for an existing thread, it's probably easier for the reader if you put your questions in a message body (had I not looked more closely to see why you quoted the entire message, without saying anything, I would have skipped replying, as it wasn't obvious that you had anything to say).

[RetroTechGuy]

It seems that Puppy uniformly fails to cleanly umount the pupsave (a known problem, but I don't know how to fix it). I traced it to a number of 4.xx versions (I didn't try the 3.xx versions, but it's likely to be there as well).
....

Back to the immediate topic, if you're using grub, go to your "/boot/grub" folder and edit menu.lst. Add pfix=fsck into the kernel /puppy431/vmlinuz ...line.

good advice...I've seen regular corruption in other distros like TinyCore, where the developer actually removed fsck from base
his usual approach to handling bugs he can't fix.

"Feature eliminated for your convenience"?