October 2002 - WLUG - wlug.mailman3.com

Re: [Wlug] RH 7.0->7.3 upgrade

by Peter Gutowski

On 10/18/2002 1:23 PM, Wes Allen <wallen(a)charter.net> wrote: >On Friday 18 October 2002 11:03, Peter Gutowski wrote: >> I'd suggest that you consider upgrading to 8.0. I've been very >>impressed with the........ ...snip... >Is the php module ready for 2.x? I've been thinking about giving >RH 8.0 a try >to see if I can make use of my usb ports! RHL8.0 includes PHP 4.2.2, plus various modules (libphp4.so for apache, imap, mysql, etc....) You might need to rework portions of the /etc/php.ini file, but it seems to be a straight shot. -PG

Oct. 18, 2002

Re: [Wlug] RH 7.0->7.3 upgrade

by Wes Allen

On Friday 18 October 2002 11:03, Peter Gutowski wrote: > I'd suggest that you consider upgrading to 8.0. I've been very impressed > with the changes in 8.0 primarily in the area of user interface. > > I've experienced problems with RHL upgrades in the past. But I believe the > bulk of those problems owed to the fact that I was attempting to upgrade > where the disk setup was just too "tight". Perhaps in contrast to to 7.0, > both 7.3 and 8.0 put a lot of files into /usr/share. You'll may make things > easier for yourself if /usr/share is on its own partition. > > Aside from the be prepared for a general tightening of security. If you use > sendmail, you'll probably have to add a "sendmail: ALL" into > /etc/hosts.allow as the default is to only do mail handling from localhost. > RHL 8.0 uses apache 2.x whereas RHL7.3 still uses the 1.3.x versions. Is the php module ready for 2.x? I've been thinking about giving RH 8.0 a try to see if I can make use of my usb ports! > > Having installations on hard disks with enough hard drive space has made > both upgrades, 7.3 and 8.0, pretty painless. As Charles Anderson ;) may > likely suggest to you, be sure to read (and digest) the README files on the > install disks... probably before you start to alleviate too many surprizes. > (Foolish boy that I was, I *didn't*. And to my embarassment, he > [rightfully] rubbed my nose in it. But, hey, I learned my lesson.) > > FYI, this may not be totally meaningful without know how much and just what > exactly in installed. But, that said, I'd characterize my installation as > medium -- neither slim nor fat. Here's some pertinent partition usages: > > Filesystem 1K Blocks Used Available % Mounted on > /dev/hda3 497861 80662 391495 18% / > /dev/hda1 31079 6419 23056 22% /boot > /dev/hda11 2063504 98612 1860072 6% /home > /dev/hda7 2063504 1209760 748924 62% /usr > /dev/hda9 521748 113052 382192 23% /usr/local > /dev/hda8 2063504 729108 1229576 38% /usr/share > /dev/hda10 521748 154348 340896 32% /usr/src > /dev/hda5 497829 76114 396013 17% /var > > -PG > > On 10/18/2002 9:53 AM, Richard Goodman <dick(a)goodman1.net> wrote: > >I have four RH servers, two 7.0 and two new 7.3 servers just put up > >last 6 > >weeks or less > >How painless would an upgrade of the older servers from 7.0->7.3 > >be? Any > >surprises I should know about? Any comments or advice? I've never > >done a > >version upgrade before. > > > >I already have a CD with the most important security upgrades I used > >on the > >7.3 servers after I had worm (Slapper/Cinik) problems. > > > >Dick > > > > Richard Goodman dick(a)goodman1.net > > > > > > > > > >_______________________________________________ > >Wlug mailing list > >Wlug(a)mail.wlug.org > >http://mail.wlug.org/mailman/listinfo/wlug > > _______________________________________________ > Wlug mailing list > Wlug(a)mail.wlug.org > http://mail.wlug.org/mailman/listinfo/wlug -- ------ This message may be signed using GPG, for my public key please send me a message with "Key Request" in the subject line.

Oct. 18, 2002

Re: [Wlug] RH 7.0->7.3 upgrade

by Theo Van Dinter

On Fri, Oct 18, 2002 at 11:54:47AM -0400, Charles R. Anderson wrote: > I wouldn't recommend running servers on 8.0 at the moment, since there are > some kinks that haven't been worked out yet, the major one being rpm hangs. Ah, as is standard: X.0 = avoid, X.1 = better, X.2 = rocks 7.3 is the only X.3 in recent times from RH so it's not in the standard yet. ;) -- Randomly Generated Tagline: "Real programmers scorn floating point arithmetic. The decimal point was invented for pansy bedwetters who are unable to 'think big'." - Unknown

Oct. 18, 2002

Re: [Wlug] RH 7.0->7.3 upgrade

by Charles R. Anderson

On Fri, Oct 18, 2002 at 09:53:47AM -0400, Richard Goodman wrote: dick> I have four RH servers, two 7.0 and two new 7.3 servers just put up last 6 dick> weeks or less dick> How painless would an upgrade of the older servers from 7.0->7.3 be? Any dick> surprises I should know about? Any comments or advice? I've never done a dick> version upgrade before. I've had excellent results with upgrading servers. I've done upgrades from 4.0 through to 7.3 on my system, and 6.2 through to 7.3 on servers at work. Just be sure to read the README and RELEASE-NOTES on the new release before upgrading. I recommend making a backup copy of /etc that you can refer to in case something in the upgrade changes a file: cp -av /etc /etc.rh70 You will need to at least check over some config files after the upgrade. You can find all the ones that were changed or for which there are new ones available by doing this: find /etc -name '*.rpm*' -ls .rpmsave are backups of your original configs which were replaced during the upgrade. .rpmnew are new versions of config files that might need to be configured and put in place over your originals. /root/upgrade.log will also have a log of every package upgrade and if they replaced any config files or provided new config files. I wouldn't recommend running servers on 8.0 at the moment, since there are some kinks that haven't been worked out yet, the major one being rpm hangs. -- Charles R. Anderson <cra(a)wpi.edu> / http://angus.ind.wpi.edu/~cra/ PGP Key ID: 49BB5886 Fingerprint: EBA3 A106 7C93 FA07 8E15 3AC2 C367 A0F9 49BB 5886

Oct. 18, 2002

Re: [Wlug] RH 7.0->7.3 upgrade

by Peter Gutowski

I'd suggest that you consider upgrading to 8.0. I've been very impressed with the changes in 8.0 primarily in the area of user interface. I've experienced problems with RHL upgrades in the past. But I believe the bulk of those problems owed to the fact that I was attempting to upgrade where the disk setup was just too "tight". Perhaps in contrast to to 7.0, both 7.3 and 8.0 put a lot of files into /usr/share. You'll may make things easier for yourself if /usr/share is on its own partition. Aside from the be prepared for a general tightening of security. If you use sendmail, you'll probably have to add a "sendmail: ALL" into /etc/hosts.allow as the default is to only do mail handling from localhost. RHL 8.0 uses apache 2.x whereas RHL7.3 still uses the 1.3.x versions. Having installations on hard disks with enough hard drive space has made both upgrades, 7.3 and 8.0, pretty painless. As Charles Anderson ;) may likely suggest to you, be sure to read (and digest) the README files on the install disks... probably before you start to alleviate too many surprizes. (Foolish boy that I was, I *didn't*. And to my embarassment, he [rightfully] rubbed my nose in it. But, hey, I learned my lesson.) FYI, this may not be totally meaningful without know how much and just what exactly in installed. But, that said, I'd characterize my installation as medium -- neither slim nor fat. Here's some pertinent partition usages: Filesystem 1K Blocks Used Available % Mounted on /dev/hda3 497861 80662 391495 18% / /dev/hda1 31079 6419 23056 22% /boot /dev/hda11 2063504 98612 1860072 6% /home /dev/hda7 2063504 1209760 748924 62% /usr /dev/hda9 521748 113052 382192 23% /usr/local /dev/hda8 2063504 729108 1229576 38% /usr/share /dev/hda10 521748 154348 340896 32% /usr/src /dev/hda5 497829 76114 396013 17% /var -PG On 10/18/2002 9:53 AM, Richard Goodman <dick(a)goodman1.net> wrote: >I have four RH servers, two 7.0 and two new 7.3 servers just put up >last 6 >weeks or less >How painless would an upgrade of the older servers from 7.0->7.3 >be? Any >surprises I should know about? Any comments or advice? I've never >done a >version upgrade before. > >I already have a CD with the most important security upgrades I used >on the >7.3 servers after I had worm (Slapper/Cinik) problems. > >Dick > > Richard Goodman dick(a)goodman1.net > > > > >_______________________________________________ >Wlug mailing list >Wlug(a)mail.wlug.org >http://mail.wlug.org/mailman/listinfo/wlug > >

