<?xml version="1.0" encoding="UTF-8" ?>

<bugzilla version="5.2"
          urlbase="https://bugzilla.altlinux.org/"
          
          maintainer="jenya@basealt.ru"
>

    <bug>
          <bug_id>38796</bug_id>
          
          <creation_ts>2020-08-11 11:50:49 +0300</creation_ts>
          <short_desc>libevms не может деактивировать RAID массив, если на нем находится LVM LV</short_desc>
          <delta_ts>2020-10-30 09:54:03 +0300</delta_ts>
          <reporter_accessible>1</reporter_accessible>
          <cclist_accessible>1</cclist_accessible>
          <classification_id>4</classification_id>
          <classification>Development</classification>
          <product>Sisyphus</product>
          <component>libevms</component>
          <version>unstable</version>
          <rep_platform>x86_64</rep_platform>
          <op_sys>Linux</op_sys>
          <bug_status>REOPENED</bug_status>
          <resolution></resolution>
          
          
          <bug_file_loc></bug_file_loc>
          <status_whiteboard></status_whiteboard>
          <keywords></keywords>
          <priority>P5</priority>
          <bug_severity>normal</bug_severity>
          <target_milestone>---</target_milestone>
          
          
          <everconfirmed>1</everconfirmed>
          <reporter name="Slava Aseev">ptrnine</reporter>
          <assigned_to name="Slava Aseev">ptrnine</assigned_to>
          <cc>mcpain</cc>
    
    <cc>mike</cc>
    
    <cc>rider</cc>
    
    <cc>snowmix</cc>
    
    <cc>zerg</cc>
          
          <qa_contact>qa-sisyphus</qa_contact>

      

      

      

          <comment_sort_order>oldest_to_newest</comment_sort_order>  
          <long_desc isprivate="0" >
    <commentid>191826</commentid>
    <comment_count>0</comment_count>
    <who name="Slava Aseev">ptrnine</who>
    <bug_when>2020-08-11 11:50:49 +0300</bug_when>
    <thetext>Баг проявляется на стартеркитах в виде &quot;падения&quot; инталлятора. Возможно, не только на стартеркитах.
Для воспроизведения необходимо создать RAID массив, создать на нем LVM LV, затем запустить инсталлятор и выбрать &quot;Destroy all partitions, then autopartion&quot;

Причина вот в чем. evms сам располагает все у себя в /dev/evms
Но в данном случае происходит один неприятный момент - при запуске RAID массива (ioctl RUN_ARRAY) автоматически запускается и LVM LV на нем, про который evms ничего не знает. Соответственно, деактивировать RAID массив у него не получится - он будет занят запущенным LVM LV.

Вот выводы lsblk на 3 стадиях для наглядности:

1. Сразу же после создания RAID массива и LVM LV на нем:
NAME        MAJ:MIN RM  SIZE RO TYPE  MOUNTPOINT
loop0         7:0    0  1.9G  1 loop  /.ro
sda           8:0    0   20G  0 disk  
└─sda1        8:1    0    3G  0 part  
  └─md127     9:127  0    3G  0 raid1 
    └─vg-lv 252:0    0    1G  0 lvm   
sdb           8:16   0   20G  0 disk  
└─sdb1        8:17   0    3G  0 part  
  └─md127     9:127  0    3G  0 raid1 
    └─vg-lv 252:0    0    1G  0 lvm

2. После запуска инсталлятора (выполнился /usr/share/install2/initinstall.d/80-stop-md-dm.sh)
NAME   MAJ:MIN RM  SIZE RO TYPE MOUNTPOINT
loop0    7:0    0  1.9G  1 loop /.ro
sda      8:0    0   20G  0 disk 
└─sda1   8:1    0    3G  0 part 
sdb      8:16   0   20G  0 disk 
└─sdb1   8:17   0    3G  0 part

3. На стадии volume management, когда evms выполнил discovery:
NAME             MAJ:MIN RM  SIZE RO TYPE  MOUNTPOINT
loop0              7:0    0  1.9G  1 loop  /.ro
sda                8:0    0   20G  0 disk  
├─sda1             8:1    0    3G  0 part  
└─sda1           252:0    0    3G  0 dm    
  └─md127          9:127  0    3G  0 raid1 
    ├─lvm2|vg|lv 252:2    0    1G  0 dm    
    └─vg-lv      252:3    0    1G  0 lvm   
