Search Results

Search found 66 results on 3 pages for 'multipath'.

Page 3/3 | < Previous Page | 1 2 3 

• Pxe net install Centos with Static IP

  - by Stu2000

  I seem to be unable to perform a kickstart installation of centos5.8 with a netinstall. It correctly gets into the text installer, but keeps sending out a request for the dhcp server and failing. I have tried to manually set the IP everywhere. Here is my pxelinux.cfg file DEFAULT menu PROMPT 0 MENU TITLE Ubuntu MAAS TIMEOUT 200 TOTALTIMEOUT 6000 ONTIMEOUT local LABEL centos5.8-net kernel /images/centos5.8-net/vmlinuz MENU LABEL centos5.8-net append initrd=/images/centos5.8-net/initrd.img ip=192.168.1.163 netmask=255.255.255.0 hostname=client101 gateway=192.168.1.1 ksdevice=eth0 dns=8.8.8.8 ks=http://192.168.1.125/cblr/svc/op/ks/profile/centos5.8-net MENU end and here is my kickstart file: # Kickstart file for a very basic Centos 5.8 system # Assigns the server ip: 192.211.48.163 # DNS 8.8.8.8, 8.8.4.4 # London TZ install url --url http://mirror.centos.org/centos-5/5.8/os/i386 lang en_US.UTF-8 keyboard us network --device=eth0 --bootproto=static --ip=192.168.1.163 --netmask=255.255.255.0 --gateway=192.168.1.1 --nameserver=8.8.8.8,8.8.4.4 --hostname=client1-server --onboot=on rootpw --iscrypted $1$Snrd2bB6$CuD/07AX2r/lHgVTPZyAz/ firewall --enabled --port=22:tcp authconfig --enableshadow --enablemd5 selinux --enforcing timezone --utc Europe/London bootloader --location=mbr --driveorder=xvda --append="console=xvc0" # The following is the partition information you requested # Note that any partitions you deleted are not expressed # here so unless you clear all partitions first, this is # not guaranteed to work part /boot --fstype ext3 --size=100 --ondisk=xvda part pv.2 --size=0 --grow --ondisk=xvda volgroup VolGroup00 --pesize=32768 pv.2 logvol swap --fstype swap --name=LogVol01 --vgname=VolGroup00 --size=528 --grow --maxsize=1056 logvol / --fstype ext3 --name=LogVol00 --vgname=VolGroup00 --size=1024 --grow %packages @base @core @dialup @editors @text-internet keyutils iscsi-initiator-utils trousers bridge-utils fipscheck device-mapper-multipath sgpio emacs Here is my dhcp file: ddns-update-style interim; allow booting; allow bootp; ignore client-updates; set vendorclass = option vendor-class-identifier; subnet 192.168.1.0 netmask 255.255.255.0 { host tower { hardware ethernet 50:E5:49:18:D5:C6; fixed-address 192.168.1.163; option routers 192.168.1.1; option domain-name-servers 8.8.8.8,8.8.4.4; option subnet-mask 255.255.255.0; filename "/pxelinux.0"; default-lease-time 21600; max-lease-time 43200; next-server 192.168.1.125; } } Is it impossible to prevent it asking for a dynamic ip before trying to install from the net? Perhaps there is an error in of my files? My dhcp server is set to ignore client-updates, and is set to only works with one mac address whilst testing.

  Read the article

• How to get an inactive RAID device working again?

  - by Jonik

  After booting, my RAID1 device (/dev/md_d0 *) sometimes goes in some funny state and I cannot mount it. * Originally I created /dev/md0 but it has somehow changed itself into /dev/md_d0. # mount /opt mount: wrong fs type, bad option, bad superblock on /dev/md_d0, missing codepage or helper program, or other error (could this be the IDE device where you in fact use ide-scsi so that sr0 or sda or so is needed?) In some cases useful info is found in syslog - try dmesg | tail or so The RAID device appears to be inactive somehow: # cat /proc/mdstat Personalities : [linear] [multipath] [raid0] [raid1] [raid6] [raid5] [raid4] [raid10] md_d0 : inactive sda4[0](S) 241095104 blocks # mdadm --detail /dev/md_d0 mdadm: md device /dev/md_d0 does not appear to be active. Question is, how to make the device active again (using mdmadm, I presume)? (Other times it's alright (active) after boot, and I can mount it manually without problems. But it still won't mount automatically even though I have it in /etc/fstab: /dev/md_d0 /opt ext4 defaults 0 0 So a bonus question: what should I do to make the RAID device automatically mount at /opt at boot time?) This is an Ubuntu 9.10 workstation. Background info about my RAID setup in this question. Edit: My /etc/mdadm/mdadm.conf looks like this. I've never touched this file, at least by hand. # by default, scan all partitions (/proc/partitions) for MD superblocks. # alternatively, specify devices to scan, using wildcards if desired. DEVICE partitions # auto-create devices with Debian standard permissions CREATE owner=root group=disk mode=0660 auto=yes # automatically tag new arrays as belonging to the local system HOMEHOST <system> # instruct the monitoring daemon where to send mail alerts MAILADDR <my mail address> # definitions of existing MD arrays # This file was auto-generated on Wed, 27 Jan 2010 17:14:36 +0200 In /proc/partitions the last entry is md_d0 at least now, after reboot, when the device happens to be active again. (I'm not sure if it would be the same when it's inactive.) Resolution: as Jimmy Hedman suggested, I took the output of mdadm --examine --scan: ARRAY /dev/md0 level=raid1 num-devices=2 UUID=de8fbd92[...] and added it in /etc/mdadm/mdadm.conf, which seems to have fixed the main problem. After changing /etc/fstab to use /dev/md0 again (instead of /dev/md_d0), the RAID device also gets automatically mounted!

  Read the article

• Availability Best Practices on Oracle VM Server for SPARC

  - by jsavit

  This is the first of a series of blog posts on configuring Oracle VM Server for SPARC (also called Logical Domains) for availability. This series will show how to how to plan for availability, improve serviceability, avoid single points of failure, and provide resiliency against hardware and software failures. Availability is a broad topic that has filled entire books, so these posts will focus on aspects specifically related to Oracle VM Server for SPARC. The goal is to improve Reliability, Availability and Serviceability (RAS): An article defining RAS can be found here. Oracle VM Server for SPARC Principles for Availability Let's state some guiding principles for availability that apply to Oracle VM Server for SPARC: Avoid Single Points Of Failure (SPOFs). Systems should be configured so a component failure does not result in a loss of application service. The general method to avoid SPOFs is to provide redundancy so service can continue without interruption if a component fails. For a critical application there may be multiple levels of redundancy so multiple failures can be tolerated. Oracle VM Server for SPARC makes it possible to configure systems that avoid SPOFs. Configure for availability at a level of resource and effort consistent with business needs. Effort and resource should be consistent with business requirements. Production has different availability requirements than test/development, so it's worth expending resources to provide higher availability. Even within the category of production there may be different levels of criticality, outage tolerances, recovery and repair time requirements. Keep in mind that a simple design may be more understandable and effective than a complex design that attempts to "do everything". Design for availability at the appropriate tier or level of the platform stack. Availability can be provided in the application, in the database, or in the virtualization, hardware and network layers they depend on - or using a combination of all of them. It may not be necessary to engineer resilient virtualization for stateless web applications applications where availability is provided by a network load balancer, or for enterprise applications like Oracle Real Application Clusters (RAC) and WebLogic that provide their own resiliency. It's (often) the same architecture whether virtual or not: For example, providing resiliency against a lost device path or failing disk media is done for the same reasons and may use the same design whether in a domain or not. It's (often) the same technique whether using domains or not: Many configuration steps are the same. For example, configuring IPMP or creating a redundant ZFS pool is pretty much the same within the guest whether you're in a guest domain or not. There are configuration steps and choices for provisioning the guest with the virtual network and disk devices, which we will discuss. Sometimes it is different using domains: There are new resources to configure. Most notable is the use of alternate service domains, which provides resiliency in case of a domain failure, and also permits improved serviceability via "rolling upgrades". This is an important differentiator between Oracle VM Server for SPARC and traditional virtual machine environments where all virtual I/O is provided by a monolithic infrastructure that itself is a SPOF. Alternate service domains are widely used to provide resiliency in production logical domains environments. Some things are done via logical domains commands, and some are done in the guest: For example, with Oracle VM Server for SPARC we provide multiple network connections to the guest, and then configure network resiliency in the guest via IP Multi Pathing (IPMP) - essentially the same as for non-virtual systems. On the other hand, we configure virtual disk availability in the virtualization layer, and the guest sees an already-resilient disk without being aware of the details. These blogs will discuss configuration details like this. Live migration is not "high availability" in the sense of "continuous availability": If the server is down, then you don't live migrate from it! (A cluster or VM restart elsewhere would be used). However, live migration can be part of the RAS (Reliability, Availability, Serviceability) picture by improving Serviceability - you can move running domains off of a box before planned service or maintenance. The blog Best Practices - Live Migration on Oracle VM Server for SPARC discusses this. Topics Here are some of the topics that will be covered: Network availability using IP Multipathing and aggregates Disk path availability using virtual disks defined with multipath groups ("mpgroup") Disk media resiliency configuring for redundant disks that can tolerate media loss Multiple service domains - this is probably the most significant item and the one most specific to Oracle VM Server for SPARC. It is very widely deployed in production environments as the means to provide network and disk availability, but it can be confusing. Subsequent articles will describe why and how to configure multiple service domains. Note, for the sake of precision: an I/O domain is any domain that has a physical I/O resource (such as a PCIe bus root complex). A service domain is a domain providing virtual device services to other domains; it is almost always an I/O domain too (so it can have something to serve). Resources Here are some important links; we'll be drawing on their content in the next several articles: Oracle VM Server for SPARC Documentation Maximizing Application Reliability and Availability with SPARC T5 Servers whitepaper by Gary Combs Maximizing Application Reliability and Availability with the SPARC M5-32 Server whitepaper by Gary Combs Summary Oracle VM Server for SPARC offers features that can be used to provide highly-available environments. This and the following blog entries will describe how to plan and deploy them.

  Read the article

• How do I stop and repair a RAID 5 array that has failed and has I/O pending?

  - by Ben Hymers

  The short version: I have a failed RAID 5 array which has a bunch of processes hung waiting on I/O operations on it; how can I recover from this? The long version: Yesterday I noticed Samba access was being very sporadic; accessing the server's shares from Windows would randomly lock up explorer completely after clicking on one or two directories. I assumed it was Windows being a pain and left it. Today the problem is the same, so I did a little digging; the first thing I noticed was that running ps aux | grep smbd gives a lot of lines like this: ben 969 0.0 0.2 96088 4128 ? D 18:21 0:00 smbd -F root 1708 0.0 0.2 93468 4748 ? Ss 18:44 0:00 smbd -F root 1711 0.0 0.0 93468 1364 ? S 18:44 0:00 smbd -F ben 3148 0.0 0.2 96052 4160 ? D Mar07 0:00 smbd -F ... There are a lot of processes stuck in the "D" state. Running ps aux | grep " D" shows up some other processes including my nightly backup script, all of which need to access the volume mounted on my RAID array at some point. After some googling, I found that it might be down to the RAID array failing, so I checked /proc/mdstat, which shows this: ben@jack:~$ cat /proc/mdstat Personalities : [linear] [multipath] [raid0] [raid1] [raid6] [raid5] [raid4] [raid10] md0 : active raid5 sdb1[3](F) sdc1[1] sdd1[2] 2930271872 blocks level 5, 64k chunk, algorithm 2 [3/2] [_UU] unused devices: <none> And running mdadm --detail /dev/md0 gives this: ben@jack:~$ sudo mdadm --detail /dev/md0 /dev/md0: Version : 00.90 Creation Time : Sat Oct 31 20:53:10 2009 Raid Level : raid5 Array Size : 2930271872 (2794.53 GiB 3000.60 GB) Used Dev Size : 1465135936 (1397.26 GiB 1500.30 GB) Raid Devices : 3 Total Devices : 3 Preferred Minor : 0 Persistence : Superblock is persistent Update Time : Mon Mar 7 03:06:35 2011 State : active, degraded Active Devices : 2 Working Devices : 2 Failed Devices : 1 Spare Devices : 0 Layout : left-symmetric Chunk Size : 64K UUID : f114711a:c770de54:c8276759:b34deaa0 Events : 0.208245 Number Major Minor RaidDevice State 3 8 17 0 faulty spare rebuilding /dev/sdb1 1 8 33 1 active sync /dev/sdc1 2 8 49 2 active sync /dev/sdd1 I believe this says that sdb1 has failed, and so the array is running with two drives out of three 'up'. Some advice I found said to check /var/log/messages for notices of failures, and sure enough there are plenty: ben@jack:~$ grep sdb /var/log/messages ... Mar 7 03:06:35 jack kernel: [4525155.384937] md/raid:md0: read error NOT corrected!! (sector 400644912 on sdb1). Mar 7 03:06:35 jack kernel: [4525155.389686] md/raid:md0: read error not correctable (sector 400644920 on sdb1). Mar 7 03:06:35 jack kernel: [4525155.389686] md/raid:md0: read error not correctable (sector 400644928 on sdb1). Mar 7 03:06:35 jack kernel: [4525155.389688] md/raid:md0: read error not correctable (sector 400644936 on sdb1). Mar 7 03:06:56 jack kernel: [4525176.231603] sd 0:0:1:0: [sdb] Unhandled sense code Mar 7 03:06:56 jack kernel: [4525176.231605] sd 0:0:1:0: [sdb] Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE Mar 7 03:06:56 jack kernel: [4525176.231608] sd 0:0:1:0: [sdb] Sense Key : Medium Error [current] [descriptor] Mar 7 03:06:56 jack kernel: [4525176.231623] sd 0:0:1:0: [sdb] Add. Sense: Unrecovered read error - auto reallocate failed Mar 7 03:06:56 jack kernel: [4525176.231627] sd 0:0:1:0: [sdb] CDB: Read(10): 28 00 17 e1 5f bf 00 01 00 00 To me it is clear that device sdb has failed, and I need to stop the array, shutdown, replace it, reboot, then repair the array, bring it back up and mount the filesystem. I cannot hot-swap a replacement drive in, and don't want to leave the array running in a degraded state. I believe I am supposed to unmount the filesystem before stopping the array, but that is failing, and that is where I'm stuck now: ben@jack:~$ sudo umount /storage umount: /storage: device is busy. (In some cases useful info about processes that use the device is found by lsof(8) or fuser(1)) It is indeed busy; there are some 30 or 40 processes waiting on I/O. What should I do? Should I kill all these processes and try again? Is that a wise move when they are 'uninterruptable'? What would happen if I tried to reboot? Please let me know what you think I should do. And please ask if you need any extra information to diagnose the problem or to help!

  Read the article

• Degraded RAID5 and no md superblock on one of remaining drive

  - by ark1214

  This is actually on a QNAP TS-509 NAS. The RAID is basically a Linux RAID. The NAS was configured with RAID 5 with 5 drives (/md0 with /dev/sd[abcde]3). At some point, /dev/sde failed and drive was replaced. While rebuilding (and not completed), the NAS rebooted itself and /dev/sdc dropped out of the array. Now the array can't start because essentially 2 drives have dropped out. I disconnected /dev/sde and hoped that /md0 can resume in degraded mode, but no luck.. Further investigation shows that /dev/sdc3 has no md superblock. The data should be good since the array was unable to assemble after /dev/sdc dropped off. All the searches I done showed how to reassemble the array assuming 1 bad drive. But I think I just need to restore the superblock on /dev/sdc3 and that should bring the array up to a degraded mode which will allow me to backup data and then proceed with rebuilding with adding /dev/sde. Any help would be greatly appreciated. mdstat does not show /dev/md0 # cat /proc/mdstat Personalities : [linear] [raid0] [raid1] [raid10] [raid6] [raid5] [raid4] [multipath] md5 : active raid1 sdd2[2](S) sdc2[3](S) sdb2[1] sda2[0] 530048 blocks [2/2] [UU] md13 : active raid1 sdd4[3] sdc4[2] sdb4[1] sda4[0] 458880 blocks [5/4] [UUUU_] bitmap: 40/57 pages [160KB], 4KB chunk md9 : active raid1 sdd1[3] sdc1[2] sdb1[1] sda1[0] 530048 blocks [5/4] [UUUU_] bitmap: 33/65 pages [132KB], 4KB chunk mdadm show /dev/md0 is still there # mdadm --examine --scan ARRAY /dev/md9 level=raid1 num-devices=5 UUID=271bf0f7:faf1f2c2:967631a4:3c0fa888 ARRAY /dev/md5 level=raid1 num-devices=2 UUID=0d75de26:0759d153:5524b8ea:86a3ee0d spares=2 ARRAY /dev/md0 level=raid5 num-devices=5 UUID=ce3e369b:4ff9ddd2:3639798a:e3889841 ARRAY /dev/md13 level=raid1 num-devices=5 UUID=7384c159:ea48a152:a1cdc8f2:c8d79a9c With /dev/sde removed, here is the mdadm examine output showing sdc3 has no md superblock # mdadm --examine /dev/sda3 /dev/sda3: Magic : a92b4efc Version : 00.90.00 UUID : ce3e369b:4ff9ddd2:3639798a:e3889841 Creation Time : Sat Dec 8 15:01:19 2012 Raid Level : raid5 Used Dev Size : 1463569600 (1395.77 GiB 1498.70 GB) Array Size : 5854278400 (5583.08 GiB 5994.78 GB) Raid Devices : 5 Total Devices : 4 Preferred Minor : 0 Update Time : Sat Dec 8 15:06:17 2012 State : active Active Devices : 4 Working Devices : 4 Failed Devices : 1 Spare Devices : 0 Checksum : d9e9ff0e - correct Events : 0.394 Layout : left-symmetric Chunk Size : 64K Number Major Minor RaidDevice State this 0 8 3 0 active sync /dev/sda3 0 0 8 3 0 active sync /dev/sda3 1 1 8 19 1 active sync /dev/sdb3 2 2 8 35 2 active sync /dev/sdc3 3 3 8 51 3 active sync /dev/sdd3 4 4 0 0 4 faulty removed [~] # mdadm --examine /dev/sdb3 /dev/sdb3: Magic : a92b4efc Version : 00.90.00 UUID : ce3e369b:4ff9ddd2:3639798a:e3889841 Creation Time : Sat Dec 8 15:01:19 2012 Raid Level : raid5 Used Dev Size : 1463569600 (1395.77 GiB 1498.70 GB) Array Size : 5854278400 (5583.08 GiB 5994.78 GB) Raid Devices : 5 Total Devices : 4 Preferred Minor : 0 Update Time : Sat Dec 8 15:06:17 2012 State : active Active Devices : 4 Working Devices : 4 Failed Devices : 1 Spare Devices : 0 Checksum : d9e9ff20 - correct Events : 0.394 Layout : left-symmetric Chunk Size : 64K Number Major Minor RaidDevice State this 1 8 19 1 active sync /dev/sdb3 0 0 8 3 0 active sync /dev/sda3 1 1 8 19 1 active sync /dev/sdb3 2 2 8 35 2 active sync /dev/sdc3 3 3 8 51 3 active sync /dev/sdd3 4 4 0 0 4 faulty removed [~] # mdadm --examine /dev/sdc3 mdadm: No md superblock detected on /dev/sdc3. [~] # mdadm --examine /dev/sdd3 /dev/sdd3: Magic : a92b4efc Version : 00.90.00 UUID : ce3e369b:4ff9ddd2:3639798a:e3889841 Creation Time : Sat Dec 8 15:01:19 2012 Raid Level : raid5 Used Dev Size : 1463569600 (1395.77 GiB 1498.70 GB) Array Size : 5854278400 (5583.08 GiB 5994.78 GB) Raid Devices : 5 Total Devices : 4 Preferred Minor : 0 Update Time : Sat Dec 8 15:06:17 2012 State : active Active Devices : 4 Working Devices : 4 Failed Devices : 1 Spare Devices : 0 Checksum : d9e9ff44 - correct Events : 0.394 Layout : left-symmetric Chunk Size : 64K Number Major Minor RaidDevice State this 3 8 51 3 active sync /dev/sdd3 0 0 8 3 0 active sync /dev/sda3 1 1 8 19 1 active sync /dev/sdb3 2 2 8 35 2 active sync /dev/sdc3 3 3 8 51 3 active sync /dev/sdd3 4 4 0 0 4 faulty removed fdisk output shows /dev/sdc3 partition is still there. [~] # fdisk -l Disk /dev/sdx: 128 MB, 128057344 bytes 8 heads, 32 sectors/track, 977 cylinders Units = cylinders of 256 * 512 = 131072 bytes Device Boot Start End Blocks Id System /dev/sdx1 1 8 1008 83 Linux /dev/sdx2 9 440 55296 83 Linux /dev/sdx3 441 872 55296 83 Linux /dev/sdx4 873 977 13440 5 Extended /dev/sdx5 873 913 5232 83 Linux /dev/sdx6 914 977 8176 83 Linux Disk /dev/sda: 1500.3 GB, 1500301910016 bytes 255 heads, 63 sectors/track, 182401 cylinders Units = cylinders of 16065 * 512 = 8225280 bytes Device Boot Start End Blocks Id System /dev/sda1 * 1 66 530113+ 83 Linux /dev/sda2 67 132 530145 82 Linux swap / Solaris /dev/sda3 133 182338 1463569695 83 Linux /dev/sda4 182339 182400 498015 83 Linux Disk /dev/sda4: 469 MB, 469893120 bytes 2 heads, 4 sectors/track, 114720 cylinders Units = cylinders of 8 * 512 = 4096 bytes Disk /dev/sda4 doesn't contain a valid partition table Disk /dev/sdb: 1500.3 GB, 1500301910016 bytes 255 heads, 63 sectors/track, 182401 cylinders Units = cylinders of 16065 * 512 = 8225280 bytes Device Boot Start End Blocks Id System /dev/sdb1 * 1 66 530113+ 83 Linux /dev/sdb2 67 132 530145 82 Linux swap / Solaris /dev/sdb3 133 182338 1463569695 83 Linux /dev/sdb4 182339 182400 498015 83 Linux Disk /dev/sdc: 1500.3 GB, 1500301910016 bytes 255 heads, 63 sectors/track, 182401 cylinders Units = cylinders of 16065 * 512 = 8225280 bytes Device Boot Start End Blocks Id System /dev/sdc1 1 66 530125 83 Linux /dev/sdc2 67 132 530142 83 Linux /dev/sdc3 133 182338 1463569693 83 Linux /dev/sdc4 182339 182400 498012 83 Linux Disk /dev/sdd: 2000.3 GB, 2000398934016 bytes 255 heads, 63 sectors/track, 243201 cylinders Units = cylinders of 16065 * 512 = 8225280 bytes Device Boot Start End Blocks Id System /dev/sdd1 1 66 530125 83 Linux /dev/sdd2 67 132 530142 83 Linux /dev/sdd3 133 243138 1951945693 83 Linux /dev/sdd4 243139 243200 498012 83 Linux Disk /dev/md9: 542 MB, 542769152 bytes 2 heads, 4 sectors/track, 132512 cylinders Units = cylinders of 8 * 512 = 4096 bytes Disk /dev/md9 doesn't contain a valid partition table Disk /dev/md5: 542 MB, 542769152 bytes 2 heads, 4 sectors/track, 132512 cylinders Units = cylinders of 8 * 512 = 4096 bytes Disk /dev/md5 doesn't contain a valid partition table

  Read the article

