Dear All,
I have a K8S-MX Asus Athlon 64 Motherboard with a 754 pin 3000+ CPU, which I cam trying to install 4.1 Centos 64 bit.
The problem seems to arise when installing onto Mirrored disks, I have noticed that from Centos 4 onwards it tries to rebuild the arrays as it installs which slows the whole process right down across all platforms I have tried it on.
In addition, the install process bails out at random times with random errors eg. "Disk Full", "error loading this package or that package", Error reading DVD etc... now I have burnt several copies of the DVD, tested them fully, tried installing from CD, even changed the hardware to a twin Opteron system, changed the RAM changed this disks and tried everything but it still seems really touch and go as to wether the install will complete.
I haven't managed it yet on the Asus platform it took about 12 goes on the opteron platform. Yet Centos 3.4 installs no problem.
Finally the last straw was the boot loader problem with occurs either immediately after reboot after install or on one of the boots soon after, and I have to do this to fix it: -------------------------------------- grub> root (hd0,0) Filesystem type is ext2fs, partition type 0xfd
grub> setup (hd0) Checking if "/boot/grub/stage1" exists... yes Checking if "/boot/grub/stage2" exists... yes Checking if "/boot/grub/e2fs_stage1_5" exists... yes Running "embed /boot/grub/e2fs_stage1_5 (hd0)"... 16 sectors are embedded. succeeded Running "install /boot/grub/stage1 (hd0) (hd0)1+16 p (hd0,0)/boot/grub/stage2 /boot/grub/grub.conf"... succeeded Done.
grub> root (hd1,0) Filesystem type is ext2fs, partition type 0xfd
grub> setup (hd1) Checking if "/boot/grub/stage1" exists... yes Checking if "/boot/grub/stage2" exists... yes Checking if "/boot/grub/e2fs_stage1_5" exists... yes Running "embed /boot/grub/e2fs_stage1_5 (hd1)"... 16 sectors are embedded. succeeded Running "install /boot/grub/stage1 (hd1) (hd1)1+16 p (hd1,0)/boot/grub/stage2 /boot/grub/grub.conf"... succeeded Done.
grub> quit ------------------
Has anyone else seen these tedious unpredicatble errors on install that seems to have arrived with version 4 onwards...?
Regards
Pete
Am Do, den 21.07.2005 schrieb Peter Farrow um 10:03:
I have a K8S-MX Asus Athlon 64 Motherboard with a 754 pin 3000+ CPU, which I cam trying to install 4.1 Centos 64 bit.
The problem seems to arise when installing onto Mirrored disks, I have noticed that from Centos 4 onwards it tries to rebuild the arrays as it installs which slows the whole process right down across all platforms I have tried it on.
Don't know whether I understand you correctly, but RAID1 array sync is started with firstboot after the installation finished.
In addition, the install process bails out at random times with random errors eg. "Disk Full", "error loading this package or that package", Error reading DVD etc... now I have burnt several copies of the DVD, tested them fully, tried installing from CD, even changed the hardware to a twin Opteron system, changed the RAM changed this disks and tried everything but it still seems really touch and go as to wether the install will complete.
I haven't managed it yet on the Asus platform it took about 12 goes on the opteron platform. Yet Centos 3.4 installs no problem.
That can be caused by bad cabling (length + quality) because kernel 2.6 is more sensible for standards. It can too help to deactivate DMA during install with: linux ide=nodma.
Finally the last straw was the boot loader problem with occurs either immediately after reboot after install or on one of the boots soon after, and I have to do this to fix it:
That is a known issue and filed in bugzilla.redhat.com. Didn't happen for my platform, grub was correctly installed, just not placed into both RAID1 drive's MBRs.
Pete
Alexander
"Don't know whether I understand you correctly, but RAID1 array sync is started with firstboot after the installation finished."
Err....no it doesn't.... it syncs the array as it installs, do a cntrl-alt-f3 when installing to bring a shell up then do a "watch cat /proc/mdstat"
and you can see it building the array as its installing, do a cntrl-alt-f7 to get back to the graphics screen.....
I did actually find what the problem was and this was it:
The SIS 965 chipset is not supported by the kernel so the IDE interfaces runs S-L-O-W-L-Y eg 1.7Mb/sec transfer rate to the disk, coupled with the RAID rebuilding in the background makes the install take about 6 hours if it can actually manage to complete, which it usually doesn't on this platform.
The solution: change the motherboard.... so I put a sempron socket A board in its place with a 3200+ CPU and it works fine....
:-)
Alexander Dalloz wrote:
Am Do, den 21.07.2005 schrieb Peter Farrow um 10:03:
I have a K8S-MX Asus Athlon 64 Motherboard with a 754 pin 3000+ CPU, which I cam trying to install 4.1 Centos 64 bit.
The problem seems to arise when installing onto Mirrored disks, I have noticed that from Centos 4 onwards it tries to rebuild the arrays as it installs which slows the whole process right down across all platforms I have tried it on.
Don't know whether I understand you correctly, but RAID1 array sync is started with firstboot after the installation finished.
In addition, the install process bails out at random times with random errors eg. "Disk Full", "error loading this package or that package", Error reading DVD etc... now I have burnt several copies of the DVD, tested them fully, tried installing from CD, even changed the hardware to a twin Opteron system, changed the RAM changed this disks and tried everything but it still seems really touch and go as to wether the install will complete.
I haven't managed it yet on the Asus platform it took about 12 goes on the opteron platform. Yet Centos 3.4 installs no problem.
That can be caused by bad cabling (length + quality) because kernel 2.6 is more sensible for standards. It can too help to deactivate DMA during install with: linux ide=nodma.
Finally the last straw was the boot loader problem with occurs either immediately after reboot after install or on one of the boots soon after, and I have to do this to fix it:
That is a known issue and filed in bugzilla.redhat.com. Didn't happen for my platform, grub was correctly installed, just not placed into both RAID1 drive's MBRs.
Pete
Alexander
CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
On Thu, Jul 21, 2005 at 03:55:25PM +0100, Peter Farrow wrote:
"Don't know whether I understand you correctly, but RAID1 array sync is started with firstboot after the installation finished."
Err....no it doesn't.... it syncs the array as it installs, do a cntrl-alt-f3 when installing to bring a shell up then do a "watch cat /proc/mdstat"
I've observed this too. Really irritating.
danno
On Thu, 2005-07-21 at 11:48, Dan Pritts wrote:
On Thu, Jul 21, 2005 at 03:55:25PM +0100, Peter Farrow wrote:
"Don't know whether I understand you correctly, but RAID1 array sync is started with firstboot after the installation finished."
Err....no it doesn't.... it syncs the array as it installs, do a cntrl-alt-f3 when installing to bring a shell up then do a "watch cat /proc/mdstat"
I've observed this too. Really irritating.
RAID1 has to sync as you create it - and if it doesn't complete and shut down cleanly it will do it again on the first boot. With hardware that is reasonable to run as RAID1 it shouldn't be noticeable. Why is it irritating?
Les Mikesell wrote:
On Thu, 2005-07-21 at 11:48, Dan Pritts wrote:
On Thu, Jul 21, 2005 at 03:55:25PM +0100, Peter Farrow wrote:
"Don't know whether I understand you correctly, but RAID1 array sync is started with firstboot after the installation finished."
Err....no it doesn't.... it syncs the array as it installs, do a cntrl-alt-f3 when installing to bring a shell up then do a "watch cat /proc/mdstat"
I've observed this too. Really irritating.
RAID1 has to sync as you create it - and if it doesn't complete and shut down cleanly it will do it again on the first boot. With hardware that is reasonable to run as RAID1 it shouldn't be noticeable. Why is it irritating?
It halts the install of packages until the sync is done for the / mount points. (/var/ /bin/ /etc/ ..) As a mount is required, it snycs the drives.
Later, when installing the files in /boot, it syncs that too. Basically, it is lots of waiting with what looks like a frozen task bar. The waiting is the pain. ;)
My observation was it never used to this until version 4....
P.
eli@streetlampsoftware.com wrote:
Les Mikesell wrote:
On Thu, 2005-07-21 at 11:48, Dan Pritts wrote:
On Thu, Jul 21, 2005 at 03:55:25PM +0100, Peter Farrow wrote:
"Don't know whether I understand you correctly, but RAID1 array sync is started with firstboot after the installation finished."
Err....no it doesn't.... it syncs the array as it installs, do a cntrl-alt-f3 when installing to bring a shell up then do a "watch cat /proc/mdstat"
I've observed this too. Really irritating.
RAID1 has to sync as you create it - and if it doesn't complete and shut down cleanly it will do it again on the first boot. With hardware that is reasonable to run as RAID1 it shouldn't be noticeable. Why is it irritating?
It halts the install of packages until the sync is done for the / mount points. (/var/ /bin/ /etc/ ..) As a mount is required, it snycs the drives.
Later, when installing the files in /boot, it syncs that too. Basically, it is lots of waiting with what looks like a frozen task bar. The waiting is the pain. ;) _______________________________________________ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
On Thu, 2005-07-21 at 16:02, eli@streetlampsoftware.com wrote:
I've observed this too. Really irritating.
RAID1 has to sync as you create it - and if it doesn't complete and shut down cleanly it will do it again on the first boot. With hardware that is reasonable to run as RAID1 it shouldn't be noticeable. Why is it irritating?
It halts the install of packages until the sync is done for the / mount points. (/var/ /bin/ /etc/ ..) As a mount is required, it snycs the drives.
I always do an NFS install so I don't wait around and watch, but I don't see any reason a RAID1 has to wait for the sync to complete before using it - it doesn't when you build one by hand.
Later, when installing the files in /boot, it syncs that too. Basically, it is lots of waiting with what looks like a frozen task bar. The waiting is the pain. ;)
It should take about 15 seconds to sync /boot... The thing that bothers me more is that it doesn't know enough to install grub on either of the underlying drives, let alone both.
The older 1.0 toaster let you set quota's from qmailadmin, this version doesn't. Where is the setting to enable it? Or does it require qmailadmin to be compiled from source?
The reason why it was irritating was because the SiS965 Athlon 64 chipset was not supported in the 4.1 kernel, which resulted in a miserably slow install which eventually ground to a halt because the load average got too high as the system was stacked behind with its disk writes....
That is irritating, the rebuild should be on first boot.....
P.
Les Mikesell wrote:
On Thu, 2005-07-21 at 11:48, Dan Pritts wrote:
On Thu, Jul 21, 2005 at 03:55:25PM +0100, Peter Farrow wrote:
"Don't know whether I understand you correctly, but RAID1 array sync is started with firstboot after the installation finished."
Err....no it doesn't.... it syncs the array as it installs, do a cntrl-alt-f3 when installing to bring a shell up then do a "watch cat /proc/mdstat"
I've observed this too. Really irritating.
RAID1 has to sync as you create it - and if it doesn't complete and shut down cleanly it will do it again on the first boot. With hardware that is reasonable to run as RAID1 it shouldn't be noticeable. Why is it irritating?
On Thu, Jul 21, 2005 at 10:19:27PM +0100, Peter Farrow wrote:
The reason why it was irritating was because the SiS965 Athlon 64 chipset was not supported in the 4.1 kernel, which resulted in a miserably slow install which eventually ground to a halt because the load average got too high as the system was stacked behind with its disk writes....
It's plenty irritating even on a system with a supported IDE chipset. an install that might have taken 15 minutes takes over an hour.
danno -- dan pritts - systems administrator - internet2 734/352-4953 office 734/834-7224 mobile
On Thu, Jul 21, 2005 at 03:38:35PM -0500, Les Mikesell wrote:
"Don't know whether I understand you correctly, but RAID1 array sync is started with firstboot after the installation finished."
Err....no it doesn't.... it syncs the array as it installs, do a cntrl-alt-f3 when installing to bring a shell up then do a "watch cat /proc/mdstat"
I've observed this too. Really irritating.
RAID1 has to sync as you create it -
no it doesn't. It could delay the sync until after the first boot or until later in the install process.
and if it doesn't complete and shut down cleanly it will do it again on the first boot. With
Fine.
hardware that is reasonable to run as RAID1 it shouldn't be noticeable.
guess you haven't been paying attention to your installs.
Why is it irritating?
Because it's trying to do the sync at the same time that the installer is trying to install packages, so the disk heads have to seek all over the place to try to service the competing I/O requests.
A much better approach would be to delay the sync until after the first boot, or to have the installer give you the option to do the sync after the packages have been written to disk but before the reboot.
danno -- dan pritts - systems administrator - internet2 734/352-4953 office 734/834-7224 mobile
Dan Pritts wrote:
no it doesn't. It could delay the sync until after the first boot or until later in the install process.
Actually, it doesn't need to do the sync at all. The reasoning being that parts of the disk you did not write to, should never be read (under normal circumstances). One version of Fedora (not sure if it was Core 1 or 2) was not syncing mirrors created during an install. I guess some people got bitten by it, so they reverted it back to the old safe way.
Because it's trying to do the sync at the same time that the installer is trying to install packages, so the disk heads have to seek all over the place to try to service the competing I/O requests.
A much better approach would be to delay the sync until after the first boot, or to have the installer give you the option to do the sync after the packages have been written to disk but before the reboot.
I've noticed this only on unsupported IDE controllers where disks were accessed in PIO mode. On anything else, the slowdown due to syncing was minimal. Anyhow, not syncing disks right away is asking for trouble. Data consistency is concern number one. Speed is somewhere around the end of the list.
Anyhow, in your case you could always do normal install on one disk, and build mirrors after installation is done. Although, option to only half-build mirror (specify only one submirror) during install for cases where second submirror is not available during install would be a nice option.
On Mon, 2005-07-25 at 11:26, Aleksandar Milivojevic wrote:
Anyhow, in your case you could always do normal install on one disk, and build mirrors after installation is done. Although, option to only half-build mirror (specify only one submirror) during install for cases where second submirror is not available during install would be a nice option.
It seems fairly painful to convert a normal partition to a mirror. I've created 'broken' mirrors by hand a few times and added the other drive later. That's easy enough and would be a good choice to have during installs.
-
Aleksandar Milivojevic -
Alexander Dalloz -
Brian Trudeau -
Dan Pritts -
eli＠streetlampsoftware.com -
Les Mikesell -
Peter Farrow