NetBSD-Bugs archive

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

kern/45957: gpt on raid gpt installation not bootable

>Number:         45957
>Category:       kern
>Synopsis:       gpt on raid gpt installation not bootable
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    kern-bug-people
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Thu Feb 09 14:40:00 +0000 2012
>Originator:     Hauke Fath
>Release:        NetBSD 5.1_STABLE
     The ASCII Ribbon Campaign                    Hauke Fath
()     No HTML/RTF in email             Institut für Nachrichtentechnik
/\     No Word docs in email                     TU Darmstadt
     Respect for open standards              Ruf +49-6151-16-3281
System: NetBSD Gstoder 5.1_STABLE NetBSD 5.1_STABLE (GENERIC) #0: Thu Nov 24 
20:29:38 CET 2011 
hf@Hochstuhl:/var/obj/netbsd-builds/5/i386/sys/arch/i386/compile/GENERIC i386
Architecture: i386
Machine: i386

        In the light of gpt disks being bootable
        <>, I
        decided to set up a new 500 GB disk pair as raid1 with gpt(8)
        and wedges.

        I set up a gpt table for the entire disk of type raid, defined
        dk0 as a wedge of type raidframe, then constructed a degraded
        one-disk raid1 like in

        Next, I set up a gpt on raid1 with a few partitions, finally
        created the wedges (dk1 .. dk5) and newfs'ed them.

        So far, accessing the dk[1345] filesystems is fine both from
        netbsd-5 and -current. But the bootxx_ffsv2 installed on dk0
        won't find /boot.

        A test gpt installation on another disk without raidframe
        boots just fine.

        See also



        Use gpt(8) to create a raid partition. Inside that raid
        partition, create another gpt with the usual few ffs & swap
        partitions. Find that the resulting assortment is not


        IIUC, teach the level ${relevant} boot-loader to take into
        account variable distance between the start of the root
        partition and the start of the actual root file-system. 
        Apparently, the disklabel code can already do that.

        But see also 


Home | Main Index | Thread Index | Old Index