lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [day] [month] [year] [list]
Date:	Mon, 26 Oct 2009 19:47:51 -0600
From:	marcus hall <marcus@...lls.org>
To:	linux-kernel@...r.kernel.org
Subject: Cannot access non-LVM /boot partiton.

Hello..

I have a Fedora system that I recently upgraded to Fedora 11 and subsequently
I cannot access my /boot partition.  I have upgraded several systems without
any problems, and I am not sure what to look at that may be the source of
the problem.  I've asked on the fedora list with no response, and although I
don't think that it is a kernel problem, perhaps somebody can point me to
the right corner of userspace to start looking deeper.

The problem system has a pair of SATA disks that are mirrored.  They each
contain two partitions, a /boot partition on /dev/sda1 and /dev/sdb1, and
an LVM setup on /dev/sda2 and /dev/sdb2.  After booting the system, the
only disk device files in /dev are /dev/sda, /dev/sdb, and /dev/sdb2.  Grub
sees the boot partition just fine and gets into the kernel, which fails
after userspace starts mounting the filesystems because it cannot find /boot.
If I run fdisk, it is happy with the partition table on either disk.

During boot, the kernel seems to be recognizing the partitions on both disks,
since it shows "sda: sda1 sda2" etc.  But, something seems to be disabling
access to the first partition later on.  If I manually create a /dev/sda1
or /dev/sdb1 device file, whenever I try to access it I get ENODEV.

When I try to boot an earlier kernel that the system was running happily on
before, I get the same problems, so I believe that this is due to some change
in user space during the "upgrade".  It does seem reasonable to block access
to the /dev/sdaX devices, since the mirroring works from the /dev/sdbX
devices, and I am suspecting that something is removing /dev/sdb1 because
it has no LVM data on it, or something.  I'm suspecting that this might be
something in udev, but that's a weaker guess.

What could remove access to a disk partition in the kernel after it comes
up?  If I cat /proc/partitions, all I see are the LVM partitions.

Thanks in advance!

Marcus Hall
marcus@...lls.org
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