• Raid 1 array won't assemble after power outage. How do I fix this ext4 mirror?

  - by Forkrul Assail

  Two ext4 drives on Raid 1 with mdadm won't reassemble after the power went out for an extended period (UPS drained). After turning the machine back on, mdadm said that the array was degraded, after which it took about 2 days for a full resync, which completed without problems. On trying to remount the array I get: mount: you must specify the filesystem type cat /etc/fstab lines relevant to setup: /dev/md127 /media/mediapool ext4 defaults 0 0 dmesg | tail (on trying to mount) says: [ 1050.818782] EXT3-fs (md127): error: can't find ext3 filesystem on dev md127. [ 1050.849214] EXT4-fs (md127): VFS: Can't find ext4 filesystem [ 1050.944781] FAT-fs (md127): invalid media value (0x00) [ 1050.944782] FAT-fs (md127): Can't find a valid FAT filesystem [ 1058.272787] EXT2-fs (md127): error: can't find an ext2 filesystem on dev md127. cat /proc/mdstat says: Personalities : [raid1] [linear] [multipath] [raid0] [raid6] [raid5] [raid4] [raid10] md127 : active (auto-read-only) raid1 sdj[2] sdi[0] 2930135360 blocks super 1.2 [2/2] [UU] unused devices: <none> fsck /dev/md127 says: fsck from util-linux 2.20.1 e2fsck 1.42 (29-Nov-2011) fsck.ext2: Superblock invalid, trying backup blocks... fsck.ext2: Bad magic number in super-block while trying to open /dev/md127 The superblock could not be read or does not describe a correct ext2 filesystem. If the device is valid and it really contains an ext2 filesystem (and not swap or ufs or something else), then the superblock is corrupt, and you might try running e2fsck with an alternate superblock: e2fsck -b 8193 <device> mdadm -E /dev/sdi gives me: /dev/sdi: Magic : a92b4efc Version : 1.2 Feature Map : 0x0 Array UUID : 37ac1824:eb8a21f6:bd5afd6d:96da6394 Name : sojourn:33 Creation Time : Sat Nov 10 10:43:52 2012 Raid Level : raid1 Raid Devices : 2 Avail Dev Size : 5860271016 (2794.40 GiB 3000.46 GB) Array Size : 2930135360 (2794.39 GiB 3000.46 GB) Used Dev Size : 5860270720 (2794.39 GiB 3000.46 GB) Data Offset : 262144 sectors Super Offset : 8 sectors State : clean Device UUID : 3e6e9a4f:6c07ab3d:22d47fce:13cecfd0 Update Time : Tue Nov 13 20:34:18 2012 Checksum : f7d10db9 - correct Events : 27 Device Role : Active device 0 Array State : AA ('A' == active, '.' == missing) boot@boot ~ $ sudo mdadm -E /dev/sdj /dev/sdj: Magic : a92b4efc Version : 1.2 Feature Map : 0x0 Array UUID : 37ac1824:eb8a21f6:bd5afd6d:96da6394 Name : sojourn:33 Creation Time : Sat Nov 10 10:43:52 2012 Raid Level : raid1 Raid Devices : 2 Avail Dev Size : 5860271016 (2794.40 GiB 3000.46 GB) Array Size : 2930135360 (2794.39 GiB 3000.46 GB) Used Dev Size : 5860270720 (2794.39 GiB 3000.46 GB) Data Offset : 262144 sectors Super Offset : 8 sectors State : clean Device UUID : 7fb84af4:e9295f7b:ede61f27:bec0cb57 Update Time : Tue Nov 13 20:34:18 2012 Checksum : b9d17fef - correct Events : 27 Device Role : Active device 1 Array State : AA ('A' == active, '.' == missing) machine@user ~ dmesg | tail [ 61.785866] init: alsa-restore main process (2736) terminated with status 99 [ 68.433548] eth0: no IPv6 routers present [ 534.142511] EXT4-fs (sdi): ext4_check_descriptors: Block bitmap for group 0 not in group (block 2838187772)! [ 534.142518] EXT4-fs (sdi): group descriptors corrupted! [ 546.418780] EXT2-fs (sdi): error: couldn't mount because of unsupported optional features (240) [ 549.654127] EXT3-fs (sdi): error: couldn't mount because of unsupported optional features (240) Since this is Raid 1 it was suggested that I try and mount or fsck the drives separately. After a long fsck on one drive, it ended with this as tail: Illegal double indirect block (2298566437) in inode 39717736. CLEARED. Illegal block #4231180 (2611866932) in inode 39717736. CLEARED. Error storing directory block information (inode=39717736, block=0, num=1092368): Memory allocation failed Recreate journal? yes Creating journal (32768 blocks): Done. *** journal has been re-created - filesystem is now ext3 again *** The drive however still doesn't want to mount: dmesg | tail [ 170.674659] md: export_rdev(sdc) [ 170.675152] md: export_rdev(sdc) [ 195.275288] md: export_rdev(sdc) [ 195.275876] md: export_rdev(sdc) [ 1338.540092] CE: hpet increased min_delta_ns to 30169 nsec [26125.734105] EXT4-fs (sdc): ext4_check_descriptors: Checksum for group 0 failed (43502!=37987) [26125.734115] EXT4-fs (sdc): group descriptors corrupted! [26182.325371] EXT3-fs (sdc): error: couldn't mount because of unsupported optional features (240) [27083.316519] EXT4-fs (sdc): ext4_check_descriptors: Checksum for group 0 failed (43502!=37987) [27083.316530] EXT4-fs (sdc): group descriptors corrupted! Please help me fix this. I never in my wildest nightmares thought a complete mirror would die this badly. Am I missing something? Suggestions on fixing this? Could someone explain why it would resync after the powerout, only to seemingly nuke the drive? Thanks for reading. Any help much appreciated. I've tried everything I can think of, including booting and filesystem checking with SystemRescue and Ubuntu liveboot discs.

  Read the article

• e2fsck / resize2fs problems

  - by BlakBat

  I've got 6 drives (each 1.5T, all same model and firmware revision) that are part of a RAID5 array. The RAID5 makes a LVM volume group and a logical group. The latter contains only one ext3 partition. I've recently ran: e2fsck -f /dev/vg03/lv01 && resize2fs -M /dev/vg03/lv01 which exited without an error. Now when I try to mount /dev/vg03/lv01 I get: EXT3-fs error (device dm-0): ext3_check_descriptors: Block bitmap for group 30533 not in group (block 1000532368)! EXT3-fs: group descriptors corrupted! How do I get out of this predicament? This is all the info I can currently give you: fdisk -l /dev/sd[cdefgh] shows (correctly) that they are "Linux raid autodetect" but fdisk now shows: fdisk -l /dev/md0 Disk /dev/md0: 7501.5 GB, 7501495664640 bytes ... Disk identifier: 0x00000000 Disk /dev/md0 doesn't contain a valid partition table (instead of a LVM type partition) fdisk -l /dev/vg03/lv01 Disk /dev/vg03/lv01: 7501.5 GB, 7501491732480 bytes ... Disk identifier: 0x00000000 Disk /dev/vg03/lv01 doesn't contain a valid partition table (instead of a ext3 type partition) I've tried: e2fsck -fy /dev/vg03/lv01 e2fsck 1.41.12 (17-May-2010) e2fsck: Group descriptors look bad... trying backup blocks... Block bitmap for group 30533 is not in group. (block 1000532368) Relocate? yes Inode bitmap for group 30533 is not in group. (block 1000532369) Relocate? yes Pass 1: Checking inodes, blocks, and sizes Relocating group 30533's block bitmap to 1000524246... Error allocating 1 contiguous block(s) in block group 30533 for inode bitmap: Could not allocate block in ext2 filesystem e2fsck: aborted Extra information I can give you: cat /proc/mdstat Personalities : [linear] [multipath] [raid0] [raid1] [raid6] [raid5] [raid4] [raid10] md0 : active (auto-read-only) raid5 sdg1[0] sdh1[5] sdf1[4] sde1[3] sdc1[2] sdd1[1] 7325679360 blocks level 5, 128k chunk, algorithm 2 [6/6] [UUUUUU] bitmap: 1/175 pages [4KB], 4096KB chunk unused devices: Lastly, all smartctl tests (short and extendend) showed no errors on any of the disks. Should I try to resize2fs to grow /dev/vg03/lv01 and redo a e2fsck ? Should I cfdisk /dev/md0 and /dev/vg03/lv01 back to their real types? Thanks in advance for all and any help. 2011-09-20 UPDATE I issued the following commands and was able to remount the partition, but by viewing the size (df) of before and after, it seems that 1Tb of data have gone missing. By checking the MD5SUMS (from an old backup) of some files with the "same" files from the remounted partition, some errors have been detected. Commands issued to remount the partition were: dumpe2fs /dev/vg03/lv01 Block count: 1000491435<br /> Block size: 4096<br /> tune2fs -O ^has_journal /dev/vg03/lv01 resize2fs -p /dev/vg03/lv01 dumpe2fs /dev/vg03/lv01 Block count: 1831418880<br /> Block size: 4096<br /> mount -o ro,noatime /dev/vg03/lv01 /mnt/raid OK... but files have been damaged / gone missing.

  Read the article

