[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: raid1 installation part. successful



On Sunday 07 March 2004 17:56, Erich Waelde wrote:
[snip]
> I managed to set up a /target tree on lvm on raid1 on scsi, but base
> install failed (could not download coreutils), and no smoke test has taken
> place. See below for details.
>
> To summarize: I found all the neccessary tools! Good work! Thank you.
> It needs a bit of polishing here and there, but AFAICS nothing really
> difficult.

I'll try to comment as good as I can on the problems.

[snip]

> * Load installer components
>   . lvmcfg, nobootloader
>
>   1.  I did expect sw-raid or md to show up here, but it didn't

As I have chosen to load it as default, it is not loadable. I haven't quite 
understood how the installer components list is generated, but I will play a 
bit with it soon.

> * Detect network hardware
> * Configure the network (dhcp)
> * Detect hardware (disks: 2 scsi, 1 ide, cdrom ide)
> * Partition a hard drive
>   ide0  part1  30 MB /boot
>   scsi0 part1   1 GB +
>   scsi1 part1   1 GB ==> /dev/md/0
>   scsi0 part2   1 GB +
>   scsi1 part2   1 GB ==> /dev/md/1
>
> * configure md
>
>   2. "configure md" is listed _after_ "configure lvm", where I would expect
>      it the other way round. Not a big deal.

Hehe, It's an easy fix too, I'll add it in my next image.

>   3. of course I forgot to mark partition type 'fd' and hat to go back.
>      Precise error message made that easy, though. :-)
>
>   4. it took several attempts until I found that mdadm (cat /proc/mdstat)
>      had some old junk information (2 broken md devs), which would prevent
>      the new partitions from showing up in the menus.
>
>      # mdadm --stop /dev/md/0
>      # mdadm --stop /dev/md/1
>      fixed that.
>
>      Of course I zeroed out the drives first and rebooted several times
>      after changes in the partition tables. But heck.

I had this problem a couple of times too. However I don't think there is an 
easy way to fix this, since broken superblocks shouldn't occour in general 
(or at least we can't assume that existing superblocks are broken).

>   5. the first raid device was created and started to sync. Then I wanted
>      to create the second device. At first it seemed that it would block on
>      the sync to finish (I used to raidtools2, rather). But that proved
>      wrong. I could kill the "mdadm --create ..." process and restart.
>      Again it did block (blue screen, nothing moving). So I killed it again
>      and issued the command on the shell:
>
>      # mdadm --create /dev/md/1 --force -l 1 -n 2 -x 0
> /dev/scsi/...target{0,1}.../part2
>
>      which did ask me, whether I wanted to proceed, yes or no. So maybe it
>      needs a "do-it-and-don't-bother-me" switch set?
>
>   At least I got 2 raid1 devices, synced and up, both consisting of 2
>   partitions on the scsi disks.

Hmm... The mdadm --create thingie blocked, right? What was it complaining 
about, existing superblock or size warnings? 
I have had this issue too, and --force isn't as forcefull as I would want it 
to be. Maybe I should patch mdadm with an --force-for-real argument ;-)

> * configure lvm
>
>   6. lvmcfg complained, that it would not find any usable partitions. Which
>      is true, kind of, since none where marked 'LVM'. However, it's wrong,
>      kinf of, too, since it doesn't consult /dev/md devices, it seems.
>
>      # pvcreate -ff /dev/md/0
>      # pvcreate -ff /dev/md/1
>
>      Unfortunately, no change (I reselected "configure lvm" from the menu).
>      So I went ahead to do it on the shell
>
>      # vgcreate vg00 /dev/md/0
>      # vgextend vg00 /dev/md/1
>
>      which worked fine.

Sounds like lvmcfg needs some work... I'll look into it at a later stage, when 
the rest works a bit better. 

[snip]

> * Install the base system
>
>   fails consistently "cannot download coreutils". Did delete the file in
>   /target/var/cache/apt/archives, but no change. But I believe this is a
>   problem with my CDRom not liking CD-RW's rather than anything else.

Now this sounds strange, haven't touched coreutils. My bet is on the CD-drive 
too -- but OTOH I am supposed to say that, am I not? ;-)


Thank you for your feedback,
-- 
Paul Fleischer // ProGuy
<proguy at proguy dot dk>
PGP key fingerprint: 755A 9FB3 F7E4 DB62 8154  C5D6 381B BBCD 7BE1 FF30



Reply to: