You are not logged in.
While troubleshooting the failures of my raid0 bootable Compact Flash devices, I proceeded to perform the following setup.
I first upgraded my system in the raid0 kernel 2.6.39.3-1 with a download via pacman -Syu. Total packages downloaded was 317. Linux kernel 3.1.4 was not accepted for download. All packages were successfully downloaded and installed( rm/etc/profile.d/xxxx.sh was removed). The device was recognized in /etc/proc/mdstat as /dev/md0.
Therefore all items concerned with the latest packages were installed. This without the new kernel 3.1.4. I upgraded mirrorlist which was included in the packages. I then rebooted into my raid0 system successfully. I then upgraded to linux 3.1.4 kernel with pacman.
I then rebooted but failed to boot with the error : unable to find /dev/md0...no major-minor number on device by uuidxxxxxxxxxxxxxxxx.
Thus, it seems obvious there is a problem in the linux-3.1.4-1-x86_64.pkg .tar.xz which affects the blkid, using UUID, since previous failures encountered with this kernel indicate that the uuid changed in linux kernels to accept the uuid of the booting device in this case, the boot device is the first device (0) of the two devices(0,1). There are also indications that the /dev/md0 becomes dev md127.
Any guidance to the solution of this discrepancy would be welcomed.
Last edited by lilsirecho (2011-11-16 15:34:12)
Prediction...This year will be a very odd year!
Hard work does not kill people but why risk it: Charlie Mccarthy
A man is not complete until he is married..then..he is finished.
When ALL is lost, what can be found? Even bytes get lonely for a little bit! X-ray confirms Iam spineless!
Offline
During the boot sequence, the following is displayed :
mdadm /dev/md0 has been started with two drives
Waiting 10 seconds for /dev/disk/by-uuid/xxxxxxxxxxxxxxxxxxxxxxxx
Root device /dev/disk/by-uuid doesn't exist..attempting to create it!
ERROR: Unable to determine major-minor of root drive /dev/disk/by-uuid/xxxxxxxxxxxxxxxxxxxx
Dropped to recovery shell,,,,,,
ramfs/]#
This is an unbelievable sequence...first says I found /dev/md0 then in the next breath says it cannot find the root device which is /dev/md0 in this system.
Then it says the major-minor number doesn't show either. Crazy!!!!!
Whazzup?
Prediction...This year will be a very odd year!
Hard work does not kill people but why risk it: Charlie Mccarthy
A man is not complete until he is married..then..he is finished.
When ALL is lost, what can be found? Even bytes get lonely for a little bit! X-ray confirms Iam spineless!
Offline
i have similar problem after upgrade, no ideas and supports for this reason i migrate to LMDE rolling distro too.
i used ARCHLINUX for many years after SLACKWARE.
pacman is wonderful, but ARCH was speedy and clean, in the last period many problem for people that must use laptop for working.
It's a pity
Offline
If you can get back into the installation either using the archlinux CD or a PXE boot, to get to your files and chroot your current volume long enough to install the linux-ck kernel, the ck kernel of 3.1.0-4 is working. Mine had a stall and video black out with the linux 3.1.0-4 linux upgrade.
I may have to CONSOLE you about your usage of ridiculously easy graphical interfaces...
Look ma, no mouse.
Offline
nomore windows:
Your post is prefaced by your ID...I agree with that!!!
But as to your recommend...my system has a root partition which is the raid0 /dev/md0. In addition, it boots from a partition within the raid array.
I cannot AFAICT boot from a partition with the latest kernel install(because I have tried to set it up in the .iso).
I have four instances of bootable raid0 with two drives each which boot into kernel26 but fail when trying to upgrade to linux 3.1.0.4 with a boot sequence that doesn't make sense(as I described).
The raid0 device is started and then ignored in the next step. /dev/md0 is the root device.
Since the linux3.1.0.4 kernel ignores the root device it will do the same in linux-ck AFAICT since it is the same kernel.
My troubleshooting indicates emphatically that the kernel is the troublemaker. Everything works as planned until the kernel is upgraded. All other upgrades were installed previous to the kernel which was upgraded and installed separately.
Prediction...This year will be a very odd year!
Hard work does not kill people but why risk it: Charlie Mccarthy
A man is not complete until he is married..then..he is finished.
When ALL is lost, what can be found? Even bytes get lonely for a little bit! X-ray confirms Iam spineless!
Offline
The kernel by itself isn't much use, but if you're having trouble mounting your root device then it can't access the kernel modules under /lib directory and continue on. Common practice if I remember right, was to have the boot partition all by itself in case the raid wouldn't start for some reason. I remember some older kernels that used md for its' raid control right in the kernel itself. The implementation back then was even though ext3 was out at the time, ext2 was the volume across the raid and the md did all of the housekeeping for the raid volume and included (I think) a journaling scheme. The other kernel that you could possibly try is the lts kernel that should be able to at least mount your raid volume. If you were going (besides the apparent problems with the current kernel) from an older kernel to the most recent, it could mean a big jump. But that's what's nice about kernels, it should be able to work regardless of what setup and files stored otherwise, just as long as the subsequent kernel modules can be accessed.
The ramfs shell can maybe give an idea of what modules are available as a possible way to get back into your system, but not with buggy kernel. (My fallback of the recent kernel didn't work either).
Last edited by nomorewindows (2011-11-11 21:03:03)
I may have to CONSOLE you about your usage of ridiculously easy graphical interfaces...
Look ma, no mouse.
Offline
Upgrade to Linux3.1.1.4 solves the boot problem for my raid0 system but I don't know why!
Prediction...This year will be a very odd year!
Hard work does not kill people but why risk it: Charlie Mccarthy
A man is not complete until he is married..then..he is finished.
When ALL is lost, what can be found? Even bytes get lonely for a little bit! X-ray confirms Iam spineless!
Offline
I have the same problem with my machine.
Every Linux-3.1.x kernel so far gives me the same error, like this one given above:
[...]
[...] ERROR: Unable to determine major-minor of root drive /dev/disk/by-uuid/xxxxxxxxxxxxxxxxxxxx [...]
[...]
Using the kernel-lts works fine; also rolling back to linux-3.0.7-1 works...
Offline
The problem occurs with many users.
My postings in the following arch post may give you a solution. My views are expressed therein and may not be valid(however, I have had messed up downloads with bad mirrors, despite what has been reported in that post)
Anyhow, there have been successful uses of my approach, even though it may seem off base.
I did the complete list of steps to correct my system. It is possible the mirror download did not include initramfs. My approach was to " cover the bases" in proper pacman order not having left out pertinent possibilities and has helped others to correct their problem.
I suggest you read the whole post , decide what might be useable including the recommend from falconindy. He can well be right but why does it hit more than one user?
Good luck and let us know how it goes...............
EDIT: The same problem occurred when I upgraded to the latest Kernel. I performed the same procedure I recommended and now have the latest kernel in 3 pairs of CF raid0 cards. They run faster than normal by 50% in hdparm -t. I attribute this to the raid0 mode striping.
It is not apparent to me what order of install or what speed of performance is applicable to pacman when downloading the core items in archlinux. Perhaps a delay(ugh) is needed for initramfs to properly install.
All of pacman is a black art but most definitely needs to be run according to hoyle but system changes such as initramfs need to be compatible with pacman if that is the problem with upgrades(as suggested by falconindy) .
I expect the next kernel upgrade to cause the same failure based on past experience with linux kernels.
Last edited by lilsirecho (2011-11-17 22:08:32)
Prediction...This year will be a very odd year!
Hard work does not kill people but why risk it: Charlie Mccarthy
A man is not complete until he is married..then..he is finished.
When ALL is lost, what can be found? Even bytes get lonely for a little bit! X-ray confirms Iam spineless!
Offline
Thanks for your reply!
I still have no luck with recent linux-3.1.1
But think I have an idea.
mkinitpcio gives me this error for 3.1.1 kernel, but not the older kernels:
==> Starting build: 3.1.1-1-ARCH
==> ERROR: module not found: `alim15x3'
==> ERROR: module not found: `ide_pci_generic'
When compiling older kernels without these modules the same startup error happens as with linux-3.1.1 (no hda)
I opened a bug report here
Offline
All right,everyting works again for me!
I just had used the very very old ide subsystem instead of the pata subsystem. Just had to change my disk links from hda to sda after removing the modules alim15x3 and ide_pi_generic from mkinitcpio.conf
Sorry for hijacking this post...
Offline
Pacman -Syu this date installs new initscrips version and linux-3.1.2-1-x85_64.pkg.tar.xz.
Install went without a hitch. This occurs with raid0 bootable system in 64 bit.
Reboot was unsuccessful with the original post error again occuring.
This is the fourth time such an occurence has manifest itself after every upgrade of linux3 type kernel.
Will attempt to correct the problem in chroot and report back with results.
Prediction...This year will be a very odd year!
Hard work does not kill people but why risk it: Charlie Mccarthy
A man is not complete until he is married..then..he is finished.
When ALL is lost, what can be found? Even bytes get lonely for a little bit! X-ray confirms Iam spineless!
Offline
Perhaps the procedure below will provide the proper "fix" for the failure to boot from /dev/md0. This performed in an hdd boot-up.
/mount /dev/md0 /mnt/md
edit /etc/default/grub
Grub_preload_modules= (add raid0) to gpt and msdos in parens....
Save and exit
Reboot.
Successfully rebooted with this change into linux-3.1.2-1-x86_64.pkg.tar.xz with partitioned boot in raid0.
Will attempt this change when upgrading to the next version of linux3 kernel.
EDIT: The procedure noted above did not solve the problem. The following procedure solved the boot problem:
Boot in HDD...mount the boot partition in /mnt...edit grub.cfg as follows:
grub kernel line...add after ro root=/dev/md0
This enables the boot from the parttioned raid0. Please note that the uuid is also provided in the same grub kernel line!
The previous procedure was left in the default grub file.
Last edited by lilsirecho (2011-11-25 01:41:25)
Prediction...This year will be a very odd year!
Hard work does not kill people but why risk it: Charlie Mccarthy
A man is not complete until he is married..then..he is finished.
When ALL is lost, what can be found? Even bytes get lonely for a little bit! X-ray confirms Iam spineless!
Offline