Bug#355580: Bug 355580: output of fdisk
On Sun, 19 Mar 2006, Moshe Yudkowsky wrote: > Ok, I've tried that, see below. > > However, if anyone ever has a legitimate reason to use "install," they > will suffer a boot failure and they won't be able to figure out why > there has been a failure. yes will need to consider that. > I set it to linux 83, took out all my modifications, and mdrun does > work. After I end up in busybox, I looked at /proc/mdstat, and I saw > that mdrun had created /dev/md/[012]. > > So mdrun continues to be confused by my configuration. well that sounds cool, just change root=/dev/md0 for grub and fstab and it will work. regards -- maks -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#355580: Bug 355580: output of fdisk
maximilian attems wrote: On Wed, 15 Mar 2006, Moshe Yudkowsky wrote: I added this line to make certain that sata_promise loads before md loads. At one time I had trouble with getting the system to boot, and that line seemed to help by making certain the serial ATA drive module was loaded before md loaded. yes initrd-tools needed that workaround, i'm happy you managed to boot sata with it. please try to remove it, initramfs-tools should load sata_promise just fine. Ok, I've tried that, see below. However, if anyone ever has a legitimate reason to use "install," they will suffer a boot failure and they won't be able to figure out why there has been a failure. Device Boot Start End Blocks Id System /dev/sda1 * 124902893+ fd Linux raid autodetect /dev/sda224912614 996030 fd Linux raid autodetect /dev/sda32615973357183367+ fd Linux raid autodetect /dev/sda49734 1459639062047+ fd Linux raid autodetect from your previous sent fstab the forth entry is false could you please set it to linux 83 that could potentially confuse mdrun, can you retry if fixing that works? I set it to linux 83, took out all my modifications, and mdrun does work. After I end up in busybox, I looked at /proc/mdstat, and I saw that mdrun had created /dev/md/[012]. So mdrun continues to be confused by my configuration. cat /proc/mdstat would be even cooler. Of course! Here it is: Personalities : [linear] [raid0] [raid1] md3 : active raid1 hda3[0] sda3[1] 57183296 blocks [2/2] [UU] md2 : active linear hda2[0] sda2[1] 1991808 blocks 64k rounding md1 : active raid1 hda1[0] sda1[1] 2768 blocks [2/2] [UU] unused devices: and as a bonus, the current fdisk: fdisk -l /dev/sda Disk /dev/sda: 120.0 GB, 120060444672 bytes 255 heads, 63 sectors/track, 14596 cylinders Units = cylinders of 16065 * 512 = 8225280 bytes Device Boot Start End Blocks Id System /dev/sda1 * 124902893+ fd Linux raid autodetect /dev/sda224912614 996030 fd Linux raid autodetect /dev/sda32615973357183367+ fd Linux raid autodetect /dev/sda49734 1459639062047+ 83 Linux Thanks again for your help, and please let me know if you need further tests by me. -- Moshe Yudkowsky * [EMAIL PROTECTED] * www.pobox.com/~moshe "You may fire when ready, Gridley." -- Commodore George Dewey -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#355580: Bug 355580: output of fdisk
On Wed, 15 Mar 2006, Moshe Yudkowsky wrote: > I added this line to make certain that sata_promise loads before md > loads. At one time I had trouble with getting the system to boot, and > that line seemed to help by making certain the serial ATA drive module > was loaded before md loaded. yes initrd-tools needed that workaround, i'm happy you managed to boot sata with it. please try to remove it, initramfs-tools should load sata_promise just fine. if you want to load some module really early in the boot you can put it in /etc/mkinitramfs/modules (attention this path will change to /etc/initramfs-tools/modules), but usually that's not needed. > >>attempts to load md. Secondly, that script also failes to load "linear". linear added to current dev branch will hit unstable in some days. >Device Boot Start End Blocks Id System > /dev/sda1 * 124902893+ fd Linux raid > autodetect > /dev/sda224912614 996030 fd Linux raid > autodetect > /dev/sda32615973357183367+ fd Linux raid > autodetect > /dev/sda49734 1459639062047+ fd Linux raid > autodetect from your previous sent fstab the forth entry is false could you please set it to linux 83 that could potentially confuse mdrun, can you retry if fixing that works? > Why, yes, I do have a mixed RAID array of /dev/hda and /dev/sda. > Unusual, but it's what I have to play with at the moment. that's fine sure. > You didn't ask, but: ;) > cat /etc/mdadm/mdadm.conf: > cat /proc/mdstat would be even cooler. regards -- maks -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#355580: Bug 355580: output of fdisk
Thanks for writing. Here's the answers you requested.
My RAID1 and LINEAR-based system had the following line in /etc/modprobe.d/md:
install md_mod /sbin/modprobe sata_promise; /sbin/modprobe --ignore-install
md_mod
how did that line get added?
none of my raids uses that nor does it seem to come from a default
install. why did you add it?
I added this line to make certain that sata_promise loads before md
loads. At one time I had trouble with getting the system to boot, and
that line seemed to help by making certain the serial ATA drive module
was loaded before md loaded.
When I run
# modprobe --set-version=2.6.15-1-k7 --show-depends md_mod
I get the result
install /sbin/modprobe sata_promise; /sbin/modprobe --ignore-install md_mod
but *no* insmod. Therefore, when this is run during mkinitramfs, the
module md_mod is not installed. I realize that although modprobe
documentation leads one to believe that there will be an insmod line
printed, in fact there is not such line printed.
The patch: add "--ignore-install" to the modprobe line in manual_add_modules:
modprobe --ignore-install --set-version="${version}" --show-depends "${1}"
this produces a line with "inmod".
nack since the problem appears to be a non standard modification.
please explain why that modification would be needed.
"install md_mod /sbin/modprobe sata_promise", etc. is not part of the
standard distribution, but it is legal. I don't know if other people use
had the same problem I had and came up with this idea to do a
pre-install as a solution. The modification that I'm making is -- I
thought -- a rather common use of modprobe.d.
I *think* manual_add_modules() will not work as expected if someone uses
an "install" for any other module they need. Since modprobe.d is used to
do exactly these sorts of modifications to the order that modules are
loaded, I thought that manual_add_modules() should support it.
If I'm wrong, please let me know how modficiations to the load order are
supported by initramfs-tools, and I'll modify my config appropriately.
The next problem wtih initramfs-tools is for md specifically. First of
all, some mischevious person has renamed the "md" module to "md-mod".
This means the distribution hook hooks/md is out of date, because it
attempts to load md. Secondly, that script also failes to load "linear".
Current fragment:
for x in md raid0 raid1 raid5 raid6; do
manual_add_modules ${x}
done
New fragment:
for x in md_mod linear raid0 raid1 raid5 raid6; do
manual_add_modules ${x}
done
md and md-mod are the same, i'm for the shorter one.
i didn't knew that linear had some exposure out there,
but as it seems needed that is an easy fix.
You're correct. I made the change from md to md_mod, thinking that the
new name was the reason the md module did not load, but the real reason
was the manual_add_modules() problem. I have just tested the "md" name
with the modifications to manual_add_modules() in place, and the
md_mod.ko module is in the image.
So the shorter name will be just fine. I personally find it confusing,
but that's besides the point.
Now, as for scripts/local-top/md, I have found that "mdrun" attempts to
start /dev/md/0, even though there is no such device on my system. I
have /1, /2, and /3, but not /0. I have not been able to debug mdrun.
Instead of using mdrun, I use the following:
In scripts/local-top/md:
mkdir /dev/md # --auto requires this directory pre-exist
/sbin/mdadm --assemble --scan --auto=md --config=/etc/mdadm/mdadm.conf
And in hooks/md I add the line:
cp /etc/mdadm/mdadm.conf ${DESTDIR}/etc/mdadm/mdadm.conf
This has the added advantage that *only* the devices that are actually
needed are created in /dev/md, instead of dozens of devices that aren't
used. udev automatically creates the link between /dev/mdN and
/dev/md/N.
Please feel free to write for clarifications or further tests.
nack we don't want the mdadm.conf inside of the initramfs,
it opens races in consideration with hardware aka configuration changes.
You are quite correct. I was worried about that, but I could not get
mdrun to work for me.
Is there a reason that mdrun doesn't use "mdadm --auto" to create device
nodes as needed?
for this issue we need more information why mdrun failed.
can you please post the output of
cat /etc/fstab
mount
fdisk -l /dev/hd[a-d]
or
fdisk -l /dev/sd[a-d]
cat /etc/fstab:
# /etc/fstab: static file system information.
#
#
# on this drive, sda1, make md1 the root drive
/dev/md/1 / reiserfsdefaults0 1
/dev/md/2 noneswapsw 0 0
/dev/md/3 /home reiserfsdefaults0 1
/dev/sda4 /backup reiserfsdefaults0 1
proc/proc procdefaults0 0
/dev/fd0/floppy autouser,noauto 0
