On Sunday 23 March 2003 09:19 am, John Richard Smith wrote:
First attempt.This is interesting, I have been using rc2 and updating with cooker mirrors on a daily basis since it came out. Over the couple of weeks or so that I was updating it continued to improve and bugs went away. I did not ever have the slow install problem you were having. This would be good info for the Mandrake design team if you could determine what the problem really is. How is your computer set up? CDROM speed and other info? Primary and Secondary set up etc?
Complete failure to install .
a) Very very long wait between install catagories . Everytime you click "next" you wait an eon betfore the next install window appears.
b) The install eventually completely stalled , trying to enter "install a screen driver", a blank grey/white window appears with the words next bottom righthand corner, but with zero sensitivity.
Eventually I gave up trying to get it to move on and rebooted , reinstalled the original M9.0 lilo and rebooted again only to find the system could not fsck /dev/hda7 (the M9.1 install partition), something about not being able to check the count or something, I soon dropped to a terminal and formatted the same partition which restored the boot to desktop in M9.0. It would seem the file system was dodgy.I don't know what it was though.
Not wishing to be a pessimist, I must say that at so late a stage in the life of this release I cannot but wonder what will be the use of it .
John
DVD + Writer mater/slave on IDE line1 Single 40gig Maxtor as primary on IDE line2
The slowness of install was never experienced with any prior mandrake releases, including M8.1,M8.2,M9.0, only 9.1 series, which
started with beta1,beta2 , somewhat updated via urpmi to rc2, but just now replaced with a straight M9.2rc2 install(not update) from discs.
I simply have no idea why.
Whether the problem with the screen driver install is related to the file system, I chose the default ext2 file system, which also seems to cause the reboot problem, I don't know.
I have a modern Pioneer DVD, and Mitsumi writer,
Cdrecord 1.11a32 (i586-mandrake-linux-gnu) Copyright (C) 1995-2002 J�rg Schilling
Linux sg driver version: 3.1.24
Using libscg version 'schily-0.6'
scsibus0:
0,0,0 0) *
0,1,0 1) *
0,2,0 2) 'PIONEER ' 'DVD-ROM DVD-116 ' '1.22' Removable CD-ROM
0,3,0 3) 'MITSUMI ' 'CR-48X9TE ' '1.0C' Removable CD-ROM
0,4,0 4) *
0,5,0 5) *
0,6,0 6) *
0,7,0 7) *
scsibus1:
1,0,0 100) 'Generic ' 'USB Storage-SMC ' '0090' Removable Disk
1,1,0 101) *
1,2,0 102) *
1,3,0 103) *
1,4,0 104) *
1,5,0 105) *
1,6,0 106) *
1,7,0 107) *
Could having a Generic "USB Storage-SMC ' '0090' Removable Disk"
disc attatched to the bus be the cause of a slow install does anyone think ?
It's the only thing that is currently different from previous release installs. Just a thought ?
By the way the position of the dvd/writer vis a vis the storage device goes walkies around the bus on every boot up, either the scanbus 0 or 1, has to check every time, and alter the appropriate commands to suit. Not critical but odd.
I don't for one minute think the dvd/rom speed is at fault, as far as install speed.
The best clue I have is the problem with fsck ' ing the partition that the install occured on, namely /dev/hda7. There has to be some reason why a fresh new install should have a problem with completing a fsck at the first boot , unless the formatting itself is the problem, and maybe the cause of the slow install, is the allocation table all screwed up ? I would think the mandrake team could take a fresh look at the programme here and assetain whether recent changes have upset things a bit ?
Bear in mind that so many of the cooker team rely on urpmi updates, so once the initial install has been accomplished and an fsck accomplished the faults would not go on being detected.
John
John
--
John Richard Smith
[EMAIL PROTECTED]
Want to buy your Pack or Services from MandrakeSoft? Go to http://www.mandrakestore.com
