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.
#
# <file system> <mount point> <type> <options> <dump>
<pass>
# on this drive, sda1, make md1 the root drive
/dev/md/1 / reiserfs defaults 0 1
/dev/md/2 none swap sw 0 0
/dev/md/3 /home reiserfs defaults 0 1
/dev/sda4 /backup reiserfs defaults 0 1
proc /proc proc defaults 0 0
/dev/fd0 /floppy auto user,noauto 0 0
/dev/cdroms/cdrom0 /cdrom iso9660 ro,user,noauto
0 0
/dev/cdroms/cdrom1 /cdrom2 iso9660 ro,user,noauto 0 0
# /dev/sdb /ums vfat user,noauto 0 0
# test of ability to mount old file systems
/dev/hda3 /mnt/hda ext3 defaults,noauto 0 0
# /dev/hda1 /mnt/hda1 ext2 defaults,noauto 0 0
mount:
/dev/md/1 on / type reiserfs (rw)
proc on /proc type proc (rw)
sysfs on /sys type sysfs (rw)
usbfs on /proc/bus/usb type usbfs (rw)
tmpfs on /dev/shm type tmpfs (rw)
devpts on /dev/pts type devpts (rw,gid=5,mode=620)
/dev/md/3 on /home type reiserfs (rw)
/dev/scsi/host0/bus0/target0/lun0/part4 on /backup type reiserfs (rw)
tmpfs on /dev type tmpfs (rw,size=10M,mode=0755)
binfmt_misc on /proc/sys/fs/binfmt_misc type binfmt_misc (rw)
/dev/scsi/host2/bus0/target0/lun0/disc on /iriver type vfat
(rw,noexec,nosuid,nodev,umask=0000)
//sluggy/c$ on /pc/sluggy/moshe type smbfs (rw)
(the iriver mp3 player is not actually on the system right now -- a udev
script error that I need to correct didn't umount /iriver when I
unplugged it from USB)
fdisk -l /dev/hda
Disk /dev/hda: 80.0 GB, 80060424192 bytes
255 heads, 63 sectors/track, 9733 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Device Boot Start End Blocks Id System
/dev/hda1 * 1 2490 20000893+ fd Linux raid
autodetect
/dev/hda2 2491 2614 996030 fd Linux raid
autodetect
/dev/hda3 2615 9733 57183367+ fd Linux raid
autodetect
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 * 1 2490 20000893+ fd Linux raid
autodetect
/dev/sda2 2491 2614 996030 fd Linux raid
autodetect
/dev/sda3 2615 9733 57183367+ fd Linux raid
autodetect
/dev/sda4 9734 14596 39062047+ fd Linux raid
autodetect
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.
You didn't ask, but:
cat /etc/mdadm/mdadm.conf:
# MY 20041227
# does not work on reboot without conf file
# try telling it to look for /dev/sda
DEVICE /dev/sda* /dev/hda*
# if this doesn't work, try ARRAY as well
# ARRAY /dev/md1 devices=/dev/sda1,/dev/hda1
# ARRAY /dev/md2 devices=/dev/sda2,/dev/hda2
# ARRAY /dev/md3 devices=/dev/sda3,/dev/hda3
ARRAY /dev/md/1 devices=/dev/sda1,/dev/hda1
ARRAY /dev/md/2 devices=/dev/sda2,/dev/hda2
ARRAY /dev/md/3 devices=/dev/sda3,/dev/hda3
Ugly, but once it started working, I was reluctant to touch it.
Please let me know if you need any additional information or need me to
perform any testing.
--
Moshe Yudkowsky * moshe@pobox.com * www.pobox.com/~moshe
"There was an crash on the expressway this morning. Fortunately, all the
traffic was backed up."
-- Eli Yudkowsky
Reply to: