Linux Archive

Linux Archive (http://www.linux-archive.org/)
-   Gentoo Desktop (http://www.linux-archive.org/gentoo-desktop/)
-   -   System problems - some progress (http://www.linux-archive.org/gentoo-desktop/505212-system-problems-some-progress.html)

Lindsay Haisley 03-24-2011 05:16 PM

System problems - some progress
 
On Tue, 2011-03-22 at 00:37 -0100, Jorge Manuel B. S. Vicetto wrote:
> I haven't seen anyone mention that the
> latest udev versions react *very* badly to CONFIG_SYSFS_DEPRECATED_V2.
> So be sure to check if you disable that as iirc udev will refuse to
> create the proper device nodes if that kernel option is active.

Jorge, thanks VERY MUCH for the heads-up on CONFIG_SYSFS_DEPRECATED_V2.
Making sure that this, and CONFIG_SYSFS_DEPRECATED are off in my kernel
config has at least gotten the system to a terminal prompt - no single
user mode and no kernel panic. Nvidia support is broken, so no X, but
that's always a hassle with new kernels and can probably be fixed,
assuming that support for my ancient Nvidia card is still available in
the portage tree and compatible with kernel 2.6.36. I've done this many
times before and I'll deal with it later for this upgrade.

Device mapper configuration seems to be broken, which is where I'm at
now. Kernel config settings for RAID autodetect and device mapper
support are exactly as before, but the RAID subsystem appears to be
stumbling on a device name conflict, which has prevented the LVM VG from
being constituted.

Looking into the kernel log file for the 2.6.36 boot up ...

Mar 24 12:18:53 [kernel] [ 1.229464] md: Autodetecting RAID arrays.
Mar 24 12:18:53 [kernel] [ 1.281388] md: Scanned 2 and added 2 devices.
Mar 24 12:18:53 [kernel] [ 1.281566] md: autorun ...
Mar 24 12:18:53 [kernel] [ 1.281739] md: considering sdc1 ...
Mar 24 12:18:53 [kernel] [ 1.281918] md: adding sdc1 ...
Mar 24 12:18:53 [kernel] [ 1.282096] md: adding sdb1 ...
Mar 24 12:18:53 [kernel] [ 1.282273] md: created md0
Mar 24 12:18:53 [kernel] [ 1.282453] md: bind<sdb1>
Mar 24 12:18:53 [kernel] [ 1.282639] md: bind<sdc1>
Mar 24 12:18:53 [kernel] [ 1.282826] md: running: <sdc1><sdb1>
Mar 24 12:18:53 [kernel] [ 1.283219] md: personality for level 1 is not loaded!
Mar 24 12:18:53 [kernel] [ 1.283401] md: do_md_run() returned -22
Mar 24 12:18:53 [kernel] [ 1.283581] md: md0 still in use.
Mar 24 12:18:53 [kernel] [ 1.283756] md: ... autorun DONE.

This is fubar! There are two RAID arrays which support the missing LVM
volume group, and they're seriously out of kilter here. The correct
configuration, booting from my old kernel, is:

$ cat /proc/mdstat
Personalities : [raid1]
md1 : active raid1 sdc1[0] sdd1[1]
36146112 blocks [2/2] [UU]

md0 : active raid1 sdb1[1] sda1[0]
117218176 blocks [2/2] [UU]

The Linux RAID subsystem is trying to pair drives drives from two
different RAID arrays into a single md! I see the possibility for
serious data corruption here :-( Although it looks as if the RAID
subsystem may have bailed on the RAID array, sensing that something was
awry.

The root of this problem is that on the old kernel, there are both
a /dev/hda1 and a /dev/sda1. The former is a partition on an old PATA
drive, while the latter is a proper component of md0, but when
everything becomes /dev/sdNx, there's an obvious conflict and the RAID
subsystem is getting confused and is obviously not seeing it's sda1.

I suspect that this is why the main VG isn't getting set up. What can
be done about this?

--
Lindsay Haisley | "Fighting against human creativity is like
FMP Computer Services | trying to eradicate dandelions"
512-259-1190 | (Pamela Jones)
http://www.fmp.com |

Edward Martinez 03-24-2011 06:15 PM

System problems - some progress
 
On 03/24/11 11:16, Lindsay Haisley wrote:

On Tue, 2011-03-22 at 00:37 -0100, Jorge Manuel B. S. Vicetto wrote:

I haven't seen anyone mention that the
latest udev versions react *very* badly to CONFIG_SYSFS_DEPRECATED_V2.
So be sure to check if you disable that as iirc udev will refuse to
create the proper device nodes if that kernel option is active.

Jorge, thanks VERY MUCH for the heads-up on CONFIG_SYSFS_DEPRECATED_V2.
Making sure that this, and CONFIG_SYSFS_DEPRECATED are off in my kernel
config has at least gotten the system to a terminal prompt - no single
user mode and no kernel panic. Nvidia support is broken, so no X, but
that's always a hassle with new kernels and can probably be fixed,
assuming that support for my ancient Nvidia card is still available in
the portage tree and compatible with kernel 2.6.36. I've done this many
times before and I'll deal with it later for this upgrade.

Device mapper configuration seems to be broken, which is where I'm at
now. Kernel config settings for RAID autodetect and device mapper
support are exactly as before, but the RAID subsystem appears to be
stumbling on a device name conflict, which has prevented the LVM VG from
being constituted.

Looking into the kernel log file for the 2.6.36 boot up ...

Mar 24 12:18:53 [kernel] [ 1.229464] md: Autodetecting RAID arrays.
Mar 24 12:18:53 [kernel] [ 1.281388] md: Scanned 2 and added 2 devices.
Mar 24 12:18:53 [kernel] [ 1.281566] md: autorun ...
Mar 24 12:18:53 [kernel] [ 1.281739] md: considering sdc1 ...
Mar 24 12:18:53 [kernel] [ 1.281918] md: adding sdc1 ...
Mar 24 12:18:53 [kernel] [ 1.282096] md: adding sdb1 ...
Mar 24 12:18:53 [kernel] [ 1.282273] md: created md0
Mar 24 12:18:53 [kernel] [ 1.282453] md: bind<sdb1>
Mar 24 12:18:53 [kernel] [ 1.282639] md: bind<sdc1>
Mar 24 12:18:53 [kernel] [ 1.282826] md: running:<sdc1><sdb1>
Mar 24 12:18:53 [kernel] [ 1.283219] md: personality for level 1 is not loaded!
Mar 24 12:18:53 [kernel] [ 1.283401] md: do_md_run() returned -22
Mar 24 12:18:53 [kernel] [ 1.283581] md: md0 still in use.
Mar 24 12:18:53 [kernel] [ 1.283756] md: ... autorun DONE.

This is fubar! There are two RAID arrays which support the missing LVM
volume group, and they're seriously out of kilter here. The correct
configuration, booting from my old kernel, is:

$ cat /proc/mdstat
Personalities : [raid1]
md1 : active raid1 sdc1[0] sdd1[1]
36146112 blocks [2/2] [UU]

md0 : active raid1 sdb1[1] sda1[0]
117218176 blocks [2/2] [UU]

The Linux RAID subsystem is trying to pair drives drives from two
different RAID arrays into a single md! I see the possibility for
serious data corruption here :-( Although it looks as if the RAID
subsystem may have bailed on the RAID array, sensing that something was
awry.

The root of this problem is that on the old kernel, there are both
a /dev/hda1 and a /dev/sda1. The former is a partition on an old PATA
drive, while the latter is a proper component of md0, but when
everything becomes /dev/sdNx, there's an obvious conflict and the RAID
subsystem is getting confused and is obviously not seeing it's sda1.

I suspect that this is why the main VG isn't getting set up. What can
be done about this?


Hi,

I think it would be faster with less headaches by reinstalling
Gentoo from the latest stage3 and portage:-)

Lindsay Haisley 03-24-2011 06:44 PM

System problems - some progress
 
On Thu, 2011-03-24 at 12:15 -0700, Edward Martinez wrote:
> I think it would be faster with less headaches by reinstalling
> Gentoo from the latest stage3 and portage:-)

Possibly, but that's unlikely to make this problem go away since it
appears to come from a device naming conflict. This is inherent in the
hardware setup. I've inquired elsewhere regarding moving this matter to
some other list where the participants are more versed in Linux kernel
and system issues. This list seems to have been a poor choice for this
thread, since kernel issues aren't the specialty of the participants,
although several people have been helpful.

The problem should be soluble without reloading the OS. I've made some
progress. If I can solve the dev name conflict issue and get my RAID
arrays reconstituted, then I can deal with the video card issues and I'm
home free :-) I'm sure the naming conflict issue has come up before,
for other people, and someone, somewhere has a solution for it.

Ultimately the path forward will be to build a new desktop box, which
probably won't be running Gentoo. It'll have a much more sane disk
configuration, and won't be subject to other legacy hardware issues
(which I haven't discussed here) than this one is. I'd like to make one
more push with this box, though, to get the immediate problem resolved.

--
Lindsay Haisley | "The difference between a duck is because
FMP Computer Services | one leg is both the same"
512-259-1190 | - Anonymous
http://www.fmp.com |

Paul Hartman 03-24-2011 07:15 PM

System problems - some progress
 
On Thu, Mar 24, 2011 at 1:16 PM, Lindsay Haisley <fmouse-gentoo@fmp.com> wrote:
> The root of this problem is that on the old kernel, there are both
> a /dev/hda1 and a /dev/sda1. *The former is a partition on an old PATA
> drive, while the latter is a proper component of md0, but when
> everything becomes /dev/sdNx, there's an obvious conflict and the RAID
> subsystem is getting confused and is obviously not seeing it's sda1.

Possible alternative is to disable raid autodetection and define the
arrays by UUID in /etc/mdadm.conf so hopefully the device names become
irrelevant at that point.

Edward Martinez 03-24-2011 07:17 PM

System problems - some progress
 
On 03/24/11 12:44, Lindsay Haisley wrote:

I can deal with the video card issues and I'm
home free

** Cool, :-) are
you aware that the nvidia kernel module needs to be reinstall every
time a new linux kernel or current kernel is compiled?



*** code: Important:
Every time you compile a
new kernel
or recompile the current one, you will need to reinstall the nVidia
kernel
modules. An easy way to keep track of modules installed by ebuilds
(such as
nvidia-drivers) is to install sys-kernel/module-rebuild. Once
you've installed it, simply run module-rebuild
populate to populate its
database with a list of packages to be rebuilt. Once you've finished
compiling
or recompiling a kernel, just run module-rebuild
rebuild to rebuild the
drivers for your new kernel./code





http://www.gentoo.org/doc/en/nvidia-guide.xml

Lindsay Haisley 03-24-2011 07:38 PM

System problems - some progress
 
On Thu, 2011-03-24 at 15:15 -0500, Paul Hartman wrote:
> On Thu, Mar 24, 2011 at 1:16 PM, Lindsay Haisley <fmouse-gentoo@fmp.com> wrote:
> > The root of this problem is that on the old kernel, there are both
> > a /dev/hda1 and a /dev/sda1. The former is a partition on an old PATA
> > drive, while the latter is a proper component of md0, but when
> > everything becomes /dev/sdNx, there's an obvious conflict and the RAID
> > subsystem is getting confused and is obviously not seeing it's sda1.
>
> Possible alternative is to disable raid autodetection and define the
> arrays by UUID in /etc/mdadm.conf so hopefully the device names become
> irrelevant at that point.

This is a good idea. I can turn off RAID autodetection in the kernel
config and spec RAID1 instead, since the root fs isn't on a RAID array.

I've found a number of references to putting UUIDs in ARRAY lines
in /etc/mdadm.conf to define the UUID of an array, but none yet to using
UUID specs in DEVICE lines, all of which I've found so far in the online
literature use /dev/xxxx specs. Before I take this step I'm going to
find a more kernel-specific list and ask if this would be appropriate.
I've tripped on RAID array errors before at the expense of days of work
to reconstitute systems and their data. I want to make sure this is
kosher before I go there.

Thanks!

--
Lindsay Haisley | "In an open world, | PGP public key
FMP Computer Services | who needs Windows | available at
512-259-1190 | or Gates" | http://pubkeys.fmp.com
http://www.fmp.com | |


All times are GMT. The time now is 01:53 PM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.