Wary slow in booting on NTFS partition

[nic007]

Wary 5.3, frugal install. All necessary files located in root directory of windows 110GB ntfs partition. Booting via grubdos but have to wait about a minute at the search for files boot stage. Is this time lapse normal behaviour when booting puppy on an ntfs partition?

Edit: Just checked the booting on another ntfs drive. Quick, no problem so must be a disk issue.

[Monsie]

nic007,

Since this is a ntfs partition, is it possible that it could be badly fragmented such that boot-up time would take longer while the system file pieces are located on the disk?

Just a thought,
Monsie

[nooby]

I would suggest an easy test.

Add a directory named Wary and place all three files
within that Dir and then change the boot code to something like

title wary
rootnoverify (hd0,0)
kernel /wary/vmlinuz root=/dev/sda1 psubdir=/wary pfix=fsck
initrd /wary/initrd.gz

And time it to be some 45 seconds or faster?

Ooops the save file should be moved to that directory too?

With reservation that I have misunderstood something.

[raffy]

At boot, when it says "looking for files", it tries to mount and read your drives and partitions.

There are times when the PC has a number of drives and partitions and some of them can have problems.

You can try telling Puppy where to look, like

root=/dev/sda1

if the files are in the first partition of the first drive.

Most new Win installations have user files in the second partition, so use

root=/dev/sda2

(The usage is as nooby showed above.)

[mikeb]

Bear in mind its searching sub sub folders now (???) so that would include your windows systems folders and program files if present....a user space file system and a search through thousands of files.
The puppy is hidden behind the settee.....

mike

[nic007]

I've deleted some unnecessary files that I don't use anymore. Much better now, thanks.

[mikeb]

I keep seeing the root=/dev/sdxx parameter floating around and unless something weird is going on its not for what some are claiming it to be...from the kernel man page..

'root=...'
This argument tells the kernel what device is to be used as
the root filesystem while booting. The default of this
setting is determined at compile time, and usually is the
value of the root device of the system that the kernel was
built on. To override this value, and select the second
floppy drive as the root device, one would use
'root=/dev/fd1'.

The root device can be specified symbolically or numerically.
A symbolic specification has the form /dev/XXYN, where XX
designates the device type ('hd' for ST-506 compatible hard
disk, with Y in 'a'-'d'; 'sd' for SCSI compatible disk, with Y
in 'a'-'e'; 'ad' for Atari ACSI disk, with Y in 'a'-'e', 'ez'
for a Syquest EZ135 parallel port removable drive, with Y='a',
'xd' for XT compatible disk, with Y either 'a' or 'b'; 'fd'
for floppy disk, with Y the floppy drive number--fd0 would be
the DOS 'A:' drive, and fd1 would be 'B:'), Y the driver
letter or number, and N the number (in decimal) of the
partition on this device (absent in the case of floppies).
Recent kernels allow many other types, mostly for CD-ROMs:
nfs, ram, scd, mcd, cdu535, aztcd, cm206cd, gscd, sbpcd,
sonycd, bpcd. (The type nfs specifies a net boot; ram refers
to a ram disk.)

Note that this has nothing to do with the designation of these
devices on your filesystem. The '/dev/' part is purely
conventional.

The more awkward and less portable numeric specification of
the above possible root devices in major/minor format is also
accepted. (E.g., /dev/sda3 is major 8, minor 3, so you could
use 'root=0x803' as an alternative.)

In simple terms its where your install lives...for a full install that would be the partition its on... for an initrd system it would be /dev/ram0 since that runs in the ram disk initially.... for a cpio init that puppy 4+ use its most likely ignored since its makes no sense with that method... Its a kernel mode parameter NOT a puppy option telling it what to ignore....

Just needed to pop that info somewhere and here seemed as good as any...

regards

Mike

[nic007]

Just an observation - When the necessary puppy files are placed in the root directory of a partition and the grub loader is set to boot from that root directory, one would think that puppy will search for its files at root level first (ie. Before looking into folders and sub folders). So logic would suggest that boot-up should always be fast in this case no matter how many directories or sub-directories. Unfortunate this seems not to be the case as the boot-up time is affected by the number of folders, sub-folders and files on the drive too.

[mikeb]

The mechanism is find is used with -maxdepth 2 (or was it 3....been some years since I had it) so it scans sub folders folders and a list is made of any files with the correct name (one usually !) Then you have a plethora of boot parameters to try and narrow the search. (if you know where things are why search...hmm)

You could edit the initrd and change it to 1 ..I found that was a big improvement or the old way of a file exists bash check.

mike

[mikeb]

actually i lied

Code: Select all

 FND_INITRDGZ="`find /mnt/data -maxdepth 2 -mount -type f -name initrd.gz | grep -v ' ' | sed -e 's%^/mnt/data%%g' | tr '\n' ' '`"
 #v3.01 '*' means zero or more extra characters. this is for custom naming...
 FND_PUPXXXSFS="`find /mnt/data -maxdepth 2 -mount -type f -name pup_${PUPPYVERSION}*.sfs | grep -v ' ' | sed -e 's%^/mnt/data%%g' | tr '\n' ' '`"
 FND_ZDRVSFS="`find /mnt/data -maxdepth 2 -mount -type f -name zdrv_${PUPPYVERSION}.sfs | grep -v ' ' | sed -e 's%^/mnt/data%%g' | tr '\n' ' '`"
 FND_PUPSAVE2FS="`find /mnt/data -maxdepth 2 -mount -type f -name pup_save*.[23]fs | grep -v ' ' | sed -e 's%^/mnt/data%%g' | tr '\n' ' '`"
 FND_SWAPFILEPUP="`find /mnt/data -maxdepth 2 -mount -type f -name pupswap.swp | grep -v ' ' | sed -e 's%^/mnt/data%%g' | tr '\n' ' '`"
 #v2.22 improved folder name search, avoid false hits...
 FND_MULTIFOLDER="`find /mnt/data -maxdepth 1 -mount -type d -name 20[0-9][0-9]-[0-9][0-9]-[0-9][0-9]-[0-9][0-9]-[0-9][0-9] | grep -v ' ' | sed -e 's%^/mnt/data%%g' | tr '\n' ' '`"

find is run 6 times...... well might be variations but this is typical code.
That initrd search can have interesting side effects

mike

[rcrsn51]

You can try telling Puppy where to look, like root=/dev/sda1

This option for frugal installs ended with Puppy 3.01. People need to stop posting it.

@nic007: Please post your current menu.lst file.

[nic007]

You can try telling Puppy where to look, like root=/dev/sda1

This option for frugal installs ended with Puppy 3.01. People need to stop posting it.

@nic007: Please post your current menu.lst file.

Hi, rcrsn51. I've decided to uninstall windows 7 on that particular machine as it was running very slowly anyway (only 1 Gig RAM, files corrupted, I think). The puppy files are in root of that partition now and it boots quickly. The menu.lst file points to the root of that partition and is correct. Earlier I checked the booting time on another windows machine, again puppy files located in the root of that partition (NTFS) with full windows install. Puppy booted fast on this machine (although the HDD has smaller capacity). Just think the files were a bit messed up on the windows 7 machine (Gparted also showed a flag and reported 18 or more bad sectors, although couldn't do a check on it because of the flag). So, nothing wrong with puppy then but rather problems with the disk/file system. Haven't checked with Gparted if the flag is gone now but will attempt re-format from dos if it gives problems in future.