• Reconstructing the disk order in RAID 6 with 7 disks

  - by rkotulla

  a little background to this question first: I am running a RAID-6 within a QNAP TS869L external RAID/NAS system. I started with 5 disks of 3 TB each back in the day, and later added another 2 disks of 3TB to the RAID. The QNAP internals handled the growing and re-syncing etc, and everything seemd to be perfectly fine. About 2 weeks ago, I had one of the disks (disk #5, disk #2 has gone bad in the mean time) fail, and somehow (I have no idea why), also disks 1 and 2 got kicked out of the array. I replaced disk #5, but the RAID didn't start working again. After some calls to QNAP technical support, they re-created the array (using mdadm --create --force --assume-clean ...), but the resulting array couldn't find a filesystem, and I was kindly referred to contact a data recovery company that I can't afford. After some digging through old log files, resetting the disk to factory default, etc, I found a few errors that were made during this re-create - I wish I still had some of the original metadata, but unfortunately i don't (I definitely learned that lesson). I'm currently at the point where I know the correct chunk-size (64K), metadata-version (1.0; factory default was 0.9, but from what I read 0.9 doesn't handle disks over 2 TB, mine are 3 TB), and I now find the ext4 filesystem that should be on the disks. Only variable left to determine is the right disk order! I started using the description found in answer #4 of "Recover RAID 5 data after created new array instead of re-using" but am a little confused on what the order should be for a proper RAID-6. RAID-5 is pretty well documented in a number of places, but RAID-6 much less so. Also, does the layout, i.e. distribution of parity and data chunks across the disks, change after the growing of the array from 5 to 7 disks, or does the re-sync re-organize them in such a way a native 7-disk RAID-6 would have been? Thanks some more mdadm output that might be helpful: mdadm version: [~] # mdadm --version mdadm - v2.6.3 - 20th August 2007 mdadm details from one of the disks in the array: [~] # mdadm --examine /dev/sda3 /dev/sda3: Magic : a92b4efc Version : 1.0 Feature Map : 0x0 Array UUID : 1c1614a5:e3be2fbb:4af01271:947fe3aa Name : 0 Creation Time : Tue Jun 10 10:27:58 2014 Raid Level : raid6 Raid Devices : 7 Used Dev Size : 5857395112 (2793.02 GiB 2998.99 GB) Array Size : 29286975360 (13965.12 GiB 14994.93 GB) Used Size : 5857395072 (2793.02 GiB 2998.99 GB) Super Offset : 5857395368 sectors State : clean Device UUID : 7c572d8f:20c12727:7e88c888:c2c357af Update Time : Tue Jun 10 13:01:06 2014 Checksum : d275c82d - correct Events : 7036 Chunk Size : 64K Array Slot : 0 (0, 1, failed, 3, failed, 5, 6) Array State : Uu_u_uu 2 failed mdadm details for the array in the current disk-order (based on my best guess reconstructed from old log-files) [~] # mdadm --detail /dev/md0 /dev/md0: Version : 01.00.03 Creation Time : Tue Jun 10 10:27:58 2014 Raid Level : raid6 Array Size : 14643487680 (13965.12 GiB 14994.93 GB) Used Dev Size : 2928697536 (2793.02 GiB 2998.99 GB) Raid Devices : 7 Total Devices : 5 Preferred Minor : 0 Persistence : Superblock is persistent Update Time : Tue Jun 10 13:01:06 2014 State : clean, degraded Active Devices : 5 Working Devices : 5 Failed Devices : 0 Spare Devices : 0 Chunk Size : 64K Name : 0 UUID : 1c1614a5:e3be2fbb:4af01271:947fe3aa Events : 7036 Number Major Minor RaidDevice State 0 8 3 0 active sync /dev/sda3 1 8 19 1 active sync /dev/sdb3 2 0 0 2 removed 3 8 51 3 active sync /dev/sdd3 4 0 0 4 removed 5 8 99 5 active sync /dev/sdg3 6 8 83 6 active sync /dev/sdf3 output from /proc/mdstat (md8, md9, and md13 are internally used RAIDs holding swap, etc; the one I'm after is md0) [~] # more /proc/mdstat Personalities : [linear] [raid0] [raid1] [raid10] [raid6] [raid5] [raid4] [multipath] md0 : active raid6 sdf3[6] sdg3[5] sdd3[3] sdb3[1] sda3[0] 14643487680 blocks super 1.0 level 6, 64k chunk, algorithm 2 [7/5] [UU_U_UU] md8 : active raid1 sdg2[2](S) sdf2[3](S) sdd2[4](S) sdc2[5](S) sdb2[6](S) sda2[1] sde2[0] 530048 blocks [2/2] [UU] md13 : active raid1 sdg4[3] sdf4[4] sde4[5] sdd4[6] sdc4[2] sdb4[1] sda4[0] 458880 blocks [8/7] [UUUUUUU_] bitmap: 21/57 pages [84KB], 4KB chunk md9 : active raid1 sdg1[6] sdf1[5] sde1[4] sdd1[3] sdc1[2] sda1[0] sdb1[1] 530048 blocks [8/7] [UUUUUUU_] bitmap: 37/65 pages [148KB], 4KB chunk unused devices: <none>

  Read the article

• linux raid 1: right after replacing and syncing one drive, the other disk fails - understanding what is going on with mdstat/mdadm

  - by devicerandom

  We have an old RAID 1 Linux server (Ubuntu Lucid 10.04), with four partitions. A few days ago /dev/sdb failed, and today we noticed /dev/sda had pre-failure ominous SMART signs (~4000 reallocated sector count). We replaced /dev/sdb this morning and rebuilt the RAID on the new drive, following this guide: http://www.howtoforge.com/replacing_hard_disks_in_a_raid1_array Everything went smooth until the very end. When it looked like it was finishing to synchronize the last partition, the other old one failed. At this point I am very unsure of the state of the system. Everything seems working and the files seem to be all accessible, just as if it synchronized everything, but I'm new to RAID and I'm worried about what is going on. The /proc/mdstat output is: Personalities : [raid1] [linear] [multipath] [raid0] [raid6] [raid5] [raid4] [raid10] md3 : active raid1 sdb4[2](S) sda4[0] 478713792 blocks [2/1] [U_] md2 : active raid1 sdb3[1] sda3[2](F) 244140992 blocks [2/1] [_U] md1 : active raid1 sdb2[1] sda2[2](F) 244140992 blocks [2/1] [_U] md0 : active raid1 sdb1[1] sda1[2](F) 9764800 blocks [2/1] [_U] unused devices: <none> The order of [_U] vs [U_]. Why aren't they consistent along all the array? Is the first U /dev/sda or /dev/sdb? (I tried looking on the web for this trivial information but I found no explicit indication) If I read correctly for md0, [_U] should be /dev/sda1 (down) and /dev/sdb1 (up). But if /dev/sda has failed, how can it be the opposite for md3 ? I understand /dev/sdb4 is now spare because probably it failed to synchronize it 100%, but why does it show /dev/sda4 as up? Shouldn't it be [__]? Or [_U] anyway? The /dev/sda drive now cannot even be accessed by SMART anymore apparently, so I wouldn't expect it to be up. What is wrong with my interpretation of the output? I attach also the outputs of mdadm --detail for the four partitions: /dev/md0: Version : 00.90 Creation Time : Fri Jan 21 18:43:07 2011 Raid Level : raid1 Array Size : 9764800 (9.31 GiB 10.00 GB) Used Dev Size : 9764800 (9.31 GiB 10.00 GB) Raid Devices : 2 Total Devices : 2 Preferred Minor : 0 Persistence : Superblock is persistent Update Time : Tue Nov 5 17:27:33 2013 State : clean, degraded Active Devices : 1 Working Devices : 1 Failed Devices : 1 Spare Devices : 0 UUID : a3b4dbbd:859bf7f2:bde36644:fcef85e2 Events : 0.7704 Number Major Minor RaidDevice State 0 0 0 0 removed 1 8 17 1 active sync /dev/sdb1 2 8 1 - faulty spare /dev/sda1 /dev/md1: Version : 00.90 Creation Time : Fri Jan 21 18:43:15 2011 Raid Level : raid1 Array Size : 244140992 (232.83 GiB 250.00 GB) Used Dev Size : 244140992 (232.83 GiB 250.00 GB) Raid Devices : 2 Total Devices : 2 Preferred Minor : 1 Persistence : Superblock is persistent Update Time : Tue Nov 5 17:39:06 2013 State : clean, degraded Active Devices : 1 Working Devices : 1 Failed Devices : 1 Spare Devices : 0 UUID : 8bcd5765:90dc93d5:cc70849c:224ced45 Events : 0.1508280 Number Major Minor RaidDevice State 0 0 0 0 removed 1 8 18 1 active sync /dev/sdb2 2 8 2 - faulty spare /dev/sda2 /dev/md2: Version : 00.90 Creation Time : Fri Jan 21 18:43:19 2011 Raid Level : raid1 Array Size : 244140992 (232.83 GiB 250.00 GB) Used Dev Size : 244140992 (232.83 GiB 250.00 GB) Raid Devices : 2 Total Devices : 2 Preferred Minor : 2 Persistence : Superblock is persistent Update Time : Tue Nov 5 17:46:44 2013 State : clean, degraded Active Devices : 1 Working Devices : 1 Failed Devices : 1 Spare Devices : 0 UUID : 2885668b:881cafed:b8275ae8:16bc7171 Events : 0.2289636 Number Major Minor RaidDevice State 0 0 0 0 removed 1 8 19 1 active sync /dev/sdb3 2 8 3 - faulty spare /dev/sda3 /dev/md3: Version : 00.90 Creation Time : Fri Jan 21 18:43:22 2011 Raid Level : raid1 Array Size : 478713792 (456.54 GiB 490.20 GB) Used Dev Size : 478713792 (456.54 GiB 490.20 GB) Raid Devices : 2 Total Devices : 2 Preferred Minor : 3 Persistence : Superblock is persistent Update Time : Tue Nov 5 17:19:20 2013 State : clean, degraded Active Devices : 1 Working Devices : 2 Failed Devices : 0 Spare Devices : 1 Number Major Minor RaidDevice State 0 8 4 0 active sync /dev/sda4 1 0 0 1 removed 2 8 20 - spare /dev/sdb4 The active sync on /dev/sda4 baffles me. I am worried because if tomorrow morning I have to replace /dev/sda, I want to be sure what should I sync with what and what is going on. I am also quite baffled by the fact /dev/sda decided to fail exactly when the raid finished resyncing. I'd like to understand what is really happening. Thanks a lot for your patience and help. Massimo

  Read the article

• Recover RAID 5 data after created new array instead of re-using

  - by Brigadieren

  Folks please help - I am a newb with a major headache at hand (perfect storm situation). I have a 3 1tb hdd on my ubuntu 11.04 configured as software raid 5. The data had been copied weekly onto another separate off the computer hard drive until that completely failed and was thrown away. A few days back we had a power outage and after rebooting my box wouldn't mount the raid. In my infinite wisdom I entered mdadm --create -f... command instead of mdadm --assemble and didn't notice the travesty that I had done until after. It started the array degraded and proceeded with building and syncing it which took ~10 hours. After I was back I saw that that the array is successfully up and running but the raid is not I mean the individual drives are partitioned (partition type f8 ) but the md0 device is not. Realizing in horror what I have done I am trying to find some solutions. I just pray that --create didn't overwrite entire content of the hard driver. Could someone PLEASE help me out with this - the data that's on the drive is very important and unique ~10 years of photos, docs, etc. Is it possible that by specifying the participating hard drives in wrong order can make mdadm overwrite them? when I do mdadm --examine --scan I get something like ARRAY /dev/md/0 metadata=1.2 UUID=f1b4084a:720b5712:6d03b9e9:43afe51b name=<hostname>:0 Interestingly enough name used to be 'raid' and not the host hame with :0 appended. Here is the 'sanitized' config entries: DEVICE /dev/sdf1 /dev/sde1 /dev/sdd1 CREATE owner=root group=disk mode=0660 auto=yes HOMEHOST <system> MAILADDR root ARRAY /dev/md0 metadata=1.2 name=tanserv:0 UUID=f1b4084a:720b5712:6d03b9e9:43afe51b Here is the output from mdstat cat /proc/mdstat Personalities : [linear] [multipath] [raid0] [raid1] [raid6] [raid5] [raid4] [raid10] md0 : active raid5 sdd1[0] sdf1[3] sde1[1] 1953517568 blocks super 1.2 level 5, 512k chunk, algorithm 2 [3/3] [UUU] unused devices: <none> fdisk shows the following: fdisk -l Disk /dev/sda: 80.0 GB, 80026361856 bytes 255 heads, 63 sectors/track, 9729 cylinders Units = cylinders of 16065 * 512 = 8225280 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disk identifier: 0x000bf62e Device Boot Start End Blocks Id System /dev/sda1 * 1 9443 75846656 83 Linux /dev/sda2 9443 9730 2301953 5 Extended /dev/sda5 9443 9730 2301952 82 Linux swap / Solaris Disk /dev/sdb: 750.2 GB, 750156374016 bytes 255 heads, 63 sectors/track, 91201 cylinders Units = cylinders of 16065 * 512 = 8225280 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disk identifier: 0x000de8dd Device Boot Start End Blocks Id System /dev/sdb1 1 91201 732572001 8e Linux LVM Disk /dev/sdc: 500.1 GB, 500107862016 bytes 255 heads, 63 sectors/track, 60801 cylinders Units = cylinders of 16065 * 512 = 8225280 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disk identifier: 0x00056a17 Device Boot Start End Blocks Id System /dev/sdc1 1 60801 488384001 8e Linux LVM Disk /dev/sdd: 1000.2 GB, 1000204886016 bytes 255 heads, 63 sectors/track, 121601 cylinders Units = cylinders of 16065 * 512 = 8225280 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disk identifier: 0x000ca948 Device Boot Start End Blocks Id System /dev/sdd1 1 121601 976760001 fd Linux raid autodetect Disk /dev/dm-0: 1250.3 GB, 1250254913536 bytes 255 heads, 63 sectors/track, 152001 cylinders Units = cylinders of 16065 * 512 = 8225280 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disk identifier: 0x00000000 Disk /dev/dm-0 doesn't contain a valid partition table Disk /dev/sde: 1000.2 GB, 1000204886016 bytes 255 heads, 63 sectors/track, 121601 cylinders Units = cylinders of 16065 * 512 = 8225280 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disk identifier: 0x93a66687 Device Boot Start End Blocks Id System /dev/sde1 1 121601 976760001 fd Linux raid autodetect Disk /dev/sdf: 1000.2 GB, 1000204886016 bytes 255 heads, 63 sectors/track, 121601 cylinders Units = cylinders of 16065 * 512 = 8225280 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disk identifier: 0xe6edc059 Device Boot Start End Blocks Id System /dev/sdf1 1 121601 976760001 fd Linux raid autodetect Disk /dev/md0: 2000.4 GB, 2000401989632 bytes 2 heads, 4 sectors/track, 488379392 cylinders Units = cylinders of 8 * 512 = 4096 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 524288 bytes / 1048576 bytes Disk identifier: 0x00000000 Disk /dev/md0 doesn't contain a valid partition table Per suggestions I did clean up the superblocks and re-created the array with --assume-clean option but with no luck at all. Is there any tool that will help me to revive at least some of the data? Can someone tell me what and how the mdadm --create does when syncs to destroy the data so I can write a tool to un-do whatever was done? After the re-creating of the raid I run fsck.ext4 /dev/md0 and here is the output root@tanserv:/etc/mdadm# fsck.ext4 /dev/md0 e2fsck 1.41.14 (22-Dec-2010) fsck.ext4: Superblock invalid, trying backup blocks... fsck.ext4: Bad magic number in super-block while trying to open /dev/md0 The superblock could not be read or does not describe a correct ext2 filesystem. If the device is valid and it really contains an ext2 filesystem (and not swap or ufs or something else), then the superblock is corrupt, and you might try running e2fsck with an alternate superblock: e2fsck -b 8193 Per Shanes' suggestion I tried root@tanserv:/home/mushegh# mkfs.ext4 -n /dev/md0 mke2fs 1.41.14 (22-Dec-2010) Filesystem label= OS type: Linux Block size=4096 (log=2) Fragment size=4096 (log=2) Stride=128 blocks, Stripe width=256 blocks 122101760 inodes, 488379392 blocks 24418969 blocks (5.00%) reserved for the super user First data block=0 Maximum filesystem blocks=0 14905 block groups 32768 blocks per group, 32768 fragments per group 8192 inodes per group Superblock backups stored on blocks: 32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632, 2654208, 4096000, 7962624, 11239424, 20480000, 23887872, 71663616, 78675968, 102400000, 214990848 and run fsck.ext4 with every backup block but all returned the following: root@tanserv:/home/mushegh# fsck.ext4 -b 214990848 /dev/md0 e2fsck 1.41.14 (22-Dec-2010) fsck.ext4: Invalid argument while trying to open /dev/md0 The superblock could not be read or does not describe a correct ext2 filesystem. If the device is valid and it really contains an ext2 filesystem (and not swap or ufs or something else), then the superblock is corrupt, and you might try running e2fsck with an alternate superblock: e2fsck -b 8193 <device> Any suggestions? Regards!

  Read the article

• Why is my mdadm raid-1 recovery so slow?

  - by dimmer

  On a system I'm running Ubuntu 10.04. My raid-1 restore started out fast but quickly became ridiculously slow (at this rate the restore will take 150 days!): dimmer@paimon:~$ cat /proc/mdstat Personalities : [linear] [multipath] [raid0] [raid1] [raid6] [raid5] [raid4] [raid10] md0 : active raid1 sdc1[2] sdb1[1] 1953513408 blocks [2/1] [_U] [====>................] recovery = 24.4% (477497344/1953513408) finish=217368.0min speed=113K/sec unused devices: <none> Eventhough I have set the kernel variables to reasonably quick values: dimmer@paimon:~$ cat /proc/sys/dev/raid/speed_limit_min 1000000 dimmer@paimon:~$ cat /proc/sys/dev/raid/speed_limit_max 100000000 I am using 2 2.0TB Western Digital Hard Disks, WDC WD20EARS-00M and WDC WD20EARS-00J. I believe they have been partitioned such that their sectors are aligned. dimmer@paimon:/sys$ sudo parted /dev/sdb GNU Parted 2.2 Using /dev/sdb Welcome to GNU Parted! Type 'help' to view a list of commands. (parted) p Model: ATA WDC WD20EARS-00M (scsi) Disk /dev/sdb: 2000GB Sector size (logical/physical): 512B/512B Partition Table: gpt Number Start End Size File system Name Flags 1 1049kB 2000GB 2000GB ext4 (parted) unit s (parted) p Number Start End Size File system Name Flags 1 2048s 3907028991s 3907026944s ext4 (parted) q dimmer@paimon:/sys$ sudo parted /dev/sdc GNU Parted 2.2 Using /dev/sdc Welcome to GNU Parted! Type 'help' to view a list of commands. (parted) p Model: ATA WDC WD20EARS-00J (scsi) Disk /dev/sdc: 2000GB Sector size (logical/physical): 512B/4096B Partition Table: gpt Number Start End Size File system Name Flags 1 1049kB 2000GB 2000GB ext4 I am beginning to think that I have a hardware problem, otherwise I can't imagine why the mdadm restore should be so slow. I have done a benchmark on /dev/sdc using Ubuntu's disk utility GUI app, and the results looked normal so I know that sdc has the capability to write faster than this. I also had the same problem on a similar WD drive that I RMAd because of bad sectors. I suppose it's possible they sent me a replacement with bad sectors too, although there are no SMART values showing them yet. Any ideas? Thanks. As requested, output of top sorted by cpu usage (notice there is ~0 cpu usage). iowait is also zero which seems strange: top - 11:35:13 up 2 days, 9:40, 3 users, load average: 2.87, 2.58, 2.30 Tasks: 142 total, 1 running, 141 sleeping, 0 stopped, 0 zombie Cpu(s): 0.0%us, 0.2%sy, 0.0%ni, 99.8%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st Mem: 3096304k total, 1482164k used, 1614140k free, 617672k buffers Swap: 1526132k total, 0k used, 1526132k free, 535416k cached PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 45 root 20 0 0 0 0 S 0 0.0 2:17.02 scsi_eh_0 1 root 20 0 2808 1752 1204 S 0 0.1 0:00.46 init 2 root 20 0 0 0 0 S 0 0.0 0:00.00 kthreadd 3 root RT 0 0 0 0 S 0 0.0 0:00.02 migration/0 4 root 20 0 0 0 0 S 0 0.0 0:00.17 ksoftirqd/0 5 root RT 0 0 0 0 S 0 0.0 0:00.00 watchdog/0 6 root RT 0 0 0 0 S 0 0.0 0:00.02 migration/1 ... dmesg errors, definitely looking like hardware: [202884.000157] ata5.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x6 frozen [202884.007015] ata5.00: failed command: FLUSH CACHE EXT [202884.013728] ata5.00: cmd ea/00:00:00:00:00/00:00:00:00:00/a0 tag 0 [202884.013730] res 40/00:00:ff:59:2e/00:00:35:00:00/e0 Emask 0x4 (timeout) [202884.033667] ata5.00: status: { DRDY } [202884.040329] ata5: hard resetting link [202889.400050] ata5: link is slow to respond, please be patient (ready=0) [202894.048087] ata5: COMRESET failed (errno=-16) [202894.054663] ata5: hard resetting link [202899.412049] ata5: link is slow to respond, please be patient (ready=0) [202904.060107] ata5: COMRESET failed (errno=-16) [202904.066646] ata5: hard resetting link [202905.840056] ata5: SATA link up 3.0 Gbps (SStatus 123 SControl 300) [202905.849178] ata5.00: configured for UDMA/133 [202905.849188] ata5: EH complete [203899.000292] ata5.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x6 frozen [203899.007096] ata5.00: failed command: IDENTIFY DEVICE [203899.013841] ata5.00: cmd ec/00:01:00:00:00/00:00:00:00:00/00 tag 0 pio 512 in [203899.013843] res 40/00:00:ff:f9:f6/00:00:38:00:00/e0 Emask 0x4 (timeout) [203899.041232] ata5.00: status: { DRDY } [203899.048133] ata5: hard resetting link [203899.816134] ata5: SATA link up 3.0 Gbps (SStatus 123 SControl 300) [203899.826062] ata5.00: configured for UDMA/133 [203899.826079] ata5: EH complete [204375.000200] ata5.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x6 frozen [204375.007421] ata5.00: failed command: IDENTIFY DEVICE [204375.014799] ata5.00: cmd ec/00:01:00:00:00/00:00:00:00:00/00 tag 0 pio 512 in [204375.014800] res 40/00:00:ff:0c:0f/00:00:39:00:00/e0 Emask 0x4 (timeout) [204375.044374] ata5.00: status: { DRDY } [204375.051842] ata5: hard resetting link [204380.408049] ata5: link is slow to respond, please be patient (ready=0) [204384.440076] ata5: SATA link up 3.0 Gbps (SStatus 123 SControl 300) [204384.449938] ata5.00: configured for UDMA/133 [204384.449955] ata5: EH complete [204395.988135] ata5.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x6 frozen [204395.988140] ata5.00: failed command: IDENTIFY DEVICE [204395.988147] ata5.00: cmd ec/00:01:00:00:00/00:00:00:00:00/00 tag 0 pio 512 in [204395.988149] res 40/00:00:ff:0c:0f/00:00:39:00:00/e0 Emask 0x4 (timeout) [204395.988151] ata5.00: status: { DRDY } [204395.988156] ata5: hard resetting link [204399.320075] ata5: SATA link up 3.0 Gbps (SStatus 123 SControl 300) [204399.330487] ata5.00: configured for UDMA/133 [204399.330503] ata5: EH complete

  Read the article

• Wireless card power management

  - by penner

  I have noticed that when my computer in plugged in, the wireless strength increases. I'm assuming this is to do with power management. Is there a way to disable Wireless Power Management? I have found a few blog posts that show hacks to disable this but what is best practice here? Should there not be an option via the power menu that lets you toggle this? EDIT -- FILES AND LOGS AS REQUESTED /var/log/kern.log Jul 11 11:45:27 CoolBreeze kernel: [ 6.528052] postgres (1308): /proc/1308/oom_adj is deprecated, please use /proc/1308/oom_score_adj instead. Jul 11 11:45:27 CoolBreeze kernel: [ 6.532080] [fglrx] Gart USWC size:1280 M. Jul 11 11:45:27 CoolBreeze kernel: [ 6.532084] [fglrx] Gart cacheable size:508 M. Jul 11 11:45:27 CoolBreeze kernel: [ 6.532091] [fglrx] Reserved FB block: Shared offset:0, size:1000000 Jul 11 11:45:27 CoolBreeze kernel: [ 6.532094] [fglrx] Reserved FB block: Unshared offset:f8fd000, size:403000 Jul 11 11:45:27 CoolBreeze kernel: [ 6.532098] [fglrx] Reserved FB block: Unshared offset:3fff4000, size:c000 Jul 11 11:45:38 CoolBreeze kernel: [ 17.423743] eth1: no IPv6 routers present Jul 11 11:46:37 CoolBreeze kernel: [ 75.836426] warning: `proftpd' uses 32-bit capabilities (legacy support in use) Jul 11 11:46:37 CoolBreeze kernel: [ 75.884215] init: plymouth-stop pre-start process (2922) terminated with status 1 Jul 11 11:54:25 CoolBreeze kernel: [ 543.679614] eth1: no IPv6 routers present dmesg [ 1.411959] ACPI: Power Button [PWRB] [ 1.412046] input: Sleep Button as /devices/LNXSYSTM:00/device:00/PNP0C0E:00/input/input1 [ 1.412054] ACPI: Sleep Button [SLPB] [ 1.412150] input: Lid Switch as /devices/LNXSYSTM:00/device:00/PNP0C0D:00/input/input2 [ 1.412765] ACPI: Lid Switch [LID0] [ 1.412866] input: Power Button as /devices/LNXSYSTM:00/LNXPWRBN:00/input/input3 [ 1.412874] ACPI: Power Button [PWRF] [ 1.412996] ACPI: Fan [FAN0] (off) [ 1.413068] ACPI: Fan [FAN1] (off) [ 1.419493] thermal LNXTHERM:00: registered as thermal_zone0 [ 1.419498] ACPI: Thermal Zone [TZ00] (27 C) [ 1.421913] thermal LNXTHERM:01: registered as thermal_zone1 [ 1.421918] ACPI: Thermal Zone [TZ01] (61 C) [ 1.421971] ACPI: Deprecated procfs I/F for battery is loaded, please retry with CONFIG_ACPI_PROCFS_POWER cleared [ 1.421986] ACPI: Battery Slot [BAT0] (battery present) [ 1.422062] ERST: Table is not found! [ 1.422067] GHES: HEST is not enabled! [ 1.422158] isapnp: Scanning for PnP cards... [ 1.422242] Serial: 8250/16550 driver, 32 ports, IRQ sharing enabled [ 1.434620] ACPI: Battery Slot [BAT0] (battery present) [ 1.736355] Freeing initrd memory: 14352k freed [ 1.777846] isapnp: No Plug & Play device found [ 1.963650] Linux agpgart interface v0.103 [ 1.967148] brd: module loaded [ 1.968866] loop: module loaded [ 1.969134] ahci 0000:00:1f.2: version 3.0 [ 1.969154] ahci 0000:00:1f.2: PCI INT B -> GSI 19 (level, low) -> IRQ 19 [ 1.969226] ahci 0000:00:1f.2: irq 45 for MSI/MSI-X [ 1.969277] ahci: SSS flag set, parallel bus scan disabled [ 1.969320] ahci 0000:00:1f.2: AHCI 0001.0300 32 slots 6 ports 3 Gbps 0x23 impl SATA mode [ 1.969329] ahci 0000:00:1f.2: flags: 64bit ncq sntf stag pm led clo pio slum part ems sxs apst [ 1.969338] ahci 0000:00:1f.2: setting latency timer to 64 [ 1.983340] scsi0 : ahci [ 1.983515] scsi1 : ahci [ 1.983670] scsi2 : ahci [ 1.983829] scsi3 : ahci [ 1.983985] scsi4 : ahci [ 1.984145] scsi5 : ahci [ 1.984270] ata1: SATA max UDMA/133 abar m2048@0xf1005000 port 0xf1005100 irq 45 [ 1.984277] ata2: SATA max UDMA/133 abar m2048@0xf1005000 port 0xf1005180 irq 45 [ 1.984282] ata3: DUMMY [ 1.984285] ata4: DUMMY [ 1.984288] ata5: DUMMY [ 1.984292] ata6: SATA max UDMA/133 abar m2048@0xf1005000 port 0xf1005380 irq 45 [ 1.985150] Fixed MDIO Bus: probed [ 1.985192] tun: Universal TUN/TAP device driver, 1.6 [ 1.985196] tun: (C) 1999-2004 Max Krasnyansky <[email protected]> [ 1.985285] PPP generic driver version 2.4.2 [ 1.985472] ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver [ 1.985507] ehci_hcd 0000:00:1a.0: PCI INT A -> GSI 16 (level, low) -> IRQ 16 [ 1.985534] ehci_hcd 0000:00:1a.0: setting latency timer to 64 [ 1.985541] ehci_hcd 0000:00:1a.0: EHCI Host Controller [ 1.985626] ehci_hcd 0000:00:1a.0: new USB bus registered, assigned bus number 1 [ 1.985666] ehci_hcd 0000:00:1a.0: debug port 2 [ 1.989663] ehci_hcd 0000:00:1a.0: cache line size of 64 is not supported [ 1.989690] ehci_hcd 0000:00:1a.0: irq 16, io mem 0xf1005800 [ 2.002183] ehci_hcd 0000:00:1a.0: USB 2.0 started, EHCI 1.00 [ 2.002447] hub 1-0:1.0: USB hub found [ 2.002455] hub 1-0:1.0: 3 ports detected [ 2.002607] ehci_hcd 0000:00:1d.0: PCI INT A -> GSI 23 (level, low) -> IRQ 23 [ 2.002633] ehci_hcd 0000:00:1d.0: setting latency timer to 64 [ 2.002639] ehci_hcd 0000:00:1d.0: EHCI Host Controller [ 2.002737] ehci_hcd 0000:00:1d.0: new USB bus registered, assigned bus number 2 [ 2.002775] ehci_hcd 0000:00:1d.0: debug port 2 [ 2.006780] ehci_hcd 0000:00:1d.0: cache line size of 64 is not supported [ 2.006806] ehci_hcd 0000:00:1d.0: irq 23, io mem 0xf1005c00 [ 2.022161] ehci_hcd 0000:00:1d.0: USB 2.0 started, EHCI 1.00 [ 2.022401] hub 2-0:1.0: USB hub found [ 2.022409] hub 2-0:1.0: 3 ports detected [ 2.022567] ohci_hcd: USB 1.1 'Open' Host Controller (OHCI) Driver [ 2.022599] uhci_hcd: USB Universal Host Controller Interface driver [ 2.022720] usbcore: registered new interface driver libusual [ 2.022813] i8042: PNP: PS/2 Controller [PNP0303:PS2K,PNP0f13:PS2M] at 0x60,0x64 irq 1,12 [ 2.035831] serio: i8042 KBD port at 0x60,0x64 irq 1 [ 2.035844] serio: i8042 AUX port at 0x60,0x64 irq 12 [ 2.036096] mousedev: PS/2 mouse device common for all mice [ 2.036710] rtc_cmos 00:07: RTC can wake from S4 [ 2.036881] rtc_cmos 00:07: rtc core: registered rtc_cmos as rtc0 [ 2.037143] rtc0: alarms up to one month, y3k, 242 bytes nvram, hpet irqs [ 2.037503] device-mapper: uevent: version 1.0.3 [ 2.037656] device-mapper: ioctl: 4.22.0-ioctl (2011-10-19) initialised: [email protected] [ 2.037725] EISA: Probing bus 0 at eisa.0 [ 2.037729] EISA: Cannot allocate resource for mainboard [ 2.037734] Cannot allocate resource for EISA slot 1 [ 2.037738] Cannot allocate resource for EISA slot 2 [ 2.037741] Cannot allocate resource for EISA slot 3 [ 2.037745] Cannot allocate resource for EISA slot 4 [ 2.037749] Cannot allocate resource for EISA slot 5 [ 2.037753] Cannot allocate resource for EISA slot 6 [ 2.037756] Cannot allocate resource for EISA slot 7 [ 2.037760] Cannot allocate resource for EISA slot 8 [ 2.037764] EISA: Detected 0 cards. [ 2.037782] cpufreq-nforce2: No nForce2 chipset. [ 2.038264] cpuidle: using governor ladder [ 2.039015] cpuidle: using governor menu [ 2.039019] EFI Variables Facility v0.08 2004-May-17 [ 2.040061] TCP cubic registered [ 2.041438] NET: Registered protocol family 10 [ 2.043814] NET: Registered protocol family 17 [ 2.043823] Registering the dns_resolver key type [ 2.044290] input: AT Translated Set 2 keyboard as /devices/platform/i8042/serio0/input/input4 [ 2.044336] Using IPI No-Shortcut mode [ 2.045620] PM: Hibernation image not present or could not be loaded. [ 2.045644] registered taskstats version 1 [ 2.073070] Magic number: 4:976:796 [ 2.073415] rtc_cmos 00:07: setting system clock to 2012-07-11 18:45:23 UTC (1342032323) [ 2.076654] BIOS EDD facility v0.16 2004-Jun-25, 0 devices found [ 2.076658] EDD information not available. [ 2.302111] ata1: SATA link up 3.0 Gbps (SStatus 123 SControl 300) [ 2.302587] ata1.00: ATA-9: M4-CT128M4SSD2, 000F, max UDMA/100 [ 2.302595] ata1.00: 250069680 sectors, multi 16: LBA48 NCQ (depth 31/32), AA [ 2.303143] ata1.00: configured for UDMA/100 [ 2.303453] scsi 0:0:0:0: Direct-Access ATA M4-CT128M4SSD2 000F PQ: 0 ANSI: 5 [ 2.303746] sd 0:0:0:0: Attached scsi generic sg0 type 0 [ 2.303920] sd 0:0:0:0: [sda] 250069680 512-byte logical blocks: (128 GB/119 GiB) [ 2.304213] sd 0:0:0:0: [sda] Write Protect is off [ 2.304225] sd 0:0:0:0: [sda] Mode Sense: 00 3a 00 00 [ 2.304471] sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA [ 2.306818] sda: sda1 sda2 < sda5 > [ 2.308780] sd 0:0:0:0: [sda] Attached SCSI disk [ 2.318162] Refined TSC clocksource calibration: 1595.999 MHz. [ 2.318169] usb 1-1: new high-speed USB device number 2 using ehci_hcd [ 2.318178] Switching to clocksource tsc [ 2.450939] hub 1-1:1.0: USB hub found [ 2.451121] hub 1-1:1.0: 6 ports detected [ 2.561786] usb 2-1: new high-speed USB device number 2 using ehci_hcd [ 2.621757] ata2: SATA link up 1.5 Gbps (SStatus 113 SControl 300) [ 2.636143] ata2.00: ATAPI: TSSTcorp DVD+/-RW TS-T633C, D800, max UDMA/100 [ 2.636152] ata2.00: applying bridge limits [ 2.649711] ata2.00: configured for UDMA/100 [ 2.653762] scsi 1:0:0:0: CD-ROM TSSTcorp DVD+-RW TS-T633C D800 PQ: 0 ANSI: 5 [ 2.661486] sr0: scsi3-mmc drive: 24x/24x writer dvd-ram cd/rw xa/form2 cdda tray [ 2.661494] cdrom: Uniform CD-ROM driver Revision: 3.20 [ 2.661890] sr 1:0:0:0: Attached scsi CD-ROM sr0 [ 2.662156] sr 1:0:0:0: Attached scsi generic sg1 type 5 [ 2.694649] hub 2-1:1.0: USB hub found [ 2.694840] hub 2-1:1.0: 8 ports detected [ 2.765823] usb 1-1.4: new high-speed USB device number 3 using ehci_hcd [ 2.981454] ata6: SATA link down (SStatus 0 SControl 300) [ 2.982597] Freeing unused kernel memory: 740k freed [ 2.983523] Write protecting the kernel text: 5816k [ 2.983808] Write protecting the kernel read-only data: 2376k [ 2.983811] NX-protecting the kernel data: 4424k [ 3.014594] udevd[127]: starting version 175 [ 3.068925] sdhci: Secure Digital Host Controller Interface driver [ 3.068932] sdhci: Copyright(c) Pierre Ossman [ 3.069714] sdhci-pci 0000:09:00.0: SDHCI controller found [1180:e822] (rev 1) [ 3.069742] sdhci-pci 0000:09:00.0: PCI INT A -> GSI 16 (level, low) -> IRQ 16 [ 3.069786] sdhci-pci 0000:09:00.0: Will use DMA mode even though HW doesn't fully claim to support it. [ 3.069798] sdhci-pci 0000:09:00.0: setting latency timer to 64 [ 3.069816] mmc0: no vmmc regulator found [ 3.069877] Registered led device: mmc0:: [ 3.070946] mmc0: SDHCI controller on PCI [0000:09:00.0] using DMA [ 3.071078] tg3.c:v3.121 (November 2, 2011) [ 3.071252] tg3 0000:0b:00.0: PCI INT A -> GSI 17 (level, low) -> IRQ 17 [ 3.071269] tg3 0000:0b:00.0: setting latency timer to 64 [ 3.071403] firewire_ohci 0000:09:00.3: PCI INT D -> GSI 19 (level, low) -> IRQ 19 [ 3.071417] firewire_ohci 0000:09:00.3: setting latency timer to 64 [ 3.078509] EXT4-fs (sda1): INFO: recovery required on readonly filesystem [ 3.078517] EXT4-fs (sda1): write access will be enabled during recovery [ 3.110417] tg3 0000:0b:00.0: eth0: Tigon3 [partno(BCM95784M) rev 5784100] (PCI Express) MAC address b8:ac:6f:71:02:a6 [ 3.110425] tg3 0000:0b:00.0: eth0: attached PHY is 5784 (10/100/1000Base-T Ethernet) (WireSpeed[1], EEE[0]) [ 3.110431] tg3 0000:0b:00.0: eth0: RXcsums[1] LinkChgREG[0] MIirq[0] ASF[0] TSOcap[1] [ 3.110436] tg3 0000:0b:00.0: eth0: dma_rwctrl[76180000] dma_mask[64-bit] [ 3.125492] firewire_ohci: Added fw-ohci device 0000:09:00.3, OHCI v1.10, 4 IR + 4 IT contexts, quirks 0x11 [ 3.390124] EXT4-fs (sda1): orphan cleanup on readonly fs [ 3.390135] EXT4-fs (sda1): ext4_orphan_cleanup: deleting unreferenced inode 7078710 [ 3.390232] EXT4-fs (sda1): ext4_orphan_cleanup: deleting unreferenced inode 2363071 [ 3.390327] EXT4-fs (sda1): ext4_orphan_cleanup: deleting unreferenced inode 7078711 [ 3.390350] EXT4-fs (sda1): ext4_orphan_cleanup: deleting unreferenced inode 7078709 [ 3.390367] EXT4-fs (sda1): ext4_orphan_cleanup: deleting unreferenced inode 7078708 [ 3.390384] EXT4-fs (sda1): ext4_orphan_cleanup: deleting unreferenced inode 7078707 [ 3.390401] EXT4-fs (sda1): ext4_orphan_cleanup: deleting unreferenced inode 7078706 [ 3.390417] EXT4-fs (sda1): ext4_orphan_cleanup: deleting unreferenced inode 7078705 [ 3.390435] EXT4-fs (sda1): ext4_orphan_cleanup: deleting unreferenced inode 7078551 [ 3.390452] EXT4-fs (sda1): ext4_orphan_cleanup: deleting unreferenced inode 7078523 [ 3.390470] EXT4-fs (sda1): ext4_orphan_cleanup: deleting unreferenced inode 7078520 [ 3.390487] EXT4-fs (sda1): ext4_orphan_cleanup: deleting unreferenced inode 7077901 [ 3.390551] EXT4-fs (sda1): ext4_orphan_cleanup: deleting unreferenced inode 4063272 [ 3.390562] EXT4-fs (sda1): ext4_orphan_cleanup: deleting unreferenced inode 4063266 [ 3.390572] EXT4-fs (sda1): ext4_orphan_cleanup: deleting unreferenced inode 4063261 [ 3.390582] EXT4-fs (sda1): ext4_orphan_cleanup: deleting unreferenced inode 4063256 [ 3.390592] EXT4-fs (sda1): ext4_orphan_cleanup: deleting unreferenced inode 4063255 [ 3.390602] EXT4-fs (sda1): ext4_orphan_cleanup: deleting unreferenced inode 2363072 [ 3.390620] EXT4-fs (sda1): ext4_orphan_cleanup: deleting unreferenced inode 2360050 [ 3.390698] EXT4-fs (sda1): ext4_orphan_cleanup: deleting unreferenced inode 5250064 [ 3.390710] EXT4-fs (sda1): ext4_orphan_cleanup: deleting unreferenced inode 2365394 [ 3.390728] EXT4-fs (sda1): ext4_orphan_cleanup: deleting unreferenced inode 2365390 [ 3.390745] EXT4-fs (sda1): 22 orphan inodes deleted [ 3.390748] EXT4-fs (sda1): recovery complete [ 3.397636] EXT4-fs (sda1): mounted filesystem with ordered data mode. Opts: (null) [ 3.624910] firewire_core: created device fw0: GUID 464fc000110e2661, S400 [ 3.927467] ADDRCONF(NETDEV_UP): eth0: link is not ready [ 3.929965] udevd[400]: starting version 175 [ 3.933581] Adding 6278140k swap on /dev/sda5. Priority:-1 extents:1 across:6278140k SS [ 3.945183] lp: driver loaded but no devices found [ 3.999389] wmi: Mapper loaded [ 4.016696] ite_cir: Auto-detected model: ITE8708 CIR transceiver [ 4.016702] ite_cir: Using model: ITE8708 CIR transceiver [ 4.016706] ite_cir: TX-capable: 1 [ 4.016710] ite_cir: Sample period (ns): 8680 [ 4.016713] ite_cir: TX carrier frequency (Hz): 38000 [ 4.016716] ite_cir: TX duty cycle (%): 33 [ 4.016719] ite_cir: RX low carrier frequency (Hz): 0 [ 4.016722] ite_cir: RX high carrier frequency (Hz): 0 [ 4.025684] fglrx: module license 'Proprietary. (C) 2002 - ATI Technologies, Starnberg, GERMANY' taints kernel. [ 4.025691] Disabling lock debugging due to kernel taint [ 4.027410] IR NEC protocol handler initialized [ 4.030250] lib80211: common routines for IEEE802.11 drivers [ 4.030257] lib80211_crypt: registered algorithm 'NULL' [ 4.036024] IR RC5(x) protocol handler initialized [ 4.036092] snd_hda_intel 0000:00:1b.0: PCI INT A -> GSI 22 (level, low) -> IRQ 22 [ 4.036188] snd_hda_intel 0000:00:1b.0: irq 46 for MSI/MSI-X [ 4.036307] snd_hda_intel 0000:00:1b.0: setting latency timer to 64 [ 4.036361] [Firmware Bug]: ACPI: No _BQC method, cannot determine initial brightness [ 4.039006] acpi device:03: registered as cooling_device10 [ 4.039164] input: Video Bus as /devices/LNXSYSTM:00/device:00/PNP0A08:00/device:01/LNXVIDEO:00/input/input5 [ 4.039261] ACPI: Video Device [M86] (multi-head: yes rom: no post: no) [ 4.049753] EXT4-fs (sda1): re-mounted. Opts: errors=remount-ro [ 4.050201] wl 0000:05:00.0: PCI INT A -> GSI 17 (level, low) -> IRQ 17 [ 4.050215] wl 0000:05:00.0: setting latency timer to 64 [ 4.052252] Registered IR keymap rc-rc6-mce [ 4.052432] input: ITE8708 CIR transceiver as /devices/virtual/rc/rc0/input6 [ 4.054614] IR RC6 protocol handler initialized [ 4.054787] rc0: ITE8708 CIR transceiver as /devices/virtual/rc/rc0 [ 4.054839] ite_cir: driver has been successfully loaded [ 4.057338] IR JVC protocol handler initialized [ 4.061553] IR Sony protocol handler initialized [ 4.066578] input: MCE IR Keyboard/Mouse (ite-cir) as /devices/virtual/input/input7 [ 4.066724] IR MCE Keyboard/mouse protocol handler initialized [ 4.072580] lirc_dev: IR Remote Control driver registered, major 250 [ 4.073280] rc rc0: lirc_dev: driver ir-lirc-codec (ite-cir) registered at minor = 0 [ 4.073286] IR LIRC bridge handler initialized [ 4.077849] Linux video capture interface: v2.00 [ 4.079402] uvcvideo: Found UVC 1.00 device Laptop_Integrated_Webcam_2M (0c45:640f) [ 4.085492] EDAC MC: Ver: 2.1.0 [ 4.087138] lib80211_crypt: registered algorithm 'TKIP' [ 4.091027] input: HDA Intel Mic as /devices/pci0000:00/0000:00:1b.0/sound/card0/input8 [ 4.091733] snd_hda_intel 0000:02:00.1: PCI INT B -> GSI 17 (level, low) -> IRQ 17 [ 4.091826] snd_hda_intel 0000:02:00.1: irq 47 for MSI/MSI-X [ 4.091861] snd_hda_intel 0000:02:00.1: setting latency timer to 64 [ 4.093115] EDAC i7core: Device not found: dev 00.0 PCI ID 8086:2c50 [ 4.112448] HDMI status: Codec=0 Pin=3 Presence_Detect=0 ELD_Valid=0 [ 4.112612] input: HD-Audio Generic HDMI/DP,pcm=3 as /devices/pci0000:00/0000:00:03.0/0000:02:00.1/sound/card1/input9 [ 4.113311] type=1400 audit(1342032325.540:2): apparmor="STATUS" operation="profile_load" name="/sbin/dhclient" pid=658 comm="apparmor_parser" [ 4.114501] type=1400 audit(1342032325.540:3): apparmor="STATUS" operation="profile_load" name="/usr/lib/NetworkManager/nm-dhcp-client.action" pid=658 comm="apparmor_parser" [ 4.115253] type=1400 audit(1342032325.540:4): apparmor="STATUS" operation="profile_load" name="/usr/lib/connman/scripts/dhclient-script" pid=658 comm="apparmor_parser" [ 4.121870] input: Laptop_Integrated_Webcam_2M as /devices/pci0000:00/0000:00:1a.0/usb1/1-1/1-1.4/1-1.4:1.0/input/input10 [ 4.122096] usbcore: registered new interface driver uvcvideo [ 4.122100] USB Video Class driver (1.1.1) [ 4.128729] [fglrx] Maximum main memory to use for locked dma buffers: 5840 MBytes. [ 4.129678] [fglrx] vendor: 1002 device: 68c0 count: 1 [ 4.131991] [fglrx] ioport: bar 4, base 0x2000, size: 0x100 [ 4.132015] pci 0000:02:00.0: PCI INT A -> GSI 16 (level, low) -> IRQ 16 [ 4.132024] pci 0000:02:00.0: setting latency timer to 64 [ 4.133712] [fglrx] Kernel PAT support is enabled [ 4.133747] [fglrx] module loaded - fglrx 8.96.4 [Mar 12 2012] with 1 minors [ 4.162666] eth1: Broadcom BCM4727 802.11 Hybrid Wireless Controller 5.100.82.38 [ 4.184133] device-mapper: multipath: version 1.3.0 loaded [ 4.196660] dcdbas dcdbas: Dell Systems Management Base Driver (version 5.6.0-3.2) [ 4.279897] input: Dell WMI hotkeys as /devices/virtual/input/input11 [ 4.292402] Bluetooth: Core ver 2.16 [ 4.292449] NET: Registered protocol family 31 [ 4.292454] Bluetooth: HCI device and connection manager initialized [ 4.292459] Bluetooth: HCI socket layer initialized [ 4.292463] Bluetooth: L2CAP socket layer initialized [ 4.292473] Bluetooth: SCO socket layer initialized [ 4.296333] Bluetooth: RFCOMM TTY layer initialized [ 4.296342] Bluetooth: RFCOMM socket layer initialized [ 4.296345] Bluetooth: RFCOMM ver 1.11 [ 4.313586] ppdev: user-space parallel port driver [ 4.316619] Bluetooth: BNEP (Ethernet Emulation) ver 1.3 [ 4.316625] Bluetooth: BNEP filters: protocol multicast [ 4.383980] type=1400 audit(1342032325.812:5): apparmor="STATUS" operation="profile_load" name="/usr/lib/cups/backend/cups-pdf" pid=938 comm="apparmor_parser" [ 4.385173] type=1400 audit(1342032325.812:6): apparmor="STATUS" operation="profile_load" name="/usr/sbin/cupsd" pid=938 comm="apparmor_parser" [ 4.425757] init: failsafe main process (898) killed by TERM signal [ 4.477052] type=1400 audit(1342032325.904:7): apparmor="STATUS" operation="profile_replace" name="/sbin/dhclient" pid=1011 comm="apparmor_parser" [ 4.477592] type=1400 audit(1342032325.904:8): apparmor="STATUS" operation="profile_load" name="/usr/lib/lightdm/lightdm/lightdm-guest-session-wrapper" pid=1010 comm="apparmor_parser" [ 4.478099] type=1400 audit(1342032325.904:9): apparmor="STATUS" operation="profile_load" name="/usr/sbin/tcpdump" pid=1017 comm="apparmor_parser" [ 4.479233] type=1400 audit(1342032325.904:10): apparmor="STATUS" operation="profile_load" name="/usr/lib/telepathy/mission-control-5" pid=1014 comm="apparmor_parser" [ 4.510060] vesafb: mode is 1152x864x32, linelength=4608, pages=0 [ 4.510065] vesafb: scrolling: redraw [ 4.510071] vesafb: Truecolor: size=0:8:8:8, shift=0:16:8:0 [ 4.510084] mtrr: no more MTRRs available [ 4.513081] vesafb: framebuffer at 0xd0000000, mapped to 0xf9400000, using 3904k, total 3904k [ 4.515203] Console: switching to colour frame buffer device 144x54 [ 4.515278] fb0: VESA VGA frame buffer device [ 4.590743] tg3 0000:0b:00.0: irq 48 for MSI/MSI-X [ 4.702009] ADDRCONF(NETDEV_UP): eth0: link is not ready [ 4.704409] ADDRCONF(NETDEV_UP): eth0: link is not ready [ 4.978379] psmouse serio1: synaptics: Touchpad model: 1, fw: 7.2, id: 0x1c0b1, caps: 0xd04733/0xa40000/0xa0000 [ 5.030104] input: SynPS/2 Synaptics TouchPad as /devices/platform/i8042/serio1/input/input12 [ 5.045782] kvm: VM_EXIT_LOAD_IA32_PERF_GLOBAL_CTRL does not work properly. Using workaround [ 5.519573] [fglrx] ATIF platform detected with notification ID: 0x81 [ 6.391466] fglrx_pci 0000:02:00.0: irq 49 for MSI/MSI-X [ 6.393137] [fglrx] Firegl kernel thread PID: 1305 [ 6.393306] [fglrx] Firegl kernel thread PID: 1306 [ 6.393472] [fglrx] Firegl kernel thread PID: 1307 [ 6.393726] [fglrx] IRQ 49 Enabled [ 6.528052] postgres (1308): /proc/1308/oom_adj is deprecated, please use /proc/1308/oom_score_adj instead. [ 6.532080] [fglrx] Gart USWC size:1280 M. [ 6.532084] [fglrx] Gart cacheable size:508 M. [ 6.532091] [fglrx] Reserved FB block: Shared offset:0, size:1000000 [ 6.532094] [fglrx] Reserved FB block: Unshared offset:f8fd000, size:403000 [ 6.532098] [fglrx] Reserved FB block: Unshared offset:3fff4000, size:c000 [ 17.423743] eth1: no IPv6 routers present [ 75.836426] warning: `proftpd' uses 32-bit capabilities (legacy support in use) [ 75.884215] init: plymouth-stop pre-start process (2922) terminated with status 1 [ 543.679614] eth1: no IPv6 routers present lsmod Module Size Used by kvm_intel 127560 0 kvm 359456 1 kvm_intel joydev 17393 0 vesafb 13516 1 parport_pc 32114 0 bnep 17830 2 ppdev 12849 0 rfcomm 38139 0 bluetooth 158438 10 bnep,rfcomm dell_wmi 12601 0 sparse_keymap 13658 1 dell_wmi binfmt_misc 17292 1 dell_laptop 17767 0 dcdbas 14098 1 dell_laptop dm_multipath 22710 0 fglrx 2909855 143 snd_hda_codec_hdmi 31775 1 psmouse 72919 0 serio_raw 13027 0 i7core_edac 23382 0 lib80211_crypt_tkip 17275 0 edac_core 46858 1 i7core_edac uvcvideo 67203 0 snd_hda_codec_idt 60251 1 videodev 86588 1 uvcvideo ir_lirc_codec 12739 0 lirc_dev 18700 1 ir_lirc_codec ir_mce_kbd_decoder 12681 0 snd_seq_midi 13132 0 ir_sony_decoder 12462 0 ir_jvc_decoder 12459 0 snd_rawmidi 25424 1 snd_seq_midi ir_rc6_decoder 12459 0 wl 2646601 0 snd_seq_midi_event 14475 1 snd_seq_midi snd_seq 51567 2 snd_seq_midi,snd_seq_midi_event ir_rc5_decoder 12459 0 video 19068 0 snd_hda_intel 32765 5 snd_seq_device 14172 3 snd_seq_midi,snd_rawmidi,snd_seq snd_hda_codec 109562 3 snd_hda_codec_hdmi,snd_hda_codec_idt,snd_hda_intel rc_rc6_mce 12454 0 lib80211 14040 2 lib80211_crypt_tkip,wl snd_hwdep 13276 1 snd_hda_codec ir_nec_decoder 12459 0 snd_pcm 80845 3 snd_hda_codec_hdmi,snd_hda_intel,snd_hda_codec ite_cir 24743 0 rc_core 21263 10 ir_lirc_codec,ir_mce_kbd_decoder,ir_sony_decoder,ir_jvc_decoder,ir_rc6_decoder,ir_rc5_decoder,rc_rc6_mce,ir_nec_decoder,ite_cir snd_timer 28931 2 snd_seq,snd_pcm wmi 18744 1 dell_wmi snd 62064 20 snd_hda_codec_hdmi,snd_hda_codec_idt,snd_rawmidi,snd_seq,snd_seq_device,snd_hda_intel,snd_hda_codec,snd_hwdep,snd_pcm,snd_timer mac_hid 13077 0 soundcore 14635 1 snd snd_page_alloc 14108 2 snd_hda_intel,snd_pcm coretemp 13269 0 lp 17455 0 parport 40930 3 parport_pc,ppdev,lp tg3 141369 0 firewire_ohci 40172 0 sdhci_pci 18324 0 firewire_core 56906 1 firewire_ohci sdhci 28241 1 sdhci_pci crc_itu_t 12627 1 firewire_core lshw *-network description: Wireless interface product: BCM4313 802.11b/g/n Wireless LAN Controller vendor: Broadcom Corporation physical id: 0 bus info: pci@0000:05:00.0 logical name: eth1 version: 01 serial: 70:f1:a1:a9:54:31 width: 64 bits clock: 33MHz capabilities: pm msi pciexpress bus_master cap_list ethernet physical wireless configuration: broadcast=yes driver=wl0 driverversion=5.100.82.38 ip=192.168.0.117 latency=0 multicast=yes wireless=IEEE 802.11 resources: irq:17 memory:f0900000-f0903fff *-network description: Ethernet interface product: NetLink BCM5784M Gigabit Ethernet PCIe vendor: Broadcom Corporation physical id: 0 bus info: pci@0000:0b:00.0 logical name: eth0 version: 10 serial: b8:ac:6f:71:02:a6 capacity: 1Gbit/s width: 64 bits clock: 33MHz capabilities: pm vpd msi pciexpress bus_master cap_list ethernet physical tp 10bt 10bt-fd 100bt 100bt-fd 1000bt 1000bt-fd autonegotiation configuration: autonegotiation=on broadcast=yes driver=tg3 driverversion=3.121 firmware=sb v2.19 latency=0 link=no multicast=yes port=twisted pair resources: irq:48 memory:f0d00000-f0d0ffff

  Read the article

• yum update failed

  - by Nemanja Djuric

  I have problem doint yum update on my OpenVZ VPS i get this error message : (56/69): glibc-devel-2.5-81.el5_8.7.x86_64.rpm | 2.4 MB 00:00 (57/69): libstdc++-devel-4.1.2-52.el5_8.1.x86_64.rpm | 2.8 MB 00:00 (58/69): binutils-2.17.50.0.6-20.el5_8.3.x86_64.rpm | 2.9 MB 00:00 (59/69): cpp-4.1.2-52.el5_8.1.x86_64.rpm | 2.9 MB 00:00 (60/69): device-mapper-multipath-0.4.7-48.el5_8.1.x86_64 | 3.0 MB 00:00 (61/69): mysql-5.1.58-jason.1.x86_64.rpm | 3.5 MB 00:03 (62/69): coreutils-5.97-34.el5_8.1.x86_64.rpm | 3.6 MB 00:00 (63/69): gcc-c++-4.1.2-52.el5_8.1.x86_64.rpm | 3.8 MB 00:00 (64/69): glibc-2.5-81.el5_8.7.x86_64.rpm | 4.8 MB 00:01 (65/69): gcc-4.1.2-52.el5_8.1.x86_64.rpm | 5.3 MB 00:01 (66/69): glibc-2.5-81.el5_8.7.i686.rpm | 5.4 MB 00:01 (67/69): python-libs-2.4.3-46.el5_8.2.x86_64.rpm | 5.9 MB 00:01 (68/69): mysql-server-5.1.58-jason.1.x86_64.rpm | 13 MB 00:07 (69/69): glibc-common-2.5-81.el5_8.7.x86_64.rpm | 16 MB 00:03 -------------------------------------------------------------------------------- Total 2.4 MB/s | 106 MB 00:44 Running rpm_check_debug Running Transaction Test Finished Transaction Test Transaction Check Error: file /etc/my.cnf from install of mysql-5.1.58-jason.1.x86_64 conflicts with file from package mysql-5.0.77-4.el5_6.6.i386 file /usr/bin/mysqlaccess from install of mysql-5.1.58-jason.1.x86_64 conflicts with file from package mysql-5.0.77-4.el5_6.6.i386 file /usr/share/man/man1/my_print_defaults.1.gz from install of mysql-5.1.58-jason.1.x86_64 conflicts with file from package mysql-5.0.77-4.el5_6.6.i386 file /usr/share/man/man1/mysql.1.gz from install of mysql-5.1.58-jason.1.x86_64 conflicts with file from package mysql-5.0.77-4.el5_6.6.i386 file /usr/share/man/man1/mysql_config.1.gz from install of mysql-5.1.58-jason.1.x86_64 conflicts with file from package mysql-5.0.77-4.el5_6.6.i386 file /usr/share/man/man1/mysql_find_rows.1.gz from install of mysql-5.1.58-jason.1.x86_64 conflicts with file from package mysql-5.0.77-4.el5_6.6.i386 file /usr/share/man/man1/mysql_waitpid.1.gz from install of mysql-5.1.58-jason.1.x86_64 conflicts with file from package mysql-5.0.77-4.el5_6.6.i386 file /usr/share/man/man1/mysqlaccess.1.gz from install of mysql-5.1.58-jason.1.x86_64 conflicts with file from package mysql-5.0.77-4.el5_6.6.i386 file /usr/share/man/man1/mysqladmin.1.gz from install of mysql-5.1.58-jason.1.x86_64 conflicts with file from package mysql-5.0.77-4.el5_6.6.i386 file /usr/share/man/man1/mysqldump.1.gz from install of mysql-5.1.58-jason.1.x86_64 conflicts with file from package mysql-5.0.77-4.el5_6.6.i386 file /usr/share/man/man1/mysqlshow.1.gz from install of mysql-5.1.58-jason.1.x86_64 conflicts with file from package mysql-5.0.77-4.el5_6.6.i386 file /usr/share/mysql/charsets/Index.xml from install of mysql-5.1.58-jason.1.x86_64 conflicts with file from package mysql-5.0.77-4.el5_6.6.i386 file /usr/share/mysql/charsets/cp1250.xml from install of mysql-5.1.58-jason.1.x86_64 conflicts with file from package mysql-5.0.77-4.el5_6.6.i386 file /usr/share/mysql/charsets/cp1251.xml from install of mysql-5.1.58-jason.1.x86_64 conflicts with file from package mysql-5.0.77-4.el5_6.6.i386 file /usr/share/mysql/czech/errmsg.sys from install of mysql-5.1.58-jason.1.x86_64 conflicts with file from package mysql-5.0.77-4.el5_6.6.i386 file /usr/share/mysql/danish/errmsg.sys from install of mysql-5.1.58-jason.1.x86_64 conflicts with file from package mysql-5.0.77-4.el5_6.6.i386 file /usr/share/mysql/dutch/errmsg.sys from install of mysql-5.1.58-jason.1.x86_64 conflicts with file from package mysql-5.0.77-4.el5_6.6.i386 file /usr/share/mysql/english/errmsg.sys from install of mysql-5.1.58-jason.1.x86_64 conflicts with file from package mysql-5.0.77-4.el5_6.6.i386 file /usr/share/mysql/estonian/errmsg.sys from install of mysql-5.1.58-jason.1.x86_64 conflicts with file from package mysql-5.0.77-4.el5_6.6.i386 file /usr/share/mysql/french/errmsg.sys from install of mysql-5.1.58-jason.1.x86_64 conflicts with file from package mysql-5.0.77-4.el5_6.6.i386 file /usr/share/mysql/german/errmsg.sys from install of mysql-5.1.58-jason.1.x86_64 conflicts with file from package mysql-5.0.77-4.el5_6.6.i386 file /usr/share/mysql/greek/errmsg.sys from install of mysql-5.1.58-jason.1.x86_64 conflicts with file from package mysql-5.0.77-4.el5_6.6.i386 file /usr/share/mysql/hungarian/errmsg.sys from install of mysql-5.1.58-jason.1.x86_64 conflicts with file from package mysql-5.0.77-4.el5_6.6.i386 file /usr/share/mysql/italian/errmsg.sys from install of mysql-5.1.58-jason.1.x86_64 conflicts with file from package mysql-5.0.77-4.el5_6.6.i386 file /usr/share/mysql/japanese/errmsg.sys from install of mysql-5.1.58-jason.1.x86_64 conflicts with file from package mysql-5.0.77-4.el5_6.6.i386 file /usr/share/mysql/korean/errmsg.sys from install of mysql-5.1.58-jason.1.x86_64 conflicts with file from package mysql-5.0.77-4.el5_6.6.i386 file /usr/share/mysql/norwegian-ny/errmsg.sys from install of mysql-5.1.58-jason.1.x86_64 conflicts with file from package mysql-5.0.77-4.el5_6.6.i386 file /usr/share/mysql/norwegian/errmsg.sys from install of mysql-5.1.58-jason.1.x86_64 conflicts with file from package mysql-5.0.77-4.el5_6.6.i386 file /usr/share/mysql/polish/errmsg.sys from install of mysql-5.1.58-jason.1.x86_64 conflicts with file from package mysql-5.0.77-4.el5_6.6.i386 file /usr/share/mysql/portuguese/errmsg.sys from install of mysql-5.1.58-jason.1.x86_64 conflicts with file from package mysql-5.0.77-4.el5_6.6.i386 file /usr/share/mysql/romanian/errmsg.sys from install of mysql-5.1.58-jason.1.x86_64 conflicts with file from package mysql-5.0.77-4.el5_6.6.i386 file /usr/share/mysql/russian/errmsg.sys from install of mysql-5.1.58-jason.1.x86_64 conflicts with file from package mysql-5.0.77-4.el5_6.6.i386 file /usr/share/mysql/serbian/errmsg.sys from install of mysql-5.1.58-jason.1.x86_64 conflicts with file from package mysql-5.0.77-4.el5_6.6.i386 file /usr/share/mysql/slovak/errmsg.sys from install of mysql-5.1.58-jason.1.x86_64 conflicts with file from package mysql-5.0.77-4.el5_6.6.i386 file /usr/share/mysql/spanish/errmsg.sys from install of mysql-5.1.58-jason.1.x86_64 conflicts with file from package mysql-5.0.77-4.el5_6.6.i386 file /usr/share/mysql/swedish/errmsg.sys from install of mysql-5.1.58-jason.1.x86_64 conflicts with file from package mysql-5.0.77-4.el5_6.6.i386 file /usr/share/mysql/ukrainian/errmsg.sys from install of mysql-5.1.58-jason.1.x86_64 conflicts with file from package mysql-5.0.77-4.el5_6.6.i386 file /etc/my.cnf from install of mysql-5.1.58-jason.1.x86_64 conflicts with file from package mysql-5.0.95-1.el5_7.1.i386 file /usr/bin/mysql_find_rows from install of mysql-5.1.58-jason.1.x86_64 conflicts with file from package mysql-5.0.95-1.el5_7.1.i386 file /usr/bin/mysqlaccess from install of mysql-5.1.58-jason.1.x86_64 conflicts with file from package mysql-5.0.95-1.el5_7.1.i386 file /usr/share/man/man1/my_print_defaults.1.gz from install of mysql-5.1.58-jason.1.x86_64 conflicts with file from package mysql-5.0.95-1.el5_7.1.i386 file /usr/share/man/man1/mysql.1.gz from install of mysql-5.1.58-jason.1.x86_64 conflicts with file from package mysql-5.0.95-1.el5_7.1.i386 file /usr/share/man/man1/mysql_config.1.gz from install of mysql-5.1.58-jason.1.x86_64 conflicts with file from package mysql-5.0.95-1.el5_7.1.i386 file /usr/share/man/man1/mysql_find_rows.1.gz from install of mysql-5.1.58-jason.1.x86_64 conflicts with file from package mysql-5.0.95-1.el5_7.1.i386 file /usr/share/man/man1/mysql_waitpid.1.gz from install of mysql-5.1.58-jason.1.x86_64 conflicts with file from package mysql-5.0.95-1.el5_7.1.i386 file /usr/share/man/man1/mysqlaccess.1.gz from install of mysql-5.1.58-jason.1.x86_64 conflicts with file from package mysql-5.0.95-1.el5_7.1.i386 file /usr/share/man/man1/mysqladmin.1.gz from install of mysql-5.1.58-jason.1.x86_64 conflicts with file from package mysql-5.0.95-1.el5_7.1.i386 file /usr/share/man/man1/mysqldump.1.gz from install of mysql-5.1.58-jason.1.x86_64 conflicts with file from package mysql-5.0.95-1.el5_7.1.i386 file /usr/share/man/man1/mysqlshow.1.gz from install of mysql-5.1.58-jason.1.x86_64 conflicts with file from package mysql-5.0.95-1.el5_7.1.i386 file /usr/share/mysql/charsets/Index.xml from install of mysql-5.1.58-jason.1.x86_64 conflicts with file from package mysql-5.0.95-1.el5_7.1.i386 file /usr/share/mysql/charsets/cp1250.xml from install of mysql-5.1.58-jason.1.x86_64 conflicts with file from package mysql-5.0.95-1.el5_7.1.i386 file /usr/share/mysql/charsets/cp1251.xml from install of mysql-5.1.58-jason.1.x86_64 conflicts with file from package mysql-5.0.95-1.el5_7.1.i386 file /usr/share/mysql/czech/errmsg.sys from install of mysql-5.1.58-jason.1.x86_64 conflicts with file from package mysql-5.0.95-1.el5_7.1.i386 file /usr/share/mysql/danish/errmsg.sys from install of mysql-5.1.58-jason.1.x86_64 conflicts with file from package mysql-5.0.95-1.el5_7.1.i386 file /usr/share/mysql/dutch/errmsg.sys from install of mysql-5.1.58-jason.1.x86_64 conflicts with file from package mysql-5.0.95-1.el5_7.1.i386 file /usr/share/mysql/english/errmsg.sys from install of mysql-5.1.58-jason.1.x86_64 conflicts with file from package mysql-5.0.95-1.el5_7.1.i386 file /usr/share/mysql/estonian/errmsg.sys from install of mysql-5.1.58-jason.1.x86_64 conflicts with file from package mysql-5.0.95-1.el5_7.1.i386 file /usr/share/mysql/french/errmsg.sys from install of mysql-5.1.58-jason.1.x86_64 conflicts with file from package mysql-5.0.95-1.el5_7.1.i386 file /usr/share/mysql/german/errmsg.sys from install of mysql-5.1.58-jason.1.x86_64 conflicts with file from package mysql-5.0.95-1.el5_7.1.i386 file /usr/share/mysql/greek/errmsg.sys from install of mysql-5.1.58-jason.1.x86_64 conflicts with file from package mysql-5.0.95-1.el5_7.1.i386 file /usr/share/mysql/hungarian/errmsg.sys from install of mysql-5.1.58-jason.1.x86_64 conflicts with file from package mysql-5.0.95-1.el5_7.1.i386 file /usr/share/mysql/italian/errmsg.sys from install of mysql-5.1.58-jason.1.x86_64 conflicts with file from package mysql-5.0.95-1.el5_7.1.i386 file /usr/share/mysql/japanese/errmsg.sys from install of mysql-5.1.58-jason.1.x86_64 conflicts with file from package mysql-5.0.95-1.el5_7.1.i386 file /usr/share/mysql/korean/errmsg.sys from install of mysql-5.1.58-jason.1.x86_64 conflicts with file from package mysql-5.0.95-1.el5_7.1.i386 file /usr/share/mysql/norwegian-ny/errmsg.sys from install of mysql-5.1.58-jason.1.x86_64 conflicts with file from package mysql-5.0.95-1.el5_7.1.i386 file /usr/share/mysql/norwegian/errmsg.sys from install of mysql-5.1.58-jason.1.x86_64 conflicts with file from package mysql-5.0.95-1.el5_7.1.i386 file /usr/share/mysql/polish/errmsg.sys from install of mysql-5.1.58-jason.1.x86_64 conflicts with file from package mysql-5.0.95-1.el5_7.1.i386 file /usr/share/mysql/portuguese/errmsg.sys from install of mysql-5.1.58-jason.1.x86_64 conflicts with file from package mysql-5.0.95-1.el5_7.1.i386 file /usr/share/mysql/romanian/errmsg.sys from install of mysql-5.1.58-jason.1.x86_64 conflicts with file from package mysql-5.0.95-1.el5_7.1.i386 file /usr/share/mysql/russian/errmsg.sys from install of mysql-5.1.58-jason.1.x86_64 conflicts with file from package mysql-5.0.95-1.el5_7.1.i386 file /usr/share/mysql/serbian/errmsg.sys from install of mysql-5.1.58-jason.1.x86_64 conflicts with file from package mysql-5.0.95-1.el5_7.1.i386 file /usr/share/mysql/slovak/errmsg.sys from install of mysql-5.1.58-jason.1.x86_64 conflicts with file from package mysql-5.0.95-1.el5_7.1.i386 file /usr/share/mysql/spanish/errmsg.sys from install of mysql-5.1.58-jason.1.x86_64 conflicts with file from package mysql-5.0.95-1.el5_7.1.i386 file /usr/share/mysql/swedish/errmsg.sys from install of mysql-5.1.58-jason.1.x86_64 conflicts with file from package mysql-5.0.95-1.el5_7.1.i386 file /usr/share/mysql/ukrainian/errmsg.sys from install of mysql-5.1.58- jason.1.x86_64 conflicts with file from package mysql-5.0.95-1.el5_7.1.i386 Error Summary Thank you for help, Best regards, Nemanja

  Read the article

• webserver horrible slow, sometimes incredible fast

  - by dhanke

  i am running a small community ( 6000+ Members ) on a non-virtual 64-bit ubuntu 11.04 system. I am not a Linux-pro, not even advanced, i just tried to setup a webserver, which does nothing special actually. Delivering some dynamic PHP and RoR websites is its task. So it might be that my configuration files do look horrible bad. Also, i might use the wrong vocabulary, so in doubt, please ask. Having a current all-time record of 520 registered users (board-accounts, no system-users) online at same time, average server-load is about 2.0 - 5.0. Meantime (~250 users) average server load value is at about 0.4 - 0.8, sometimes, on some expensive searches a bit higher. everything fine. From time to time however, the load increases up to 120 (120.0, not 12.0 ;) ). In this time, its hard to even connect via SSH, but when i reach the server, and use top/htop/iotop to see whats happening, i cannot identify any process causing high CPU load. iotop tells me about a current reading/writing speed of about approx. 70kb/s, which is quite equal to power-off i think. Memory-Usage is max. at ~ 12GB of 16GB, so swap remains empty. now the odd (at least for me:) waiting some minutes ( since i always get a bit into a panic when this happens, it feels like 5 minutes, but i suppose its more like 20-30 minutes) and the server is back to normal. everything continues as normal. another odd fact: when i run hdparm -tT /dev/sda, i get answer like: /dev/sda: Timing cached reads: 7180 MB in 2.00 seconds = 3591.13 MB/sec Timing buffered disk reads: 348 MB in 3.02 seconds = 115.41 MB/sec when i run the same command while the server is "frozen", the answer is like /dev/sda: <- takes about 5 minutes until this line appears Timing cached reads: 7180 MB in 2.00 seconds = 3591.13 MB/sec <- 5 more minutes Timing buffered disk reads: 348 MB in 3.02 seconds = 115.41 MB/sec <- another 5 minutes so the values are the same, but the quoted time is completely wrong. using time command as prefix also tells me that ~ 15 minutes were used. I searched in dmesg, /var/log/[messages|syslog] - nothing found. /var/log/errors however tells me that: Jul 4 20:28:30 localhost kernel: [19080.671415] INFO: task php5-fpm:27728 blocked for more than 120 seconds. Jul 4 20:28:30 localhost kernel: [19080.671419] "echo 0 /proc/sys/kernel/hung_task_timeout_secs" disables this message. multiple times. now that message does tell me that php5-fpm task was blocked or did block ? - but not if that is the cause or just one of the results of that "freeze". Anyone? to cut the long story short, i dont know where even to start analyzing. So if you can give me any advice by looking at following specs and configs, or ask me to provide more information, i`d be glad. Specs: 6 Core AMD Phenom(tm) II X6 1055T Processor * 16 Gigabyte Ram 2x 1.5 TB Seagate ST1500DL003-9VT16L via SATA 3 via SoftwareRaid (i suppose) Services: (due to service --status-all, those with [ + ]) nginx Webserver 1.0.14 mySQL 5.1.63 Server Ruby on Rails 2.3.11 ( passenger-nginx-module ) php5-fpm 5.3.6-13ubuntu3.7 SSH ido2db Further services: default crontab + nightly backup. syslog-ng Website consists of 2 subdomains, forum. and www. where forum is a phpBB3.x PHP-Board, and www a Ruby on Rails 2.3.11 application (portal). Mini-Note: sometimes i notice that the forum is pretty slow, in contrast to the always-fast (except for this "freeze") portal. Both share the same Database, but the portal is using it read-only. The Webserver is nginx, using phusion passenger module to communicate with the ruby-application. Also, for the forum it communicates with php5-fpm via socket: relevant nginx configuration parts ( with comments/questions starting by ; ) ; in case of freeze due to too high Filesystem activity, maybe adding a limit? #worker_rlimit_nofile 50000; user www-data; ; 6 cores, so i read 6 fits. maybe already wrong? worker_processes 6; pid /var/run/nginx.pid; events { worker_connections 1024; } http { passenger_root /var/lib/gems/1.8/gems/passenger-3.0.11; passenger_ruby /usr/bin/ruby1.8; ; the forum once featured a chat, which was working w/o websockets. ; so it was a hell of pull requests (deactivated now, freeze still happening) keepalive_timeout 65; keepalive_requests 50; gzip on; server { listen 80; server_name www.domain.tld; root /var/www/domain/rails/public; passenger_enabled on; } server { listen 80; server_name forum.domain.tld; location / { root /var/www/domain/forum; index index.php; } ; satic stuff to be handled by nginx location ~* ^/style/.+.(jpg|jpeg|gif|css|png|js|ico|xml)$ { access_log off; expires 30d; root /var/www/domain/forum/; } ; now the php magic, note the "backend"-fcgi_pass location ~ .php$ { fastcgi_split_path_info ^(.+\.php)(.*)$; fastcgi_pass backend; fastcgi_index index.php; fastcgi_param SCRIPT_FILENAME /var/www/domain/forum$fastcgi_script_name; include fastcgi_params; fastcgi_param QUERY_STRING $query_string; fastcgi_param REQUEST_METHOD $request_method; fastcgi_param CONTENT_TYPE $content_type; fastcgi_param CONTENT_LENGTH $content_length; fastcgi_intercept_errors on; fastcgi_ignore_client_abort off; fastcgi_connect_timeout 60; fastcgi_send_timeout 180; fastcgi_read_timeout 180; fastcgi_buffer_size 128k; fastcgi_buffers 256 16k; fastcgi_busy_buffers_size 256k; fastcgi_temp_file_write_size 256k; fastcgi_max_temp_file_size 0; } location ~ /\.ht { deny all; } } ;the php5-fpm socket. i read that /dev/shm/ whould be the fastes place for this. bad idea in general? upstream backend { server unix:/dev/shm/phpfpm; } ... } php5-fpm settings (i changed this values due to php5-fpm error log messages higher and higher.. (freeze-problem was there before as well)* listen = /dev/shm/phpfpm user = www-data group = www-data pm = dynamic ; holy, 4000! well, shinking this value to earth-level gave me ; 100s of 502 bad gateway commands. this values were quite stable. ; since there are only max 520 users online i dont get it, why i would need ; as many children as configured here. due to keep-alive maybe? ; asking questions is easier for me since restarting server will make ; my community-members angry ;) pm.max_children = 4000 pm.start_servers = 100 pm.min_spare_servers = 50 pm.max_spare_servers = 150 pm.max_requests = 10 pm.status_path = /status ping.path = /ping ping.response = pong slowlog = log/$pool.log.slow ;should i use rlimit? ;rlimit_files = 1024 chdir = / mysql/my.cnf [client] port = 3306 socket = /var/run/mysqld/mysqld.sock [mysqld_safe] socket = /var/run/mysqld/mysqld.sock nice = 0 [mysqld] user = mysql socket = /var/run/mysqld/mysqld.sock port = 3306 basedir = /usr datadir = /var/lib/mysql tmpdir = /tmp skip-external-locking bind-address = 127.0.0.1 key_buffer = 16M max_allowed_packet = 16M thread_stack = 192K thread_cache_size = 8 myisam-recover = BACKUP ; high number, but less gives some phpBB errors. max_connections = 450 table_cache = 512 ; i read twice the cpu cores, bad? thread_concurrency = 12 join_buffer_size = 2084K concurrent_insert = 3 query_cache_limit = 64M query_cache_size = 512M query_cache_type = 1 log_error = /var/log/mysql/error.log log_slow_queries = /var/log/mysql/mysql-slow.log long_query_time = 2 expire_logs_days = 10 max_binlog_size = 100M low_priority_updates=1 [mysqldump] quick quote-names max_allowed_packet = 16M [isamchk] key_buffer = 16M !includedir /etc/mysql/conf.d/ I used smartctl already, hdds seem to be fine. /proc/mdstatus quotes: Personalities : [raid1] [linear] [multipath] [raid0] [raid6] [raid5] [raid4] [raid10] md3 : active raid1 sda3[1] 1459264192 blocks [2/1] [_U] md1 : active raid1 sda1[0] 3911680 blocks [2/1] [U_] unused devices: ulimit -a core file size (blocks, -c) 0 data seg size (kbytes, -d) unlimited scheduling priority (-e) 0 file size (blocks, -f) unlimited pending signals (-i) 127727 max locked memory (kbytes, -l) 64 max memory size (kbytes, -m) unlimited open files (-n) 1024 pipe size (512 bytes, -p) 8 POSIX message queues (bytes, -q) 819200 real-time priority (-r) 0 stack size (kbytes, -s) 8192 cpu time (seconds, -t) unlimited max user processes (-u) 127727 virtual memory (kbytes, -v) unlimited file locks (-x) unlimited I quote some questions in my configuration files, these are not (intentional) directly problem-related, but would be nice for me to know wether they are indeed questionable or done right. One additional Fact: my MYSQL-database is at 12GB size. i dont know if that does matter, but mytop sometimes shows me 4-5 seconds long insert queries, some are 20-30 seconds long. Its just a feeling that i am unable to prove (because i dont know how), but when i disable the database, the freeze seems not to happen. Example: i created a dummy rails application to see the development log. the app made some sql-queries, reads and inserts. the log quite often was like: DbTest Load (0.3ms) SELECT * FROM `db_test` WHERE (`db_test`.`id` = 31722) LIMIT 1 SQL (0.1ms) BEGIN DbTest Update (0.3ms) UPDATE `db_test` SET `updated_at` = '2012-07-04 23:32:34' WHERE `id` = 31722 - now the log stands still for 5-60 seconds. SQL (49.1ms) COMMIT - SQL-Update time in the log does not include freeze time Rendering test/index Completed in 96ms (View: 16, DB: 59) | 200 OK [http://localhost:9000/test] Bad part is: this mini-freeze here only happens from time to time as well. note: meanwhile i cannot even upload files via scp. I currently feel like running form bad to worse and back by googling for my server-problem due to immense lack of knowledge regarding server configurations. It still makes me wonder, why those problems even appear, since 250 users a time is not such a high amount, right? So my questions: whats wrong and how to fix? ;) or: what information can i provide to make the situation more clear? can you point at some critical bad configuration-line which i should consider to catch up in the documentation? are there any tools i can run to see some possible bottlenecks? any further advice? (next to: "pay someone who knows what he does" - its a private project, server costs enough already. :)) Thanks for your time and help. Best Regards, Daniel P.S.: i renamed the configfiles to domain.tld since i dont want to have any % more load to the server until its fixed. might be a exaggeratedly thought.. P.P.S: if i asked a complete duplicate question, sorry. my search results seemed to be quite specific in their own way.

  Read the article

• Did I lose my RAID again?

  - by BarsMonster

  Hi! A little history: 2 years ago I was really excited to find out that mdadm is so powerful that it even can reshape arrays, so you can start with a smaller array and then grow it as you need. I've bought 3x1Tb drives and made a RAID-5. It was fine for a year. Then I bought 2x more, and tried to reshape to RAID-6 out of 5 drives, and due to some mess with superblock versions, lost all content. Had to rebuild it from scratch, but 2Tb of data were gone. Yesterday I bought 2 more drives, and this time I had everything: properly built array, UPS. I've disabled write intent map, added 2 new drives as spares and run a command to grow array to 7-disks. It started working, but speed was ridiculously slow, ~100kb/sec. After processing first 37Mb at such an amazing speed, one of old HDDs fails. I properly shutdown the PC and disconnected the failed drive. After bootup it appeared that it recreated the intent map as it was still in mdadm config, so I removed it from config and rebooted again. Now all I see is that all mdadm processes deadlock, and don't do anything. PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 1937 root 20 0 12992 608 444 D 0 0.1 0:00.00 mdadm 2283 root 20 0 12992 852 704 D 0 0.1 0:00.01 mdadm 2287 root 20 0 0 0 0 D 0 0.0 0:00.01 md0_reshape 2288 root 18 -2 12992 820 676 D 0 0.1 0:00.01 mdadm And all I see in mdstat is: $ cat /proc/mdstat Personalities : [linear] [multipath] [raid0] [raid1] [raid6] [raid5] [raid4] [raid10] md0 : active raid6 sdb1[1] sdg1[4] sdf1[7] sde1[6] sdd1[0] sdc1[5] 2929683456 blocks super 1.2 level 6, 1024k chunk, algorithm 2 [7/6] [UU_UUUU] [>....................] reshape = 0.0% (37888/976561152) finish=567604147.2min speed=0K/sec I've already tried mdadm 2.6.7, 3.1.4 and 3.2 - nothing helps. Did I lose my data again? Any suggestions on how can I make this work? OS is Ubuntu Server 10.04.2. PS. Needless to say, the data is inaccessible - I cannot mount /dev/md0 to save the most valuable data. You can see my disappointment - the very specific thing I was excited about failed twice taking 5Tb of my data with it. Update: It appears there is some nice info in kern.log: 21:38:48 ...: [ 166.522055] raid5: reshape will continue 21:38:48 ...: [ 166.522085] raid5: device sdb1 operational as raid disk 1 21:38:48 ...: [ 166.522091] raid5: device sdg1 operational as raid disk 4 21:38:48 ...: [ 166.522097] raid5: device sdf1 operational as raid disk 5 21:38:48 ...: [ 166.522102] raid5: device sde1 operational as raid disk 6 21:38:48 ...: [ 166.522107] raid5: device sdd1 operational as raid disk 0 21:38:48 ...: [ 166.522111] raid5: device sdc1 operational as raid disk 3 21:38:48 ...: [ 166.523942] raid5: allocated 7438kB for md0 21:38:48 ...: [ 166.524041] 1: w=1 pa=2 pr=5 m=2 a=2 r=7 op1=0 op2=0 21:38:48 ...: [ 166.524050] 4: w=2 pa=2 pr=5 m=2 a=2 r=7 op1=0 op2=0 21:38:48 ...: [ 166.524056] 5: w=3 pa=2 pr=5 m=2 a=2 r=7 op1=0 op2=0 21:38:48 ...: [ 166.524062] 6: w=4 pa=2 pr=5 m=2 a=2 r=7 op1=0 op2=0 21:38:48 ...: [ 166.524068] 0: w=5 pa=2 pr=5 m=2 a=2 r=7 op1=0 op2=0 21:38:48 ...: [ 166.524073] 3: w=6 pa=2 pr=5 m=2 a=2 r=7 op1=0 op2=0 21:38:48 ...: [ 166.524079] raid5: raid level 6 set md0 active with 6 out of 7 devices, algorithm 2 21:38:48 ...: [ 166.524519] RAID5 conf printout: 21:38:48 ...: [ 166.524523] --- rd:7 wd:6 21:38:48 ...: [ 166.524528] disk 0, o:1, dev:sdd1 21:38:48 ...: [ 166.524532] disk 1, o:1, dev:sdb1 21:38:48 ...: [ 166.524537] disk 3, o:1, dev:sdc1 21:38:48 ...: [ 166.524541] disk 4, o:1, dev:sdg1 21:38:48 ...: [ 166.524545] disk 5, o:1, dev:sdf1 21:38:48 ...: [ 166.524550] disk 6, o:1, dev:sde1 21:38:48 ...: [ 166.524553] ...ok start reshape thread 21:38:48 ...: [ 166.524727] md0: detected capacity change from 0 to 2999995858944 21:38:48 ...: [ 166.524735] md: reshape of RAID array md0 21:38:48 ...: [ 166.524740] md: minimum _guaranteed_ speed: 1000 KB/sec/disk. 21:38:48 ...: [ 166.524745] md: using maximum available idle IO bandwidth (but not more than 200000 KB/sec) for reshape. 21:38:48 ...: [ 166.524756] md: using 128k window, over a total of 976561152 blocks. 21:39:05 ...: [ 166.525013] md0: 21:42:04 ...: [ 362.520063] INFO: task mdadm:1937 blocked for more than 120 seconds. 21:42:04 ...: [ 362.520068] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. 21:42:04 ...: [ 362.520073] mdadm D 00000000ffffffff 0 1937 1 0x00000000 21:42:04 ...: [ 362.520083] ffff88002ef4f5d8 0000000000000082 0000000000015bc0 0000000000015bc0 21:42:04 ...: [ 362.520092] ffff88002eb5b198 ffff88002ef4ffd8 0000000000015bc0 ffff88002eb5ade0 21:42:04 ...: [ 362.520100] 0000000000015bc0 ffff88002ef4ffd8 0000000000015bc0 ffff88002eb5b198 21:42:04 ...: [ 362.520107] Call Trace: 21:42:04 ...: [ 362.520133] [<ffffffffa0224892>] get_active_stripe+0x312/0x3f0 [raid456] 21:42:04 ...: [ 362.520148] [<ffffffff81059ae0>] ? default_wake_function+0x0/0x20 21:42:04 ...: [ 362.520159] [<ffffffffa0228413>] make_request+0x243/0x4b0 [raid456] 21:42:04 ...: [ 362.520169] [<ffffffffa0221a90>] ? release_stripe+0x50/0x70 [raid456] 21:42:04 ...: [ 362.520179] [<ffffffff81084790>] ? autoremove_wake_function+0x0/0x40 21:42:04 ...: [ 362.520188] [<ffffffff81414df0>] md_make_request+0xc0/0x130 21:42:04 ...: [ 362.520194] [<ffffffff81414df0>] ? md_make_request+0xc0/0x130 21:42:04 ...: [ 362.520205] [<ffffffff8129f8c1>] generic_make_request+0x1b1/0x4f0 21:42:04 ...: [ 362.520214] [<ffffffff810f6515>] ? mempool_alloc_slab+0x15/0x20 21:42:04 ...: [ 362.520222] [<ffffffff8116c2ec>] ? alloc_buffer_head+0x1c/0x60 21:42:04 ...: [ 362.520230] [<ffffffff8129fc80>] submit_bio+0x80/0x110 21:42:04 ...: [ 362.520236] [<ffffffff8116c849>] submit_bh+0xf9/0x140 21:42:04 ...: [ 362.520244] [<ffffffff8116f124>] block_read_full_page+0x274/0x3b0 21:42:04 ...: [ 362.520251] [<ffffffff81172c90>] ? blkdev_get_block+0x0/0x70 21:42:04 ...: [ 362.520258] [<ffffffff8110d875>] ? __inc_zone_page_state+0x35/0x40 21:42:04 ...: [ 362.520265] [<ffffffff810f46d8>] ? add_to_page_cache_locked+0xe8/0x160 21:42:04 ...: [ 362.520272] [<ffffffff81173d78>] blkdev_readpage+0x18/0x20 21:42:04 ...: [ 362.520279] [<ffffffff810f484b>] __read_cache_page+0x7b/0xe0 21:42:04 ...: [ 362.520285] [<ffffffff81173d60>] ? blkdev_readpage+0x0/0x20 21:42:04 ...: [ 362.520290] [<ffffffff81173d60>] ? blkdev_readpage+0x0/0x20 21:42:04 ...: [ 362.520297] [<ffffffff810f57dc>] do_read_cache_page+0x3c/0x120 21:42:04 ...: [ 362.520304] [<ffffffff810f5909>] read_cache_page_async+0x19/0x20 21:42:04 ...: [ 362.520310] [<ffffffff810f591e>] read_cache_page+0xe/0x20 21:42:04 ...: [ 362.520317] [<ffffffff811a6cb0>] read_dev_sector+0x30/0xa0 21:42:04 ...: [ 362.520324] [<ffffffff811a7fcd>] amiga_partition+0x6d/0x460 21:42:04 ...: [ 362.520331] [<ffffffff811a7938>] check_partition+0x138/0x190 21:42:04 ...: [ 362.520338] [<ffffffff811a7a7a>] rescan_partitions+0xea/0x2f0 21:42:04 ...: [ 362.520344] [<ffffffff811744c7>] __blkdev_get+0x267/0x3d0 21:42:04 ...: [ 362.520350] [<ffffffff81174650>] ? blkdev_open+0x0/0xc0 21:42:04 ...: [ 362.520356] [<ffffffff81174640>] blkdev_get+0x10/0x20 21:42:04 ...: [ 362.520362] [<ffffffff811746c1>] blkdev_open+0x71/0xc0 21:42:04 ...: [ 362.520369] [<ffffffff811419f3>] __dentry_open+0x113/0x370 21:42:04 ...: [ 362.520377] [<ffffffff81253f8f>] ? security_inode_permission+0x1f/0x30 21:42:04 ...: [ 362.520385] [<ffffffff8114de3f>] ? inode_permission+0xaf/0xd0 21:42:04 ...: [ 362.520391] [<ffffffff81141d67>] nameidata_to_filp+0x57/0x70 21:42:04 ...: [ 362.520398] [<ffffffff8115207a>] do_filp_open+0x2da/0xba0 21:42:04 ...: [ 362.520406] [<ffffffff811134a8>] ? unmap_vmas+0x178/0x310 21:42:04 ...: [ 362.520414] [<ffffffff8115dbfa>] ? alloc_fd+0x10a/0x150 21:42:04 ...: [ 362.520421] [<ffffffff81141769>] do_sys_open+0x69/0x170 21:42:04 ...: [ 362.520428] [<ffffffff811418b0>] sys_open+0x20/0x30 21:42:04 ...: [ 362.520437] [<ffffffff810121b2>] system_call_fastpath+0x16/0x1b 21:42:04 ...: [ 362.520446] INFO: task mdadm:2283 blocked for more than 120 seconds. 21:42:04 ...: [ 362.520450] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. 21:42:04 ...: [ 362.520454] mdadm D 0000000000000000 0 2283 2212 0x00000000 21:42:04 ...: [ 362.520462] ffff88002cca7d98 0000000000000086 0000000000015bc0 0000000000015bc0 21:42:04 ...: [ 362.520470] ffff88002ededf78 ffff88002cca7fd8 0000000000015bc0 ffff88002ededbc0 21:42:04 ...: [ 362.520478] 0000000000015bc0 ffff88002cca7fd8 0000000000015bc0 ffff88002ededf78 21:42:04 ...: [ 362.520485] Call Trace: 21:42:04 ...: [ 362.520495] [<ffffffff81543a97>] __mutex_lock_slowpath+0xf7/0x180 21:42:04 ...: [ 362.520502] [<ffffffff8154397b>] mutex_lock+0x2b/0x50 21:42:04 ...: [ 362.520508] [<ffffffff8117404d>] __blkdev_put+0x3d/0x190 21:42:04 ...: [ 362.520514] [<ffffffff811741b0>] blkdev_put+0x10/0x20 21:42:04 ...: [ 362.520520] [<ffffffff811741f3>] blkdev_close+0x33/0x60 21:42:04 ...: [ 362.520527] [<ffffffff81145375>] __fput+0xf5/0x210 21:42:04 ...: [ 362.520534] [<ffffffff811454b5>] fput+0x25/0x30 21:42:04 ...: [ 362.520540] [<ffffffff811415ad>] filp_close+0x5d/0x90 21:42:04 ...: [ 362.520546] [<ffffffff81141697>] sys_close+0xb7/0x120 21:42:04 ...: [ 362.520553] [<ffffffff810121b2>] system_call_fastpath+0x16/0x1b 21:42:04 ...: [ 362.520559] INFO: task md0_reshape:2287 blocked for more than 120 seconds. 21:42:04 ...: [ 362.520563] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. 21:42:04 ...: [ 362.520567] md0_reshape D ffff88003aee96f0 0 2287 2 0x00000000 21:42:04 ...: [ 362.520575] ffff88003cf05a70 0000000000000046 0000000000015bc0 0000000000015bc0 21:42:04 ...: [ 362.520582] ffff88003aee9aa8 ffff88003cf05fd8 0000000000015bc0 ffff88003aee96f0 21:42:04 ...: [ 362.520590] 0000000000015bc0 ffff88003cf05fd8 0000000000015bc0 ffff88003aee9aa8 21:42:04 ...: [ 362.520597] Call Trace: 21:42:04 ...: [ 362.520608] [<ffffffffa0224892>] get_active_stripe+0x312/0x3f0 [raid456] 21:42:04 ...: [ 362.520616] [<ffffffff81059ae0>] ? default_wake_function+0x0/0x20 21:42:04 ...: [ 362.520626] [<ffffffffa0226f80>] reshape_request+0x4c0/0x9a0 [raid456] 21:42:04 ...: [ 362.520634] [<ffffffff81084790>] ? autoremove_wake_function+0x0/0x40 21:42:04 ...: [ 362.520644] [<ffffffffa022777a>] sync_request+0x31a/0x3a0 [raid456] 21:42:04 ...: [ 362.520651] [<ffffffff81052713>] ? __wake_up+0x53/0x70 21:42:04 ...: [ 362.520658] [<ffffffff814156b1>] md_do_sync+0x621/0xbb0 21:42:04 ...: [ 362.520668] [<ffffffff810387b9>] ? default_spin_lock_flags+0x9/0x10 21:42:04 ...: [ 362.520675] [<ffffffff8141640c>] md_thread+0x5c/0x130 21:42:04 ...: [ 362.520681] [<ffffffff81084790>] ? autoremove_wake_function+0x0/0x40 21:42:04 ...: [ 362.520688] [<ffffffff814163b0>] ? md_thread+0x0/0x130 21:42:04 ...: [ 362.520694] [<ffffffff81084416>] kthread+0x96/0xa0 21:42:04 ...: [ 362.520701] [<ffffffff810131ea>] child_rip+0xa/0x20 21:42:04 ...: [ 362.520707] [<ffffffff81084380>] ? kthread+0x0/0xa0 21:42:04 ...: [ 362.520713] [<ffffffff810131e0>] ? child_rip+0x0/0x20 21:42:04 ...: [ 362.520718] INFO: task mdadm:2288 blocked for more than 120 seconds. 21:42:04 ...: [ 362.520721] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. 21:42:04 ...: [ 362.520725] mdadm D 0000000000000000 0 2288 1 0x00000000 21:42:04 ...: [ 362.520733] ffff88002cca9c18 0000000000000086 0000000000015bc0 0000000000015bc0 21:42:04 ...: [ 362.520741] ffff88003aee83b8 ffff88002cca9fd8 0000000000015bc0 ffff88003aee8000 21:42:04 ...: [ 362.520748] 0000000000015bc0 ffff88002cca9fd8 0000000000015bc0 ffff88003aee83b8 21:42:04 ...: [ 362.520755] Call Trace: 21:42:04 ...: [ 362.520763] [<ffffffff81543a97>] __mutex_lock_slowpath+0xf7/0x180 21:42:04 ...: [ 362.520771] [<ffffffff812a6d50>] ? exact_match+0x0/0x10 21:42:04 ...: [ 362.520777] [<ffffffff8154397b>] mutex_lock+0x2b/0x50 21:42:04 ...: [ 362.520783] [<ffffffff811742c8>] __blkdev_get+0x68/0x3d0 21:42:04 ...: [ 362.520790] [<ffffffff81174650>] ? blkdev_open+0x0/0xc0 21:42:04 ...: [ 362.520795] [<ffffffff81174640>] blkdev_get+0x10/0x20 21:42:04 ...: [ 362.520801] [<ffffffff811746c1>] blkdev_open+0x71/0xc0 21:42:04 ...: [ 362.520808] [<ffffffff811419f3>] __dentry_open+0x113/0x370 21:42:04 ...: [ 362.520815] [<ffffffff81253f8f>] ? security_inode_permission+0x1f/0x30 21:42:04 ...: [ 362.520821] [<ffffffff8114de3f>] ? inode_permission+0xaf/0xd0 21:42:04 ...: [ 362.520828] [<ffffffff81141d67>] nameidata_to_filp+0x57/0x70 21:42:04 ...: [ 362.520834] [<ffffffff8115207a>] do_filp_open+0x2da/0xba0 21:42:04 ...: [ 362.520841] [<ffffffff810ff0e1>] ? lru_cache_add_lru+0x21/0x40 21:42:04 ...: [ 362.520848] [<ffffffff8111109c>] ? do_anonymous_page+0x11c/0x330 21:42:04 ...: [ 362.520855] [<ffffffff81115d5f>] ? handle_mm_fault+0x31f/0x3c0 21:42:04 ...: [ 362.520862] [<ffffffff8115dbfa>] ? alloc_fd+0x10a/0x150 21:42:04 ...: [ 362.520868] [<ffffffff81141769>] do_sys_open+0x69/0x170 21:42:04 ...: [ 362.520874] [<ffffffff811418b0>] sys_open+0x20/0x30 21:42:04 ...: [ 362.520882] [<ffffffff810121b2>] system_call_fastpath+0x16/0x1b 21:44:04 ...: [ 482.520065] INFO: task mdadm:1937 blocked for more than 120 seconds. 21:44:04 ...: [ 482.520071] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. 21:44:04 ...: [ 482.520077] mdadm D 00000000ffffffff 0 1937 1 0x00000000 21:44:04 ...: [ 482.520087] ffff88002ef4f5d8 0000000000000082 0000000000015bc0 0000000000015bc0 21:44:04 ...: [ 482.520096] ffff88002eb5b198 ffff88002ef4ffd8 0000000000015bc0 ffff88002eb5ade0 21:44:04 ...: [ 482.520104] 0000000000015bc0 ffff88002ef4ffd8 0000000000015bc0 ffff88002eb5b198 21:44:04 ...: [ 482.520112] Call Trace: 21:44:04 ...: [ 482.520139] [<ffffffffa0224892>] get_active_stripe+0x312/0x3f0 [raid456] 21:44:04 ...: [ 482.520154] [<ffffffff81059ae0>] ? default_wake_function+0x0/0x20 21:44:04 ...: [ 482.520165] [<ffffffffa0228413>] make_request+0x243/0x4b0 [raid456] 21:44:04 ...: [ 482.520175] [<ffffffffa0221a90>] ? release_stripe+0x50/0x70 [raid456] 21:44:04 ...: [ 482.520185] [<ffffffff81084790>] ? autoremove_wake_function+0x0/0x40 21:44:04 ...: [ 482.520194] [<ffffffff81414df0>] md_make_request+0xc0/0x130 21:44:04 ...: [ 482.520201] [<ffffffff81414df0>] ? md_make_request+0xc0/0x130 21:44:04 ...: [ 482.520212] [<ffffffff8129f8c1>] generic_make_request+0x1b1/0x4f0 21:44:04 ...: [ 482.520221] [<ffffffff810f6515>] ? mempool_alloc_slab+0x15/0x20 21:44:04 ...: [ 482.520229] [<ffffffff8116c2ec>] ? alloc_buffer_head+0x1c/0x60 21:44:04 ...: [ 482.520237] [<ffffffff8129fc80>] submit_bio+0x80/0x110 21:44:04 ...: [ 482.520244] [<ffffffff8116c849>] submit_bh+0xf9/0x140 21:44:04 ...: [ 482.520252] [<ffffffff8116f124>] block_read_full_page+0x274/0x3b0 21:44:04 ...: [ 482.520258] [<ffffffff81172c90>] ? blkdev_get_block+0x0/0x70 21:44:04 ...: [ 482.520266] [<ffffffff8110d875>] ? __inc_zone_page_state+0x35/0x40 21:44:04 ...: [ 482.520273] [<ffffffff810f46d8>] ? add_to_page_cache_locked+0xe8/0x160 21:44:04 ...: [ 482.520280] [<ffffffff81173d78>] blkdev_readpage+0x18/0x20 21:44:04 ...: [ 482.520286] [<ffffffff810f484b>] __read_cache_page+0x7b/0xe0 21:44:04 ...: [ 482.520293] [<ffffffff81173d60>] ? blkdev_readpage+0x0/0x20 21:44:04 ...: [ 482.520299] [<ffffffff81173d60>] ? blkdev_readpage+0x0/0x20 21:44:04 ...: [ 482.520306] [<ffffffff810f57dc>] do_read_cache_page+0x3c/0x120 21:44:04 ...: [ 482.520313] [<ffffffff810f5909>] read_cache_page_async+0x19/0x20 21:44:04 ...: [ 482.520319] [<ffffffff810f591e>] read_cache_page+0xe/0x20 21:44:04 ...: [ 482.520327] [<ffffffff811a6cb0>] read_dev_sector+0x30/0xa0 21:44:04 ...: [ 482.520334] [<ffffffff811a7fcd>] amiga_partition+0x6d/0x460 21:44:04 ...: [ 482.520341] [<ffffffff811a7938>] check_partition+0x138/0x190 21:44:04 ...: [ 482.520348] [<ffffffff811a7a7a>] rescan_partitions+0xea/0x2f0 21:44:04 ...: [ 482.520355] [<ffffffff811744c7>] __blkdev_get+0x267/0x3d0 21:44:04 ...: [ 482.520361] [<ffffffff81174650>] ? blkdev_open+0x0/0xc0 21:44:04 ...: [ 482.520367] [<ffffffff81174640>] blkdev_get+0x10/0x20 21:44:04 ...: [ 482.520373] [<ffffffff811746c1>] blkdev_open+0x71/0xc0 21:44:04 ...: [ 482.520380] [<ffffffff811419f3>] __dentry_open+0x113/0x370 21:44:04 ...: [ 482.520388] [<ffffffff81253f8f>] ? security_inode_permission+0x1f/0x30 21:44:04 ...: [ 482.520396] [<ffffffff8114de3f>] ? inode_permission+0xaf/0xd0 21:44:04 ...: [ 482.520403] [<ffffffff81141d67>] nameidata_to_filp+0x57/0x70 21:44:04 ...: [ 482.520410] [<ffffffff8115207a>] do_filp_open+0x2da/0xba0 21:44:04 ...: [ 482.520417] [<ffffffff811134a8>] ? unmap_vmas+0x178/0x310 21:44:04 ...: [ 482.520426] [<ffffffff8115dbfa>] ? alloc_fd+0x10a/0x150 21:44:04 ...: [ 482.520432] [<ffffffff81141769>] do_sys_open+0x69/0x170 21:44:04 ...: [ 482.520438] [<ffffffff811418b0>] sys_open+0x20/0x30 21:44:04 ...: [ 482.520447] [<ffffffff810121b2>] system_call_fastpath+0x16/0x1b 21:44:04 ...: [ 482.520458] INFO: task mdadm:2283 blocked for more than 120 seconds. 21:44:04 ...: [ 482.520462] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. 21:44:04 ...: [ 482.520467] mdadm D 0000000000000000 0 2283 2212 0x00000000 21:44:04 ...: [ 482.520475] ffff88002cca7d98 0000000000000086 0000000000015bc0 0000000000015bc0 21:44:04 ...: [ 482.520483] ffff88002ededf78 ffff88002cca7fd8 0000000000015bc0 ffff88002ededbc0 21:44:04 ...: [ 482.520490] 0000000000015bc0 ffff88002cca7fd8 0000000000015bc0 ffff88002ededf78 21:44:04 ...: [ 482.520498] Call Trace: 21:44:04 ...: [ 482.520508] [<ffffffff81543a97>] __mutex_lock_slowpath+0xf7/0x180 21:44:04 ...: [ 482.520515] [<ffffffff8154397b>] mutex_lock+0x2b/0x50 21:44:04 ...: [ 482.520521] [<ffffffff8117404d>] __blkdev_put+0x3d/0x190 21:44:04 ...: [ 482.520527] [<ffffffff811741b0>] blkdev_put+0x10/0x20 21:44:04 ...: [ 482.520533] [<ffffffff811741f3>] blkdev_close+0x33/0x60 21:44:04 ...: [ 482.520541] [<ffffffff81145375>] __fput+0xf5/0x210 21:44:04 ...: [ 482.520547] [<ffffffff811454b5>] fput+0x25/0x30 21:44:04 ...: [ 482.520554] [<ffffffff811415ad>] filp_close+0x5d/0x90 21:44:04 ...: [ 482.520560] [<ffffffff81141697>] sys_close+0xb7/0x120 21:44:04 ...: [ 482.520568] [<ffffffff810121b2>] system_call_fastpath+0x16/0x1b 21:44:04 ...: [ 482.520574] INFO: task md0_reshape:2287 blocked for more than 120 seconds. 21:44:04 ...: [ 482.520578] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. 21:44:04 ...: [ 482.520582] md0_reshape D ffff88003aee96f0 0 2287 2 0x00000000 21:44:04 ...: [ 482.520590] ffff88003cf05a70 0000000000000046 0000000000015bc0 0000000000015bc0 21:44:04 ...: [ 482.520597] ffff88003aee9aa8 ffff88003cf05fd8 0000000000015bc0 ffff88003aee96f0 21:44:04 ...: [ 482.520605] 0000000000015bc0 ffff88003cf05fd8 0000000000015bc0 ffff88003aee9aa8 21:44:04 ...: [ 482.520612] Call Trace: 21:44:04 ...: [ 482.520623] [<ffffffffa0224892>] get_active_stripe+0x312/0x3f0 [raid456] 21:44:04 ...: [ 482.520633] [<ffffffff81059ae0>] ? default_wake_function+0x0/0x20 21:44:04 ...: [ 482.520643] [<ffffffffa0226f80>] reshape_request+0x4c0/0x9a0 [raid456] 21:44:04 ...: [ 482.520651] [<ffffffff81084790>] ? autoremove_wake_function+0x0/0x40 21:44:04 ...: [ 482.520661] [<ffffffffa022777a>] sync_request+0x31a/0x3a0 [raid456] 21:44:04 ...: [ 482.520668] [<ffffffff81052713>] ? __wake_up+0x53/0x70 21:44:04 ...: [ 482.520675] [<ffffffff814156b1>] md_do_sync+0x621/0xbb0 21:44:04 ...: [ 482.520685] [<ffffffff810387b9>] ? default_spin_lock_flags+0x9/0x10 21:44:04 ...: [ 482.520692] [<ffffffff8141640c>] md_thread+0x5c/0x130 21:44:04 ...: [ 482.520699] [<ffffffff81084790>] ? autoremove_wake_function+0x0/0x40 21:44:04 ...: [ 482.520705] [<ffffffff814163b0>] ? md_thread+0x0/0x130 21:44:04 ...: [ 482.520711] [<ffffffff81084416>] kthread+0x96/0xa0 21:44:04 ...: [ 482.520718] [<ffffffff810131ea>] child_rip+0xa/0x20 21:44:04 ...: [ 482.520725] [<ffffffff81084380>] ? kthread+0x0/0xa0 21:44:04 ...: [ 482.520730] [<ffffffff810131e0>] ? child_rip+0x0/0x20 21:44:04 ...: [ 482.520735] INFO: task mdadm:2288 blocked for more than 120 seconds. 21:44:04 ...: [ 482.520739] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. 21:44:04 ...: [ 482.520743] mdadm D 0000000000000000 0 2288 1 0x00000000 21:44:04 ...: [ 482.520751] ffff88002cca9c18 0000000000000086 0000000000015bc0 0000000000015bc0 21:44:04 ...: [ 482.520759] ffff88003aee83b8 ffff88002cca9fd8 0000000000015bc0 ffff88003aee8000 21:44:04 ...: [ 482.520767] 0000000000015bc0 ffff88002cca9fd8 0000000000015bc0 ffff88003aee83b8 21:44:04 ...: [ 482.520774] Call Trace: 21:44:04 ...: [ 482.520782] [<ffffffff81543a97>] __mutex_lock_slowpath+0xf7/0x180 21:44:04 ...: [ 482.520790] [<ffffffff812a6d50>] ? exact_match+0x0/0x10 21:44:04 ...: [ 482.520797] [<ffffffff8154397b>] mutex_lock+0x2b/0x50 21:44:04 ...: [ 482.520804] [<ffffffff811742c8>] __blkdev_get+0x68/0x3d0 21:44:04 ...: [ 482.520810] [<ffffffff81174650>] ? blkdev_open+0x0/0xc0 21:44:04 ...: [ 482.520816] [<ffffffff81174640>] blkdev_get+0x10/0x20 21:44:04 ...: [ 482.520822] [<ffffffff811746c1>] blkdev_open+0x71/0xc0 21:44:04 ...: [ 482.520829] [<ffffffff811419f3>] __dentry_open+0x113/0x370 21:44:04 ...: [ 482.520837] [<ffffffff81253f8f>] ? security_inode_permission+0x1f/0x30 21:44:04 ...: [ 482.520843] [<ffffffff8114de3f>] ? inode_permission+0xaf/0xd0 21:44:04 ...: [ 482.520850] [<ffffffff81141d67>] nameidata_to_filp+0x57/0x70 21:44:04 ...: [ 482.520857] [<ffffffff8115207a>] do_filp_open+0x2da/0xba0 21:44:04 ...: [ 482.520864] [<ffffffff810ff0e1>] ? lru_cache_add_lru+0x21/0x40 21:44:04 ...: [ 482.520871] [<ffffffff8111109c>] ? do_anonymous_page+0x11c/0x330 21:44:04 ...: [ 482.520878] [<ffffffff81115d5f>] ? handle_mm_fault+0x31f/0x3c0 21:44:04 ...: [ 482.520885] [<ffffffff8115dbfa>] ? alloc_fd+0x10a/0x150 21:44:04 ...: [ 482.520891] [<ffffffff81141769>] do_sys_open+0x69/0x170 21:44:04 ...: [ 482.520897] [<ffffffff811418b0>] sys_open+0x20/0x30 21:44:04 ...: [ 482.520905] [<ffffffff810121b2>] system_call_fastpath+0x16/0x1b 21:46:04 ...: [ 602.520053] INFO: task mdadm:1937 blocked for more than 120 seconds. 21:46:04 ...: [ 602.520059] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. 21:46:04 ...: [ 602.520065] mdadm D 00000000ffffffff 0 1937 1 0x00000000 21:46:04 ...: [ 602.520075] ffff88002ef4f5d8 0000000000000082 0000000000015bc0 0000000000015bc0 21:46:04 ...: [ 602.520084] ffff88002eb5b198 ffff88002ef4ffd8 0000000000015bc0 ffff88002eb5ade0 21:46:04 ...: [ 602.520091] 0000000000015bc0 ffff88002ef4ffd8 0000000000015bc0 ffff88002eb5b198 21:46:04 ...: [ 602.520099] Call Trace: 21:46:04 ...: [ 602.520127] [<ffffffffa0224892>] get_active_stripe+0x312/0x3f0 [raid456] 21:46:04 ...: [ 602.520142] [<ffffffff81059ae0>] ? default_wake_function+0x0/0x20 21:46:04 ...: [ 602.520153] [<ffffffffa0228413>] make_request+0x243/0x4b0 [raid456] 21:46:04 ...: [ 602.520162] [<ffffffffa0221a90>] ? release_stripe+0x50/0x70 [raid456] 21:46:04 ...: [ 602.520171] [<ffffffff81084790>] ? autoremove_wake_function+0x0/0x40 21:46:04 ...: [ 602.520180] [<ffffffff81414df0>] md_make_request+0xc0/0x130 21:46:04 ...: [ 602.520187] [<ffffffff81414df0>] ? md_make_request+0xc0/0x130 21:46:04 ...: [ 602.520197] [<ffffffff8129f8c1>] generic_make_request+0x1b1/0x4f0 21:46:04 ...: [ 602.520206] [<ffffffff810f6515>] ? mempool_alloc_slab+0x15/0x20 21:46:04 ...: [ 602.520215] [<ffffffff8116c2ec>] ? alloc_buffer_head+0x1c/0x60 21:46:04 ...: [ 602.520222] [<ffffffff8129fc80>] submit_bio+0x80/0x110 21:46:04 ...: [ 602.520229] [<ffffffff8116c849>] submit_bh+0xf9/0x140 21:46:04 ...: [ 602.520237] [<ffffffff8116f124>] block_read_full_page+0x274/0x3b0 21:46:04 ...: [ 602.520244] [<ffffffff81172c90>] ? blkdev_get_block+0x0/0x70 21:46:04 ...: [ 602.520252] [<ffffffff8110d875>] ? __inc_zone_page_state+0x35/0x40 21:46:04 ...: [ 602.520259] [<ffffffff810f46d8>] ? add_to_page_cache_locked+0xe8/0x160 21:46:04 ...: [ 602.520266] [<ffffffff81173d78>] blkdev_readpage+0x18/0x20 21:46:04 ...: [ 602.520273] [<ffffffff810f484b>] __read_cache_page+0x7b/0xe0 21:46:04 ...: [ 602.520279] [<ffffffff81173d60>] ? blkdev_readpage+0x0/0x20 21:46:04 ...: [ 602.520285] [<ffffffff81173d60>] ? blkdev_readpage+0x0/0x20 21:46:04 ...: [ 602.520292] [<ffffffff810f57dc>] do_read_cache_page+0x3c/0x120 21:46:04 ...: [ 602.520300] [<ffffffff810f5909>] read_cache_page_async+0x19/0x20 21:46:04 ...: [ 602.520306] [<ffffffff810f591e>] read_cache_page+0xe/0x20 21:46:04 ...: [ 602.520314] [<ffffffff811a6cb0>] read_dev_sector+0x30/0xa0 21:46:04 ...: [ 602.520321] [<ffffffff811a7fcd>] amiga_partition+0x6d/0x460 21:46:04 ...: [ 602.520328] [<ffffffff811a7938>] check_partition+0x138/0x190 21:46:04 ...: [ 602.520335] [<ffffffff811a7a7a>] rescan_partitions+0xea/0x2f0 21:46:04 ...: [ 602.520342] [<ffffffff811744c7>] __blkdev_get+0x267/0x3d0 21:46:04 ...: [ 602.520348] [<ffffffff81174650>] ? blkdev_open+0x0/0xc0 21:46:04 ...: [ 602.520354] [<ffffffff81174640>] blkdev_get+0x10/0x20 21:46:04 ...: [ 602.520359] [<ffffffff811746c1>] blkdev_open+0x71/0xc0 21:46:04 ...: [ 602.520367] [<ffffffff811419f3>] __dentry_open+0x113/0x370 21:46:04 ...: [ 602.520375] [<ffffffff81253f8f>] ? security_inode_permission+0x1f/0x30 21:46:04 ...: [ 602.520383] [<ffffffff8114de3f>] ? inode_permission+0xaf/0xd0 21:46:04 ...: [ 602.520390] [<ffffffff81141d67>] nameidata_to_filp+0x57/0x70 21:46:04 ...: [ 602.520397] [<ffffffff8115207a>] do_filp_open+0x2da/0xba0 21:46:04 ...: [ 602.520404] [<ffffffff811134a8>] ? unmap_vmas+0x178/0x310 21:46:04 ...: [ 602.520413] [<ffffffff8115dbfa>] ? alloc_fd+0x10a/0x150 21:46:04 ...: [ 602.520419] [<ffffffff81141769>] do_sys_open+0x69/0x170 21:46:04 ...: [ 602.520425] [<ffffffff811418b0>] sys_open+0x20/0x30 21:46:04 ...: [ 602.520434] [<ffffffff810121b2>] system_call_fastpath+0x16/0x1b 21:46:04 ...: [ 602.520443] INFO: task mdadm:2283 blocked for more than 120 seconds. 21:46:04 ...: [ 602.520447] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. 21:46:04 ...: [ 602.520451] mdadm D 0000000000000000 0 2283 2212 0x00000000 21:46:04 ...: [ 602.520460] ffff88002cca7d98 0000000000000086 0000000000015bc0 0000000000015bc0 21:46:04 ...: [ 602.520468] ffff88002ededf78 ffff88002cca7fd8 0000000000015bc0 ffff88002ededbc0 21:46:04 ...: [ 602.520475] 0000000000015bc0 ffff88002cca7fd8 0000000000015bc0 ffff88002ededf78 21:46:04 ...: [ 602.520483] Call Trace: 21:46:04 ...: [ 602.520492] [<ffffffff81543a97>] __mutex_lock_slowpath+0xf7/0x180 21:46:04 ...: [ 602.520500] [<ffffffff8154397b>] mutex_lock+0x2b/0x50 21:46:04 ...: [ 602.520506] [<ffffffff8117404d>] __blkdev_put+0x3d/0x190 21:46:04 ...: [ 602.520512] [<ffffffff811741b0>] blkdev_put+0x10/0x20 21:46:04 ...: [ 602.520518] [<ffffffff811741f3>] blkdev_close+0x33/0x60 21:46:04 ...: [ 602.520526] [<ffffffff81145375>] __fput+0xf5/0x210 21:46:04 ...: [ 602.520533] [<ffffffff811454b5>] fput+0x25/0x30 21:46:04 ...: [ 602.520539] [<ffffffff811415ad>] filp_close+0x5d/0x90 21:46:04 ...: [ 602.520545] [<ffffffff81141697>] sys_close+0xb7/0x120 21:46:04 ...: [ 602.520552] [<ffffffff810121b2>] system_call_fastpath+0x16/0x1b

  Read the article

• dbus dependency with yum

  - by Hengjie

  Whenever, I try and run yum update I get the following error: [root@server ~]# yum update Loaded plugins: dellsysid, fastestmirror Loading mirror speeds from cached hostfile * base: mirror01.idc.hinet.net * extras: mirror01.idc.hinet.net * rpmforge: fr2.rpmfind.net * updates: mirror01.idc.hinet.net Excluding Packages in global exclude list Finished Setting up Update Process Resolving Dependencies --> Running transaction check ---> Package NetworkManager.x86_64 1:0.7.0-13.el5 set to be updated ---> Package NetworkManager-glib.x86_64 1:0.7.0-13.el5 set to be updated ---> Package SysVinit.x86_64 0:2.86-17.el5 set to be updated ---> Package acl.x86_64 0:2.2.39-8.el5 set to be updated ---> Package acpid.x86_64 0:1.0.4-12.el5 set to be updated ---> Package apr.x86_64 0:1.2.7-11.el5_6.5 set to be updated ---> Package aspell.x86_64 12:0.60.3-12 set to be updated ---> Package audit.x86_64 0:1.8-2.el5 set to be updated ---> Package audit-libs.x86_64 0:1.8-2.el5 set to be updated ---> Package audit-libs-python.x86_64 0:1.8-2.el5 set to be updated ---> Package authconfig.x86_64 0:5.3.21-7.el5 set to be updated ---> Package autofs.x86_64 1:5.0.1-0.rc2.163.el5 set to be updated ---> Package bash.x86_64 0:3.2-32.el5 set to be updated ---> Package bind.x86_64 30:9.3.6-20.P1.el5 set to be updated ---> Package bind-libs.x86_64 30:9.3.6-20.P1.el5 set to be updated ---> Package bind-utils.x86_64 30:9.3.6-20.P1.el5 set to be updated ---> Package binutils.x86_64 0:2.17.50.0.6-20.el5 set to be updated ---> Package centos-release.x86_64 10:5-8.el5.centos set to be updated ---> Package centos-release-notes.x86_64 0:5.8-0 set to be updated ---> Package coreutils.x86_64 0:5.97-34.el5_8.1 set to be updated ---> Package cpp.x86_64 0:4.1.2-52.el5 set to be updated ---> Package cpuspeed.x86_64 1:1.2.1-10.el5 set to be updated ---> Package crash.x86_64 0:5.1.8-1.el5.centos set to be updated ---> Package cryptsetup-luks.x86_64 0:1.0.3-8.el5 set to be updated ---> Package cups.x86_64 1:1.3.7-30.el5 set to be updated ---> Package cups-libs.x86_64 1:1.3.7-30.el5 set to be updated ---> Package curl.x86_64 0:7.15.5-15.el5 set to be updated --> Processing Dependency: dbus = 1.1.2-15.el5_6 for package: dbus-libs ---> Package dbus.x86_64 0:1.1.2-16.el5_7 set to be updated ---> Package dbus-libs.x86_64 0:1.1.2-16.el5_7 set to be updated ---> Package device-mapper.x86_64 0:1.02.67-2.el5 set to be updated ---> Package device-mapper-event.x86_64 0:1.02.67-2.el5 set to be updated ---> Package device-mapper-multipath.x86_64 0:0.4.7-48.el5_8.1 set to be updated ---> Package dhclient.x86_64 12:3.0.5-31.el5 set to be updated ---> Package dmidecode.x86_64 1:2.11-1.el5 set to be updated ---> Package dmraid.x86_64 0:1.0.0.rc13-65.el5 set to be updated ---> Package dmraid-events.x86_64 0:1.0.0.rc13-65.el5 set to be updated ---> Package dump.x86_64 0:0.4b41-6.el5 set to be updated ---> Package e2fsprogs.x86_64 0:1.39-33.el5 set to be updated ---> Package e2fsprogs-devel.x86_64 0:1.39-33.el5 set to be updated ---> Package e2fsprogs-libs.x86_64 0:1.39-33.el5 set to be updated ---> Package ecryptfs-utils.x86_64 0:75-8.el5 set to be updated ---> Package file.x86_64 0:4.17-21 set to be updated ---> Package finger.x86_64 0:0.17-33 set to be updated ---> Package firstboot-tui.x86_64 0:1.4.27.9-1.el5.centos set to be updated ---> Package freetype.x86_64 0:2.2.1-28.el5_7.2 set to be updated ---> Package freetype-devel.x86_64 0:2.2.1-28.el5_7.2 set to be updated ---> Package ftp.x86_64 0:0.17-37.el5 set to be updated ---> Package gamin.x86_64 0:0.1.7-10.el5 set to be updated ---> Package gamin-python.x86_64 0:0.1.7-10.el5 set to be updated ---> Package gawk.x86_64 0:3.1.5-15.el5 set to be updated ---> Package gcc.x86_64 0:4.1.2-52.el5 set to be updated ---> Package gcc-c++.x86_64 0:4.1.2-52.el5 set to be updated ---> Package glibc.i686 0:2.5-81.el5_8.1 set to be updated ---> Package glibc.x86_64 0:2.5-81.el5_8.1 set to be updated ---> Package glibc-common.x86_64 0:2.5-81.el5_8.1 set to be updated ---> Package glibc-devel.x86_64 0:2.5-81.el5_8.1 set to be updated ---> Package glibc-headers.x86_64 0:2.5-81.el5_8.1 set to be updated ---> Package gnutls.x86_64 0:1.4.1-7.el5_8.2 set to be updated ---> Package groff.x86_64 0:1.18.1.1-13.el5 set to be updated ---> Package gtk2.x86_64 0:2.10.4-21.el5_7.7 set to be updated ---> Package gzip.x86_64 0:1.3.5-13.el5.centos set to be updated ---> Package hmaccalc.x86_64 0:0.9.6-4.el5 set to be updated ---> Package htop.x86_64 0:1.0.1-2.el5.rf set to be updated ---> Package hwdata.noarch 0:0.213.26-1.el5 set to be updated ---> Package ifd-egate.x86_64 0:0.05-17.el5 set to be updated ---> Package initscripts.x86_64 0:8.45.42-1.el5.centos set to be updated ---> Package iproute.x86_64 0:2.6.18-13.el5 set to be updated ---> Package iptables.x86_64 0:1.3.5-9.1.el5 set to be updated ---> Package iptables-ipv6.x86_64 0:1.3.5-9.1.el5 set to be updated ---> Package iscsi-initiator-utils.x86_64 0:6.2.0.872-13.el5 set to be updated ---> Package kernel.x86_64 0:2.6.18-308.1.1.el5 set to be installed ---> Package kernel-headers.x86_64 0:2.6.18-308.1.1.el5 set to be updated ---> Package kpartx.x86_64 0:0.4.7-48.el5_8.1 set to be updated ---> Package krb5-devel.x86_64 0:1.6.1-70.el5 set to be updated ---> Package krb5-libs.x86_64 0:1.6.1-70.el5 set to be updated ---> Package krb5-workstation.x86_64 0:1.6.1-70.el5 set to be updated ---> Package ksh.x86_64 0:20100621-5.el5_8.1 set to be updated ---> Package kudzu.x86_64 0:1.2.57.1.26-3.el5.centos set to be updated ---> Package less.x86_64 0:436-9.el5 set to be updated ---> Package lftp.x86_64 0:3.7.11-7.el5 set to be updated ---> Package libX11.x86_64 0:1.0.3-11.el5_7.1 set to be updated ---> Package libX11-devel.x86_64 0:1.0.3-11.el5_7.1 set to be updated ---> Package libXcursor.x86_64 0:1.1.7-1.2 set to be updated ---> Package libacl.x86_64 0:2.2.39-8.el5 set to be updated ---> Package libgcc.x86_64 0:4.1.2-52.el5 set to be updated ---> Package libgomp.x86_64 0:4.4.6-3.el5.1 set to be updated ---> Package libpng.x86_64 2:1.2.10-16.el5_8 set to be updated ---> Package libpng-devel.x86_64 2:1.2.10-16.el5_8 set to be updated ---> Package libsmbios.x86_64 0:2.2.27-3.2.el5 set to be updated ---> Package libstdc++.x86_64 0:4.1.2-52.el5 set to be updated ---> Package libstdc++-devel.x86_64 0:4.1.2-52.el5 set to be updated ---> Package libsysfs.x86_64 0:2.1.0-1.el5 set to be updated ---> Package libusb.x86_64 0:0.1.12-6.el5 set to be updated ---> Package libvolume_id.x86_64 0:095-14.27.el5_7.1 set to be updated ---> Package libxml2.x86_64 0:2.6.26-2.1.15.el5_8.2 set to be updated ---> Package libxml2-python.x86_64 0:2.6.26-2.1.15.el5_8.2 set to be updated ---> Package logrotate.x86_64 0:3.7.4-12 set to be updated ---> Package lsof.x86_64 0:4.78-6 set to be updated ---> Package lvm2.x86_64 0:2.02.88-7.el5 set to be updated ---> Package m2crypto.x86_64 0:0.16-8.el5 set to be updated ---> Package man.x86_64 0:1.6d-2.el5 set to be updated ---> Package man-pages.noarch 0:2.39-20.el5 set to be updated ---> Package mcelog.x86_64 1:0.9pre-1.32.el5 set to be updated ---> Package mesa-libGL.x86_64 0:6.5.1-7.10.el5 set to be updated ---> Package mesa-libGL-devel.x86_64 0:6.5.1-7.10.el5 set to be updated ---> Package microcode_ctl.x86_64 2:1.17-1.56.el5 set to be updated ---> Package mkinitrd.x86_64 0:5.1.19.6-75.el5 set to be updated ---> Package mktemp.x86_64 3:1.5-24.el5 set to be updated --> Processing Dependency: nash = 5.1.19.6-68.el5_6.1 for package: mkinitrd ---> Package nash.x86_64 0:5.1.19.6-75.el5 set to be updated ---> Package net-snmp.x86_64 1:5.3.2.2-17.el5 set to be updated ---> Package net-snmp-devel.x86_64 1:5.3.2.2-17.el5 set to be updated ---> Package net-snmp-libs.x86_64 1:5.3.2.2-17.el5 set to be updated ---> Package net-snmp-utils.x86_64 1:5.3.2.2-17.el5 set to be updated ---> Package net-tools.x86_64 0:1.60-82.el5 set to be updated ---> Package nfs-utils.x86_64 1:1.0.9-60.el5 set to be updated ---> Package nfs-utils-lib.x86_64 0:1.0.8-7.9.el5 set to be updated ---> Package nscd.x86_64 0:2.5-81.el5_8.1 set to be updated ---> Package nspr.x86_64 0:4.8.9-1.el5_8 set to be updated ---> Package nspr-devel.x86_64 0:4.8.9-1.el5_8 set to be updated ---> Package nss.x86_64 0:3.13.1-5.el5_8 set to be updated ---> Package nss-devel.x86_64 0:3.13.1-5.el5_8 set to be updated ---> Package nss-tools.x86_64 0:3.13.1-5.el5_8 set to be updated ---> Package nss_ldap.x86_64 0:253-49.el5 set to be updated ---> Package ntp.x86_64 0:4.2.2p1-15.el5.centos.1 set to be updated ---> Package numactl.x86_64 0:0.9.8-12.el5_6 set to be updated ---> Package oddjob.x86_64 0:0.27-12.el5 set to be updated ---> Package oddjob-libs.x86_64 0:0.27-12.el5 set to be updated ---> Package openldap.x86_64 0:2.3.43-25.el5 set to be updated ---> Package openssh.x86_64 0:4.3p2-82.el5 set to be updated ---> Package openssh-clients.x86_64 0:4.3p2-82.el5 set to be updated ---> Package openssh-server.x86_64 0:4.3p2-82.el5 set to be updated ---> Package openssl.i686 0:0.9.8e-22.el5_8.1 set to be updated ---> Package openssl.x86_64 0:0.9.8e-22.el5_8.1 set to be updated ---> Package openssl-devel.x86_64 0:0.9.8e-22.el5_8.1 set to be updated ---> Package pam_krb5.x86_64 0:2.2.14-22.el5 set to be updated ---> Package pam_pkcs11.x86_64 0:0.5.3-26.el5 set to be updated ---> Package pango.x86_64 0:1.14.9-8.el5.centos.3 set to be updated ---> Package parted.x86_64 0:1.8.1-29.el5 set to be updated ---> Package pciutils.x86_64 0:3.1.7-5.el5 set to be updated ---> Package perl.x86_64 4:5.8.8-38.el5 set to be updated ---> Package perl-Compress-Raw-Bzip2.x86_64 0:2.037-1.el5.rf set to be updated ---> Package perl-Compress-Raw-Zlib.x86_64 0:2.037-1.el5.rf set to be updated ---> Package perl-rrdtool.x86_64 0:1.4.7-1.el5.rf set to be updated ---> Package poppler.x86_64 0:0.5.4-19.el5 set to be updated ---> Package poppler-utils.x86_64 0:0.5.4-19.el5 set to be updated ---> Package popt.x86_64 0:1.10.2.3-28.el5_8 set to be updated ---> Package postgresql-libs.x86_64 0:8.1.23-1.el5_7.3 set to be updated ---> Package procps.x86_64 0:3.2.7-18.el5 set to be updated ---> Package proftpd.x86_64 0:1.3.4a-1.el5.rf set to be updated --> Processing Dependency: perl(Mail::Sendmail) for package: proftpd ---> Package python.x86_64 0:2.4.3-46.el5 set to be updated ---> Package python-ctypes.x86_64 0:1.0.2-3.el5 set to be updated ---> Package python-libs.x86_64 0:2.4.3-46.el5 set to be updated ---> Package python-smbios.x86_64 0:2.2.27-3.2.el5 set to be updated ---> Package rhpl.x86_64 0:0.194.1-2 set to be updated ---> Package rmt.x86_64 0:0.4b41-6.el5 set to be updated ---> Package rng-utils.x86_64 1:2.0-5.el5 set to be updated ---> Package rpm.x86_64 0:4.4.2.3-28.el5_8 set to be updated ---> Package rpm-build.x86_64 0:4.4.2.3-28.el5_8 set to be updated ---> Package rpm-devel.x86_64 0:4.4.2.3-28.el5_8 set to be updated ---> Package rpm-libs.x86_64 0:4.4.2.3-28.el5_8 set to be updated ---> Package rpm-python.x86_64 0:4.4.2.3-28.el5_8 set to be updated ---> Package rrdtool.x86_64 0:1.4.7-1.el5.rf set to be updated ---> Package rsh.x86_64 0:0.17-40.el5_7.1 set to be updated ---> Package rsync.x86_64 0:3.0.6-4.el5_7.1 set to be updated ---> Package ruby.x86_64 0:1.8.5-24.el5 set to be updated ---> Package ruby-libs.x86_64 0:1.8.5-24.el5 set to be updated ---> Package sblim-sfcb.x86_64 0:1.3.11-49.el5 set to be updated ---> Package sblim-sfcc.x86_64 0:2.2.2-49.el5 set to be updated ---> Package selinux-policy.noarch 0:2.4.6-327.el5 set to be updated ---> Package selinux-policy-targeted.noarch 0:2.4.6-327.el5 set to be updated ---> Package setup.noarch 0:2.5.58-9.el5 set to be updated ---> Package shadow-utils.x86_64 2:4.0.17-20.el5 set to be updated ---> Package smartmontools.x86_64 1:5.38-3.el5 set to be updated ---> Package smbios-utils-bin.x86_64 0:2.2.27-3.2.el5 set to be updated ---> Package smbios-utils-python.x86_64 0:2.2.27-3.2.el5 set to be updated ---> Package sos.noarch 0:1.7-9.62.el5 set to be updated ---> Package srvadmin-omilcore.x86_64 0:6.5.0-1.452.1.el5 set to be updated ---> Package strace.x86_64 0:4.5.18-11.el5_8 set to be updated ---> Package subversion.x86_64 0:1.6.11-7.el5_6.4 set to be updated ---> Package sudo.x86_64 0:1.7.2p1-13.el5 set to be updated ---> Package sysfsutils.x86_64 0:2.1.0-1.el5 set to be updated ---> Package syslinux.x86_64 0:3.11-7 set to be updated ---> Package system-config-network-tui.noarch 0:1.3.99.21-1.el5 set to be updated ---> Package talk.x86_64 0:0.17-31.el5 set to be updated ---> Package tar.x86_64 2:1.15.1-31.el5 set to be updated ---> Package traceroute.x86_64 3:2.0.1-6.el5 set to be updated ---> Package tzdata.x86_64 0:2012b-3.el5 set to be updated ---> Package udev.x86_64 0:095-14.27.el5_7.1 set to be updated ---> Package util-linux.x86_64 0:2.13-0.59.el5 set to be updated ---> Package vixie-cron.x86_64 4:4.1-81.el5 set to be updated ---> Package wget.x86_64 0:1.11.4-3.el5_8.1 set to be updated ---> Package xinetd.x86_64 2:2.3.14-16.el5 set to be updated ---> Package yp-tools.x86_64 0:2.9-2.el5 set to be updated ---> Package ypbind.x86_64 3:1.19-12.el5_6.1 set to be updated ---> Package yum.noarch 0:3.2.22-39.el5.centos set to be updated ---> Package yum-dellsysid.x86_64 0:2.2.27-3.2.el5 set to be updated ---> Package yum-fastestmirror.noarch 0:1.1.16-21.el5.centos set to be updated ---> Package zlib.x86_64 0:1.2.3-4.el5 set to be updated ---> Package zlib-devel.x86_64 0:1.2.3-4.el5 set to be updated --> Running transaction check --> Processing Dependency: dbus = 1.1.2-15.el5_6 for package: dbus-libs --> Processing Dependency: nash = 5.1.19.6-68.el5_6.1 for package: mkinitrd ---> Package perl-Mail-Sendmail.noarch 0:0.79-1.2.el5.rf set to be updated base/filelists | 3.5 MB 00:00 dell-omsa-indep/filelists | 195 kB 00:01 dell-omsa-specific/filelists | 1.0 kB 00:00 extras/filelists_db | 224 kB 00:00 rpmforge/filelists | 4.8 MB 00:06 updates/filelists_db | 715 kB 00:00 --> Finished Dependency Resolution dbus-libs-1.1.2-15.el5_6.i386 from installed has depsolving problems --> Missing Dependency: dbus = 1.1.2-15.el5_6 is needed by package dbus-libs-1.1.2-15.el5_6.i386 (installed) mkinitrd-5.1.19.6-68.el5_6.1.i386 from installed has depsolving problems --> Missing Dependency: nash = 5.1.19.6-68.el5_6.1 is needed by package mkinitrd-5.1.19.6-68.el5_6.1.i386 (installed) Error: Missing Dependency: nash = 5.1.19.6-68.el5_6.1 is needed by package mkinitrd-5.1.19.6-68.el5_6.1.i386 (installed) Error: Missing Dependency: dbus = 1.1.2-15.el5_6 is needed by package dbus-libs-1.1.2-15.el5_6.i386 (installed) You could try using --skip-broken to work around the problem You could try running: package-cleanup --problems package-cleanup --dupes rpm -Va --nofiles --nodigest The program package-cleanup is found in the yum-utils package. I have tried running package-cleanup --dupes and package-cleanup --problems but to no avail.

  Read the article

< Previous Page | 1 2 3