HD install routine
HD install routine
Apologies if someone has already sussed this, but installing Puppy to HD can be very problematic. Advice in the Type 2 install for avoiding the Catch22 is to 'hide the FAT/Linux partition' so that pup001 cannot be installed there. The easiest way to do this is to delete the intended partition using fdisk from an M$DOS/DRDOS/XDOS FDD boot, then reinstate it immediately. [Deleting & Selecting FAT from cfdisk within Puppy doesn't seem to work?]. The most important (non)procedure then is to not reformat this partition, thus preventing the boot from the Puppy CD from writing to it, whilst still recognising it as a FAT partition (why is this important?). The Type 2 install procedure seems to work every time thereafter; no need to tangle with weird formats. Only reservation is that any Linux swap area needs to be created with cfdisk prior to manipulating the intended install partition, since MSDOS fdisk cannot do this (although PQMagic can). It should be possible to rewrite the install advice with a couple of words that include hiding the FAT partition by unformatting it.
Last edited by Sage on Sat 12 Nov 2005, 14:04, edited 1 time in total.
Easy HD install
What a curious response. It really is very easy. Did you try it? It makes the nearly impossible very straightforward.
Who changed the title?
Who changed the title?
-
Bruce B
The purpose of my post is to explain some of the obstacles could encounter in an Option 2, and techniques a person could use. And ramble on some.
Puppy's default creates a pupxxx user file on a filesystem it deems the best one to use. This might not be the filesystem you would have liked it to create the pupxxx file. There are many ways to control where the pupxxx file is created and how large it is. But the default is to let Puppy make this decision.
One problem people have when attempting to do an Option 2 install is that they want to install on the same partition that the 'mounted' pupxxx file is on.
The install routine will not install on a 'mounted' partition.
One work around is: at boot time don't let Puppy mount the pupxxx file at all. This way the partitions will be unmounted and likely available for an Option 2 install.
At install time, Puppy will give a you a list of available partitions to install to.
---------------
Changing subject a little. I think a lot of people conceptualize Linux as mounting drives and / or partitions, which it does do. I'd like to sell the idea of conceptualizing Linux as an operating system that mounts filesystems. For an example, the way the Puppy uses the pupxxx file is:
1) it mounts the filesystem where the pupxxx file is on
2) it mounts the pupxxx file as a filesystem
The result is: One partition mounted with two separate mounted filesystems.
----------------
More change of subject.
Marking a FAT filesystem as hidden doesn't hinder Linux' ability to mount and use the filesystem. Although, it could be that the Puppy install scripts deal with hidden FAT partitions in different ways, according to the scripting.
----------------
About DOS Fdisk programs:
The DR DOS fdisk only recognizes about 8 GB, it's a good FDISK otherwise. If you format a partition with DR DOS format, it will be a good format. If MS-DOS / Windows accesses that filesystem it will damage it.
The PC DOS (IBM) fdisk won't access large drives either.
FreeDOS fdisk, sys and format utilities had the same problem with MS-DOS behaving destructively against their work. The FreeDOS community was informed about the cause of puzzling behavior MS-DOS on their filesystem. They corrected the problems in July 2004.
DR DOS version 8.0 corrected the problem, the 7.03 version still leaves itself wide open to the MS-DOS bad behavior.
Simply stated the Microsoft Operating system thru virtually all DOS and Windows versions through ME do this: It reads a text field in the boot sector of each FAT partition and adjusts behavior according to the text string it finds. This eight text string is called the OEM ID field.
It is officially denied that Microsoft uses this field in its specifications and other places. Programmers naive enough to believe the official documentation fall into a trap sometimes of writing an OEM text string that triggers MS bad beahvior and don't know what is going on because they did everything right (or so they think).
As far as FDISK programs go, if you are working with big drives, MS Fdisk and FreeDOS Fdisk are viable options. Generally, I use the MS fdisk on big drives, (any drive for that matter).
It is however helpful to understand its personality as well as some Puppy limits.
Puppy's compilation will only recognize up to 9 partitions per hard drive. Considering that the extended partition is not mountable, this means with Puppy you can have up to 8 working partitions per hard disk.
Typically, people set up a primary, then extended, then logical partitions. Doing it that way, they might end up with something like this:
hda1 primary
hda4 extended (and unmountable)
hda5 logical
hda6 logical
hda7 logical
hda8 logical
hda9 logical
If your scheme does look like this you've reached the Puppy limit of 6 as there is no device driver for hda10 and you don't have an hda2 and hda3
In order that I can have 8 usable partitions I do it like this:
hda1 primary
hda2 primary
hda3 primary
hda4 extended (and unmountable)
hda5 logical
hda6 logical
hda7 logical
hda8 logical
hda9 logical
MS-DOS Fdisk will not create hda2 primary or hda3 primary. Linux cfdisk would create these partitions, but if you used MS-DOS Fdisk to make the extended partition AND you marked hda2 and hda3 as Linux partitions, MS-DOS Fdisk would write the partition inside the Linux partition and make things unusable. If you marked hda2 and hda3 as FAT with Cfdisk, then MS-DOS Fdisk will put the extended partition where it belongs. This is probably very unintentional on MS' part.
There are also other DOS based fdisk utilities that will make hda2 and hda3. Aefdisk will do it and I'm pretty sure the FreeDOS fdisk will do it.
One point I wish to make is that using DOS based fdisk utilities, I can create complex Linux partitioning schemes. In the example above, after I setup the partitions, I'd use the DOS aefdisk to mark each partition according to the filesystem I wish it to contain.
If for example I wanted hda9 to be a Linux swap filesytem, I'd mark it as type 82, then when I boot Linux I'd format it accordingly.
--------------------
As far as PQmagic is concerned. It is a very powerful tool. But if you use it, you may get stuck with it as your partitioning tool.
Suppose I wanted to delete logical partitions hda8 and hda9. If I do it with Linux fdisk or MS fdisk, I still have free space in the extended partition. I can then make other partitions in the extended partition.
If I delete hda8 and hda9 with PQmagic, it resizes the extended partition to contain hda5 thru hda7. You still have free space on the hard drive, but it is not in the extended partition. What to do? Use PQmagic to handle the free space, as other utilities might not be able to, or give you results you don't want.
I'm not trying to knock PQmagic, I think enough of it that I purchased three version over the course of years. But it does do what it does.
--------------------
In conclusion: I think the easiest why to prepare for an Option 2 install, is mark the partition you want to install it on as type 83, don't format it. Boot Puppy and it won't mount that partition because there is no filesystem on it to work with. It will therefore be available as a useable, properly marked, and unmounted partition for Puppy to install on.
Puppy's default creates a pupxxx user file on a filesystem it deems the best one to use. This might not be the filesystem you would have liked it to create the pupxxx file. There are many ways to control where the pupxxx file is created and how large it is. But the default is to let Puppy make this decision.
One problem people have when attempting to do an Option 2 install is that they want to install on the same partition that the 'mounted' pupxxx file is on.
The install routine will not install on a 'mounted' partition.
One work around is: at boot time don't let Puppy mount the pupxxx file at all. This way the partitions will be unmounted and likely available for an Option 2 install.
At install time, Puppy will give a you a list of available partitions to install to.
---------------
Changing subject a little. I think a lot of people conceptualize Linux as mounting drives and / or partitions, which it does do. I'd like to sell the idea of conceptualizing Linux as an operating system that mounts filesystems. For an example, the way the Puppy uses the pupxxx file is:
1) it mounts the filesystem where the pupxxx file is on
2) it mounts the pupxxx file as a filesystem
The result is: One partition mounted with two separate mounted filesystems.
----------------
More change of subject.
Marking a FAT filesystem as hidden doesn't hinder Linux' ability to mount and use the filesystem. Although, it could be that the Puppy install scripts deal with hidden FAT partitions in different ways, according to the scripting.
----------------
About DOS Fdisk programs:
The DR DOS fdisk only recognizes about 8 GB, it's a good FDISK otherwise. If you format a partition with DR DOS format, it will be a good format. If MS-DOS / Windows accesses that filesystem it will damage it.
The PC DOS (IBM) fdisk won't access large drives either.
FreeDOS fdisk, sys and format utilities had the same problem with MS-DOS behaving destructively against their work. The FreeDOS community was informed about the cause of puzzling behavior MS-DOS on their filesystem. They corrected the problems in July 2004.
DR DOS version 8.0 corrected the problem, the 7.03 version still leaves itself wide open to the MS-DOS bad behavior.
Simply stated the Microsoft Operating system thru virtually all DOS and Windows versions through ME do this: It reads a text field in the boot sector of each FAT partition and adjusts behavior according to the text string it finds. This eight text string is called the OEM ID field.
It is officially denied that Microsoft uses this field in its specifications and other places. Programmers naive enough to believe the official documentation fall into a trap sometimes of writing an OEM text string that triggers MS bad beahvior and don't know what is going on because they did everything right (or so they think).
As far as FDISK programs go, if you are working with big drives, MS Fdisk and FreeDOS Fdisk are viable options. Generally, I use the MS fdisk on big drives, (any drive for that matter).
It is however helpful to understand its personality as well as some Puppy limits.
Puppy's compilation will only recognize up to 9 partitions per hard drive. Considering that the extended partition is not mountable, this means with Puppy you can have up to 8 working partitions per hard disk.
Typically, people set up a primary, then extended, then logical partitions. Doing it that way, they might end up with something like this:
hda1 primary
hda4 extended (and unmountable)
hda5 logical
hda6 logical
hda7 logical
hda8 logical
hda9 logical
If your scheme does look like this you've reached the Puppy limit of 6 as there is no device driver for hda10 and you don't have an hda2 and hda3
In order that I can have 8 usable partitions I do it like this:
hda1 primary
hda2 primary
hda3 primary
hda4 extended (and unmountable)
hda5 logical
hda6 logical
hda7 logical
hda8 logical
hda9 logical
MS-DOS Fdisk will not create hda2 primary or hda3 primary. Linux cfdisk would create these partitions, but if you used MS-DOS Fdisk to make the extended partition AND you marked hda2 and hda3 as Linux partitions, MS-DOS Fdisk would write the partition inside the Linux partition and make things unusable. If you marked hda2 and hda3 as FAT with Cfdisk, then MS-DOS Fdisk will put the extended partition where it belongs. This is probably very unintentional on MS' part.
There are also other DOS based fdisk utilities that will make hda2 and hda3. Aefdisk will do it and I'm pretty sure the FreeDOS fdisk will do it.
One point I wish to make is that using DOS based fdisk utilities, I can create complex Linux partitioning schemes. In the example above, after I setup the partitions, I'd use the DOS aefdisk to mark each partition according to the filesystem I wish it to contain.
If for example I wanted hda9 to be a Linux swap filesytem, I'd mark it as type 82, then when I boot Linux I'd format it accordingly.
--------------------
As far as PQmagic is concerned. It is a very powerful tool. But if you use it, you may get stuck with it as your partitioning tool.
Suppose I wanted to delete logical partitions hda8 and hda9. If I do it with Linux fdisk or MS fdisk, I still have free space in the extended partition. I can then make other partitions in the extended partition.
If I delete hda8 and hda9 with PQmagic, it resizes the extended partition to contain hda5 thru hda7. You still have free space on the hard drive, but it is not in the extended partition. What to do? Use PQmagic to handle the free space, as other utilities might not be able to, or give you results you don't want.
I'm not trying to knock PQmagic, I think enough of it that I purchased three version over the course of years. But it does do what it does.
--------------------
In conclusion: I think the easiest why to prepare for an Option 2 install, is mark the partition you want to install it on as type 83, don't format it. Boot Puppy and it won't mount that partition because there is no filesystem on it to work with. It will therefore be available as a useable, properly marked, and unmounted partition for Puppy to install on.
Re: Easy HD install
No, I've never installed Puppy on a hard drive. I only run Puppy from the (multisession) DVD. As I understand it, Barry originally developed Puppy only to run from the CD, which philosophy naturally included DVD. It seems to me that must be why so many people have trouble installing Puppy on their hard drive.Sage wrote:...Did you try it? It makes the nearly impossible very straightforward.
That was me.Who changed the title?
It had nothing to do with my response to your post. I often edit a short subject line, after reading the post, so that someone searching the forum doesn't have to download the post just to see what it's about. If you don't like that, I'll leave your subject lines alone. For what it's worth, I never mess with the contents of a post except to correct obvious spelling and punctuation mistakes, and then usually only if they are so bad the post is difficult to read.
Thanks for that most informative discourse, Bruce. Now I understand why my simple routine works every time! As for partitioning tools, I've been in the habit using a range of options - whatever worked.
As for M$, this a company I've come to hate - they turn up to all the big, decision-making committees as full members, agree international standards, then go away and break them for the advantage of leverage, spelled $$$$. It took the USDoJ to convict them, albeit with somewhat limited end result. Digital Research is still D-E-A-D! If only the Linux gurus could simplify their masterpiece and make it usable for the proletariat, the world would be a better place. I see Puppy and one or two others as major steps in this direction. Sometimes, the Aussies have a clarity of vision, committment and generosity that the RoW lacks - we admire them tremendously back in Blighty.
I'd known about the size limitations of early DRDOS, but my main preoccupation (outlined in other threads) is with pressing old hardware back into service, rather than killing Chinese recyclers or poisoning the planet with landfill. Puppy is a perfect vehicle for this; one partition plus a small swap is adequate. The swap is needed to permit lower memory resources usually found in older HW using 68pin strips (haven't had a lot of success with 30pin machines, yet!). Typical HDs that I use are in the 300Mb - 1.5Gb region. They can be found languishing in roadside skips and municipal waste sites in perfect working order - no bad sectors! These were some of the best ever made, often carrying five year warranties, and often not used for more than a year or so with the inexorable spiral that has been the IT world. The early technical problems of IDE devices had been solved and the new ones afflicting >=20Gb had yet to arise. An ~1Gb gives plenty of room for many of the apps on offer together with generated text files.
Thanks for taking the time, Bruce - most appreciated.
As for M$, this a company I've come to hate - they turn up to all the big, decision-making committees as full members, agree international standards, then go away and break them for the advantage of leverage, spelled $$$$. It took the USDoJ to convict them, albeit with somewhat limited end result. Digital Research is still D-E-A-D! If only the Linux gurus could simplify their masterpiece and make it usable for the proletariat, the world would be a better place. I see Puppy and one or two others as major steps in this direction. Sometimes, the Aussies have a clarity of vision, committment and generosity that the RoW lacks - we admire them tremendously back in Blighty.
I'd known about the size limitations of early DRDOS, but my main preoccupation (outlined in other threads) is with pressing old hardware back into service, rather than killing Chinese recyclers or poisoning the planet with landfill. Puppy is a perfect vehicle for this; one partition plus a small swap is adequate. The swap is needed to permit lower memory resources usually found in older HW using 68pin strips (haven't had a lot of success with 30pin machines, yet!). Typical HDs that I use are in the 300Mb - 1.5Gb region. They can be found languishing in roadside skips and municipal waste sites in perfect working order - no bad sectors! These were some of the best ever made, often carrying five year warranties, and often not used for more than a year or so with the inexorable spiral that has been the IT world. The early technical problems of IDE devices had been solved and the new ones afflicting >=20Gb had yet to arise. An ~1Gb gives plenty of room for many of the apps on offer together with generated text files.
Thanks for taking the time, Bruce - most appreciated.
Last edited by Sage on Sun 13 Nov 2005, 08:48, edited 1 time in total.
-
Guest
I have always installed Puppy to hard drive. It does start faster and seems to me to run faster. I have never had a problem on installation until 1.0.6 .
Everytime I try 1.0.6, it bombs out on installing Grub, it never did on earlier verisons.
Has anyone installed 1.0.6 with Grub? Any problems like I had?
I guess I will download it again and burn another copy, maybe that will fix it.
Everytime I try 1.0.6, it bombs out on installing Grub, it never did on earlier verisons.
Has anyone installed 1.0.6 with Grub? Any problems like I had?
I guess I will download it again and burn another copy, maybe that will fix it.
No problem with GRUB loader in 1.0.6, ES. You could use a previous version live CD to install it - that would establish whether your d/l or burn is corrupt.
Whilst RAM works in the ns range and HDs access in the ms regime, like ES, subjectively, Puppy can often appear to run faster when installed. Not sure what the overheads are in decompression, etc. but Bruce is about to enlighten us..............
Whilst RAM works in the ns range and HDs access in the ms regime, like ES, subjectively, Puppy can often appear to run faster when installed. Not sure what the overheads are in decompression, etc. but Bruce is about to enlighten us..............
-
Bruce B
The topic of this post is "saving and reusing the MBR". I should probably start a new thread, but this is in response to Earl and his problem with GRUB on version 1.06
Under many circumstances, I will make a copy of the MBR prior to installing an operating system. At the end of the post I'll explain how I copy and restore the MBR after an install.
It is not uncommon for me to have a few operating systems on the same computer. It is very common for me to try out various distros, when time permits.
Suppose I'm going to install distro abc-linux, I don't know in advance what options it will give me as far as a boot manager. There is a chance the install will mess up. There is a good chance it will install lilo.
Generally, I'll let it install lilo or grub, even though I don't want to use the particular boot loader. The reason why I let it install the boot loader is; I want to read the configuration file it uses to boot. If it's lilo, I'll convert it to my grub menu.lst and boot that distro from where I was previously booting.
After I boot the new abc-linux and play with it some, I'll fix up my old menu.lst and put the old MBR back.
-----------
If a person is doing nothing more than upgrading Puppy on the same partition the previous Puppy was installed, you can go ahead and run the install grub program. It doesn't have any problem installing the menu.lst and stages, the problems usually have to do with the MBR getting written properly. If you have a backup MBR you restore it and all is well.
Also, Puppy should put the original MBR in /boot/grub as a backup, along with instructions how to put it back from within Linux.
So, if the grub install didn't go right - maybe reverting to the previous MBR will fix things up.
-------------
The way I save and restore the MBR is with a DOS utility called AEFDISK, get it from wwww.aefdisk.com
I save the MBR to another drive or floppy and on the same drive. It is pretty simple to save and restore.
Caution: The MBR has a life span - not in time - in terms of changes you make to the disk. If you change partitioning structures or types, the backup MBR may be more of a liability than an asset. If you don't change your disk around, the MBR will be good until you do.
Under many circumstances, I will make a copy of the MBR prior to installing an operating system. At the end of the post I'll explain how I copy and restore the MBR after an install.
It is not uncommon for me to have a few operating systems on the same computer. It is very common for me to try out various distros, when time permits.
Suppose I'm going to install distro abc-linux, I don't know in advance what options it will give me as far as a boot manager. There is a chance the install will mess up. There is a good chance it will install lilo.
Generally, I'll let it install lilo or grub, even though I don't want to use the particular boot loader. The reason why I let it install the boot loader is; I want to read the configuration file it uses to boot. If it's lilo, I'll convert it to my grub menu.lst and boot that distro from where I was previously booting.
After I boot the new abc-linux and play with it some, I'll fix up my old menu.lst and put the old MBR back.
-----------
If a person is doing nothing more than upgrading Puppy on the same partition the previous Puppy was installed, you can go ahead and run the install grub program. It doesn't have any problem installing the menu.lst and stages, the problems usually have to do with the MBR getting written properly. If you have a backup MBR you restore it and all is well.
Also, Puppy should put the original MBR in /boot/grub as a backup, along with instructions how to put it back from within Linux.
So, if the grub install didn't go right - maybe reverting to the previous MBR will fix things up.
-------------
The way I save and restore the MBR is with a DOS utility called AEFDISK, get it from wwww.aefdisk.com
I save the MBR to another drive or floppy and on the same drive. It is pretty simple to save and restore.
- aefdisk /save
\mymbr.bin
aefdisk /restore\mymbr.bin
\mymbr.binCaution: The MBR has a life span - not in time - in terms of changes you make to the disk. If you change partitioning structures or types, the backup MBR may be more of a liability than an asset. If you don't change your disk around, the MBR will be good until you do.
-
Bruce B
You're funny. Anyway, this is what I think about speed variations.Sage wrote:No problem with GRUB loader in 1.0.6, ES. You could use a previous version live CD to install it - that would establish whether your d/l or burn is corrupt.
Whilst RAM works in the ns range and HDs access in the ms regime, like ES, subjectively, Puppy can often appear to run faster when installed. Not sure what the overheads are in decompression, etc. but Bruce is about to enlighten us..............
OPTION 1 HARD INSTALL VS. BOOTING FROM CD DISC
The Option 1 install will boot a lot faster than the CD disc. The reason why is, the computer can read the hard disk faster than a CD disc. There are about 60 MB worth of data that has to be located and read.
Once the computer has been booted the actual operation theoretically should be identical. The three key files necessary to boot Puppy only get read one time, and they are not used or needed again.
An exception would be on a low memory system. The file usr_cram.fs normally gets copied to RAM then mounted as a file system. If Puppy calculates that the computer doesn't have enough RAM to copy usr_cram.fs into RAM, it will mount it and read it as needed from where it is.
OPTION 2 INSTALL VS. OPTION 1 HD INSTALL
Puppy will boot markedly faster with Option 2 than with Option 1. The principle reasons are that it doesn't need to copy usr_cram.fs to RAM, and it doesn't need to setup and configure a file system, as the file system is already in place and ready to go.
Read operations will be slower from hard disk than RAM, simply because the hard disk is slower. On the other hand the files read don't go through the same decompression process. In actual practice the computer should be able to locate and read a small file off the hard disk so fast you wouldn't notice the read time.
If you were to launch a large program like Mozilla, it should take 'noticably' longer time to read it from the hard disc as it would from RAM.
Once Mozilla's working components are loaded in memory, they should run about the same speed.
Except for the very fast boot, an Option 2 is slower in some areas of operation than an Option 1.
There is an exception to this rule and that is with low memory systems. An Option 1 uses up considerably more RAM space than an Option 2, because all the filesystem is in RAM and taking up space, except for /root and whatever you have mounted yourself.
If your computer doesn't have sufficient RAM and is actively using a swap filesystem for its normal operations on an Option 1, it is very likely that it would run faster with an Option 2 because there is more RAM to work with before it needs to swap.
SUMMARY: Puppy is respectably fast regardless of how you install it.
I knew we could rely on you, Bruce, for the full SP!
Thanks again. Ever thought of writing a compilation of your wisdom for folk who are PC literate (users) but non-IT professionals? These constitute the largest putative Linux converts (the gurus can take care of themselves.)
Humour & perversity is the main export from the motherland these days.
Thanks again. Ever thought of writing a compilation of your wisdom for folk who are PC literate (users) but non-IT professionals? These constitute the largest putative Linux converts (the gurus can take care of themselves.)
Humour & perversity is the main export from the motherland these days.
-
Chuck the Plant
- Posts: 17
- Joined: Fri 04 Nov 2005, 05:08
- Location: USA
An Inefficeint Technique That Worked for Me
I first installed Puppy on a 2GB HDD. I formatted hda1 as ext2 and left it blank. To avoid the catch 22 discussed earlier, I then created a small (300MB) partition for Pup001, as well as a small swap, for a total of 3 partitions. I loaded pup001 into the small partition using boot option 3, then ran the install targeting hda1. This was grotesquely inefficient, as I wasted a lot of HD space, but the full HD install to hda1 worked like a charm every time I used this method.
Thinking about this, the pup001 partition could be made significantly smaller...
My partitioner of choice is the version of QT parted included in the System Rescue CD. QT parted is a gui-based graphical partitioner with lots of options that a newbie like me felt comfortable with. I found it very helpful. The System Resucue CD is a free bootable implementation of Gentoo Linux with a lot of handy formatting and recovery tools, including a useful suite of drive-wipers that tackle everything, including the MBR, when hopeless corruption occurs. Its available without cost at
http://www.sysresccd.org/
If you want to use QT parted, be sure to type fb640 at boot, then run_qtparted at the shell prompt. On old PCs, ide=nodma at boot, (with a space between this and fb640) is also a good idea.
Thinking about this, the pup001 partition could be made significantly smaller...
My partitioner of choice is the version of QT parted included in the System Rescue CD. QT parted is a gui-based graphical partitioner with lots of options that a newbie like me felt comfortable with. I found it very helpful. The System Resucue CD is a free bootable implementation of Gentoo Linux with a lot of handy formatting and recovery tools, including a useful suite of drive-wipers that tackle everything, including the MBR, when hopeless corruption occurs. Its available without cost at
http://www.sysresccd.org/
If you want to use QT parted, be sure to type fb640 at boot, then run_qtparted at the shell prompt. On old PCs, ide=nodma at boot, (with a space between this and fb640) is also a good idea.
Puppy to Hard Drive
Before I start: I use removable hard drives in an expansion bay, with the drives in caddies.
This way I can do clean install's
When I install Puppy to a Hard Drive I use Bart's Boot and Nuke on the drive first.
When I boot with puppy on the CD it can't write to a disk with no partitions or anything else
on it. This makes the install easier. (this bypasses the problem with the pup001 file being
written to a mounted hda)
I then use CFDISK (included with puppy) and create what partitions
I need (hda1, swap,etc...)
Then I use puppy's formatting tools to create the file system I want to use.
note: (these are command line tools)
Then it is easy to use puppy's installer for the hard disk install.
I install GRUB right on the MBR of the HD.
I'm writing this to you on a machine installed this way.
puppy-1.0.6-mozilla
I hope this helps!
This way I can do clean install's
When I install Puppy to a Hard Drive I use Bart's Boot and Nuke on the drive first.
When I boot with puppy on the CD it can't write to a disk with no partitions or anything else
on it. This makes the install easier. (this bypasses the problem with the pup001 file being
written to a mounted hda)
I then use CFDISK (included with puppy) and create what partitions
I need (hda1, swap,etc...)
Then I use puppy's formatting tools to create the file system I want to use.
note: (these are command line tools)
Then it is easy to use puppy's installer for the hard disk install.
I install GRUB right on the MBR of the HD.
I'm writing this to you on a machine installed this way.
puppy-1.0.6-mozilla
I hope this helps!
-
Bruce B
I'm not the guy you asked the question of. But, since it wasn't answered, I'll tell you what little I know.
Cfdisk and DBAN have an interface and use intuitive keyboard navigation.
As for formatting, I'd suggest typing at the prompt:
# mk
then hit the tab key to see what tools come up.
for help type in the toolname --help
it's usually as simple as:
# toolname /dev/hda3
to format a partition
Cfdisk and DBAN have an interface and use intuitive keyboard navigation.
As for formatting, I'd suggest typing at the prompt:
# mk
then hit the tab key to see what tools come up.
for help type in the toolname --help
it's usually as simple as:
# toolname /dev/hda3
to format a partition
Hard Drive install
Thanks again, Bruce & Ian
I'm sorry I couldn't answer any sooner than this.
My car was broke and I had to fix it,
Then my dad needed to go to the doctor.
With enough people and all the accumulated knowledge we should
be able to accomplish just about anything.
Sometimes just a small addition to a helpful post is all that is
needed to clarify what is being said.
Thanks
I'm sorry I couldn't answer any sooner than this.
My car was broke and I had to fix it,
Then my dad needed to go to the doctor.
With enough people and all the accumulated knowledge we should
be able to accomplish just about anything.
Sometimes just a small addition to a helpful post is all that is
needed to clarify what is being said.
Thanks