Oct. 18, 2002

RH 7.0->7.3 upgrade

by Richard Goodman

I have four RH servers, two 7.0 and two new 7.3 servers just put up last 6 weeks or less How painless would an upgrade of the older servers from 7.0->7.3 be? Any surprises I should know about? Any comments or advice? I've never done a version upgrade before. I already have a CD with the most important security upgrades I used on the 7.3 servers after I had worm (Slapper/Cinik) problems. Dick Richard Goodman dick(a)goodman1.net

Oct. 18, 2002

Re: duplicate entry in mdstat with RAID-5

by Neil Brown

On Thursday October 17, karl(a)mail.accusense.com wrote: > > Can someone please help me fix this problem? I don't know if my data is > safe at the moment. > > > I have double entries for hde1 and hde in /proc/mdstat. The problem arose > when i did a raidhotadd for /dev/hde then again for /dev/hde1. Doh. Is > this a problem? How do i fix it? I would like to be using hde1, hdf1, > hdc1 > > The problem arose when the 60GB /dev/hde failed. I replaced it with an > 80GB drive. > > I am running redhat 7.2 with their kernel 2.4.9-31 > > > # cat /proc/mdstat > Personalities : [raid5] > read_ahead 1024 sectors > md0 : active raid5 hde1[3] hde[2] hdf1[1] hdc1[0] > 120102912 blocks level 5, 64k chunk, algorithm 0 [3/3] [UUU] > > unused devices: <none> So the raid is made of hdc1 hdf1 hde, with hde1 as a hot spare.. Not what you want. raidhotremove /dev/md0 /dev/hde1 raidsetfaulty /dev/md0 /dev/hde raidhotremove /dev/md0 /dev/hde Repartition hde correctly, the partition table will have been corrupted. raidhotadd /dev/md0 /dev/hde1 and don't make a typo this time :-) NeilBrown > > ---- > # fdisk -l /dev/hde > > Disk /dev/hde: 16 heads, 63 sectors, 155061 cylinders > Units = cylinders of 1008 * 512 bytes > > Disk /dev/hde doesn't contain a valid partition table > ----- > > # fdisk -l /dev/hdc > Disk /dev/hdc: 16 heads, 63 sectors, 119150 cylinders > Units = cylinders of 1008 * 512 bytes > > Device Boot Start End Blocks Id System > /dev/hdc1 * 1 119150 60051568+ fd Linux raid autodetect > > ---- > # fdisk -l /dev/hdf > Disk /dev/hdf: 16 heads, 63 sectors, 119150 cylinders > Units = cylinders of 1008 * 512 bytes > > Device Boot Start End Blocks Id System > /dev/hdf1 1 119150 60051568+ fd Linux raid autodetect > > > -- > /var/log/messages file > when i tried to remove /dev/hde with raidhotremove > > > Oct 17 22:17:15 data kernel: md: trying to remove hde from md0 ... > Oct 17 22:17:15 data kernel: md: bug in file md.c, line 2344 > Oct 17 22:17:15 data kernel: > Oct 17 22:17:15 data kernel: md:^I********************************** > Oct 17 22:17:15 data kernel: md:^I* <COMPLETE RAID STATE PRINTOUT> * > Oct 17 22:17:15 data kernel: md:^I********************************** > Oct 17 22:17:15 data kernel: md0: <hde1><hde><hdf1><hdc1> array > superblock: > Oct 17 22:17:15 data kernel: md: SB: (V:0.90.0) > ID:<a595074f.25e94a64.bec4b48a.e946a7b6> CT:3bdeb7e7 > Oct 17 22:17:15 data kernel: md: L5 S60051456 ND:4 RD:3 md0 LO:0 > CS:65536 > Oct 17 22:17:15 data kernel: md: UT:3daf6d69 ST:0 AD:3 WD:4 FD:0 SD:1 > CSUM:99d87466 E:0000009c > Oct 17 22:17:15 data kernel: D 0: DISK<N:0,hdc1(22,1),R:0,S:6> > Oct 17 22:17:15 data kernel: D 1: DISK<N:1,hdf1(33,65),R:1,S:6> > Oct 17 22:17:15 data kernel: D 2: DISK<N:2,hde(33,0),R:2,S:6> > Oct 17 22:17:15 data kernel: D 3: DISK<N:3,hde1(33,1),R:3,S:0> > Oct 17 22:17:15 data kernel: md: THIS: DISK<N:3,hde1(33,1),R:3,S:0> > Oct 17 22:17:15 data kernel: md: rdev hde1: O:hde1, SZ:60051456 F:0 DN:3 > md: rdev superblock: > Oct 17 22:17:15 data kernel: md: SB: (V:0.90.0) > ID:<a595074f.25e94a64.bec4b48a.e946a7b6> CT:3bdeb7e7 > Oct 17 22:17:15 data kernel: md: L5 S60051456 ND:4 RD:3 md0 LO:0 > CS:65536 > Oct 17 22:17:15 data kernel: md: UT:3daf6d69 ST:0 AD:3 WD:4 FD:0 SD:1 > CSUM:99d874aa E:0000009c > Oct 17 22:17:15 data kernel: D 0: DISK<N:0,hdc1(22,1),R:0,S:6> > Oct 17 22:17:15 data kernel: D 1: DISK<N:1,hdf1(33,65),R:1,S:6> > Oct 17 22:17:15 data kernel: D 2: DISK<N:2,hde(33,0),R:2,S:6> > Oct 17 22:17:15 data kernel: D 3: DISK<N:3,hde1(33,1),R:3,S:0> > Oct 17 22:17:15 data kernel: md: THIS: DISK<N:3,hde1(33,1),R:3,S:0> > Oct 17 22:17:15 data kernel: md: rdev hde: O:hde, SZ:78150656 F:0 DN:2 md: > rdev superblock: > Oct 17 22:17:15 data kernel: md: SB: (V:0.90.0) > ID:<a595074f.25e94a64.bec4b48a.e946a7b6> CT:3bdeb7e7 > Oct 17 22:17:15 data kernel: md: L5 S60051456 ND:4 RD:3 md0 LO:0 > CS:65536 > Oct 17 22:17:15 data kernel: md: UT:3daf6d69 ST:0 AD:3 WD:4 FD:0 SD:1 > CSUM:99d874ad E:0000009c > > Oct 17 22:17:15 data kernel: D 0: DISK<N:0,hdc1(22,1),R:0,S:6> > Oct 17 22:17:15 data kernel: D 1: DISK<N:1,hdf1(33,65),R:1,S:6> > Oct 17 22:17:15 data kernel: D 2: DISK<N:2,hde(33,0),R:2,S:6> > Oct 17 22:17:15 data kernel: D 3: DISK<N:3,hde1(33,1),R:3,S:0> > Oct 17 22:17:15 data kernel: md: THIS: DISK<N:2,hde(33,0),R:2,S:6> > Oct 17 22:17:15 data kernel: md: rdev hdf1: O:hdf1, SZ:60051456 F:0 DN:1 > md: rdev superblock: > Oct 17 22:17:15 data kernel: md: SB: (V:0.90.0) > ID:<a595074f.25e94a64.bec4b48a.e946a7b6> CT:3bdeb7e7 > Oct 17 22:17:15 data kernel: md: L5 S60051456 ND:4 RD:3 md0 LO:0 > CS:65536 > Oct 17 22:17:15 data kernel: md: UT:3daf6d69 ST:0 AD:3 WD:4 FD:0 SD:1 > CSUM:99d874ec E:0000009c > Oct 17 22:17:15 data kernel: D 0: DISK<N:0,hdc1(22,1),R:0,S:6> > Oct 17 22:17:15 data kernel: D 1: DISK<N:1,hdf1(33,65),R:1,S:6> > Oct 17 22:17:15 data kernel: D 2: DISK<N:2,hde(33,0),R:2,S:6> > Oct 17 22:17:15 data kernel: D 3: DISK<N:3,hde1(33,1),R:3,S:0> > Oct 17 22:17:15 data kernel: md: THIS: DISK<N:1,hdf1(33,65),R:1,S:6> > Oct 17 22:17:15 data kernel: md: rdev hdc1: O:hdc1, SZ:60051456 F:0 DN:0 > md: rdev superblock: > Oct 17 22:17:15 data kernel: md: SB: (V:0.90.0) > ID:<a595074f.25e94a64.bec4b48a.e946a7b6> CT:3bdeb7e7 > Oct 17 22:17:15 data kernel: md: L5 S60051456 ND:4 RD:3 md0 LO:0 > CS:65536 > Oct 17 22:17:15 data kernel: md: UT:3daf6d69 ST:0 AD:3 WD:4 FD:0 SD:1 > CSUM:99d8749f E:0000009c > Oct 17 22:17:15 data kernel: D 0: DISK<N:0,hdc1(22,1),R:0,S:6> > Oct 17 22:17:15 data kernel: D 1: DISK<N:1,hdf1(33,65),R:1,S:6> > Oct 17 22:17:15 data kernel: D 2: DISK<N:2,hde(33,0),R:2,S:6> > Oct 17 22:17:15 data kernel: D 3: DISK<N:3,hde1(33,1),R:3,S:0> > Oct 17 22:17:15 data kernel: md: THIS: DISK<N:0,hdc1(22,1),R:0,S:6> > Oct 17 22:17:15 data kernel: md:^I********************************** > Oct 17 22:17:15 data kernel: > Oct 17 22:17:15 data kernel: md: cannot remove active disk hde from md0 > ... > Oct 17 22:23:11 data kernel: md: interrupting MD-thread pid 130 > Oct 17 22:23:11 data kernel: md: raid5d(130) flushing signals. > Oct 17 22:23:11 data kernel: md: marking sb clean... > Oct 17 22:23:11 data kernel: md: updating md0 RAID superblock on device > Oct 17 22:23:11 data kernel: md: hde1 [events: 0000009d](write) hde1's sb > offset: 60051456 > Oct 17 22:23:11 data kernel: md: hde [events: 0000009d](write) hde's sb > offset: 78150656 > Oct 17 22:23:11 data kernel: md: hdf1 [events: 0000009d](write) hdf1's sb > offset: 60051456 > Oct 17 22:23:11 data kernel: md: hdc1 [events: 0000009d](write) hdc1's sb > offset: 60051456 > Oct 17 22:23:11 data kernel: md: md0 stopped. > Oct 17 22:23:11 data kernel: md: unbind<hde1,3> > Oct 17 22:23:11 data kernel: md: export_rdev(hde1) > Oct 17 22:23:11 data kernel: md: unbind<hde,2> > Oct 17 22:23:11 data kernel: md: export_rdev(hde) > Oct 17 22:23:11 data kernel: md: unbind<hdf1,1> > Oct 17 22:23:11 data kernel: md: export_rdev(hdf1) > Oct 17 22:23:11 data kernel: md: unbind<hdc1,0> > Oct 17 22:23:11 data kernel: md: export_rdev(hdc1) > Oct 17 22:28:12 data dhcpd: DHCPREQUEST for 192.168.2.113 from > 00:50:fc:21:77:64 via eth0 > Oct 17 22:29:48 data kernel: (read) hdc1's sb offset: 60051456 [events: > 0000009d] > Oct 17 22:29:48 data kernel: (read) hdf1's sb offset: 60051456 [events: > 0000009d] > Oct 17 22:29:48 data kernel: (read) hde's sb offset: 78150656 [events: > 0000009d] > Oct 17 22:29:49 data kernel: (read) hde1's sb offset: 60051456 [events: > 0000009d] > Oct 17 22:29:49 data kernel: md: autorun ... > Oct 17 22:29:49 data kernel: md: considering hde1 ... > Oct 17 22:29:49 data kernel: md: adding hde1 ... > Oct 17 22:29:49 data kernel: md: adding hde ... > Oct 17 22:29:49 data kernel: md: adding hdf1 ... > Oct 17 22:29:49 data kernel: md: adding hdc1 ... > Oct 17 22:29:49 data kernel: md: created md0 > Oct 17 22:29:49 data kernel: md: bind<hdc1,1> > Oct 17 22:29:49 data kernel: md: bind<hdf1,2> > Oct 17 22:29:49 data kernel: md: bind<hde,3> > Oct 17 22:29:49 data kernel: md0: WARNING: hde1 appears to be on the same > physical disk as hde. True > Oct 17 22:29:49 data kernel: protection against single-disk failure > might be compromised. > Oct 17 22:29:49 data kernel: md: bind<hde1,4> > Oct 17 22:29:49 data kernel: md: running: <hde1><hde><hdf1><hdc1> > Oct 17 22:29:49 data kernel: md: hde1's event counter: 0000009d > Oct 17 22:29:49 data kernel: md: hde's event counter: 0000009d > Oct 17 22:29:49 data kernel: md: hdf1's event counter: 0000009d > Oct 17 22:29:49 data kernel: md: hdc1's event counter: 0000009d > Oct 17 22:29:49 data kernel: md0: max total readahead window set to 512k > Oct 17 22:29:49 data kernel: md0: 2 data-disks, max readahead per > data-disk: 256k > Oct 17 22:29:49 data kernel: raid5: spare disk hde1 > Oct 17 22:29:49 data kernel: raid5: device hde operational as raid disk 2 > Oct 17 22:29:49 data kernel: raid5: device hdf1 operational as raid disk 1 > Oct 17 22:29:49 data kernel: raid5: device hdc1 operational as raid disk 0 > Oct 17 22:29:49 data kernel: raid5: allocated 3291kB for md0 > Oct 17 22:29:49 data kernel: raid5: raid level 5 set md0 active with 3 out > of 3 devices, algorithm 0 > Oct 17 22:29:49 data kernel: RAID5 conf printout: > Oct 17 22:29:49 data kernel: --- rd:3 wd:3 fd:0 > Oct 17 22:29:49 data kernel: disk 0, s:0, o:1, n:0 rd:0 us:1 dev:hdc1 > Oct 17 22:29:49 data kernel: disk 1, s:0, o:1, n:1 rd:1 us:1 dev:hdf1 > Oct 17 22:29:49 data kernel: disk 2, s:0, o:1, n:2 rd:2 us:1 dev:hde > Oct 17 22:29:49 data kernel: RAID5 conf printout: > Oct 17 22:29:49 data kernel: --- rd:3 wd:3 fd:0 > Oct 17 22:29:49 data kernel: disk 0, s:0, o:1, n:0 rd:0 us:1 dev:hdc1 > Oct 17 22:29:49 data kernel: disk 1, s:0, o:1, n:1 rd:1 us:1 dev:hdf1 > Oct 17 22:29:49 data kernel: disk 2, s:0, o:1, n:2 rd:2 us:1 dev:hde > Oct 17 22:29:49 data kernel: md: updating md0 RAID superblock on device > Oct 17 22:29:49 data kernel: md: hde1 [events: 0000009e](write) hde1's sb > offset: 60051456 > Oct 17 22:29:49 data kernel: md: hde [events: 0000009e](write) hde's sb > offset: 78150656 > Oct 17 22:29:49 data kernel: md: hdf1 [events: 0000009e](write) hdf1's sb > offset: 60051456 > Oct 17 22:29:49 data kernel: md: hdc1 [events: 0000009e](write) hdc1's sb > offset: 60051456 > Oct 17 22:29:49 data kernel: md: ... autorun DONE. > > > > > > Thanks, > > > -------------------------------------------------------------------- > Karl Hiramoto - Design Engineer > Cambridge Accusense > www.accusense.com > Tel: 978-425-2090 > Toll Free in US: 1-800-313-9271 > Fax: 978-425-4062 > > - > To unsubscribe from this list: send the line "unsubscribe linux-raid" in > the body of a message to majordomo(a)vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html

