Strange raid init sequence
During the boot up sequence (suse 8.1), the kernel autodetects and tries
to mount a software raid partition I have with data, and fails:
<6>md: Autodetecting RAID arrays.
<6> [events: 0000032b]
<6> [events: 0000032b]
<6>md: autorun ...
<6>md: considering hdb14 ...
<6>md: adding hdb14 ...
<6>md: adding hda11 ...
<6>md: created md0
<6>md: bind
On Thursday 20 February 2003 13:59, Carlos E. R. wrote:
During the boot up sequence (suse 8.1), the kernel autodetects and tries to mount a software raid partition I have with data, and fails: [snip] <3>kmod: failed to exec /sbin/modprobe -s -k md-personality-3, errno = 2 <3>md: personality 3 is not loaded! [snip]
I suppose I should add that "md-personality-3" module to the initrd, but there is no such module.
Carlos, Look in /etc/modules.conf. There you'll find some aliases (at least, I hope so): alias md-personality-1 linear alias md-personality-2 raid0 alias md-personality-3 raid1 alias md-personality-4 raid5 alias md-personality-7 multipath So I would think that raid1 should be included in initrd. Paul.
The 03.02.21 at 00:37, Paul Uiterlinden wrote:
Look in /etc/modules.conf. There you'll find some aliases (at least, I hope so):
alias md-personality-1 linear alias md-personality-2 raid0 alias md-personality-3 raid1 alias md-personality-4 raid5 alias md-personality-7 multipath
So I would think that raid1 should be included in initrd.
Right! I have just done so, and will check what happens tomorrow on boot; I'll report again then. Thanks! -- Cheers, Carlos R.
The 03.02.21 at 02:14, Carlos E. R. wrote:
The 03.02.21 at 00:37, Paul Uiterlinden wrote:
So I would think that raid1 should be included in initrd.
Right! I have just done so, and will check what happens tomorrow on boot; I'll report again then. Thanks!
It doesn't work. I think that at that point initrd is not yet loaded, so that raid1 should have to be in the kernel itself, not as a module. Or disable the kernel trying to mount the raid automatically, I think I saw an option. Or just ignore it. -- Cheers, Carlos Robinson
On Saturday 22 February 2003 02:38, Carlos E. R. wrote:
The 03.02.21 at 02:14, Carlos E. R. wrote:
The 03.02.21 at 00:37, Paul Uiterlinden wrote:
So I would think that raid1 should be included in initrd.
Right! I have just done so, and will check what happens tomorrow on boot; I'll report again then. Thanks!
It doesn't work. I think that at that point initrd is not yet loaded, so that raid1 should have to be in the kernel itself, not as a module. Or disable the kernel trying to mount the raid automatically, I think I saw an option. Or just ignore it.
Strange. I have a RAID0 root partion (/dev/md0, ext3) and it works fine. In INITRD_MODULES I have: "aic7xxx jbd ext3 raid0 ide-scsi". My /boot partion is non-RAID (/dev/sda3, ext2). This is (or was?) needed for LILO. What does your RAID1 partition contain? Paul.
The 03.02.22 at 12:48, Paul Uiterlinden wrote:
It doesn't work. I think that at that point initrd is not yet loaded, so that raid1 should have to be in the kernel itself, not as a module. Or disable the kernel trying to mount the raid automatically, I think I saw an option. Or just ignore it.
Strange. I have a RAID0 root partion (/dev/md0, ext3) and it works fine. In INITRD_MODULES I have: "aic7xxx jbd ext3 raid0 ide-scsi".
No, no, you misunderstood me: I can mount my raid, that is no problem :-) The thing is that I'm curious why the kernel tries to mount it very early on the boot process, but it fails. A bit later, initrd is read, the root partition (reiserfs) is mounted, and then the raid is successfully mounted, maybe after reading /etc/fstab (this last detail I'm not sure). But this means the system is trying twice; I was trying to optimize the process, and understand why it is happening. My guess is that, for the first try to succeed, the raid code must not be a module, but linked directly into the kernel. Probably, this would be needed to boot from a software raid, which is not my case. In my case, I would like to disable that first try. -- Cheers, Carlos Robinson
On Saturday 22 February 2003 22:46, Carlos E. R. wrote:
No, no, you misunderstood me: I can mount my raid, that is no problem :-)
The thing is that I'm curious why the kernel tries to mount it very early on the boot process, but it fails. A bit later, initrd is read, the root partition (reiserfs) is mounted, and then the raid is successfully mounted, maybe after reading /etc/fstab (this last detail I'm not sure).
But this means the system is trying twice; I was trying to optimize the process, and understand why it is happening.
That's why I asked what your RAID1 partition contains (boot, root?).
My boot partition is non-RAID. I was guessing this would be the
difference (it's just guessing).
But now you mention that the system is trying twice: looking carefully
to the output of dmesg, I see the same. Only thing is: the first time
it succeeds, the second time it says "md: array md0 already exists!"
(see below for complete output).
My RAID stuff is all modularized (/usr/src/linux/.config):
#
# Multi-device support (RAID and LVM)
#
CONFIG_MD=y
CONFIG_BLK_DEV_MD=y
CONFIG_MD_LINEAR=m
CONFIG_MD_RAID0=m
# CONFIG_MD_RAID1 is not set
# CONFIG_MD_RAID5 is not set
# CONFIG_MD_MULTIPATH is not set
CONFIG_BLK_DEV_LVM=m
Hmmm, "all modularized"? Not quite: CONFIG_BLK_DEV_MD can be set to
"m" as well. I wonder what happens if I do that. As soon as I've
done that, I'll let you know.
Paul.
-------------------- Start of dmesg output --------------------
0000009fc00 - 00000000000a0000 (reserved)
BIOS-e820: 00000000000f0000 - 0000000000100000 (reserved)
BIOS-e820: 0000000000100000 - 000000001fff0000 (usable)
BIOS-e820: 000000001fff0000 - 000000001fff3000 (ACPI NVS)
BIOS-e820: 000000001fff3000 - 0000000020000000 (ACPI data)
BIOS-e820: 00000000ffff0000 - 0000000100000000 (reserved)
Scanning bios EBDA for MXT signature
511MB LOWMEM available.
Advanced speculative caching feature not present
On node 0 totalpages: 131056
zone(0): 4096 pages.
zone(1): 126960 pages.
zone(2): 0 pages.
Building zonelist for node : 0
Kernel command line: auto BOOT_IMAGE=linux ro root=900 hdd=ide-scsi
ide_setup: hdd=ide-scsi
Initializing CPU#0
Detected 350.801 MHz processor.
Console: colour VGA+ 132x25
Calibrating delay loop... 699.59 BogoMIPS
Memory: 515240k/524224k available (1214k kernel code, 8596k reserved,
452k data, 144k init, 0k highmem)
Dentry cache hash table entries: 65536 (order: 7, 524288 bytes)
Inode cache hash table entries: 32768 (order: 6, 262144 bytes)
Mount-cache hash table entries: 512 (order: 0, 4096 bytes)
Buffer-cache hash table entries: 32768 (order: 5, 131072 bytes)
Page-cache hash table entries: 131072 (order: 7, 524288 bytes)
CPU: Before vendor init, caps: 0183f9ff 00000000 00000000, vendor = 0
CPU: L1 I cache: 16K, L1 D cache: 16K
CPU: L2 cache: 512K
CPU: After vendor init, caps: 0183f9ff 00000000 00000000 00000000
Intel machine check architecture supported.
Intel machine check reporting enabled on CPU#0.
CPU: After generic, caps: 0183f9ff 00000000 00000000 00000000
CPU: Common caps: 0183f9ff 00000000 00000000 00000000
CPU: Intel Pentium II (Deschutes) stepping 02
Enabling fast FPU save and restore... done.
Checking 'hlt' instruction... OK.
POSIX conformance testing by UNIFIX
mtrr: v1.40 (20010327) Richard Gooch (rgooch@atnf.csiro.au)
mtrr: detected mtrr type: Intel
PCI: PCI BIOS revision 2.10 entry at 0xfb2f0, last bus=1
PCI: Using configuration type 1
PCI: Probing PCI hardware
PCI: Probing PCI hardware (bus 00)
PCI: Using IRQ router PIIX [8086/7110] at 00:02.0
Limiting direct PCI/PCI transfers.
Linux NET4.0 for Linux 2.4
Based upon Swansea University Computer Society NET3.039
Initializing RT netlink socket
apm: BIOS version 1.2 Flags 0x07 (Driver version 1.16)
mxt_scan_bios: enter
Starting kswapd
bigpage subsystem: allocated 0 bigpages (=0MB).
kinoded started
aio_setup: num_physpages = 32764
aio_setup: sizeof(struct page) = 44
pty: 256 Unix98 ptys configured
Real Time Clock Driver v1.10e
Uniform Multi-Platform E-IDE driver Revision: 6.31
ide: Assuming 33MHz system bus speed for PIO modes; override with
idebus=xx
PIIX4: IDE controller on PCI bus 00 dev 11
PIIX4: chipset revision 1
PIIX4: not 100% native mode: will probe irqs later
ide0: BM-DMA at 0xf000-0xf007, BIOS settings: hda:DMA, hdb:DMA
ide1: BM-DMA at 0xf008-0xf00f, BIOS settings: hdc:DMA, hdd:DMA
hda: CD-ROM CDU771, ATAPI CD/DVD-ROM drive
hdd: LITE-ON LTR-48246S, ATAPI CD/DVD-ROM drive
ide0 at 0x1f0-0x1f7,0x3f6 on irq 14
ide1 at 0x170-0x177,0x376 on irq 15
Floppy drive(s): fd0 is 1.44M
FDC 0 is a post-1991 82077
RAMDISK driver initialized: 16 RAM disks of 64000K size 1024 blocksize
loop: loaded (max 16 devices)
SCSI subsystem driver Revision: 1.00
kmod: failed to exec /sbin/modprobe -s -k scsi_hostadapter, errno = 2
md: md driver 0.90.0 MAX_MD_DEVS=256, MD_SB_DISKS=27
md: Autodetecting RAID arrays.
md: autorun ...
md: ... autorun DONE.
NET4: Linux TCP/IP 1.0 for NET4.0
IP Protocols: ICMP, UDP, TCP
IP: routing cache hash table of 4096 buckets, 32Kbytes
TCP: Hash tables configured (established 32768 bind 65536)
NET4: Unix domain sockets 1.0/SMP for Linux NET4.0.
RAMDISK: Compressed image found at block 0
Freeing initrd memory: 259k freed
VFS: Mounted root (ext2 filesystem).
PCI: Found IRQ 9 for device 00:0c.0
PCI: Sharing IRQ 9 with 00:0f.0
scsi0 : Adaptec AIC7XXX EISA/VLB/PCI SCSI HBA DRIVER, Rev 6.2.8
<Adaptec aic7880 Ultra SCSI adapter>
aic7880: Ultra Wide Channel A, SCSI Id=7, 16/253 SCBs
Vendor: SEAGATE Model: ST34520W Rev: 1444
Type: Direct-Access ANSI SCSI revision: 02
Vendor: SEAGATE Model: ST34520W Rev: 1444
Type: Direct-Access ANSI SCSI revision: 02
Vendor: HP Model: HP35470A Rev: T503
Type: Sequential-Access ANSI SCSI revision: 02
Vendor: DEC Model: RZ29B (C) DEC Rev: 0016
Type: Direct-Access ANSI SCSI revision: 02
Vendor: DEC Model: RZ29B (C) DEC Rev: 0016
Type: Direct-Access ANSI SCSI revision: 02
scsi0:A:0:0: Tagged Queuing enabled. Depth 32
scsi0:A:1:0: Tagged Queuing enabled. Depth 32
scsi0:A:8:0: Tagged Queuing enabled. Depth 32
scsi0:A:9:0: Tagged Queuing enabled. Depth 32
sd_init()
sd: allocated major 8
sd_attach()
sd: find_free_slot ...<7>sd: ... found 08:00
Attached scsi disk sda at scsi0, channel 0, id 0, lun 0
sd_attach()
sd: find_free_slot ...<7>sd: ... found 08:10
Attached scsi disk sdb at scsi0, channel 0, id 1, lun 0
sd_attach()
sd_attach()
sd: find_free_slot ...<7>sd: ... found 08:20
Attached scsi disk sdc at scsi0, channel 0, id 8, lun 0
sd_attach()
sd: find_free_slot ...<7>sd: ... found 08:30
Attached scsi disk sdd at scsi0, channel 0, id 9, lun 0
sd_finish()
sd_init_onedisk (0,0), sda 08:00
(scsi0:A:0): 40.000MB/s transfers (20.000MHz, offset 8, 16bit)
SCSI device sda: 8888924 512-byte hdwr sectors (4551 MB)
Partition check:
sda: sda1 sda2 sda3 sda4
sd_init_onedisk (0,1), sdb 08:10
(scsi0:A:1): 40.000MB/s transfers (20.000MHz, offset 8, 16bit)
SCSI device sdb: 8888924 512-byte hdwr sectors (4551 MB)
sdb: sdb1 sdb2 sdb3
sd_init_onedisk (0,2), sdc 08:20
(scsi0:A:8): 20.000MB/s transfers (10.000MHz, offset 8, 16bit)
SCSI device sdc: 8380080 512-byte hdwr sectors (4291 MB)
sdc: sdc1 sdc2
sd_init_onedisk (0,3), sdd 08:30
(scsi0:A:9): 20.000MB/s transfers (10.000MHz, offset 8, 16bit)
SCSI device sdd: 8380080 512-byte hdwr sectors (4291 MB)
sdd: sdd1 sdd2
Journalled Block Device driver loaded
md: raid0 personality registered as nr 2
hda: no flushcache support
hdd: no flushcache support
scsi1 : SCSI host adapter emulation for IDE ATAPI devices
Vendor: SONY Model: CD-ROM CDU771 Rev: 1.0m
Type: CD-ROM ANSI SCSI revision: 02
Vendor: LITE-ON Model: LTR-48246S Rev: SS09
Type: CD-ROM ANSI SCSI revision: 02
sd_init()
sd_attach()
sd_attach()
sd_finish()
md: Autodetecting RAID arrays.
[events: 000001a1]
[events: 000001a1]
[events: 000001a1]
[events: 000001a1]
md: autorun ...
md: considering sdd2 ...
md: adding sdd2 ...
md: adding sdc2 ...
md: adding sdb2 ...
md: adding sda2 ...
md: created md0
md: bind
On Monday 24 February 2003 11:23, Paul Uiterlinden wrote:
Hmmm, "all modularized"? Not quite: CONFIG_BLK_DEV_MD can be set to "m" as well. I wonder what happens if I do that. As soon as I've done that, I'll let you know.
Setting CONFIG_BLK_DEV_MD to m creates a module not suprisingly called md.o. Without adding this to initrd, module raid0 cannot be loaded (undefined symbols), and the root partition cannot be mounted. So far, clear. Now I add md to initrd, run lilo, boot, so it should work again, right? Wrong! Although raid0 now is loaded correctly, the root partition still cannot be mounted. I do not understand this, so I simply revert back to the old situation (CONFIG_BLK_DEV_MD = y). It's been an interesting excercize, though not very fruitfull. Paul.
The 03.02.24 at 13:38, Paul Uiterlinden wrote:
It's been an interesting excercize, though not very fruitfull.
:-) My mother tells an anecdote of Edison. He had to test hundred of materials for the filament of the electric bulb lamp he was inventing, but all of them burnt too soon. Someone told him he had failed, and he replied that no, he had learnt that those hundreds of materials were no good for the task. I read somewhere the one that finally worked was made from carbonized sugar cane fibers! -- Cheers, Carlos Robinson
On Monday 24 February 2003 17:00, Carlos E. R. wrote:
The 03.02.24 at 13:38, Paul Uiterlinden wrote:
It's been an interesting excercize, though not very fruitfull.
:-)
My mother tells an anecdote of Edison. He had to test hundred of materials for the filament of the electric bulb lamp he was inventing, but all of them burnt too soon. Someone told him he had failed, and he replied that no, he had learnt that those hundreds of materials were no good for the task.
Quite true!
I read somewhere the one that finally worked was made from carbonized sugar cane fibers!
I like sugar canes better caramelized. Carbonized seems a bit over-done to me! :-) Paul.
The 03.02.24 at 13:38, Paul Uiterlinden wrote:
On Monday 24 February 2003 11:23, Paul Uiterlinden wrote:
Hmmm, "all modularized"? Not quite: CONFIG_BLK_DEV_MD can be set to "m" as well. I wonder what happens if I do that. As soon as I've done that, I'll let you know.
Setting CONFIG_BLK_DEV_MD to m creates a module not suprisingly called md.o. Without adding this to initrd, module raid0 cannot be loaded (undefined symbols), and the root partition cannot be mounted. So far, clear.
Ah! I bumped into that the other day, without knowing. I updated the patch for the kernel sources, but not for the kernel binary, in order to save transmission time (and money), as I use a V90 modem. So I set up to compile the kernel, and I got the error you mention above. I couldn't see what I had done wrong, so I had to download the patch for binary as well (k_deflt). After that, i made a make cloneconfig and compiled without problems. -- Cheers, Carlos Robinson
The 03.02.24 at 11:23, Paul Uiterlinden wrote:
On Saturday 22 February 2003 22:46, Carlos E. R. wrote:
No, no, you misunderstood me: I can mount my raid, that is no problem :-)
The thing is that I'm curious why the kernel tries to mount it very early on the boot process, but it fails. A bit later, initrd is read, the root partition (reiserfs) is mounted, and then the raid is successfully mounted, maybe after reading /etc/fstab (this last detail I'm not sure).
But this means the system is trying twice; I was trying to optimize the process, and understand why it is happening.
That's why I asked what your RAID1 partition contains (boot, root?). My boot partition is non-RAID. I was guessing this would be the difference (it's just guessing).
Ahh. No, my root partition is plain reiser, and /boot is ext2, both non raid, on /dev/hdb. I only have an extra 3 Gb partition as raid, to experiment with :-)
But now you mention that the system is trying twice: looking carefully to the output of dmesg, I see the same. Only thing is: the first time it succeeds, the second time it says "md: array md0 already exists!" (see below for complete output).
Interesting... Ah, but yours are scsi disks, it seems. Maybe there is a difference there :-?
My RAID stuff is all modularized (/usr/src/linux/.config):
# # Multi-device support (RAID and LVM) # CONFIG_MD=y CONFIG_BLK_DEV_MD=y CONFIG_MD_LINEAR=m CONFIG_MD_RAID0=m # CONFIG_MD_RAID1 is not set # CONFIG_MD_RAID5 is not set # CONFIG_MD_MULTIPATH is not set CONFIG_BLK_DEV_LVM=m
Hmmm, "all modularized"? Not quite: CONFIG_BLK_DEV_MD can be set to "m" as well. I wonder what happens if I do that. As soon as I've done that, I'll let you know.
Mine is very similar: CONFIG_MD=y CONFIG_BLK_DEV_MD=y CONFIG_MD_LINEAR=m CONFIG_MD_RAID0=m CONFIG_MD_RAID1=m CONFIG_MD_RAID5=m CONFIG_MD_MULTIPATH=m CONFIG_BLK_DEV_LVM=m -- Cheers, Carlos Robinson
On Monday 24 February 2003 15:11, Carlos E. R. wrote:
Ahh. No, my root partition is plain reiser, and /boot is ext2, both non raid, on /dev/hdb. I only have an extra 3 Gb partition as raid, to experiment with :-)
OK, I see. It only adds to the mystery. Why does it still fail? You suggested in an earlier mail it might be because initrd is not yet loaded at that point. But I think that's not possible. I mean: the whole idea of initrd is that you can insert modules even before the root partition is mounted.
But now you mention that the system is trying twice: looking carefully to the output of dmesg, I see the same. Only thing is: the first time it succeeds, the second time it says "md: array md0 already exists!" (see below for complete output).
Interesting...
Ah, but yours are scsi disks, it seems. Maybe there is a difference there :-?
Yes, they are indeed SCSI disks. I would not expect any difference on that account. But then again: who am I? Paul.
The 03.02.24 at 21:44, Paul Uiterlinden wrote:
On Monday 24 February 2003 15:11, Carlos E. R. wrote:
Ahh. No, my root partition is plain reiser, and /boot is ext2, both non raid, on /dev/hdb. I only have an extra 3 Gb partition as raid, to experiment with :-)
OK, I see. It only adds to the mystery. Why does it still fail? You suggested in an earlier mail it might be because initrd is not yet loaded at that point. But I think that's not possible. I mean: the whole idea of initrd is that you can insert modules even before the root partition is mounted.
Yes, that's right.
The sequence is this: the kernel loads, initialises a lot of things, like
IDE, checks the partitions, sees some of them are raid, and tries to load
them:
<4>ide-floppy driver 0.99.newide
<6>Partition check:
<6> hda: hda1 hda2 < hda5 hda6 hda7 hda8 hda9 hda10 hda11 > hda3 hda4
<6> hdb: hdb1 hdb2 hdb3 < hdb5 hdb6 hdb7 hdb8 hdb9 hdb10 hdb11 hdb12 hdb13 hdb14
<6>Floppy drive(s): fd0 is 1.44M
<6>FDC 0 is a post-1991 82077
<4>RAMDISK driver initialized: 16 RAM disks of 64000K size 1024 blocksize
<6>loop: loaded (max 16 devices)
<4>ide-floppy driver 0.99.newide
<6>SCSI subsystem driver Revision: 1.00
<3>kmod: failed to exec /sbin/modprobe -s -k scsi_hostadapter, errno = 2
<6>md: md driver 0.90.0 MAX_MD_DEVS=256, MD_SB_DISKS=27
<6>md: Autodetecting RAID arrays.
<6> [events: 00000344]
<6> [events: 00000344]
<6>md: autorun ...
<6>md: considering hdb14 ...
<6>md: adding hdb14 ...
<6>md: adding hda11 ...
<6>md: created md0
<6>md: bind
Some time ago, on 03.02.25 we were talking about a strange sequence of events when mounting a software raid:
On Monday 24 February 2003 15:11, Carlos E. R. wrote: [...] The sequence is this: the kernel loads, initialises a lot of things, like IDE, checks the partitions, sees some of them are raid, and tries to load
The 03.02.24 at 21:44, Paul Uiterlinden wrote: them: [but fails the first time] [ ...] Now the root filesystem has been really mounted, and the raid is again considered:
<6>Freeing unused kernel memory: 168k freed <6>md: Autodetecting RAID arrays. <6> [events: 00000344] <6> [events: 00000344] <6>md: autorun ... <6>md: considering hda11 ... <6>md: adding hda11 ... <6>md: adding hdb14 ... <6>md: created md0 <6>md: bind
<6>md: bind <6>md: running: <hda11><hdb14> <6>md: hda11's event counter: 00000344 <6>md: hdb14's event counter: 00000344 <6>md: RAID level 1 does not need chunksize! Continuing anyway. <6>md: raid1 personality registered as nr 3 <6>md0: max total readahead window set to 508k <6>md0: 1 data-disks, max readahead per data-disk: 508k <6>raid1: device hda11 operational as mirror 0 <6>raid1: device hdb14 operational as mirror 1 <6>raid1: raid set md0 active with 2 out of 2 mirrors <6>md: updating md0 RAID superblock on device <6>md: hda11 [events: 00000345]<6>(write) hda11's sb offset: 3124544 <6>md: hdb14 [events: 00000345]<6>(write) hdb14's sb offset: 3124544 <6> [events: 0f227faa] <3>md: invalid raid superblock magic on md0 <4>md: md0 has invalid sb, not importing! <4>md: no nested md device found <6>md: ... autorun DONE. Now I'm noticing that it says "invalid raid superblock magic on md0". I
Well, that's a extract of what we were saying then. I have discovered some
new info. I was watching the console 10 when halting the system, and
noticed a message about md being stoped, and something that failed -
unfortunately, the system powers off at that precise moment, and I can not
read it.
I have edited "/etc/init.d/halt" right at the end. First, I added a
"sleep 20":
echo "----------- real halt comming in 20\" ----------"
sleep 20
echo "----------- real halt now ----------------------"
# Now talk to kernel
exec $command -d -f
I do see those lines on the output, and I read a message about md being
stopped. But that's all! The error message I see goes after that "exec
$command -d -f" (probably halt -p -d -f), so I still can not read it. It's
probably doing a "halt -p -d -f":
-f Force halt or reboot, don't call shutdown(8).
-d Don't write the wtmp record. The -n flag implies -d.
-p When halting the system, do a poweroff. This is the default
when halt is called as poweroff.
So, I remove the "-p" (not shown), and this is what I see on console
number 10, copied by hand:
analog.c [...] gameport
md: recovery thread got woken up ...
md: recovery thread finished ...
---> kernel halt is called here
md: stopping al md devices
md: marking sb clean
md: updating md0 RAID superblock on device
md: hda11 [events: 000004c2]<6>(write) hda11's sb offset: 3124544
md: hdb14 [events: 000004c2]<6>(write) hdb14's sb offset: 3124544
md: md0 switched to read_only mode
flushing ide devices: hda hdb hdc hdd
System halted
My guess is that the software raid is trying to do something as a result
of the halt command, but can not finish writing it to disk. Thus, on the
next wakeup, there are always errors:
<6>md: created md0
<6>md: bind
Is anyone else having problems adding packages to an installation via ftp ? I've successfully installed SuSE8.0 via ftp on two occasion however whenever I try to add freeswan or other packeges I get unable to find file or connection errors. I've tried several ftp mirrors, and even downloaded the entire source to my local ftp server. I am at a complete loss. Also the isntallation was a minimal install with apache, ftp and a few other server specific items. What has me really confused is my other server which I have updated in the past isnt' working. YOU however does work on both.
I've been trying to install free swan and in so doing killed my machine. I installed 2.4.19 kernel. With the appropriate patchs. For some reason when I boot. Even with the failsafe kernel my interfaces fail to load. I can do a modprob eth1 and eth2 and it loads. Then I can also do an ifconfig eth1 up 192.168.1.1 and it loads. I tried using yast to remove and re-add the interfaces with no luck. Any ideas where to check next. ?
I tried running rcnetwork, in debug more and it returned an error -7 which interface does not exist. When I tried running ifup eth0 I get an error could not get a valid interface name. Now for some reason I can modprob eth0 ifconfig eth0 up 192.168.1.1 Route add -net 192.168.1.0 netmask 255.255.255.0 This will allow my to ping an outside interface but I cannot ping 192.168.1.1 from another system on the network. What am I doing wrong or forgetting
I've been trying to install free swan and in so doing killed my machine. I installed 2.4.19 kernel. With the appropriate patchs. For some reason when I boot. Even with the failsafe kernel my interfaces fail to load. I can do a modprob eth1 and eth2 and it loads. Then I can also do an ifconfig eth1 up 192.168.1.1 and it loads. I tried using yast to remove and re-add the interfaces with no luck. Any ideas where to check next. ?
participants (3)
-
Carlos E. R.
-
Paul Uiterlinden
-
Rowan Reid