sdb                8:16   0   20G  0 disk  
├─sdb1             8:17   0    3G  0 part  
└─sdb1           252:1    0    3G  0 dm    
  └─md127          9:127  0    3G  0 raid1 
    ├─lvm2|vg|lv 252:2    0    1G  0 dm    
    └─vg-lv      252:3    0    1G  0 lvm</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>191827</commentid>
    <comment_count>1</comment_count>
    <who name="Slava Aseev">ptrnine</who>
    <bug_when>2020-08-11 11:53:24 +0300</bug_when>
    <thetext>И на данный момент мне пока неизвестно, как решить эту проблему без навороченных костылей</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>191828</commentid>
    <comment_count>2</comment_count>
    <who name="Anton Farygin">rider</who>
    <bug_when>2020-08-11 11:58:51 +0300</bug_when>
    <thetext>Слава, а можешь оценить принциальную возможность отвязать libevms от /dev/evms и использовать его просто как удобную универсальную библиотеку для работы с томами и файловыми системами разного формата ?</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>191839</commentid>
    <comment_count>3</comment_count>
    <who name="Slava Aseev">ptrnine</who>
    <bug_when>2020-08-11 16:11:54 +0300</bug_when>
    <thetext>(Ответ для Anton Farygin на комментарий #2)
&gt; Слава, а можешь оценить принциальную возможность отвязать libevms от
&gt; /dev/evms и использовать его просто как удобную универсальную библиотеку для
&gt; работы с томами и файловыми системами разного формата ?

Это принципиально возможно.
То есть я не вижу непреодолимых препятствий, которые не позволят заставить работать необходимое для alterator-vm &quot;подмножество&quot; libevms без /dev/evms/
Насколько это будет просто, и какие проблемы могут возникнуть я пока не знаю, нужно детально разбираться.</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>191851</commentid>
    <comment_count>4</comment_count>
    <who name="Slava Aseev">ptrnine</who>
    <bug_when>2020-08-12 14:11:37 +0300</bug_when>
    <thetext>Можно подойти немного по-другому. Если бы evms не раздавал названия для свой лад, подобных проблем бы не было.
evms в именах для device mapper заменяет &quot;/&quot; на &quot;|&quot;, а в плагине lvm2 добавляет еще и префикс lvm2
Если это поправить, то dm клона уже не наблюдается:

NAME        MAJ:MIN RM  SIZE RO TYPE  MOUNTPOINT
loop0         7:0    0  1.9G  1 loop  /.ro
sda           8:0    0   20G  0 disk  
├─sda1        8:1    0    5G  0 part  
└─sda1      252:0    0    5G  0 dm    
  └─md127     9:127  0    5G  0 raid1 
    └─vg-lv 252:2    0    1G  0 dm    
sdb           8:16   0   20G  0 disk  
├─sdb1        8:17   0    5G  0 part  
└─sdb1      252:1    0    5G  0 dm    
  └─md127     9:127  0    5G  0 raid1 
    └─vg-lv 252:2    0    1G  0 dm    
sr0          11:0    1    2G  0 rom   /image</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>191857</commentid>
    <comment_count>5</comment_count>
    <who name="Anton Farygin">rider</who>
    <bug_when>2020-08-12 14:44:57 +0300</bug_when>
    <thetext>а какие отрицательные последствия могут быть для нас от этого шага ?</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>191864</commentid>
    <comment_count>6</comment_count>
    <who name="Slava Aseev">ptrnine</who>
    <bug_when>2020-08-12 16:37:03 +0300</bug_when>
    <thetext>(Ответ для Anton Farygin на комментарий #5)
&gt; а какие отрицательные последствия могут быть для нас от этого шага ?

Тут сложно ответить, нужно будет тщательно протестировать на различных комбинациях ФС/raid и т.д.

Но он данного поведения evms в прошлом были только одни проблемы. Этот баг тоже отчасти возникает по этой же причине.
Непонятно, как и зачем был выбран символ &apos;|&apos;. dmsetup вот вообще ругается символы &apos;|&apos; в имени:

# dmsetup info
The name &quot;lvm2|vg|lv&quot; should be mangled but it contains blacklisted character</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>191867</commentid>
    <comment_count>7</comment_count>
    <who name="Anton Farygin">rider</who>
    <bug_when>2020-08-12 18:55:26 +0300</bug_when>
    <thetext>тогда давай сделаем экспериментальную сборку, с которой соберём инсталятор и проверим в наших базовых сценариях.</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>191903</commentid>
    <comment_count>8</comment_count>
    <who name="Michael Shigorin">mike</who>
    <bug_when>2020-08-15 11:03:28 +0300</bug_when>
    <thetext>(Ответ для Slava Aseev на комментарий #6)
&gt; Но он данного поведения evms в прошлом были только одни проблемы.
+1

Возможно, это ещё с AIX приползло и так и осталось.</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>192148</commentid>
    <comment_count>9</comment_count>
    <who name="Slava Aseev">ptrnine</who>
    <bug_when>2020-09-02 12:13:12 +0300</bug_when>
    <thetext>Сделал тестовый таск, где &apos;/&apos; в названиях LV заменяется на &apos;-&apos;, а также убран префикс &quot;lvm2/&quot;

http://webery.altlinux.org/task/257200

Проверил на raid+lvm2 - работает</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>192978</commentid>
    <comment_count>10</comment_count>
    <who name="Slava Aseev">ptrnine</who>
    <bug_when>2020-10-02 18:14:51 +0300</bug_when>
    <thetext>В общем, новости печальные, обнаружился еще один баг, гораздо более серьезный.
Оказалось, что evms при деактивации RAID на LVM2 LV может повиснуть намертво, да так, что никакой SIGKILL не поможет (либо срабатывает с ооочень огромной задержкой)

Баг воспроизводится не всегда, при чем от действи</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>192979</commentid>
    <comment_count>11</comment_count>
    <who name="Slava Aseev">ptrnine</who>
    <bug_when>2020-10-02 18:16:50 +0300</bug_when>
    <thetext>(Ответ для Slava Aseev на комментарий #10)
&gt; В общем, новости печальные, обнаружился еще один баг, гораздо более
&gt; серьезный.
&gt; Оказалось, что evms при деактивации RAID на LVM2 LV может повиснуть
&gt; намертво, да так, что никакой SIGKILL не поможет (либо срабатывает с ооочень
&gt; огромной задержкой)
&gt; 
&gt; Баг воспроизводится не всегда, при чем от действи

При чем от действий пользователя ничего не зависит, т.е. возможно это какая-то гонка в ядре.</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>192980</commentid>
    <comment_count>12</comment_count>
    <who name="Slava Aseev">ptrnine</who>
    <bug_when>2020-10-02 18:54:44 +0300</bug_when>
    <thetext>Вот фрагмент dmesg в момент дективации RAID массива и последующего зависания evms. Воспроизвел на evms-ncurses, но то же самое происходит и на инсталляторе. Лог периодически пополняется, Call Trace каждый раз разный, закономерности никакой, разве что в RIP очень часто всякие спинлоки и мьютексы (deadlock?)
Сейчас еще попробую на un-def.

[Oct 2 18:24] md: md255: resync interrupted.
[  +0.004418] md255: detected capacity change from 5363466240 to 0
[  +0.000016] md: md255 stopped.
[ +24.731606] watchdog: BUG: soft lockup - CPU#1 stuck for 23s! [evmsn:2751]
[  +0.000003] Modules linked in: dm_mod(E) raid1(E) af_packet(E) rfkill(E) snd_seq_midi(E) snd_seq_midi_event(E) snd_seq(E) snd_rawmidi(E) snd_seq_device(E) intel_rapl_msr(E) intel_rapl_common(E) intel_pmc_core_pltdrv(E) intel_pmc_core(E) crct10dif_pclmul(E) crc32_pclmul(E) ghash_clmulni_intel(E) snd_intel8x0(E) snd_ac97_codec(E) pktcdvd(E) snd_pcm(E) aesni_intel(E) crypto_simd(E) cryptd(E) glue_helper(E) input_leds(E) snd_timer(E) psmouse(E) joydev(E) pcspkr(E) snd(E) soundcore(E) i2c_piix4(E) ac97_bus(E) intel_agp(E) intel_gtt(E) ac(E) sch_fq_codel(E) vboxsf(OE) vboxguest(OE) ip_tables(E) x_tables(E) ipv6(E) crc_ccitt(E) autofs4(E) overlay(E) squashfs(E) nls_utf8(E) isofs(E) uas(E) usb_storage(E) hid_generic(E) usbhid(E) hid(E) sr_mod(E) cdrom(E) sd_mod(E) pata_acpi(E) ata_generic(E) ohci_pci(E) ata_piix(E) ehci_pci(E) ohci_hcd(E) vmwgfx(E) ehci_hcd(E) drm_kms_helper(E) libata(E) evdev(E) ttm(E) crc32c_intel(E) serio_raw(E) drm(E) usbcore(E) e1000(E) usb_common(E) scsi_mod(E) battery(E)
[  +0.000031]  video(E) button(E)
[  +0.000003] CPU: 1 PID: 2751 Comm: evmsn Tainted: G           OE     5.4.62-std-def-alt1 #1
[  +0.000001] Hardware name: innotek GmbH VirtualBox/VirtualBox, BIOS VirtualBox 12/01/2006
[  +0.000010] RIP: 0010:__raw_callee_save___pv_queued_spin_unlock+0x1/0x12
[  +0.000003] Code: 90 90 90 90 90 90 90 90 90 51 52 56 57 41 50 41 51 41 52 41 53 e8 6f 05 00 00 41 5b 41 5a 41 59 41 58 5f 5e 5a 59 c3 66 90 52 &lt;b8&gt; 01 00 00 00 31 d2 f0 0f b0 17 3c 01 75 02 5a c3 56 0f b6 f0 e8
[  +0.000000] RSP: 0018:ffffc900039bbbd8 EFLAGS: 00000286 ORIG_RAX: ffffffffffffff13
[  +0.000002] RAX: 0000000000000000 RBX: 00000000000000ff RCX: 0000000000000000
[  +0.000001] RDX: ffff888070eb63d8 RSI: 000000000800001f RDI: ffffffff8291d8f8
[  +0.000000] RBP: 0000000000000000 R08: 0000000000000001 R09: ffff888070eb6000
[  +0.000001] R10: 0000000000000001 R11: 0000000000000000 R12: ffff888070eb6000
[  +0.000000] R13: 00000000009000ff R14: 0000000000000001 R15: ffff888070e85000
[  +0.000002] FS:  00007ff08ef0d740(0000) GS:ffff88807a100000(0000) knlGS:0000000000000000
[  +0.000000] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[  +0.000001] CR2: 0000555bb2cc4d08 CR3: 0000000027780001 CR4: 00000000000606e0
[  +0.000003] Call Trace:
[  +0.000016]  mddev_find+0x104/0x280
[  +0.000007]  md_open+0x16/0xd0
[  +0.000004]  __blkdev_get+0xe1/0x550
[  +0.000006]  ? blkdev_get_by_dev+0x50/0x50
[  +0.000001]  blkdev_get+0x38/0x130
[  +0.000001]  ? bd_acquire+0xbc/0xf0
[  +0.000001]  ? blkdev_get_by_dev+0x50/0x50
[  +0.000002]  do_dentry_open+0x13d/0x3a0
[  +0.000004]  path_openat+0x570/0x1630
[  +0.000002]  ? filename_lookup+0xf1/0x170
[  +0.000002]  ? kmem_cache_alloc+0x1ca/0x580
[  +0.000001]  ? __check_object_size+0x130/0x141
[  +0.000002]  do_filp_open+0x91/0x100
[  +0.000001]  ? kmem_cache_alloc+0x1ca/0x580
[  +0.000001]  ? __check_object_size+0x130/0x141
[  +0.000002]  do_sys_open+0x184/0x220
[  +0.000003]  do_syscall_64+0x5c/0x140
[  +0.000009]  entry_SYSCALL_64_after_hwframe+0x44/0xa9
[  +0.000005] RIP: 0033:0x7ff08f33b674
[  +0.000002] Code: 84 00 00 00 00 00 44 89 54 24 0c e8 96 f4 ff ff 44 8b 54 24 0c 44 89 e2 48 89 ee 41 89 c0 bf 9c ff ff ff b8 01 01 00 00 0f 05 &lt;48&gt; 3d 00 f0 ff ff 77 32 44 89 c7 89 44 24 0c e8 c8 f4 ff ff 8b 44
[  +0.000001] RSP: 002b:00007ffe54567650 EFLAGS: 00000293 ORIG_RAX: 0000000000000101
[  +0.000001] RAX: ffffffffffffffda RBX: 6d76652f7665642f RCX: 00007ff08f33b674
[  +0.000000] RDX: 0000000000000002 RSI: 00007ffe54567710 RDI: 00000000ffffff9c
[  +0.000001] RBP: 00007ffe54567710 R08: 0000000000000000 R09: 00000000000000ff
[  +0.000001] R10: 0000000000000000 R11: 0000000000000293 R12: 0000000000000002
[  +0.000000] R13: 00007ffe54567e30 R14: 0000000000000000 R15: 0000000000000000</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>193348</commentid>
    <comment_count>13</comment_count>
    <who name="Repository Robot">repository-robot</who>
    <bug_when>2020-10-19 20:00:40 +0300</bug_when>
    <thetext>evms-2.5.5-alt46 -&gt; sisyphus:

 Tue Sep 29 2020 Slava Aseev &lt;ptrnine@altlinux&gt; 2.5.5-alt46
 - Fix LVM2 logical volume deactivation (closes: #38796)
 - Remove broken dependency on
   /usr/share/install2/initinstall.d/80-stop-md-dm.sh</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>193352</commentid>
    <comment_count>14</comment_count>
    <who name="Slava Aseev">ptrnine</who>
    <bug_when>2020-10-20 12:14:46 +0300</bug_when>
    <thetext>(Ответ для Repository Robot на комментарий #13)
&gt; evms-2.5.5-alt46 -&gt; sisyphus:
&gt; 
&gt;  Tue Sep 29 2020 Slava Aseev &lt;ptrnine@altlinux&gt; 2.5.5-alt46
&gt;  - Fix LVM2 logical volume deactivation (closes: #38796)
&gt;  - Remove broken dependency on
&gt;    /usr/share/install2/initinstall.d/80-stop-md-dm.sh

Отправил исправление для этого бага по ошибке, оно еще не готово.</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>193450</commentid>
    <comment_count>15</comment_count>
    <who name="Repository Robot">repository-robot</who>
    <bug_when>2020-10-22 20:38:20 +0300</bug_when>
    <thetext>evms-2.5.5-alt47 -&gt; p9:

 Tue Oct 20 2020 Slava Aseev &lt;ptrnine@altlinux&gt; 2.5.5-alt47
 - Revert &quot;Fix LVM2 logical volume deactivation&quot;
   Fix not ready yet and was sent by mistake
 Tue Sep 29 2020 Slava Aseev &lt;ptrnine@altlinux&gt; 2.5.5-alt46
 - Fix LVM2 logical volume deactivation (closes: #38796)
 - Remove broken dependency on
   /usr/share/install2/initinstall.d/80-stop-md-dm.sh
 Tue Sep 15 2020 Slava Aseev &lt;ptrnine@altlinux&gt; 2.5.5-alt45
 - plugins/md:
   + fix raid discovering and md_minor getting for metadata=1.*
     (closes: #35918)
   + use better name&apos;s collision resolving for metadata=1.*
   + use metadata=1.2 by default
   + add RAID test</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>193474</commentid>
    <comment_count>16</comment_count>
    <who name="Slava Aseev">ptrnine</who>
    <bug_when>2020-10-23 11:30:05 +0300</bug_when>
    <thetext>Опять переоткрываю. Скрипт отработал после того, как прошло в p9 :)</thetext>
  </long_desc>
      
      

    </bug>

</bugzilla>