Oct. 18, 2002

duplicate entry in mdstat with RAID-5 (fwd)

by Karl Hiramoto

Can someone please help me fix this problem? I don't know if my data is safe at the moment. I have double entries for hde1 and hde in /proc/mdstat. The problem arose when i did a raidhotadd for /dev/hde then again for /dev/hde1. Doh. Is this a problem? How do i fix it? I would like to be using hde1, hdf1, hdc1 The problem arose when the 60GB /dev/hde failed. I replaced it with an 80GB drive. I am running redhat 7.2 with their kernel 2.4.9-31 # cat /proc/mdstat Personalities : [raid5] read_ahead 1024 sectors md0 : active raid5 hde1[3] hde[2] hdf1[1] hdc1[0] 120102912 blocks level 5, 64k chunk, algorithm 0 [3/3] [UUU] unused devices: <none> ---- # fdisk -l /dev/hde Disk /dev/hde: 16 heads, 63 sectors, 155061 cylinders Units = cylinders of 1008 * 512 bytes Disk /dev/hde doesn't contain a valid partition table ----- # fdisk -l /dev/hdc Disk /dev/hdc: 16 heads, 63 sectors, 119150 cylinders Units = cylinders of 1008 * 512 bytes Device Boot Start End Blocks Id System /dev/hdc1 * 1 119150 60051568+ fd Linux raid autodetect ---- # fdisk -l /dev/hdf Disk /dev/hdf: 16 heads, 63 sectors, 119150 cylinders Units = cylinders of 1008 * 512 bytes Device Boot Start End Blocks Id System /dev/hdf1 1 119150 60051568+ fd Linux raid autodetect -- /var/log/messages file when i tried to remove /dev/hde with raidhotremove Oct 17 22:17:15 data kernel: md: trying to remove hde from md0 ... Oct 17 22:17:15 data kernel: md: bug in file md.c, line 2344 Oct 17 22:17:15 data kernel: Oct 17 22:17:15 data kernel: md:^I********************************** Oct 17 22:17:15 data kernel: md:^I* <COMPLETE RAID STATE PRINTOUT> * Oct 17 22:17:15 data kernel: md:^I********************************** Oct 17 22:17:15 data kernel: md0: <hde1><hde><hdf1><hdc1> array superblock: Oct 17 22:17:15 data kernel: md: SB: (V:0.90.0) ID:<a595074f.25e94a64.bec4b48a.e946a7b6> CT:3bdeb7e7 Oct 17 22:17:15 data kernel: md: L5 S60051456 ND:4 RD:3 md0 LO:0 CS:65536 Oct 17 22:17:15 data kernel: md: UT:3daf6d69 ST:0 AD:3 WD:4 FD:0 SD:1 CSUM:99d87466 E:0000009c Oct 17 22:17:15 data kernel: D 0: DISK<N:0,hdc1(22,1),R:0,S:6> Oct 17 22:17:15 data kernel: D 1: DISK<N:1,hdf1(33,65),R:1,S:6> Oct 17 22:17:15 data kernel: D 2: DISK<N:2,hde(33,0),R:2,S:6> Oct 17 22:17:15 data kernel: D 3: DISK<N:3,hde1(33,1),R:3,S:0> Oct 17 22:17:15 data kernel: md: THIS: DISK<N:3,hde1(33,1),R:3,S:0> Oct 17 22:17:15 data kernel: md: rdev hde1: O:hde1, SZ:60051456 F:0 DN:3 md: rdev superblock: Oct 17 22:17:15 data kernel: md: SB: (V:0.90.0) ID:<a595074f.25e94a64.bec4b48a.e946a7b6> CT:3bdeb7e7 Oct 17 22:17:15 data kernel: md: L5 S60051456 ND:4 RD:3 md0 LO:0 CS:65536 Oct 17 22:17:15 data kernel: md: UT:3daf6d69 ST:0 AD:3 WD:4 FD:0 SD:1 CSUM:99d874aa E:0000009c Oct 17 22:17:15 data kernel: D 0: DISK<N:0,hdc1(22,1),R:0,S:6> Oct 17 22:17:15 data kernel: D 1: DISK<N:1,hdf1(33,65),R:1,S:6> Oct 17 22:17:15 data kernel: D 2: DISK<N:2,hde(33,0),R:2,S:6> Oct 17 22:17:15 data kernel: D 3: DISK<N:3,hde1(33,1),R:3,S:0> Oct 17 22:17:15 data kernel: md: THIS: DISK<N:3,hde1(33,1),R:3,S:0> Oct 17 22:17:15 data kernel: md: rdev hde: O:hde, SZ:78150656 F:0 DN:2 md: rdev superblock: Oct 17 22:17:15 data kernel: md: SB: (V:0.90.0) ID:<a595074f.25e94a64.bec4b48a.e946a7b6> CT:3bdeb7e7 Oct 17 22:17:15 data kernel: md: L5 S60051456 ND:4 RD:3 md0 LO:0 CS:65536 Oct 17 22:17:15 data kernel: md: UT:3daf6d69 ST:0 AD:3 WD:4 FD:0 SD:1 CSUM:99d874ad E:0000009c Oct 17 22:17:15 data kernel: D 0: DISK<N:0,hdc1(22,1),R:0,S:6> Oct 17 22:17:15 data kernel: D 1: DISK<N:1,hdf1(33,65),R:1,S:6> Oct 17 22:17:15 data kernel: D 2: DISK<N:2,hde(33,0),R:2,S:6> Oct 17 22:17:15 data kernel: D 3: DISK<N:3,hde1(33,1),R:3,S:0> Oct 17 22:17:15 data kernel: md: THIS: DISK<N:2,hde(33,0),R:2,S:6> Oct 17 22:17:15 data kernel: md: rdev hdf1: O:hdf1, SZ:60051456 F:0 DN:1 md: rdev superblock: Oct 17 22:17:15 data kernel: md: SB: (V:0.90.0) ID:<a595074f.25e94a64.bec4b48a.e946a7b6> CT:3bdeb7e7 Oct 17 22:17:15 data kernel: md: L5 S60051456 ND:4 RD:3 md0 LO:0 CS:65536 Oct 17 22:17:15 data kernel: md: UT:3daf6d69 ST:0 AD:3 WD:4 FD:0 SD:1 CSUM:99d874ec E:0000009c Oct 17 22:17:15 data kernel: D 0: DISK<N:0,hdc1(22,1),R:0,S:6> Oct 17 22:17:15 data kernel: D 1: DISK<N:1,hdf1(33,65),R:1,S:6> Oct 17 22:17:15 data kernel: D 2: DISK<N:2,hde(33,0),R:2,S:6> Oct 17 22:17:15 data kernel: D 3: DISK<N:3,hde1(33,1),R:3,S:0> Oct 17 22:17:15 data kernel: md: THIS: DISK<N:1,hdf1(33,65),R:1,S:6> Oct 17 22:17:15 data kernel: md: rdev hdc1: O:hdc1, SZ:60051456 F:0 DN:0 md: rdev superblock: Oct 17 22:17:15 data kernel: md: SB: (V:0.90.0) ID:<a595074f.25e94a64.bec4b48a.e946a7b6> CT:3bdeb7e7 Oct 17 22:17:15 data kernel: md: L5 S60051456 ND:4 RD:3 md0 LO:0 CS:65536 Oct 17 22:17:15 data kernel: md: UT:3daf6d69 ST:0 AD:3 WD:4 FD:0 SD:1 CSUM:99d8749f E:0000009c Oct 17 22:17:15 data kernel: D 0: DISK<N:0,hdc1(22,1),R:0,S:6> Oct 17 22:17:15 data kernel: D 1: DISK<N:1,hdf1(33,65),R:1,S:6> Oct 17 22:17:15 data kernel: D 2: DISK<N:2,hde(33,0),R:2,S:6> Oct 17 22:17:15 data kernel: D 3: DISK<N:3,hde1(33,1),R:3,S:0> Oct 17 22:17:15 data kernel: md: THIS: DISK<N:0,hdc1(22,1),R:0,S:6> Oct 17 22:17:15 data kernel: md:^I********************************** Oct 17 22:17:15 data kernel: Oct 17 22:17:15 data kernel: md: cannot remove active disk hde from md0 ... Oct 17 22:23:11 data kernel: md: interrupting MD-thread pid 130 Oct 17 22:23:11 data kernel: md: raid5d(130) flushing signals. Oct 17 22:23:11 data kernel: md: marking sb clean... Oct 17 22:23:11 data kernel: md: updating md0 RAID superblock on device Oct 17 22:23:11 data kernel: md: hde1 [events: 0000009d](write) hde1's sb offset: 60051456 Oct 17 22:23:11 data kernel: md: hde [events: 0000009d](write) hde's sb offset: 78150656 Oct 17 22:23:11 data kernel: md: hdf1 [events: 0000009d](write) hdf1's sb offset: 60051456 Oct 17 22:23:11 data kernel: md: hdc1 [events: 0000009d](write) hdc1's sb offset: 60051456 Oct 17 22:23:11 data kernel: md: md0 stopped. Oct 17 22:23:11 data kernel: md: unbind<hde1,3> Oct 17 22:23:11 data kernel: md: export_rdev(hde1) Oct 17 22:23:11 data kernel: md: unbind<hde,2> Oct 17 22:23:11 data kernel: md: export_rdev(hde) Oct 17 22:23:11 data kernel: md: unbind<hdf1,1> Oct 17 22:23:11 data kernel: md: export_rdev(hdf1) Oct 17 22:23:11 data kernel: md: unbind<hdc1,0> Oct 17 22:23:11 data kernel: md: export_rdev(hdc1) Oct 17 22:28:12 data dhcpd: DHCPREQUEST for 192.168.2.113 from 00:50:fc:21:77:64 via eth0 Oct 17 22:29:48 data kernel: (read) hdc1's sb offset: 60051456 [events: 0000009d] Oct 17 22:29:48 data kernel: (read) hdf1's sb offset: 60051456 [events: 0000009d] Oct 17 22:29:48 data kernel: (read) hde's sb offset: 78150656 [events: 0000009d] Oct 17 22:29:49 data kernel: (read) hde1's sb offset: 60051456 [events: 0000009d] Oct 17 22:29:49 data kernel: md: autorun ... Oct 17 22:29:49 data kernel: md: considering hde1 ... Oct 17 22:29:49 data kernel: md: adding hde1 ... Oct 17 22:29:49 data kernel: md: adding hde ... Oct 17 22:29:49 data kernel: md: adding hdf1 ... Oct 17 22:29:49 data kernel: md: adding hdc1 ... Oct 17 22:29:49 data kernel: md: created md0 Oct 17 22:29:49 data kernel: md: bind<hdc1,1> Oct 17 22:29:49 data kernel: md: bind<hdf1,2> Oct 17 22:29:49 data kernel: md: bind<hde,3> Oct 17 22:29:49 data kernel: md0: WARNING: hde1 appears to be on the same physical disk as hde. True Oct 17 22:29:49 data kernel: protection against single-disk failure might be compromised. Oct 17 22:29:49 data kernel: md: bind<hde1,4> Oct 17 22:29:49 data kernel: md: running: <hde1><hde><hdf1><hdc1> Oct 17 22:29:49 data kernel: md: hde1's event counter: 0000009d Oct 17 22:29:49 data kernel: md: hde's event counter: 0000009d Oct 17 22:29:49 data kernel: md: hdf1's event counter: 0000009d Oct 17 22:29:49 data kernel: md: hdc1's event counter: 0000009d Oct 17 22:29:49 data kernel: md0: max total readahead window set to 512k Oct 17 22:29:49 data kernel: md0: 2 data-disks, max readahead per data-disk: 256k Oct 17 22:29:49 data kernel: raid5: spare disk hde1 Oct 17 22:29:49 data kernel: raid5: device hde operational as raid disk 2 Oct 17 22:29:49 data kernel: raid5: device hdf1 operational as raid disk 1 Oct 17 22:29:49 data kernel: raid5: device hdc1 operational as raid disk 0 Oct 17 22:29:49 data kernel: raid5: allocated 3291kB for md0 Oct 17 22:29:49 data kernel: raid5: raid level 5 set md0 active with 3 out of 3 devices, algorithm 0 Oct 17 22:29:49 data kernel: RAID5 conf printout: Oct 17 22:29:49 data kernel: --- rd:3 wd:3 fd:0 Oct 17 22:29:49 data kernel: disk 0, s:0, o:1, n:0 rd:0 us:1 dev:hdc1 Oct 17 22:29:49 data kernel: disk 1, s:0, o:1, n:1 rd:1 us:1 dev:hdf1 Oct 17 22:29:49 data kernel: disk 2, s:0, o:1, n:2 rd:2 us:1 dev:hde Oct 17 22:29:49 data kernel: RAID5 conf printout: Oct 17 22:29:49 data kernel: --- rd:3 wd:3 fd:0 Oct 17 22:29:49 data kernel: disk 0, s:0, o:1, n:0 rd:0 us:1 dev:hdc1 Oct 17 22:29:49 data kernel: disk 1, s:0, o:1, n:1 rd:1 us:1 dev:hdf1 Oct 17 22:29:49 data kernel: disk 2, s:0, o:1, n:2 rd:2 us:1 dev:hde Oct 17 22:29:49 data kernel: md: updating md0 RAID superblock on device Oct 17 22:29:49 data kernel: md: hde1 [events: 0000009e](write) hde1's sb offset: 60051456 Oct 17 22:29:49 data kernel: md: hde [events: 0000009e](write) hde's sb offset: 78150656 Oct 17 22:29:49 data kernel: md: hdf1 [events: 0000009e](write) hdf1's sb offset: 60051456 Oct 17 22:29:49 data kernel: md: hdc1 [events: 0000009e](write) hdc1's sb offset: 60051456 Oct 17 22:29:49 data kernel: md: ... autorun DONE. Thanks, -------------------------------------------------------------------- Karl Hiramoto - Design Engineer Cambridge Accusense www.accusense.com Tel: 978-425-2090 Toll Free in US: 1-800-313-9271 Fax: 978-425-4062

