> vgcreate vg2t /dev/sda /dev/sdb > lvcreate --type raid0 -name lv-stg --size 16700GiB vg2t
I solved the problem by manually activating it initially. On Sat, May 29, 2021 at 10:41 PM Tom Dial <tdd...@comcast.net> wrote: > > > > On 5/28/21 12:58, Gokan Atmaca wrote: > >> Is your '/etc/crypttab' file properly populated? > > > > There is no encrypted volume. > > > > > > On Fri, May 28, 2021 at 9:37 PM john doe <johndoe65...@mail.com> wrote: > >> > >> On 5/28/2021 8:31 PM, Gokan Atmaca wrote: > >>> Additionally I found something like the following in the dmesg logs. > >>> > >>> [Fri May 28 14:14:19 2021] x86/cpu: VMX (outside TXT) disabled by BIOS > >>> [Fri May 28 14:14:20 2021] r8169 0000:06:00.0: unknown chip XID 641 > >>> [Fri May 28 14:14:22 2021] device-mapper: table: 253:2: raid: Failed > >>> to run raid array > >>> [Fri May 28 14:14:22 2021] device-mapper: table: 253:2: raid: Failed > >>> to run raid array > >>> [Fri May 28 14:15:25 2021] hdaudio hdaudioC0D2: Unable to bind the codec > >>> > >>> On Fri, May 28, 2021 at 9:27 PM Gokan Atmaca <linux.go...@gmail.com> > >>> wrote: > >>>> > >>>> Hello > >>>> > >>>> I did LVM raid 0. But when reboot the disks come as "inherit". > >>>> What would be the reason ? > >>>> > >>>> lvdisplay > >>>> --- Logical volume --- > >>>> LV Path /dev/vg2t/lv-st0 > >>>> LV Name lv-st0 > >>>> VG Name vg2t > >>>> LV UUID JOfIdw-8uhQ-OvsF-4Sdp-LMDm-NEVv-UMjFDW > >>>> LV Write Access read/write > >>>> LV Creation host, time ob, 2021-05-28 10:46:49 -0400 > >>>> LV Status NOT available > >>>> LV Size 1.81 TiB > >>>> Current LE 474482 > >>>> Segments 1 > >>>> Allocation inherit > >>>> Read ahead sectors auto > >>>> > >>>> --- Logical volume --- > >>>> LV Path /dev/vg2t/lv_storage14t > >>>> LV Name lv_storage14t > >>>> VG Name vg2t > >>>> LV UUID jHbg36-GKU0-Mked-PbMd-Vnio-IPbE-lpGWD4 > >>>> LV Write Access read/write > >>>> LV Creation host, time ob 2021-05-28 13:41:04 -0400 > >>>> LV Status NOT available > >>>> LV Size 14.50 TiB > >>>> Current LE 3801088 > >>>> Segments 1 > >>>> Allocation inherit > >>>> Read ahead sectors auto > > Allocation inherit is the default (inherited from the volume group) if > you did not specify an allocation rule in the lvcreate command that > created the volume group. Based on my experience and existing volume > groups, it also is the default for vgcreate command if nothing else is > specified. > > The above also shows "LV Status NOT available". That likely indicates > that the volume group was not activated at boot. That would prevent use > of the logical volumes for anything and probably explain the device > mapper messages shown above. > > As Reco suggested in a later reply, it would be helpful to see the > output of both vgdisplay -v and pvdisplay. > > It also might be helpful if you could show the exact commands you used > originally to set up the RAID environment. > > I realize that may be impossible, but wonder if you defined a raid0 > device on top of the LVM logical volumes using external raid management > software. My understanding is that while that might be possible, the > usual way to create raid under LVM is to specify it by type when > creating the logical volume. In this case, for (partly made up) example: > > vgcreate vg2t /dev/sda /dev/sdb > lvcreate --type raid0 -name lv-stg --size 16700GiB vg2t > > This would result in one logical volume, /dev/vg2t/, split between the > two physical volumes (assumed here to be /dev/sda and /dev/sdb but maybe > different on your system), with total storage of about 16.3 TiB. I guess > that allocation would be first from /dev/sda and, when that is > exhausted, /dev/sdb. Other allocation rules could be specified in the > vgcreate command (and inherited by the logical volume) or the lvcreate > command. With the very different sized disks involved, it is not clear > that would be useful. > > Regards, > Tom Dial > > >>>> > >>>> > >>>> Thanls. > >>>> > >>>> > >>>> > >>>> > >>>> -- > >>>> ⢀⣴⠾⠻⢶⣦⠀ > >>>> ⣾⠁⢠⠒⠀⣿⡁ Debian - The universal operating system > >>>> ⢿⡄⠘⠷⠚⠋⠀ https://www.debian.org > >>>> ⠈⠳⣄⠀⠀⠀⠀ > >>> > >> > >> Is your '/etc/crypttab' file properly populated? > >> > >> -- > >> John Doe > >>
