Re: Architecture usertags
On Tue, Mar 03, 2009 at 10:03:18PM +0200, Vasilios Karaklioumis wrote: > Wouter Verhelst wrote: >> Hi, >> >> I've often thought that it would be useful to have tags in the BTS so >> that users or maintainers could mark a bug as specific to a particular >> architecture. This way, when I have some spare time, I could go to the >> BTS, fetch a list of bugs that are specific to an architecture I care >> about, and see what I can do about them, or give some feedback if that >> would help. >> >> Using a set of usertags under my own email address on the BTS wouldn't >> really work for that, since it kindof defeats the whole purpose; I want >> to use these tags to find bugs that I care about in the first place, but >> in order for me to be able to add a usertag, I would have to know about >> the bug before I could find it. Kind of a chicken-and-egg problem. >> >> So I suggested to Don Armstrong that he add a set of >> architecture-specific regular tags; but he seemed averse to this, as the >> current informal policy of the debbugs maintainers is to require that a >> usertag is used for a particular purpose before they add a new regular >> tag; this is so that no tags get created which won't be used. I guess >> this is a worty goal. >> >> After a short discussion on IRC, we came up with another option: a set >> of publically documented usertags, the definition of which would be >> announced on debian-devel-announce and linked to from the BTS homepage, >> so that maintainers could apply them to architecture-specific bugs when >> necessary. The format, suggested by Steve Langasek, was to use the >> porters mailinglist as the user, and the architecture name as the >> usertag (e.g., 'debian-m...@lists.debian.org' as user, and 'm68k' as >> tag). >> >> Before I'll fire off an email to d-d-a announcing that, does anyone have >> any comments, objections, or suggestions to improve this proposal? >> >> Thanks, >> >> > Excellent news.This will come very handy.Thanks. +1 -- dann frazier -- To UNSUBSCRIBE, email to debian-amd64-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
[tutorial] kde 4.3 over SVN on debian sid
I have maked a tutorial about how to install kde 4.3 on debian sid over svn. Link : http://www.unixcod.org/component/option,com_fireboard/Itemid,83/func,view/catid,21/id,88/ Regards, Vina Petre Jan http://www.unixcod.org -- To UNSUBSCRIBE, email to debian-amd64-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: raid1 issue, somewhat related to recent "debian on big machines"
On Tue, Mar 03, 2009 at 10:59:50PM +0100, Francesco Pietra wrote: > I understand that the double recommendation is fine. Though, I am > pressed by answering the referees about a submitted paper as they > requested additional computation. That was going on until the host > suspended access to sda. As I find risky to go on with one disk only > (for a many days computation), could you please explain how to > reactivate the removed sda, or format it to try if it recovers? I made > some proposals in previous post. Or indicated that the best is > replacing the disk with a new one. You can simply ask mdadm to readd it back and let it rebuild, but likely the error will happen again and you will need to replace the disk. If you replace the disk (with a disk at least as big as the old one), then copy the partition table from the working drive and reread the partition table (hdparm -z /dev/sda can do that for you) and finally readd to the various raids again. You do not need to create a filesystem, since the filesystem runs on the raid, not the individual partitions, and hence you already have your filesystems made. -- Len Sorensen -- To UNSUBSCRIBE, email to debian-amd64-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: raid1 issue, somewhat related to recent "debian on big machines"
On Tue, Mar 3, 2009 at 9:52 PM, Alex Samad wrote: > On Tue, Mar 03, 2009 at 12:26:27PM +0100, Goswin von Brederlow wrote: >> Francesco Pietra writes: > [snip] > >> >> That is a lot of raids. Have you ever thought about using LVM? The >> different raid1 will mess up each others assumption about the head >> positioning of the component devices. On read the linux kernel tries >> to use the disk with the shorter seek and assumes the head is where it >> left it on the last access. But if one of the other raids used that >> disk the head will be way off. >> >> I would suggest the following scheme: > > this is what I would recommend as well I understand that the double recommendation is fine. Though, I am pressed by answering the referees about a submitted paper as they requested additional computation. That was going on until the host suspended access to sda. As I find risky to go on with one disk only (for a many days computation), could you please explain how to reactivate the removed sda, or format it to try if it recovers? I made some proposals in previous post. Or indicated that the best is replacing the disk with a new one. Thanks francesco >> >> sda1 / sdb1 : 100Mb raid1 for /boot (or 1GB for / + /boot) >> sda2 / sdb2 : rest raid1 with lvm >> >> MfG >> Goswin >> >> >> -- >> To UNSUBSCRIBE, email to debian-amd64-requ...@lists.debian.org >> with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org >> >> > > -- > "Perhaps one way will be, if we use military force, in the post-Saddam Iraq > the U.N. will definitely need to have a role. And that way it can begin to > get its legs, legs of responsibility back." > > - George W. Bush > 03/16/2003 > the Azores, Portugal > > -BEGIN PGP SIGNATURE- > Version: GnuPG v1.4.9 (GNU/Linux) > > iEYEARECAAYFAkmtmHwACgkQkZz88chpJ2OpcACgmoZ41ASQaImVnKgcXiovFAya > DKwAnA4YwO7GWaL4QHnx02mSnAQdgmSM > =SAtK > -END PGP SIGNATURE- > > -- To UNSUBSCRIBE, email to debian-amd64-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: blacklist doesn't blacklist !!
On Tue, Mar 03, 2009 at 05:44:11PM -0300, macdowell@dpf.gov.br wrote: > Hi > > > I put ssd in my blacklist but after boot there it comes again. > > m...@hp:~$ cat /etc/modprobe.d/blacklist | grep ssb > blacklist ssb > m...@hp:~$ lsmod | grep ssb > ssb43140 0 > pcmcia 38680 1 ssb > pcmcia_core41508 2 ssb,pcmcia > m...@hp:~$ > > > Why ? Perhaps it's loaded during boot in the initrd. Try rebuild your initrd with : # update-initramfs -u signature.asc Description: Digital signature
Re: raid1 issue, somewhat related to recent "debian on big machines"
On Tue, Mar 03, 2009 at 12:26:27PM +0100, Goswin von Brederlow wrote: > Francesco Pietra writes: [snip] > > That is a lot of raids. Have you ever thought about using LVM? The > different raid1 will mess up each others assumption about the head > positioning of the component devices. On read the linux kernel tries > to use the disk with the shorter seek and assumes the head is where it > left it on the last access. But if one of the other raids used that > disk the head will be way off. > > I would suggest the following scheme: this is what I would recommend as well > > sda1 / sdb1 : 100Mb raid1 for /boot (or 1GB for / + /boot) > sda2 / sdb2 : rest raid1 with lvm > > MfG > Goswin > > > -- > To UNSUBSCRIBE, email to debian-amd64-requ...@lists.debian.org > with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org > > -- "Perhaps one way will be, if we use military force, in the post-Saddam Iraq the U.N. will definitely need to have a role. And that way it can begin to get its legs, legs of responsibility back." - George W. Bush 03/16/2003 the Azores, Portugal signature.asc Description: Digital signature
blacklist doesn't blacklist !!
Hi I put ssd in my blacklist but after boot there it comes again. m...@hp:~$ cat /etc/modprobe.d/blacklist | grep ssb blacklist ssb m...@hp:~$ lsmod | grep ssb ssb43140 0 pcmcia 38680 1 ssb pcmcia_core41508 2 ssb,pcmcia m...@hp:~$ Why ? thank you for help s macdowell -- To UNSUBSCRIBE, email to debian-amd64-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Architecture usertags
Wouter Verhelst wrote: Hi, I've often thought that it would be useful to have tags in the BTS so that users or maintainers could mark a bug as specific to a particular architecture. This way, when I have some spare time, I could go to the BTS, fetch a list of bugs that are specific to an architecture I care about, and see what I can do about them, or give some feedback if that would help. Using a set of usertags under my own email address on the BTS wouldn't really work for that, since it kindof defeats the whole purpose; I want to use these tags to find bugs that I care about in the first place, but in order for me to be able to add a usertag, I would have to know about the bug before I could find it. Kind of a chicken-and-egg problem. So I suggested to Don Armstrong that he add a set of architecture-specific regular tags; but he seemed averse to this, as the current informal policy of the debbugs maintainers is to require that a usertag is used for a particular purpose before they add a new regular tag; this is so that no tags get created which won't be used. I guess this is a worty goal. After a short discussion on IRC, we came up with another option: a set of publically documented usertags, the definition of which would be announced on debian-devel-announce and linked to from the BTS homepage, so that maintainers could apply them to architecture-specific bugs when necessary. The format, suggested by Steve Langasek, was to use the porters mailinglist as the user, and the architecture name as the usertag (e.g., 'debian-m...@lists.debian.org' as user, and 'm68k' as tag). Before I'll fire off an email to d-d-a announcing that, does anyone have any comments, objections, or suggestions to improve this proposal? Thanks, Excellent news.This will come very handy.Thanks. -- To UNSUBSCRIBE, email to debian-amd64-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Architecture usertags
Hi, I've often thought that it would be useful to have tags in the BTS so that users or maintainers could mark a bug as specific to a particular architecture. This way, when I have some spare time, I could go to the BTS, fetch a list of bugs that are specific to an architecture I care about, and see what I can do about them, or give some feedback if that would help. Using a set of usertags under my own email address on the BTS wouldn't really work for that, since it kindof defeats the whole purpose; I want to use these tags to find bugs that I care about in the first place, but in order for me to be able to add a usertag, I would have to know about the bug before I could find it. Kind of a chicken-and-egg problem. So I suggested to Don Armstrong that he add a set of architecture-specific regular tags; but he seemed averse to this, as the current informal policy of the debbugs maintainers is to require that a usertag is used for a particular purpose before they add a new regular tag; this is so that no tags get created which won't be used. I guess this is a worty goal. After a short discussion on IRC, we came up with another option: a set of publically documented usertags, the definition of which would be announced on debian-devel-announce and linked to from the BTS homepage, so that maintainers could apply them to architecture-specific bugs when necessary. The format, suggested by Steve Langasek, was to use the porters mailinglist as the user, and the architecture name as the usertag (e.g., 'debian-m...@lists.debian.org' as user, and 'm68k' as tag). Before I'll fire off an email to d-d-a announcing that, does anyone have any comments, objections, or suggestions to improve this proposal? Thanks, -- Home is where you have to wash the dishes. -- #debian-devel, Freenode, 2004-09-22 signature.asc Description: Digital signature
Re: raid1 issue, somewhat related to recent "debian on big machines"
It came to mind how to check the raid. Below the key tests. I am not sure if the disk removed by the system (sda) has to be replaced with a new one or it could be forced into place, tried, reformatted, and what else should be better tried. If to be replaced, it would be the second time in a less than 2000 hours service, while there is a good UPS and the disks are mounted on Zahlman coolers with a strong fan directly on them. Unfortunately I have a badly planned huge raid. If trying to reuse sda, is it correct to command directly: # sfdisk -d /dev/sdb > /tmp/partitions # sfdisk --force /dev/sda < /tmp/partitions # mdadm -add /dev/md0 /dev/sdb1 # mdadm -add /dev/md1 /dev/sdb2 # mdadm -add /dev/md2 /dev/sdb3 # mdadm -add /dev/md3 /dev/sdb5 # mdadm -add /dev/md4 /dev/sdb6 # mdadm -add /dev/md5 /dev/sdb7 # mdadm -add /dev/md6 /dev/sdb8 or should sda be first ext3 formatted? = cat /proc/mdstat Personalities : [raid1] md6 : active raid1 sdb8[1] 102341952 blocks [2/1] [_U] md5 : active raid1 sdb7[1] 1951744 blocks [2/1] [_U] md4 : active raid1 sdb6[1] 2931712 blocks [2/1] [_U] md3 : active raid1 sdb5[1] 14651136 blocks [2/1] [_U] md1 : active (auto-read-only) raid1 sdb2[1] 6835584 blocks [2/1] [_U] md0 : active raid1 sdb1[1] 2931712 blocks [2/1] [_U] md2 : active raid1 sdb3[1] 14651200 blocks [2/1] [_U] unused devices: mdadm --detail /dev/md0 /dev/md0: Version : 00.90 Creation Time : Wed Sep 13 16:50:11 2006 Raid Level : raid1 Array Size : 2931712 (2.80 GiB 3.00 GB) Used Dev Size : 2931712 (2.80 GiB 3.00 GB) Raid Devices : 2 Total Devices : 1 Preferred Minor : 0 Persistence : Superblock is persistent Update Time : Tue Mar 3 19:05:21 2009 State : clean, degraded Active Devices : 1 Working Devices : 1 Failed Devices : 0 Spare Devices : 0 UUID : 5afe70f3:fa1dcb8c:5cc73e84:1c5db3e0 Events : 0.912 Number Major Minor RaidDevice State 0 000 removed 1 8 171 active sync /dev/sdb1 == Similar situation with all other raids == smartctl --all /dev/sda (the disk removed): smartctl version 5.38 [x86_64-unknown-linux-gnu] Copyright (C) 2002-8 Bruce Allen Home page is http://smartmontools.sourceforge.net/ === START OF INFORMATION SECTION === Model Family: Western Digital Raptor family Device Model: WDC WD1500ADFD-00NLR1 Serial Number:WD-WMAP41185084 Firmware Version: 20.07P20 User Capacity:150,039,945,216 bytes Device is:In smartctl database [for details use: -P show] ATA Version is: 7 ATA Standard is: ATA/ATAPI-7 published, ANSI INCITS 397-2005 Local Time is:Tue Mar 3 19:41:15 2009 CET SMART support is: Available - device has SMART capability. SMART support is: Enabled === START OF READ SMART DATA SECTION === SMART overall-health self-assessment test result: PASSED General SMART Values: Offline data collection status: (0x84) Offline data collection activity was suspended by an interrupting command from host. Auto Offline Data Collection: Enabled. Self-test execution status: ( 0) The previous self-test routine completed without error or no self-test has ever been run. Total time to complete Offline data collection: (4783) seconds. Offline data collection capabilities:(0x7b) SMART execute Offline immediate. Auto Offline data collection on/off support. Suspend Offline collection upon new command. Offline surface scan supported. Self-test supported. Conveyance Self-test supported. Selective Self-test supported. SMART capabilities:(0x0003) Saves SMART data before entering power-saving mode. Supports SMART auto save timer. Error logging capability:(0x01) Error logging supported. General Purpose Logging supported. Short self-test routine recommended polling time:( 2) minutes. Extended self-test routine recommended polling time:( 72) minutes. Conveyance self-test routine recommended polling time:( 5) minutes. SCT capabilities: (0x103f) SCT Status supported.
Life - Un salto nella tua filiera
To view the message, please use an HTML compatible email viewer!
Fwd: raid1 issue, somewhat related to recent "debian on big machines"
How to run selftest with raid1? smartctl -t /dev/sda (or sda1, sda2, ..) is incorrect. I don't remember what should first be done with mdadm. I would like to run the test because smartctl --all /dev/sd# report errors for only sda, as follows: SMART Error Log Version: 1 ATA Error Count: 12 (device log contains only the most recent five errors) CR = Command Register [HEX] FR = Features Register [HEX] SC = Sector Count Register [HEX] SN = Sector Number Register [HEX] CL = Cylinder Low Register [HEX] CH = Cylinder High Register [HEX] DH = Device/Head Register [HEX] DC = Device Command Register [HEX] ER = Error register [HEX] ST = Status register [HEX] Powered_Up_Time is measured from power on, and printed as DDd+hh:mm:SS.sss where DD=days, hh=hours, mm=minutes, SS=sec, and sss=millisec. It "wraps" after 49.710 days. Error 12 occurred at disk power-on lifetime: 1940 hours (80 days + 20 hours) When the command that caused the error occurred, the device was active or idle. After command completion occurred, registers were: ER ST SC SN CL CH DH -- -- -- -- -- -- -- 40 51 08 4a 9d 9b ec Error: UNC 8 sectors at LBA = 0x0c9b9d4a = 211524938 Commands leading to the command that caused the error were: CR FR SC SN CL CH DH DC Powered_Up_Time Command/Feature_Name -- -- -- -- -- -- -- -- c8 00 08 47 9d 9b 4c 00 00:52:49.600 READ DMA ec 00 08 4a 9d 9b 00 00 00:52:49.600 IDENTIFY DEVICE c8 00 08 47 9d 9b 4c 00 00:52:49.600 READ DMA ec 00 08 4a 9d 9b 00 00 00:52:49.600 IDENTIFY DEVICE c8 00 08 47 9d 9b 4c 00 00:52:49.600 READ DMA Error 11 occurred at disk power-on lifetime: 1940 hours (80 days + 20 hours) When the command that caused the error occurred, the device was active or idle. After command completion occurred, registers were: ER ST SC SN CL CH DH -- -- -- -- -- -- -- 40 51 08 4a 9d 9b ec Error: UNC 8 sectors at LBA = 0x0c9b9d4a = 211524938 Commands leading to the command that caused the error were: CR FR SC SN CL CH DH DC Powered_Up_Time Command/Feature_Name -- -- -- -- -- -- -- -- c8 00 08 47 9d 9b 4c 00 00:52:46.400 READ DMA ec 00 08 4a 9d 9b 00 00 00:52:46.400 IDENTIFY DEVICE c8 00 08 47 9d 9b 4c 00 00:52:46.400 READ DMA ec 00 08 4a 9d 9b 00 00 00:52:46.400 IDENTIFY DEVICE c8 00 08 47 9d 9b 4c 00 00:52:46.400 READ DMA Error 10 occurred at disk power-on lifetime: 1940 hours (80 days + 20 hours) When the command that caused the error occurred, the device was active or idle. After command completion occurred, registers were: ER ST SC SN CL CH DH -- -- -- -- -- -- -- 40 51 08 4a 9d 9b ec Error: UNC 8 sectors at LBA = 0x0c9b9d4a = 211524938 Commands leading to the command that caused the error were: CR FR SC SN CL CH DH DC Powered_Up_Time Command/Feature_Name -- -- -- -- -- -- -- -- c8 00 08 47 9d 9b 4c 00 00:52:42.950 READ DMA ec 00 08 4a 9d 9b 00 00 00:52:42.950 IDENTIFY DEVICE c8 00 08 47 9d 9b 4c 00 00:52:42.950 READ DMA ec 00 08 4a 9d 9b 00 00 00:52:42.950 IDENTIFY DEVICE c8 00 08 47 9d 9b 4c 00 00:52:42.950 READ DMA Error 9 occurred at disk power-on lifetime: 1940 hours (80 days + 20 hours) When the command that caused the error occurred, the device was active or idle. After command completion occurred, registers were: ER ST SC SN CL CH DH -- -- -- -- -- -- -- 40 51 08 4a 9d 9b ec Error: UNC 8 sectors at LBA = 0x0c9b9d4a = 211524938 Commands leading to the command that caused the error were: CR FR SC SN CL CH DH DC Powered_Up_Time Command/Feature_Name -- -- -- -- -- -- -- -- c8 00 08 47 9d 9b 4c 00 00:52:39.800 READ DMA ec 00 08 4a 9d 9b 00 00 00:52:39.800 IDENTIFY DEVICE c8 00 08 47 9d 9b 4c 00 00:52:39.800 READ DMA ec 00 08 4a 9d 9b 00 00 00:52:39.800 IDENTIFY DEVICE c8 00 08 47 9d 9b 4c 00 00:52:39.800 READ DMA Error 8 occurred at disk power-on lifetime: 1940 hours (80 days + 20 hours) When the command that caused the error occurred, the device was active or idle. After command completion occurred, registers were: ER ST SC SN CL CH DH -- -- -- -- -- -- -- 40 51 08 4a 9d 9b ec Error: UNC 8 sectors at LBA = 0x0c9b9d4a = 211524938 Commands leading to the command that caused the error were: CR FR SC SN CL CH DH DC Powered_Up_Time Command/Feature_Name -- -- -- -- -- -- -- -- c8 00 08 47 9d 9b 4c 00 00:52:36.600 READ DMA ec 00 08 4a 9d 9b 00 00 00:52:36.600 IDENTIFY DEVICE c8 00 08 47 9d 9b 4c 00 00:52:36.600 READ DMA c8 00 08 3f 9d 9b 4c 00 00:52:36.600 READ DMA c8 00 08 37 9d 9b 4c 00 00:52:36.600 READ DMA SMART Self-test l
Re: raid1 issue, somewhat related to recent "debian on big machines"
Francesco Pietra writes: The important bit is: > Disk failure on sda1, disabling device So one of your disks failed. The kernel marked it as such and continious on the other disk alone. This is invisible to the application (apart from the short hickup) and no data is corrupted or lost. That is why you use raid1 after all. > Personalities : [raid1] > md6 : active raid1 sda8[2](F) sdb8[1] > 102341952 blocks [2/1] [_U] > > md5 : active raid1 sda7[2](F) sdb7[1] > 1951744 blocks [2/1] [_U] > > md4 : active raid1 sda6[2](F) sdb6[1] > 2931712 blocks [2/1] [_U] > > md3 : active raid1 sda5[2](F) sdb5[1] > 14651136 blocks [2/1] [_U] > > md1 : active raid1 sda2[2](F) sdb2[1] > 6835584 blocks [2/1] [_U] > > md0 : active raid1 sda1[2](F) sdb1[1] > 2931712 blocks [2/1] [_U] > > md2 : active raid1 sda3[2](F) sdb3[1] > 14651200 blocks [2/1] [_U] That is a lot of raids. Have you ever thought about using LVM? The different raid1 will mess up each others assumption about the head positioning of the component devices. On read the linux kernel tries to use the disk with the shorter seek and assumes the head is where it left it on the last access. But if one of the other raids used that disk the head will be way off. I would suggest the following scheme: sda1 / sdb1 : 100Mb raid1 for /boot (or 1GB for / + /boot) sda2 / sdb2 : rest raid1 with lvm MfG Goswin -- To UNSUBSCRIBE, email to debian-amd64-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: raid1 issue, somewhat related to recent "debian on big machines"
On 03/03/2009 02:53 AM, Francesco Pietra wrote: lupus in fabula as a follow up of my short intervention on raid1 with my machine to the thread "Debian on big systems". System: supermicro H8QC8 m.board, two WD Raptor SATA 150GB, Debian amd64 lenny, raid1 While running an electronic molecular calculation - estimated to four days time - I noticed by chance on the screen (what is not in the out file of the calculation) that there was a disk problem. I took some scattered notes from the scree: RAID1 conf printout wd: 1 rd:2 [snip] What you are looking for should be in syslog, not your application's log. -- Ron Johnson, Jr. Jefferson LA USA The feeling of disgust at seeing a human female in a Relationship with a chimp male is Homininphobia, and you should be ashamed of yourself. -- To UNSUBSCRIBE, email to debian-amd64-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
raid1 issue, somewhat related to recent "debian on big machines"
lupus in fabula as a follow up of my short intervention on raid1 with my machine to the thread "Debian on big systems". System: supermicro H8QC8 m.board, two WD Raptor SATA 150GB, Debian amd64 lenny, raid1 While running an electronic molecular calculation - estimated to four days time - I noticed by chance on the screen (what is not in the out file of the calculation) that there was a disk problem. I took some scattered notes from the scree: RAID1 conf printout wd: 1 rd:2 disk0 wd:1 o:0 dev: sda6 disk0 wd:1 o:0 dev: sdb6 md: recovery of raid array md4 minimum guaranteed speed 1000 kB/sec/disk using max available idle I/O bandwidth but no more than 20 .. Disk failure on sda1, disabling device Operation continues on 1 devices. raid sdb1: redirecting sector 262176 to another mirror RAID1 conf printout wd:1 rd:2 .. disk1, wd:0 0:1 dev:sdb7 = Then, the electronic molecular calculation resumed - with all CPUs at work, as indicated by top - and in its output file there was no trace of the above problems. Command: lshw -class disk reported: *-cdrom description: DVD writer product: PIONEER DVD-RW DVR-111D vendor: Pioneer physical id: 0 bus info: i...@0.0 logical name: /dev/hda version: 1.02 capabilities: packet atapi cdrom removable nonmagnetic dma lba iordy pm audio cd-r cd-rw dvd dvd-r configuration: mode=udma4 status=nodisc *-disk:0 description: SCSI Disk physical id: 0 bus info: s...@0:0.0.0 logical name: /dev/sda size: 139GiB (150GB) *-disk:1 description: ATA Disk product: WDC WD1500ADFD-0 vendor: Western Digital physical id: 1 bus info: s...@1:0.0.0 logical name: /dev/sdb version: 20.0 serial: WD-WMAP41173675 size: 139GiB (150GB) capabilities: partitioned partitioned:dos configuration: ansiversion=5 signature=000b05ba The description of disk 0 was cryptic to me. As there have been RAM problems, I also run lshw -class memory all DIMMs are correctly reported. No mem problem. === Then I run: /proc/mdstat the output was: Personalities : [raid1] md6 : active raid1 sda8[2](F) sdb8[1] 102341952 blocks [2/1] [_U] md5 : active raid1 sda7[2](F) sdb7[1] 1951744 blocks [2/1] [_U] md4 : active raid1 sda6[2](F) sdb6[1] 2931712 blocks [2/1] [_U] md3 : active raid1 sda5[2](F) sdb5[1] 14651136 blocks [2/1] [_U] md1 : active raid1 sda2[2](F) sdb2[1] 6835584 blocks [2/1] [_U] md0 : active raid1 sda1[2](F) sdb1[1] 2931712 blocks [2/1] [_U] md2 : active raid1 sda3[2](F) sdb3[1] 14651200 blocks [2/1] [_U] unused devices: === I would appreciate advice. thanks francesco pietra -- To UNSUBSCRIBE, email to debian-amd64-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