Oct. 18, 2002

Re: [Wlug] usb 2.0 backward compatable? yes?

by Wesley Allen

The bios sets the usb controller irq to 9, which is where it also has apic. Unfortunately, the bios isn't letting that irq be shared at all and usb devices can't get an address. Reading about problems on similar laptops I found that forcing the usb irq to something else fixes it; but they don't have the solutions on their pages (though one does has a kernel patch, which I can't use). I've not gotten a response from the author's of the pages that describe the problem. So, I'm thinking that getting another controller might be a work-around...Or, how do I switch the irq? I asked this before, but still can't get a new irq to take (and the bios won't allow apic to be turned off!). Wes On Wed, 16 Oct 2002 13:08:20 -0400 "Charles R. Anderson" <cra(a)WPI.EDU> wrote: >On Wed, Oct 16, 2002 at 12:42:51PM -0400, Wesley Allen >wrote: >wallen> 1.0 and be able to use those drivers. Is this >correct? > >Yes. > >wallen> Now, if I've got problem with my stupid bios >not >wallen> assigning a correct irq on my built-in usb >controller, >wallen> will this issue pan over to a pcmcia card as >well? > >What is the "correct" IRQ? > >-- >Charles R. Anderson <cra(a)wpi.edu> / >http://angus.ind.wpi.edu/~cra/ >PGP Key ID: 49BB5886 >Fingerprint: EBA3 A106 7C93 FA07 8E15 3AC2 C367 A0F9 >49BB 5886 > >_______________________________________________ >Wlug mailing list >Wlug(a)mail.wlug.org >http://mail.wlug.org/mailman/listinfo/wlug >

Oct. 16, 2002

Re: [Wlug] usb 2.0 backward compatable? yes?

by Charles R. Anderson

On Wed, Oct 16, 2002 at 12:42:51PM -0400, Wesley Allen wrote: wallen> 1.0 and be able to use those drivers. Is this correct? Yes. wallen> Now, if I've got problem with my stupid bios not wallen> assigning a correct irq on my built-in usb controller, wallen> will this issue pan over to a pcmcia card as well? What is the "correct" IRQ? -- Charles R. Anderson <cra(a)wpi.edu> / http://angus.ind.wpi.edu/~cra/ PGP Key ID: 49BB5886 Fingerprint: EBA3 A106 7C93 FA07 8E15 3AC2 C367 A0F9 49BB 5886

Oct. 16, 2002