Hard Disk Defragmentation from Linux?

[Benny]

I'm almost sure that I've read a thread somewhere (probably Sylvander started or participated in it) where it was stated that you can achieve the same end in a hdd from linux as with the Defragmenter found in Windows.

Don't remember what was the process or the machine capabilities required for it. Does someone knows how to achieve that end? I'm running PL 511 from a live cd...

Thanks in advanced!

[Sylvander]

1. See:
Defragged & restored C: in 12 min using SyncBack in BoxPup (http://www.pcguide.com/vb/showthread.php?t=67809).

2. It's not essential to use SyncBack to do the job; I'd now use Xfe.

3. The principle of the method is:
Use Xfe to....
(a) Copy the contents of the partition to somewhere handy [a USB2 connected external HDD?]
Of course...
Must be big enough to hold the contents.

(b) Delete the folder/file contents of the partition.
Before you do this, it's wise to make an image backup of the partition, so you have a 2nd method to restore if the primary method by Xfe goes wrong somehow.

(c) Copy the folder/file contents back to the partition.

4. I found this method to be REALLY FAST, and produce PERFECTLY DEFRAGMENTED CONTENTS...
[with the exception of a small working region at the beginning of the partition].

[Benny]

Do you have any idea if the ROX file manager for PL 511 could be used for these ends? Have read in Wikipedia about Syncback & Xfe & it appears to me that if you move a set of files from a directory/drive to another drive, delete the originals & copy back to the original location(s) the files, they will end up in straight line (the directory/drive won't be fragmented i the hdd anymore). My only limitation here is that I do have a hdd with XP in it, but cannot run it because it pertains to another motherboard, so running the defragmenter program won't do.
Do you know of a way to extract these kind of info from a hdd from linux, just to compare if this approach of mine with Rox would do?
Thanks!

[Sylvander]

1. "Do you have any idea if the ROX file manager for PL 511 could be used for these ends?"
(a) I expect so; it's just that I've always used Xfe, which seems to me to do a particularly good job.
Not sure of the rules that govern such actions when using ROX.

2. "if you move a set of files from a directory/drive to another drive, delete the originals & copy back to the original location(s) the files, they will end up in straight line (the directory/drive won't be fragmented i the hdd anymore)"
That's what I believe to be true. :)

3. "Do you know of a way to extract these kind of info from a hdd from linux, just to compare if this approach of mine with Rox would do?"
(a) If you make an image backup of the partition contents before messing with the files, you should be able to restore the contents if anything should go wrong.
Then...

(b) Provided you know how to use ROX...
You can use ROX to copy the partition contents to somewhere handy...
Delete the original contents...
Copy the contents back to the partition.

(c) If [for some reason] the above doesn't work...
Restore the partition contents by restoring your image backup.

4. My Win2000Pro partition_file_system is FAT32...
And I normally use Xfe to do the work, and it has never failed.
However....

(a) Once when working on a neighbours' PC...
He had XP on an NTFS partition...
Something went wrong with a copy/restore operation using Puppy->Xfe [I think].
So I restored the image I'd made.
Yet still his XP wouldn't boot.
I had to use a Puppy program to restore [the NTFS automatically made backup] copy of a previous partition file table.
That restored its ability to boot.
Perhaps there had been some inability to handle long filenames or whatever.

[jlreich]

With NTFS, ext3 and particularly ext4 (actually calculates space needed and available before writing to avoid fragmentation), fragmentation is not really an issue. Back in the days of FAT/FAT32 and small hard drives fragmentation was an issue, but not really now days.

Not that it normally hurts. Though it can during a data recovery process cause issues per Paul Komski.

I do run Defraggler on a schedule to defrag my NTFS partitions in windows on my main system. But there is really no need. I rarely even think about it.

[Paul Komski]

My only limitation here is that I do have a hdd with XP in it, but cannot run it because it pertains to another motherboard, so running the defragmenter program won't do.
Could you give an indication of why you feel the need to defragment a partition that you are not even running Windows from and what percentage of the partition is occupied by files?

[Sylvander]

1. "With NTFS, ext3 and particularly ext4...fragmentation is not really an issue...there is really no need. I rarely even think about it"
Yes...
I have no NTFS partitions...
And never defrag ext3 partitions...
And these days I practically never defrag my Win2000Pro->FAT32 partition, because I use it so seldom.

[Paul Komski]

I have no NTFS partitions
The OP apparently does though - since it would appear to be a WinXP partition.

Can I just say that there is much misconception about the need to defragment Windows NTFS partitions. I only ever defragment them if there is system slowness or if one particular program has become very slow to start up and only after running chkdsk /f but also when a disk is running out of free space; and to be honest it seldom seems to correct such effects.

One thing to note is that there comes a point when free space gets low enough that it affects both system speed and increases actual fragmentation per se; this effect means that the rate of fragmentation accelerates and the real answer is to free up space, in such a situation, rather than to repeatedly defragment the partition.

Like it or not Windows is pretty intelligent when it comes to organising its file system. It doesn't just "line the files up in a straight line" but, if it can, it organises files that need to start-up quickly near the start of the partition in as contiguous a fashion as possible.

The NTFS file system may not be absolutely the best in the world but it does efficiently distribute (even defragmented) data and recollect it very efficiently and that is why when what looks like a horrible mess of fragments to us humans you will usually find that Windows itself does not recommend ("there is no need to defragment this volume") defragmenting such partitions.

[Benny]

Sylvander, I think that the 1st thing to have is a way to check for the fragmentation in order to compare the result of the copy process.
The ntfs thing that you say gives me a bad feeling...

jlreich & Paul Komski, as per the instructions found here & elsewhere for frugal Puppies installations (and other activities --Puppy related), the advise is to defragment the partition first.
I don't know the reasons for puppy related task they recommend to defreg 1st, but I suspect that it might have something to do with the necessity for enough free disk space when performing such tasks. As reported by dos, the free disk space (partition) is different before & after running defrag. More blocks/sectors of disk would appear as empty after defrag, even to a linux system. Just, my only guess about the reasons...

[Sylvander]

1. "the 1st thing to have is a way to check for the fragmentation in order to compare the result of the copy process"
(a) Hmmm...
Offhand, I don't know of a way to display the level of fragmentation...
Of the contents of a partition...
Using an OS that isn't installed on the partition.
Need to think about that one. :confused:

(b) What I can say for sure is...
That the state of defragmentation produced by this method...
Is the best I've ever seen.
Never seen any other method produce anything like as good.
All the contents [after the defrag] are totally contiguous.
So does it really matter how good or bad the situation was prior to the defrag?

2. "The ntfs thing that you say gives me a bad feeling..."
Well...
There may be some risk involved [can't really be sure if it was something peculiar to what I was doing]...
Isn't there always some risk when you try something new?
But with the insurance provided by an image backup [of the whole drive?]...
You aught to be able to recover if something does go wrong.

3. "I don't know the reasons for puppy related task they recommend to defreg 1st"
I think that is recommended when you intend to use a pupsave file.
It isn't a good idea to have a pupsave file [with its internal Linux filesystem] scattered in fragments all over the partition.
Would have a very negative effect on the efficient functioning of the Puppy OS.

[Paul Komski]

as per the instructions found here & elsewhere for frugal Puppies installations (and other activities --Puppy related), the advise is to defragment the partition first.
I don't know the reasons for puppy related task they recommend to defreg 1st, but I suspect that it might have something to do with the necessity for enough free disk space when performing such tasks. As reported by dos, the free disk space (partition) is different before & after running defrag.
The instructions from http://www.puppylinux.com/hard-puppy.htm make no mention of defragmenting before a frugal installation of Linux.

DOS is not the best way to estimate free disk space since it does not, by default, include hidden or system files in the totals and certainly defragmentaion DOES NOT liberate new free disk space however it is done.

In the first place, if there is adequate free space the newly copied puppy files are most unlikely to be fragmented. In the second place, even if they are fragmented this will not affect performance once Puppy is running since Puppy will have copied the necessary data from the files on the hard drive into RAM in which state it is when you start to use the operating system and does not therefore need the hard drive at all to function until the point when any data is desired to be saved there.

As so often the whole defragmentation issue is almost certainly a red herring in this particular arena and it is the human anal obsession to see that everything is lined up that detracts from what actually matters at all.

Sylvander restates "That the state of defragmentation produced by this method... Is the best I've ever seen" without seeming to comprehend what I stated before that Windows will organise files in an appropriate manner whilst a copying method that places the files "in a straight line" is not necessarily the best way to have them organised.

Have it your own way of course - but you are, in my opinion, just making what should be quite simple more complicated.

It isn't a good idea to have a pupsave file [with its internal Linux filesystem] scattered in fragments all over the partition.
Would have a very negative effect on the efficient functioning of the Puppy OS.
So what if it is fragmented - it is only loaded during the Puppy start-up and even if there is dynamic saving of changes to it during operation this should not detract from Puppy's performance.

[Sylvander]

1. "So what if it is fragmented - it is only loaded during the Puppy start-up and even if there is dynamic saving of changes to it during operation this should not detract from Puppy's performance"
I'm no expert, but for what its worth, here are my thoughts on the subject:
(a) A Puppy doesn't load ALL of the contents of the pupsave file into RAM; it only loads so much as is needed, when it is needed.
So if you choose to load some program say, perhaps a number of windows of Firefox saved from the previous session...
Those will be read from the pupsave.

(b) Now, if the pupsave is scattered widely over a very fragmented host partition, it will take more time and effort to find all the parts, and Firefox will take longer to load.
See this thread titled "Puppy defrag app?" (http://www.murga-linux.com/puppy/viewtopic.php?t=66496&sid=2ba48fce7cde9deb1dcb9418f152d166), particularly this post (http://www.murga-linux.com/puppy/viewtopic.php?p=510003#510003) where Bruce B says:

"We have a 160GB partition which is badly fragmented. The filesystem
works on a what's available next write scenario. The filesystem is like
80% used.

There is a little free space at the beginning of the partition. Some down
the path, more down the path, so on and so forth.

Our 1GB pupsave file gets written in such a way that it spans 75GB.

Now when inside Puppy the operating system and hard disk have to do
more work. Even if Puppy fragmentation was great.

The read and write heads have to span 75GB back and forth to do their
work.

We want them to only have to span the size of 1GB. To accomplish this
we make the pupsave file contiguous."

(c) Now to consider a copy or save, back to the pupsave file:
This depends on the type of device on which the pupsave is held.
c1. Pupsave on an internal HDD:
This NORMALLY auto-copies back to the pupsave, each change as it is made.
So the copy-back is done in the background unseen, but even so, I wouldn't want to make this inefficient/slow.
However, I have my setup arranged so my pupsave on the internal HDD is treated as though a pupsave on a Flash Drive. [See c2 below]

c2. Pupsave on a Flash Drive:
[I have my internal HDD treated/behave as though it's a Flash Drive]
By default, the Puppy auto-copies the session back to the pupsave [not at the moment a change takes place, but instead] every 30 minutes...
But this can be easily re-configured to any time interval, including zero = NEVER, which is how I have mine set.
The copy-back during a session can be done manually at any time .
It then takes a certain period of time to complete, during which time %CPU usage is high.
[I can see this (time taken and high %CPU usage) displayed by Pwidgets on the desktop]
[B]Anything that makes this operation take longer is not good.
A fragmented pupsave would make it take longer methinks.
----
Same applies if/when I choose to save during shut-down/reboot.
It would increase the delay while I wait for shut-down to complete, so I can power-off.

[jlreich]

I understand and have always thought that the issue with fragmentation is causing the read/write head to have to move back and forth instead of reading the file/s in a linear fashion. Less head movement equals better performance.

But I also understand that with a modern drives logic, caching, and file systems ability to smartly arrange files in a fashion, as Paul points out, in a logical manner that doesn't look logical to us from a visual aspect, that even if there is a performance loss it is negligible. I mean milliseconds to maybe a whole whopping second. :p Is anyone really going to notice if puppy shuts down 20ms slower? Or FF starts one second slower?

Yes yes, there are some that want every last ounce of performance from their system that will care for bragging rights.

From what I get from what Paul has stated you could actually be hurting performance by "defragging" the system as you do with your windows partition from within Linux. Though once again I am sure it is negligible.

[Paul Komski]

Reading some of the spiel about how 1GB can be scattered and broken-up all over a "tiny" 70 GB partition makes one wonder if the designers are simply trying to make things work as badly as possible; it's almost as if fragmentation would be the norm.

On good functioning modern systems with adequate RAM and adequate free disk space file fragmentation will always be minimal and performance will normally be fantastic.

One perhps tends to forget that modern CPUs can do three thousand million mathematical or logical operations in a second. That it takes milliseconds to request and download a webpage from the other side of the planet via multiple computers. That chipset architectures and software design have improved out of all recognition. Operating systems and file systems continue to get cleverer and cleverer. The same is true of hard drive architecture and performance and so on ad nauseum.

I think that having some knowledge about how hardware and software work can not only on occasions be counter intuitive but also actually counter productive. It's like the medical technician who believes he understands what even a consultant practitioner or professor hasn't yet fully grasped.

I will only add two other points. If it works leave it alone and always try to KISS.

[Sylvander]

1. "it's almost as if fragmentation would be the norm"
(a) I was educated and trained in Mechanical Engineering.
As a result I've gained the idea/belief that...
Whenever events take place...
CHAOS naturally increases.
This is in effect a law of nature.
The only way to slow or reverse that natural process...
Is by the INPUT OF WORK.

(b) This natural law in action with regards to the contents of a partition that holds an operating system...
Means that unless work is constantly being expended as changes of partition contents take place...
Then as sure as hot things tend to cool...
And rivers run downhill...
And living things tend to die...
In a similar way, partition contents tend to become increasingly fragmented.

(c) But then, I don't know whether operating systems are constantly expending work to counteract this natural effect.
Can you tell me if this is so?
Any details?

[Paul Komski]

I certainly don't believe it is the norm to fragment files "willy nilly" but the quote in question seems to indicate that files get scattered all over the place. That is generally not the case until a disk begins to get very full. And yes of course there can be other reasons as well for a file to become fragmented but in general unless the files are very large and the free space very small it is unusual to have files occupying more than two or three fragments.

If you want to examine how such files are distributed then use a forensic disk editor such as WinHex. It can delineate exactly where every allocation unit of a file has been stored. For small files under NTFS this is usually within the MFT, which is in itself a file that can be fragmented (not very good when it happens) and one that is most unlikely to be included in any Linux file copying process because it is quite simply metadata.

In a similar way, partition contents tend to become increasingly fragmented.I think the metaphor is a bad one and does not represent what actually goes on.

Let me point out some simple facts. Some files have fixed sizes but others (databases and text documents and email folders etc) change their size over time. To put such a file inside a contiguous unit is somewhat inappropriate. Such a file should be placed where it can expand without the need to necessarily jump to another part of the hard drive. Having all files lined up and thus congiguous does, in such cases, make bad sense.

I don't care if someone is a mechanical engineer or a mathematician or a network administrator or a farmer or whatever - what impresses me, in life, is those who can explain what they advocate and believe in rather than resort to "I know because I have this or that qualification or belief or experience.

But do let me say everyone defragment away to your heart's content. Line up your files in military precision. That is your prerogative of course.

[Sylvander]

See Entropy (arrow of time) (http://en.wikipedia.org/wiki/Entropy_%28arrow_of_time%29)....

And how this would explain that the Entropy of stored information in a "closed" system can only increase [e.g. disorder/chaos (of which fragmentation is one kind) would increase] as changes take place...

That is: as time moves forward fragmentation MUST increase.

The only way to prevent this is by the input of WORK to the "system".
i.e By expending energy.
At the expense of the surroundings of the system.

THIS IS NOT A METAPHOR.
Nor are the other examples quoted.
It is a physical FACT [or law] of the the natural world.

All things which take place in the real world conform to natural laws.

[Paul Komski]

Operating systems do no work; hence the metaphor.

The thermodynamic entropy of a PC is a reflection of the amount of wasted heat - and PCs waste a lot of heat since they do little physical work (and in the main this is done by a few electric motors).

I believe it to be the case that operating systems are not by nature chaotic/random and actually attempt to make order out of chaos. So I don't see how even using entropy from a statistical standpoint makes much sense in this arena since both fragmentation and defragmentation are controlled and not random events.

[Sylvander]

1. "Thermodynamic Entropy" is only one example; there are others.

See Entropy (information theory) (https://secure.wikimedia.org/wikipedia/en/wiki/Entropy_%28information_theory%29)

Where it says for example:
"Entropy is a measure of disorder..."

2. "systems are not by nature chaotic/random and actually attempt to make order out of chaos"
Order can only be increased [chaos decreased] by WORK being done = energy expended.
This is a fact of nature.
You will NEVER see a computer that has no supply of power.
[Not one that actually does anything, anyway. :) ]

[Paul Komski]

I have already made the point about thermodynamics (basically the second law thereof) and that it doesn't apply to the operating system at all but to the computer hardware.

I also understand about information theory and unless you can show that either fragmentation or defragmentation are random events resulting in disorder then no chaos ensues and no extra work is done.

Of course computers use power (but do very little actual work - in the sense of pure physics and as any decent O-level physics student should know).

And I'm really not sure exactly what point is trying to be made other than it seems confused to me.

[Sylvander]

1. "unless you can show that...fragmentation...are random events resulting in disorder then no chaos ensues and no extra work is done"
(a) When changes take place...
To a [fairly orderly?] system of stored information...
What's to prevent those changes from being chaotic?
Or put another way...
How would we make sure the changes are orderly?

Why, by seeing to it that the necessary WORK is done.

Otherwise who can say what the form/nature of the changes will be?

Natural law predicts that changes WILL increase chaos, if the system is "closed".

If no work is done to avoid the increase of chaos [to keep the system orderly]...
Then surely the information will be written to the drive in a random manner, resulting in increased chaos/disorder.

[Benny]

I know is a shame, especially having done this a couple of times already but, I'm in the middle of a frugal install & had to stop because I don't know if I've Grub installed or not. I don't see the menu.lst file anywhere in any partition...
What's next? Visited the PETs' site & didn't see anything concerning grub.
I do have an api within pl511 in <Menu | System >> Grub Bootloader config>, I ran it believing it was about to create/find & edit that menu.lst file but that didn't happened.
Need extra help here...
Thanks in advanced!

[Paul Komski]

if the system is "closed"
Well that's a very very big if indeed.

A computer or a human body or a building project; none of them are closed systems. Possibly the only "closed" system is the Universe itself and that is a matter of conjecture.

That is why an acorn or a conceptus can create order out of chaos by creating an oak tree or human being from a wide variety of random parts. Why a skyscraper can be created out of all sorts of bits and pieces and why a computer can also create order out of chaos. None of them are closed systems and all require inputs of energy and usuallyto the effect of decreasing and not increasing the entropy of the part in question.

[Benny]

I searched the web with various search engines for "lin'n'winnewbieproject" & didn't find a single link to the page as if it was retired/expired/deleted. I've used that approach along with xp for dual booting 2 times already (many years ago). Does anybody around knows what happened to the link?
Thanks! --Tried to edit my last post but time limits from here prohibited it...

[Sylvander]

@Benny
Re: post #22
1. "I don't see the menu.lst file anywhere in any partition..."
(a) I'm not very knowlegeable regarding GRUB, which is why I don't like frugal installs, so don't do them.
But...
(b) Since you are working with a frugal install...
The menu.lst file will NOT be held directly in any partition.
I believe it should/will be held in the Puppy file system [WHICH PUPPY?] inside the pupsave file.
There is probably a way to access the contents of the pupsave file from another Puppy [use a different puppy version (not Lupu), so it doesn't attempt to use the lupusave file]...
I tried the filemnt command on a couple of my pupsave files, but they failed to mount. [I've succeeded in mounting ISO files with this command]
I don't know how else to do it.
Yet again you need a Puppy/Linux expert.

2. "I do have an api within pl511 in <Menu | System >> Grub Bootloader config>, I ran it believing it was about to create/find & edit that menu.lst file but that didn't happened"
(a) That won't work.
You could only use this to edit a menu.lst file held within the Lupu-511 lupusave file system [used by this Lupu-511].

3. "I searched the web with various search engines for "lin'n'winnewbieproject" & didn't find a single link to the page"
THE Lin'N'WinNewB PROJECT CONTENTS LIST (http://www.icpug.org.uk/national/linnwin/contents.htm).

@Paul Komski
4.
(a) I pretty much agree with everything you say in post #23. :)
e.g. I agree that in reality, in the example of the PC, it is not a closed system.
I guess work probably is done on the files [by the OS] when they are being stored.
But I don't know for sure that is so, or the nature of the work done.
My guess would be that there may indeed be work done to maintain an orderly file system...
perhaps even so far as to prevent the increase of chaos...
But I don't know that to be so.
So who knows?

(b) It would be great if OS's automatically did the necessary to prevent the increase of chaos; maintain an orderly file system.
Do they do that?
If they do...
And part of that is that they do the necessary work to prevent increasing fragmentation...
Then indeed, defragmenting by other means would be redundant.

[Benny]

Thanks a lot Sylvander for the link! As far as I remember the menu.lst resides in the root directory (normally) of a Win machine (think after Win 98). That's the .txt file that has to be edited in order to prevent automatic Windows startup process, because once it has started Puppy or any other OS won't start via a single os system approach (system wide OS), even though know you can run linuxes from within Windows via other means (need a lot of resources).
My approach to a frugal installation wasn't finished (&, probably, that's why I don't see the said file). Maybe if I restart the process & follow the same steps I'll catch up. Later, maybe tomorrow, I'll post what I've done.

[Benny]

Sorry to bother with this but I've found an expected issue with WinXP. There's a file at root named boot.ini (which is normally hidden & Write-Protected). I need to edit the contents of that file but it has disappeared.
What might have caused this was that even though I new the hdd didn't come with this motherboard (but both were intended to run linux xp op. syst.s) on dif. machines I tried to boot the xp in this one, with the known BSOD window showing a crashed system as the result. Vane hopes of mine...
Well, apparently, one of the consequences of this effort by my part was the deletion of the said file. I don't have an idea of the original-normal contents of it but, since what I want is to boot PL from the hdd it really matters just very little to me right now.
My 1st question is, am I right in thinking that I caused this by just trying to boot xp from this hdd in this notebook?
2nd question, what's the common-original contents of the said file, if it matters at all?
Thanks!

PS. Edit: I don't remember that this happened before, now if I go into /mnt/sda1/boot I get to see the contents of the folder but also a little window opens saying: "Error scanning '/mnt/sda1/boot':
Can't stat directory: No such file or directory". The 'menu.lst file should exist in root, not in a folder below it.
Any idea about this?

[jlreich]

Run the Grub installer, there will not be a menu.lst file until you do. When prompted for what disk to install it on type in /dev/sda1. Of course change sda1 to whatever your drive is if you have more than one. Do use "s" and not "h" even if you have an IDE drive that is normally called hda. For whatever reason this installer wants "s" regardless. It was quite the aggravation until I figured that out when I was installing it. ;)

Just do yourself a favor and completely ignore the text that pops up about installing grub after the puppy installer finishes. Just close the window. ;)

Edit - Sorry, I just seen your last two posts. Not sure what is going on, but the boot.ini file should not be missing unless you installed another windows OS while the drive was attached and visible, and even then it will usually just add itself to the file. But you can find a standard boot.ini file by doing a web search. Will just have to change the partition number, remembering that windows partitions start with 1 and hard disks start with 0.

[Paul Komski]

1. Boot.ini. The boot.ini file can be rebuilt appropriately as long as you can boot to a recovery console and the underlying windows installation is still in existence. The command is bootcfg /rebuild (http://support.microsoft.com/kb/291980)

The following is a typical boot.ini file which can be made with notepad.
[boot loader]
timeout=30
default=multi(0)disk(0)rdisk(0)partition(1)\WINDOW S
[operating systems]
multi(0)disk(0)rdisk(0)partition(1)\WINDOWS="Microsoft Windows XP Professional" /fastdetect /NoExecute=OptIn

2. On fragmentation and chaos. I think the word fragmentation may be at the back of things because it simply sounds chaotic; things being smashed into fragments. But in reality this is programmed just as defragmentation is and just as most operating system functions are in a logical/controlled manner. It is not in the nature of programming to leave operations to random responses though of course random things can be specifically programmed - for example in the generation of strong passwords.

Fragmentation of files is largely required when either a file cannot fit into the largest available area of free space or when it's expansion is needed because it is followed immediately by another file on the hard drive. The analogy I like is how books are stored in a library. If there is not enough space on the shelves for a complete book then it must be split and placed in more than one location and if there is a volume 1 it would be nice to put volume 2 beside it but if that is impossible it must be placed elsewhere. If the placement and splitting of books was completely random and chaotic there would pages of different books simply "all over the place".

I am of course not privvy to Microsofts algorithms but if fragmentation was truly random then even drives with adequate space would very rapidly be very fragmented. Enough already - by me anyway - sorry for dragging the issue out.

[Benny]

After trying to boot with a 'mock' boot.ini file I noticed 2 "important" things:
1) apparently, the os in the original hdd is Vista & not XP;
2) I see the usual 1st Menu showing the alternative os's.
The problem starts as I choose to boot Puppy Linux. I'm not sure, but I believe this menu is from the boot.ini file & not from menu.lst; if this's true then have to fix something but I'm still just probing.
I'll follow the example given above by Paul Komski. If that doesn't fix it I'll try your solution jlreich.
Thanks to all three for helping me on this!

[jlreich]

apparently, the os in the original hdd is Vista & not XP;
That's why there is no boot.ini file, vista and 7 use a new format called bcd (boot configuration data). Completely different than boot.ini. There are a couple tools you can run. Off the top of my head there is "BCD Edit", and "Easy BCD".

However, if booting puppy is the issue then Grub is what needs to be dealt with. Windows boot files will have nothing to do with that.

[Paul Komski]

I am now completely lost as to what is going on and what help is expected or required.

1st menu v menu lst is just one thing.

Boot.ini or no such file is another.

Win XP or Vista or 7 is another.

There is also the commet "The 'menu.lst file should exist in root, not in a folder below it" that has flown in from outer space and which makes little sense at all to me.

[jlreich]

Honestly it has been difficult for me to figure out what is going on as well...

[Benny]

I'm sorry to have caused confusion to you both!
Here is the info concerning the place of the 'menu.lst' file:
http://www.icpug.org.uk/national/linnwin/step1-xp.htm
Remember, I'm a follower on this... In 2 other trials on another VAIO model/year it worked fine (Puppy 421 & 431) almost 2 years ago. That VAIO was running XP, though.
What I've found is that after running <Menu><System>Grub bootloader config & rebooting I see my choices: Vista or Puppy. After selecting Puppy the Microsoft software takes control & put me into a situation where I must decide to Diagnose, Start Vista or Exit. I was expecting, though, another menu showing me my alternatives (all the puppies I've configured for booting).
Yes, I'm confused, too!

[Paul Komski]

That VAIO was running XP, though.
The Lin'N'Win project linked-to is (in my own opinion) a very long-winded way to dual boot Puppy and Windows (2000 or XP). After Windows XP with Windows (Vista or 7) the project wont work because boot.ini is not used by these later versions of Windows and boot.ini is a prerequisite to launch a customised version of GRUB in the grldr file which itself reads a cutomised version of a menu.lst file. In addition it only "supports" up to Puppy 4.3.1 even though later versions should work (via Win2000/XP) with appropriate modifications.

This customised way of dual booting is "safe" in that the normal GRUB is not installed as per normal to the MBR. When you invoked the "grub bootloader config" command you wrote an inappropriate version of GRUB to the MBR and that is why Vista then would no longer boot.

If you want to install Puppy to the hard drive of a Vista machine then boot to the Puppy CD and run the setup. This should install the normal GRUB to the MBR and "should" setup a dual boot menu. The downside is that the original MBR gets rewritten (just as after invoking "grub bootloader config") but this time it should link to the correct files and metadata.

If you go this route I suggest that you first make a copy of the original MBR from the puppy CD that you boot up to. Post back of you want details of how to do this using the dd command.

The other safe alternative is to simply boot to the Puppy CD and save the settings on exit. That way you can continue to boot to Puppy by putting in the CD and boot to Vista by removing the CD. An alternative to the CD on some systems is to configure a USB drive to do the same thing. This is normally done by invoking the Puppy Universal Installer after booting to the Puppy CD and after having appropriately prepared the USB drive (or indeed an internal hard drive for that matter). The MBR of the USB drive or the internal hard drive is, as with running setup, overwritten with GRUB once again.

[Benny]

Paul, in your 2nd paragraph you mention a reason for Vista not booting but isn't it true that if you put computer A's hdd in computer B it'll refuse to boot because of an awareness of the change in hardware?
I've prepared many years ago an old 64 MB MP3 Player (MuVo) to boot DSL from the usb port (on that old dead VAIO) & it worked fine for me but in this VAIO that I'm using now it refuses to boot. This's why I'm not very inclined to try usb dependent installations for this machine. Once I already tried it for a few weeks but obtained the same results as with the DSL stick.
Now I'm running PL511 from the live cd with pupsave & SFS files in sda1 (ntfs) & it works fine, for now. Still having some problems with some hardware functionality: mic (line), internal speakers (good for the sound that comes with the 1st screen at start up but not afterward), 2nd/alternate crt screen & others in relation to some multimedia buttons.
Since I've some issues with this machine that aren't related to the same point/driver/lib/etc/ I decided long ago to deal with them one at a time. One thing that suggested me that would be a good 1st approach was to stop booting solely with the live cd, that at least has been accomplished!
When my head clears a little bit I'll rearrange my priorities...

[Paul Komski]

if you put computer A's hdd in computer B it'll refuse to boot because of an awareness of the change in hardwareIt's a hit and miss affair as to how far the boot process will get to because of any specific hardware drivers issues but the boot process will usually at least begin normally if the HDD is visible and set correctly in the BIOS setup. Also, sometimes the old CMOS settings will need a reset. The "awareness" issue of hardware changes relates more to the possibility of Windows requiring a reactivation before it will let you log on to the Desktop should it get that far.

The issue of any Windows OS not booting properly after an installation or attempted installation of a Linux OS is likely to arise becaue the MBR was overwritten with GRUB or LILO or that the boot flag was changed there. Reverting to a saved copy of the MBR or resetting the active partition and running fdisk /r from DOS or fixmbr from a WinXP recovery console are possible fixes short of running an in place upgrade or repair of Windows.

Booting to USB drives is another very hit and miss affair. A PC might or might not boot from any one or more of a pen drive, a different pen drive, a flash memory card/card-reader, an external spinning HDD, etc. Usually the only hope in the BIOS settings is to choose USB Hard Drive or USB Zip Drive (even though its not a Zip Drive) or USB Floppy Drive (even though its not a FDD). More modern hardware is more likely to work but this is a very very grey area unless you know, say from the internet searches, that a specific USB model and specific PC work together OK from a specific BIOS setting. The other thing that must usually be done is to create a HDD type of MBR on the first sector (the one that contains the four partition tables that allows a drive to be partitioned like a HDD) since some drives have a PBS in that position just like a floppy drive and that will have a big effect in booting from any "so called" external hard drive.

[Benny]

I'm still in doubt with respect to the booting windows oss issue, Does WinXP or Vista boot readily if you take the hdd where it resides & put it in another machine? To add to my confusion is the fact that it 'asks' for the installation cds but it has been the norm, recently, to include in the hdd the recup files, & in this case I don't know if the said cds exist or not.
Is there a way to know (as if ticking on Properties) when the MBR has been modified? I've my doubts of having already changed it in this process...

[Paul Komski]

Does WinXP or Vista boot readily if you take the hdd where it resides & put it in another machine?
In a work - no it does not - nor do earlier or later versions of Windows. Only if you put the old HDD into virtually identical hardware is it likely to succeed. With WinXP a repair installation (http://www.michaelstevenstech.com/XPrepairinstall.htm) is usually required - With Vista it is apparently similar (http://www.vistax64.com/tutorials/88236-repair-install-vista.html).
it 'asks' for the installation cds but it has been the norm, recently, to include in the hdd the recup files
Don't know what you mean by recup files but in order to run the repair/in place upgrade you generally need the Windows/Vista CD/DVD for the exact same version of the original installation. It is possible to do this from the i386 folder transferred to the HDD and then initiated from DOS for WinXP (http://www.paulski.com/zpages.php?id=1711) and it is also possible to run the Vista installation for the installation files copied to a bootable USB drive; both are geekish and a bit elaborate but doable.
Is there a way to know (as if ticking on Properties) when the MBR has been modified?The only method I know is to examine it with a Hex Editor and compare it with a generic MBR made with Windows in mind. If you want to have it examined you can make a copy with WinHex (http://www.winhex.com/winhex/). A copy of one of my own follows but it is just as simple to write normal code back using fixmbr from a WinXP recovery console.

Offset 0 1 2 3 4 5 6 7 8 9 A B C D E F

000000000 33 C0 8E D0 BC 00 7C FB 50 07 50 1F FC BE 1B 7C 3ÀŽÐ¼.|ûP.P.ü¾.|
000000010 BF 1B 06 50 57 B9 E5 01 F3 A4 CB BE BE 07 B1 04 ¿..PW¹å.ó¤Ë¾¾.±.
000000020 38 2C 7C 09 75 15 83 C6 10 E2 F5 CD 18 8B 14 8B 8,|.u.ƒÆ.âõÍ.‹.‹
000000030 EE 83 C6 10 49 74 16 38 2C 74 F6 BE 10 07 4E AC îƒÆ.It.8,tö¾..N¬
000000040 3C 00 74 FA BB 07 00 B4 0E CD 10 EB F2 89 46 25 <.tú»..´.Í.ëò‰F%
000000050 96 8A 46 04 B4 06 3C 0E 74 11 B4 0B 3C 0C 74 05 –ŠF.´.<.t.´.<.t.
000000060 3A C4 75 2B 40 C6 46 25 06 75 24 BB AA 55 50 B4 :Äu+@ÆF%.u$»ªUP´
000000070 41 CD 13 58 72 16 81 FB 55 AA 75 10 F6 C1 01 74 AÍ.Xr.�ûUªu.öÁ.t
000000080 0B 8A E0 88 56 24 C7 06 A1 06 EB 1E 88 66 04 BF .ŠàˆV$Ç.¡.ë.ˆf.¿
000000090 0A 00 B8 01 02 8B DC 33 C9 83 FF 05 7F 03 8B 4E ..¸..‹Ü3Ƀÿ..‹N
0000000A0 25 03 4E 02 CD 13 72 29 BE 46 07 81 3E FE 7D 55 %.N.Í.r)¾F.�>þ}U
0000000B0 AA 74 5A 83 EF 05 7F DA 85 F6 75 83 BE 27 07 EB ªtZƒï.Ú…öuƒ¾'.ë
0000000C0 8A 98 91 52 99 03 46 08 13 56 0A E8 12 00 5A EB Š˜‘R™.F..V.è..Zë
0000000D0 D5 4F 74 E4 33 C0 CD 13 EB B8 00 00 00 00 00 00 ÕOtä3ÀÍ.ë¸......
0000000E0 56 33 F6 56 56 52 50 06 53 51 BE 10 00 56 8B F4 V3öVVRP.SQ¾..V‹ô
0000000F0 50 52 B8 00 42 8A 56 24 CD 13 5A 58 8D 64 10 72 PR¸.BŠV$Í.ZX�d.r
000000100 0A 40 75 01 42 80 C7 02 E2 F7 F8 5E C3 EB 74 49 .@u.B€Ç.â÷ø^ÃëtI
000000110 6E 76 61 6C 69 64 20 70 61 72 74 69 74 69 6F 6E nvalid partition
000000120 20 74 61 62 6C 65 00 45 72 72 6F 72 20 6C 6F 61 table.Error loa
000000130 64 69 6E 67 20 6F 70 65 72 61 74 69 6E 67 20 73 ding operating s
000000140 79 73 74 65 6D 00 4D 69 73 73 69 6E 67 20 6F 70 ystem.Missing op
000000150 65 72 61 74 69 6E 67 20 73 79 73 74 65 6D 00 00 erating system..
000000160 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
000000170 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
000000180 00 00 00 8B FC 1E 57 8B F5 CB 00 00 00 00 00 00 ...‹ü.W‹õË......
000000190 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0000001A0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0000001B0 00 00 00 00 00 00 00 00 49 3D 4A 3D 00 00 00 01 ........I=J=....
0000001C0 01 00 07 FE FF FF 3F 00 00 00 EC ED E1 04 00 FE ...þÿÿ?...ìíá..þ
0000001D0 FF FF 07 FE FF FF 2B EE E1 04 B9 C6 41 3E 00 FE ÿÿ.þÿÿ+îá.¹ÆA>.þ
0000001E0 FF FF 07 FE FF FF 23 B5 23 43 9E A4 4C 31 00 00 ÿÿ.þÿÿ#µ#Cž¤L1..
0000001F0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 55 AA ..............Uª

[Benny]

Thanks Paul for your advise! I'm sorry for not writing complete words: recup = recuperation.

I haven't tried to get a DOS command console yet but I'm thinking of it now because of something I read in one of your linked pages about recovering Vista from the console... I've a serious doubt in relation to this: how much danger are my pupsave & SFS files sustaining through this process?

Will it be safer to just start trying to fix the MBR first?

[Paul Komski]

fdisk /mbr from DOS or fixmbr from WinXP recovery console do almost exactly the same thing and modify the first 444 and 440 bytes respectively of the 512 bytes in the MBR.

The difference between them is that fixmbr does not write a new 4 byte disk signature but neither of them write to any data area of the hard drive or modify any of the files on it.

[Benny]

Thanks Paul for the tips! Now, I'm going to find a way to start this no-floppy drive notebook with a dos command only shell in order to run that command. I might have a way of doing it right from whatever is already in the hdd (I don't know, just a wild guess)...