7369 2005-07-15 02:35:59 +0400 udev tmpfs overrides LVM nodes created at startup 2007-03-24 15:21:59 +0300 1 1 4 Development Sisyphus udev unstable all Linux CLOSED FIXED P2 critical --- 7101 1 gns vsu abulava arseny hiddenman icesik mike oes rider sbolshakov shaba thresh qa-sisyphus oldest_to_newest 27292 0 gns 2005-07-15 02:35:59 +0400 udevd стартует после активации LVM, из-за чего созданные LVM устройства стаановятся недоступны. 27293 1 gns 2005-07-15 02:43:42 +0400 решение: --- 00-lsb.rules 2005-03-31 18:57:09 +0300 +++ 00-lsb.rules.gns 2005-07-15 01:37:18 +0300 @@ -15,7 +15,6 @@ # block # ignore dm -KERNEL="dm-[0-9]*", NAME="" KERNEL="device-mapper", NAME="mapper/control" KERNEL="raw[0-9]*", NAME="raw/%k" ------------------------------------------- /etc/udev/rules.d/10-lvm.rules: ## LVM compatibility by gns@altlinux.org KERNEL="dm-[0-9]*", PROGRAM="/etc/udev/scripts/lvm-vg.sh %M %m", NAME="%k", SYMLINK="%c" ------------------------------------------- /etc/udev/scripts/lvm-vg.sh: #!/bin/sh ## LVM compatibility by gns@altlinux.org [ -e /usr/sbin/vgmknodes ] && /usr/sbin/vgmknodes >/dev/null 2>/dev/null /sbin/devmap_name $* ------------------------------------------- упомянутый devmap_name выковыривается отсюда: http://gd.tuwien.ac.at/gnu/sourceware/dm/multipath-tools/multipath-tools-0.4.3.tar.bz2 можно не собирать весь multipath-tools, взять один файл и положить в libdevmapper или сам udev. 27295 2 989 gns 2005-07-15 02:52:30 +0400 Created attachment 989 devmap_name.c 27296 3 990 gns 2005-07-15 02:52:49 +0400 Created attachment 990 makefile for it 27297 4 991 gns 2005-07-15 02:53:09 +0400 Created attachment 991 devmap_name.c 27299 5 wrar 2005-07-15 07:00:09 +0400 *** Bug 7370 has been marked as a duplicate of this bug. *** 27312 6 rider 2005-07-15 11:55:54 +0400 IMHO все-таки стоит собрать multipath-tools Может быть соберете ? там есть только одна проблема: gpt.c:85: undefined reference to `__le16_to_cpu' надо либо затащить byteorder к себе, либо попробовать собрать с glibc-kernheaders, но в этом случае может поломаться что-то другое. 27313 7 rider 2005-07-15 12:09:57 +0400 да, в новом multipath-tools пофиксили сборку. но он доступен только в git За основу можно взять пакет из SuSE: http://ftp.lug.ro/suse/people/lmb/multipath-tools/multipath-tools-0.4.4-0.18.src.rpm 27319 8 gns 2005-07-15 13:40:31 +0400 > IMHO все-таки стоит собрать multipath-tools кому-то оно надо? + в udev появляется совершенно излишняя зависимость на этот пакет. imho все же стоит иметь отдельный бинарь (независимо от этого с multipath я все же поиграюсь). 27322 9 rider 2005-07-15 13:53:26 +0400 Надо. Да и devmap_name можно собрать в отдельный пакет, но из multipath-tools.src.rpm 29705 10 rider 2005-08-31 12:41:51 +0400 Nick, так и не добрался ты до multipath-tools ? 29715 11 gns 2005-08-31 14:40:52 +0400 (In reply to comment #10) > Nick, так и не добрался ты до multipath-tools ? добирался... тестировать не на чем, из него всего мне один devmap_name нужен. но могу залить с формулировкой УМР :) 29716 12 rider 2005-08-31 14:42:45 +0400 заливай, там разберемся. 29721 13 gns 2005-08-31 16:52:42 +0400 (In reply to comment #12) > заливай, там разберемся. залил. осталось придумать в какой пакет положить все эти /etc/udev/scripts/lvm-vg.sh (обычный rules.d/multipath.rules не катит - нужно делать vgmknodes). 29724 14 rider 2005-08-31 17:48:21 +0400 либо в multipath-tools, либо соответственно в lvm2 Надо подумать как лучше сделать. Можно конечно и в udev, но тогда мне придется в нем поставить соответствующие зависимости. 29727 15 gns 2005-08-31 17:59:30 +0400 (In reply to comment #14) > либо в multipath-tools я вынес devmap_name в отдельный пакет, тогда уж в него. но лучше не стоит. >либо соответственно в lvm2 а если udev нету? > Надо подумать как лучше сделать. > Можно конечно и в udev, но тогда мне придется в нем поставить соответствующие > зависимости. на маленький devmap_name, наверное так лучше всего. нужно еще из дефолтных правил вынести строку про ignore dm. 29729 16 rider 2005-08-31 18:05:35 +0400 (In reply to comment #15) > (In reply to comment #14) > > либо в multipath-tools > я вынес devmap_name в отдельный пакет, тогда уж в него. но лучше не стоит. Почему ? > > >либо соответственно в lvm2 > а если udev нету? Если udev нет, то все равно все будет работать. > > > Надо подумать как лучше сделать. > > Можно конечно и в udev, но тогда мне придется в нем поставить соответствующие > > зависимости. > на маленький devmap_name, наверное так лучше всего. нужно еще из дефолтных правил > вынести строку про ignore dm. Лучше конечно если это кто-то сделает в отдельных пакетах. Ну или в виде патча к текущему udev (068-alt2). Но лучше все-таки отдельно. 29731 17 gns 2005-08-31 18:20:46 +0400 > Почему ? некрасиво можно отдельно udev-lvmtool, в него эту ботву. и пусть udev (или lvm? как все сложно :)) требует этот пакет. а он требует devmap_name. 33834 18 rider 2005-12-14 14:41:10 +0300 ну так что, пакет готов ? 33934 19 gns 2005-12-16 17:46:33 +0300 давно в сизифе -rw-r--r-- 1 ftp ftp 9090 Sep 01 13:25 multipath-tools-devmap_name-0.4.4-alt0.18.i586.rpm , а вот как положить конфиги - я не знаю. проблема в отсутствии у rpm hints - этот пакет должен ставиться если установлены udev и lvm2 33993 20 rider 2005-12-19 13:04:01 +0300 Конфиг можно дать мне, и я его включу в udev 37364 21 enp 2006-04-15 21:45:45 +0400 multipath-tools а также multipath-tools-devmap_name снова в Сизифе, приведенные выше /etc/udev/rules.d/10-lvm.rules и /etc/udev/scripts/lvm-vg.sh вполне рабочие - можно включать их в udev с зависимостью на multipath-tools-devmap_name 37381 22 rider 2006-04-17 13:59:41 +0400 Включим в следущей сборке. 37384 23 gns 2006-04-17 16:02:45 +0400 с одной поправкой в lvm-vg.sh: /sbin/devmap_name $* | sed 's,|,/,g' | sed 's,lvm2/,,' я делаю так, для того чтобы имена устройств LV до загрузки udev и после совпадали: типа /dev/mainvg/coolvolume. 38063 24 rider 2006-05-16 15:28:17 +0400 так где брать этот lvm-vg.sh и правила для udev? Сейчас есть такое правило: KERNEL=="dm-[0-9]*", ACTION=="add", PROGRAM="/sbin/dmsetup info -c --noopencount --noheadings -o name -j %M -m %m", SYMLINK="disk/by-name/%c" его не достаточно ? 38064 25 rider 2006-05-16 15:35:16 +0400 посмотрите на последнем udev. Судя по всему сейчас lvm'ные тома создаются в /dev/disk/by-name/ 38065 26 gns 2006-05-16 15:53:35 +0400 (In reply to comment #25) > посмотрите на последнем udev. > > Судя по всему сейчас lvm'ные тома создаются в /dev/disk/by-name/ > это хорошо, но этого недостаточно - хотелось бы чтобы были доступны /dev/vgtest/lvtest. 38067 27 gns 2006-05-16 16:32:23 +0400 [root@mordor ~]# /sbin/dmsetup info -j 253 -m 0 Name: test-lvtest State: ACTIVE Tables present: LIVE Open count: 0 Event number: 0 Major, minor: 253, 0 Number of targets: 1 UUID: LVM-mqIQOvy4V0T2LLfF67WgfFsdA7iFEAkPy9UwCbiNG7a0zGo9Nqc56wj4izwSqZH9 хм. если у lvm томов всегда есть "LVM" в UUID, можно их по этому признаку искать и для них создавать дополнительный симлинк, типа /sbin/dmsetup info --noheadings -c -o name -j 253 -m 1 | sed 's,-,/,g' | sed 's,//,-,g' 38068 28 gns 2006-05-16 16:43:04 +0400 давай я вечерком напишу обвязку для всего этого - обрабатывая LVM специальным образом и сохраняя текущее поведение для остальных? 38072 29 rider 2006-05-16 17:18:42 +0400 Давай. Тогда сразу делай патч на мой git: rsync://rsync.altlinux.org/people/rider/git/udev.git 38086 30 gns 2006-05-16 19:59:41 +0400 (In reply to comment #29) > Давай. > > Тогда сразу делай патч на мой git: > rsync://rsync.altlinux.org/people/rider/git/udev.git > gns@mordor new/udev/git $ git-clone rsync://rsync.altlinux.org/people/rider/git/udev.git git Welcome to ALT Linux Team public rsync server! receiving file list ... rsync: link_stat "/rider/git/udev.git/objects/." (in people) failed: No such file or directory (2) done 38090 31 1490 gns 2006-05-16 21:54:27 +0400 Created attachment 1490 поддержка LVM device nodes замечательно работает с вот такой штукой: scripts/dm_helper.sh: #!/bin/sh dminfo=$(/sbin/dmsetup info -c --noopencount --noheadings -j $1 -m $2) echo DM_NAME=$(echo $dminfo | cut -d: -f 1) echo DM_NAME_LVM=$(echo $dminfo | cut -d: -f 1 | sed 's,-,/,g' | sed 's,//,-,g') echo DM_ID=$(echo $dminfo | cut -d: -f 8 ) после этого получаем: find /dev/ -name \*te\* /dev/test /dev/test/lvtest-my /dev/test/lvtest /dev/disk/by-name/test-lvtest--my /dev/disk/by-name/test-lvtest 38112 32 rider 2006-05-17 15:15:28 +0400 забыл udev.git выложить Сейчас можно забрать. По поводу изменения: я считаю не очень хорошо, когда создаются какие-то файлы по именам в /dev/ т.е. - если я правильно понял, то DM_NAME_LVM в теории может привести к неработоспособности чего-либо, если пользователь назовёт том каким-то именем, под которое есть устройство. Например hda 38113 33 gns 2006-05-17 15:32:41 +0400 > т.е. - если я правильно понял, то DM_NAME_LVM в теории может привести к > неработоспособности чего-либо, если пользователь назовёт том каким-то именем, > под которое есть устройство. > > Например hda только если обозвать volume group, тогда будет дира /dev/hda/. 38114 34 gns 2006-05-17 15:40:06 +0400 > > Например hda > только если обозвать volume group, тогда будет дира /dev/hda/. том *всегда* будет в подкаталоге: /dev/hda/lvolume. LVM по жизни так работает, если без udev. и vgchange -ay именно так создает - в т.ч. поверх udev (возможно, он для начала не позволит vgcreate hda ?). а пользователь если захочет, всегда сможет прострелить себе ногу. 38118 35 rider 2006-05-17 16:11:22 +0400 Понятно. Тогда давайте так: скрипт переместите в /lib/udev/ и бросайте сюда патч на git. 38121 36 1493 gns 2006-05-17 20:34:18 +0400 Created attachment 1493 git patch for udev 091 вот, собственно 38128 37 rider 2006-05-18 10:12:12 +0400 Добавил в 092-alt1 38310 38 enp 2006-05-25 15:00:52 +0400 Сейчас при запущенном udevd имеем такое поведение: # lvscan ACTIVE '/dev/system/root' [2.00 GB] inherit ACTIVE '/dev/system/home' [1.00 GB] inherit ACTIVE '/dev/system/var' [1.00 GB] inherit ACTIVE '/dev/system/data' [65.00 GB] inherit # /sbin/lvcreate -L1000 -s -nhomebackup /dev/system/home Symbolic link /dev/mapper/system-home not created: file exists Failed to create symlinks for home. Failed to suspend origin home # lvscan ACTIVE '/dev/system/root' [2.00 GB] inherit ACTIVE '/dev/system/home' [1.00 GB] inherit ACTIVE '/dev/system/var' [1.00 GB] inherit ACTIVE '/dev/system/data' [65.00 GB] inherit ACTIVE '/dev/system/homebackup' [1000.00 MB] inherit # mount /dev/system/homebackup /mnt/backup /dev/system/homebackup: Invalid argument mount: /dev/system/homebackup: can't read superblock # lvremove /dev/system/homebackup Do you really want to remove active logical volume "homebackup"? [y/n]: y Logical volume "homebackup" successfully removed Способ борьбы (думаю, сильно неправильный) : комментируем в 60-persistent-storage.rules все строки с KERNEL=="dm-[0-9]*", откатываемся на 10-lvm.rules и lvm-vg.sh, а затем после каждого создания/удаления логических томов вызываем lvscan. Если не делать вышесказанного, то нужно время от времени удалять инвалидные ссылки вида /dev/vgname/lvname -> /dev/mapper/vgname-lvname, /dev/mapper/vgname-lvname удаляется сам. Как правильно с этим бороться? 38311 39 rider 2006-05-25 15:06:13 +0400 2gns: что скажешь ? 38312 40 gns 2006-05-25 15:17:31 +0400 (In reply to comment #39) > 2gns: > что скажешь ? откуда ссылки /dev/vgname/lvname -> /dev/mapper/vgname-lvname - я не знаю, у меня их нет: [root@localhost eth0]# ll /dev/caybo/mirror lrwxrwxrwx 1 root root 7 May 25 03:10 /dev/caybo/mirror -> ../dm-1 у меня все работает на свежеустановленном 3.0, обновленом до сизифа: [root@localhost eth0]# lvscan ACTIVE '/dev/caybo/postie' [400.00 MB] inherit ACTIVE '/dev/caybo/mirror' [10.00 GB] inherit [root@localhost eth0]# lvcreate -s -L100M -n postiebackup /dev/caybo/postie Logical volume "postiebackup" created root@localhost eth0]# lvscan ACTIVE Original '/dev/caybo/postie' [400.00 MB] inherit ACTIVE '/dev/caybo/mirror' [10.00 GB] inherit ACTIVE Snapshot '/dev/caybo/postiebackup' [100.00 MB] inherit [root@localhost eth0]# mount /dev/caybo/postiebackup /mnt/floppy/ [root@localhost eth0]# mount /dev/hda2 on / type ext3 (rw) proc on /proc type proc (rw,gid=19) devpts on /dev/pts type devpts (rw,gid=5,mode=620) /dev/hda1 on /boot type ext3 (rw) udev on /dev type tmpfs (rw,mode=755,size=5m) /dev/pts on /dev/pts type none (rw) shmfs on /dev/shm type tmpfs (rw) usbfs on /proc/bus/usb type usbfs (rw) /dev/dm-0 on /var/lib/vservers/postie.caybo.ru type ext3 (rw) /dev/dm-1 on /var/ftp/pub type ext2 (rw) /dev/dm-4 on /mnt/floppy type ext3 (rw) [root@localhost eth0]# rpm -q lvm2 lvm2-2.02.01-alt2 [root@localhost eth0]# rpm -q udev udev-092-alt1 [root@localhost eth0]# umount /mnt/floppy/ [root@localhost eth0]# lvremove /dev/caybo/postiebackup Do you really want to remove active logical volume "postiebackup"? [y/n]: y Logical volume "postiebackup" successfully removed [root@localhost eth0]# ll /dev/caybo/ total 0 drwx------ 2 root root 80 May 25 14:15 ./ lrwxrwxrwx 1 root root 24 May 25 14:15 postie -> /dev/mapper/caybo-postie drwxr-xr-x 11 root root 3660 May 25 14:15 ../ lrwxrwxrwx 1 root root 7 May 25 03:10 mirror -> ../dm-1 [root@localhost eth0]# lvcreate -s -L100M -n postiebackup /dev/caybo/postie Logical volume "postiebackup" created [root@localhost eth0]# lvscan ACTIVE Original '/dev/caybo/postie' [400.00 MB] inherit ACTIVE '/dev/caybo/mirror' [10.00 GB] inherit ACTIVE Snapshot '/dev/caybo/postiebackup' [100.00 MB] inherit [root@localhost eth0]# lvremove /dev/caybo/postiebackup Do you really want to remove active logical volume "postiebackup"? [y/n]: y Logical volume "postiebackup" successfully removed ... и так далее. не воспроизводится, в общем. 38313 41 enp 2006-05-25 16:06:07 +0400 > Способ борьбы ... Однако этот способ все равно приводит к: + /sbin/lvscan /dev/dm-4: stat failed: No such file or directory Path /dev/dm-4 no longer valid for device(253,4) /dev/disk/by-uuid/7ac36a0d-59a7-457a-871a-0b2e929c3a8d: stat failed: No such file or directory Path /dev/disk/by-uuid/7ac36a0d-59a7-457a-871a-0b2e929c3a8d no longer valid for device(253,4) Aborting - please provide new pathname for what used to be /dev/disk/by-uuid/7ac36a0d-59a7-457a-871a-0b2e929c3a8d ACTIVE '/dev/system/root' [2.00 GB] inherit ACTIVE '/dev/system/home' [1.00 GB] inherit ACTIVE '/dev/system/var' [1.00 GB] inherit ACTIVE '/dev/system/data' [65.00 GB] inherit 38314 42 enp 2006-05-25 16:08:26 +0400 (In reply to comment #41) > > Способ борьбы ... > > Однако этот способ все равно приводит к: > ... Но не всегда. Вот сейчас не воспроизвелось :( 38315 43 gns 2006-05-25 16:11:06 +0400 пожалуйста, если есть возможность - попробуйте воспроизвести на чистом сизифе (3.0 -> sisyphus). у меня не воспроизводится, похоже на какой-то подземный стук в самом lvm - зачем ему /dev/disk/by-uuid/7ac36a0d-59a7-457a-871a-0b2e929c3a8? 38318 44 enp 2006-05-25 16:24:56 +0400 (In reply to comment #40) > (In reply to comment #39) > > 2gns: > > что скажешь ? > > откуда ссылки /dev/vgname/lvname -> /dev/mapper/vgname-lvname - я не знаю, у > меня их нет: > [root@localhost eth0]# ll /dev/caybo/mirror > lrwxrwxrwx 1 root root 7 May 25 03:10 /dev/caybo/mirror -> ../dm-1 Удалил 10-lvm.rules и lvm-vg.sh, раскомментировал в 60-persistent-storage.rules все строки с KERNEL=="dm-[0-9]*". Перегрузился. Имею: root@asterisk ~ # ls -l /dev/mapper total 0 lrwxrwxrwx 1 root root 16 May 25 19:19 control -> ../device-mapper root@asterisk ~ # ls -l /dev/device-mapper crw-rw---- 1 root root 10, 63 May 25 19:19 /dev/device-mapper root@asterisk ~ # ls -l /dev/system ls: /dev/system: No such file or directory root@asterisk ~ # lvscan ACTIVE '/dev/system/root' [2.00 GB] inherit ACTIVE '/dev/system/home' [1.00 GB] inherit ACTIVE '/dev/system/var' [1.00 GB] inherit ACTIVE '/dev/system/data' [65.00 GB] inherit На самом деле все так: есть hda и hdc, hda1+hdc1 - это md0 (/boot), на hda2 и hdc2 - swap, hda3+hdc3 - это md1, который целиком отведен под system. Загрузкой занимается специальный initrd, в linuxrc которого написано: #!/bin/sh /bin/insmod -f /lib/modules/2.6.16-std26-up-alt5/kernel/drivers/md/dm-mod.ko /bin/insmod -f /lib/modules/2.6.16-std26-up-alt5/kernel/drivers/ide/ide-core.ko /bin/insmod -f /lib/modules/2.6.16-std26-up-alt5/kernel/drivers/ide/pci/piix.ko /bin/insmod -f /lib/modules/2.6.16-std26-up-alt5/kernel/drivers/ide/pci/generic.ko /bin/insmod -f /lib/modules/2.6.16-std26-up-alt5/kernel/drivers/ide/ide-generic.ko /bin/insmod -f /lib/modules/2.6.16-std26-up-alt5/kernel/drivers/ide/ide-disk.ko /bin/insmod -f /lib/modules/2.6.16-std26-up-alt5/kernel/drivers/md/raid0.ko /bin/insmod -f /lib/modules/2.6.16-std26-up-alt5/kernel/drivers/md/raid1.ko /bin/insmod -f /lib/modules/2.6.16-std26-up-alt5/kernel/fs/mbcache.ko /bin/insmod -f /lib/modules/2.6.16-std26-up-alt5/kernel/fs/jbd/jbd.ko /bin/insmod -f /lib/modules/2.6.16-std26-up-alt5/kernel/fs/ext3/ext3.ko /bin/mount -t proc proc /proc /bin/mount -t tmpfs -o size=1m none /dev/mapper /bin/mount -t tmpfs -o size=1m none /dev/system /bin/mount -t tmpfs -o size=1m none /etc /bin/mount -t tmpfs -o size=1m none /var /bin/mknod -m 600 /dev/mapper/control c 10 63 /bin/raidautorun /dev/md255 cat /proc/mdstat /bin/lvm vgscan /bin/lvm vgchange -ay /bin/lvm lvscan read cmdline </proc/cmdline cmdline=" $cmdline " if test -z "${cmdline##*[ ]real_root=*}" ; then root="${cmdline##*[ ]real_root=}" echo "real_root param is " $root root_mapping=`ls -l $root | awk -F'->' '{print $2}'` echo "root mapping is " $root_mapping major=`ls -l $root_mapping | awk '{print $5}' | awk -F',' '{print $1}'` minor=`ls -l $root_mapping | awk '{print $6}'` echo "root mapping is " $root_mapping " " $major " " $minor echo $(( ($minor & 0xff) | ($major << 8) | (($minor & ~0xff) << 12) )) > /proc/sys/kernel/real-root-dev fi /bin/umount /var /bin/umount /etc /bin/umount /dev/system /bin/umount /dev/mapper /bin/umount /proc Не спорю, что это не самый прямой способ, но более прямые у меня не заработали - см. сизифовские арихивы Но связи с тем, что у меня рут на lvm и тем, что происходит, я не вижу. /dev/caybo/mirror -> ../dm-1 у gns меня сильно удивляет. Это без ручных манипуляций, т.е. так отрабатывает udevd и компания? 38319 45 gns 2006-05-25 16:46:14 +0400 > /dev/caybo/mirror -> ../dm-1 у gns меня сильно удивляет. Это без ручных > манипуляций, т.е. так отрабатывает udevd и компания? да правда, в процессе симлинки иногда меняются: появляется postie -> /dev/mapper/caybo-postie, но это явно делает не udev а сам lvm. есть у него такая вредная (теперь) привычка - создавать device nodes и symlinks. / на lvm я никогда не делал, вечером попробую (обычно у меня типа Disk /dev/hdd: 200.0 GB, 200049647616 bytes 255 heads, 63 sectors/track, 24321 cylinders Units = cylinders of 16065 * 512 = 8225280 bytes Device Boot Start End Blocks Id System /dev/hdd1 1 10 80293+ 83 Linux /dev/hdd2 11 130 963900 82 Linux swap / Solaris /dev/hdd3 131 300 1365525 fd Linux raid autodetect /dev/hdd4 301 24321 192948682+ 5 Extended /dev/hdd5 301 24321 192948651 fd Linux raid autodetect и md0 - /, pvcreate /dev/md1). 38320 46 enp 2006-05-25 17:20:12 +0400 (In reply to comment #45) > > /dev/caybo/mirror -> ../dm-1 у gns меня сильно удивляет. Это без ручных > > манипуляций, т.е. так отрабатывает udevd и компания? > > да > > правда, в процессе симлинки иногда меняются: появляется postie -> > /dev/mapper/caybo-postie, но это явно делает не udev а сам lvm. есть у него > такая вредная (теперь) привычка - создавать device nodes и symlinks. да, так оно и есть: /dev/caybo/postie -> /dev/mapper/caybo-postie, но /dev/caybo/postie -> ../dm-1 я никогда не видел > / на lvm я никогда не делал, вечером попробую Попробуйте. Т.к. если / не на lvm, то все происходит именно так, как вы описываете (и lvtest -> ../dm-0 есть) : root@test ~ # fdisk -l /dev/hda Disk /dev/hda: 20.0 GB, 20020396032 bytes 16 heads, 63 sectors/track, 38792 cylinders Units = cylinders of 1008 * 512 = 516096 bytes Device Boot Start End Blocks Id System /dev/hda1 1 2031 1023592+ 83 Linux /dev/hda2 2032 3046 511560 82 Linux swap / Solaris /dev/hda3 3047 4984 976752 8e Linux LVM root@test ~ # pvcreate /dev/hda3 Physical volume "/dev/hda3" successfully created root@test ~ # vgcreate test /dev/hda3 Volume group "test" successfully created root@test ~ # ls -l /dev/mapper total 0 lrwxrwxrwx 1 root root 16 May 25 20:12 control -> ../device-mapper root@test ~ # ls -l /dev/test ls: /dev/test: No such file or directory root@test ~ # ls -l /dev/device-mapper crw-rw---- 1 root root 10, 63 May 25 20:12 /dev/device-mapper root@test ~ # lvcreate -nlvtest -L100M test /dev/cdrom: open failed: Read-only file system Logical volume "lvtest" created root@test ~ # ls -l /dev/mapper total 0 lrwxrwxrwx 1 root root 16 May 25 20:12 control -> ../device-mapper brw------- 1 root root 253, 0 May 25 20:14 test-lvtest root@test ~ # ls -l /dev/device-mapper crw-rw---- 1 root root 10, 63 May 25 20:12 /dev/device-mapper root@test ~ # ls -l /dev/mapper total 0 lrwxrwxrwx 1 root root 16 May 25 20:12 control -> ../device-mapper brw------- 1 root root 253, 0 May 25 20:14 test-lvtest root@test ~ # ls -l /dev/test total 0 lrwxrwxrwx 1 root root 7 May 25 20:14 lvtest -> ../dm-0 root@test ~ # service udevd restart Stopping udevd service: [ DONE ] Removing udev device nodes: [ DONE ] Starting udevd service: [ DONE ] Populating /dev [ DONE ] root@test ~ # ls -l /dev/test total 0 lrwxrwxrwx 1 root root 7 May 25 20:15 lvtest -> ../dm-0 В чем тогда разница? 38321 47 gns 2006-05-25 17:22:59 +0400 разница очевидно в том, создает ли ноды lvm или udev. а при загрузке Вы root= как указываете? 38326 48 enp 2006-05-25 22:26:09 +0400 (In reply to comment #47) > разница очевидно в том, создает ли ноды lvm или udev. а при загрузке Вы root= > как указываете? А чем отличается, создает ли ноды lvm или udev? Тогда, когда udevd опущен, ноды созданы средствами vgmknodes. Точно так же они созданы внутри initrd. После старта udevd старое содержимое /dev, насколько я понимаю, уничтожается, и нодами начинает заниматься udevd, а lvm по мере возможностей вставляет ему палки в колеса ;) Но в чем разница - на lvm / или нет? Что меняется? В lilo.conf у меня написано: raid-extra-boot=mbr-only boot=/dev/md0 map=/boot/map install=/boot/boot-bmp.b vga=0x0311 default=linux-up ramdisk=8192 image=/boot/vmlinuz-2.6.16-std26-up-alt5 label=linux-up initrd=/boot/initrd-up append=" real_root=/dev/system/root" read-only Как обрабатывается real_root= см. выше. Параметр root не используется, т.к. у lilo есть привычка его уродовать. На grub не перехожу ввиду отсутствия там raid-extra-boot 43352 49 mike 2006-12-17 21:32:38 +0300 * vsu|x86_64 готовит бомбу с надписью udev-103-alt1 43373 50 vsu 2006-12-17 22:43:45 +0300 (In reply to comment #49) > * vsu|x86_64 готовит бомбу с надписью udev-103-alt1 И это там не трогалось; основная цель - засунуть версию с поддержкой нового синтаксиса (который там очередной раз поменяли). 47126 51 vsu 2007-03-24 15:21:59 +0300 Насколько я понимаю, при использовании startup >= 0.9.8.9-alt1 и udev >= 105-alt3 проблем быть уже не должно, если только не отключить запуск udev из rc.sysinit. Остаётся только race между libblkid и udevd, если в fstab устройства задаются через UUID=... или LABEL=..., но это отдельная проблема (Bug #11133). Переносить создание симлинков /dev/$VG_NAME/$LV_NAME в udevd, на мой взгляд, нецелесообразно - как минимум, появится race (нужно будет каким-то образом дожидаться, когда udevd завершит обработку событий). 989 2005-07-15 02:52:30 +0400 2006-05-16 21:54:27 +0400 devmap_name.c devmap_name.c text/plain 1670 gns I2luY2x1ZGUgPHN0ZGlvLmg+CiNpbmNsdWRlIDxzdGRsaWIuaD4KI2luY2x1ZGUgPHN0cmluZy5o PgojaW5jbHVkZSA8Y3R5cGUuaD4KI2luY2x1ZGUgPHVuaXN0ZC5oPgojaW5jbHVkZSA8bGludXgv a2Rldl90Lmg+CiNpbmNsdWRlIDxsaWJkZXZtYXBwZXIuaD4KCnN0YXRpYyB2b2lkIHVzYWdlKGNo YXIgKiBwcm9nbmFtZSkgewoJZnByaW50ZihzdGRlcnIsICJ1c2FnZSA6ICVzIFstdCB0YXJnZXQg dHlwZV0gZGV2X3RcbiIsIHByb2duYW1lKTsKCWZwcmludGYoc3RkZXJyLCAid2hlcmUgZGV2X3Qg aXMgZWl0aGVyICdtYWpvciBtaW5vcicgb3IgJ21ham9yOm1pbm9yJ1xuIik7CglleGl0KDEpOwp9 CgppbnQgZG1fdGFyZ2V0X3R5cGUoaW50IG1ham9yLCBpbnQgbWlub3IsIGNoYXIgKnR5cGUpCnsK CXN0cnVjdCBkbV90YXNrICpkbXQ7Cgl2b2lkICpuZXh0ID0gTlVMTDsKCXVpbnQ2NF90IHN0YXJ0 LCBsZW5ndGg7CgljaGFyICp0YXJnZXRfdHlwZSA9IE5VTEw7CgljaGFyICpwYXJhbXM7CglpbnQg ciA9IDE7CgoJaWYgKCEoZG10ID0gZG1fdGFza19jcmVhdGUoRE1fREVWSUNFX1NUQVRVUykpKQoJ CXJldHVybiAxOwoKCWlmICghZG1fdGFza19zZXRfbWFqb3IoZG10LCBtYWpvcikgfHwKCSAgICAh ZG1fdGFza19zZXRfbWlub3IoZG10LCBtaW5vcikpCgkJZ290byBiYWQ7CgoJZG1fdGFza19ub19v cGVuX2NvdW50KGRtdCk7CgoJaWYgKCFkbV90YXNrX3J1bihkbXQpKQoJCWdvdG8gYmFkOwoKCWlm ICghdHlwZSkKCQlnb3RvIGdvb2Q7CgoJZG8gewoJCW5leHQgPSBkbV9nZXRfbmV4dF90YXJnZXQo ZG10LCBuZXh0LCAmc3RhcnQsICZsZW5ndGgsCgkJCQkJICAmdGFyZ2V0X3R5cGUsICZwYXJhbXMp OwoJCWlmICh0YXJnZXRfdHlwZSAmJiBzdHJjbXAodGFyZ2V0X3R5cGUsIHR5cGUpKQoJCQlnb3Rv IGJhZDsKCX0gd2hpbGUgKG5leHQpOwoKZ29vZDoKCXByaW50ZigiJXNcbiIsIGRtX3Rhc2tfZ2V0 X25hbWUoZG10KSk7CglyID0gMDsKYmFkOgoJZG1fdGFza19kZXN0cm95KGRtdCk7CglyZXR1cm4g cjsKfQoKaW50IG1haW4oaW50IGFyZ2MsIGNoYXIgKiphcmd2KQp7CglpbnQgYzsKCWludCBtYWpv ciwgbWlub3I7CgljaGFyICp0YXJnZXRfdHlwZSA9IE5VTEw7CgoJd2hpbGUgKChjID0gZ2V0b3B0 KGFyZ2MsIGFyZ3YsICJ0OiIpKSAhPSAtMSkgewoJCXN3aXRjaCAoYykgewoJCWNhc2UgJ3QnOgoJ CQl0YXJnZXRfdHlwZSA9IG9wdGFyZzsKCQkJYnJlYWs7CgkJZGVmYXVsdDoKCQkJdXNhZ2UoYXJn dlswXSk7CgkJCXJldHVybiAxOwoJCQlicmVhazsKCQl9Cgl9CgoJLyogc2FuaXR5IGNoZWNrICov CglpZiAob3B0aW5kID09IGFyZ2MgLSAyKSB7CgkJbWFqb3IgPSBhdG9pKGFyZ3ZbYXJnYyAtIDJd KTsKCQltaW5vciA9IGF0b2koYXJndlthcmdjIC0gMV0pOwoJfSBlbHNlIGlmIChvcHRpbmQgIT0g YXJnYyAtIDEgfHwKCQkgICAyICE9IHNzY2FuZihhcmd2W2FyZ2MgLSAxXSwgIiVpOiVpIiwgJm1h am9yLCAmbWlub3IpKQoJCXVzYWdlKGFyZ3ZbMF0pOwoKCWlmIChkbV90YXJnZXRfdHlwZShtYWpv ciwgbWlub3IsIHRhcmdldF90eXBlKSkKCQlyZXR1cm4gMTsKICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAKCXJldHVybiAwOwp9Cgo= 990 2005-07-15 02:52:49 +0400 2006-05-16 21:54:27 +0400 makefile for it Makefile text/plain 558 gns IyBNYWtlZmlsZQojCiMgQ29weXJpZ2h0IChDKSAyMDAzIENocmlzdG9waGUgVmFyb3F1aSwgPGNo cmlzdG9waGUudmFyb3F1aUBmcmVlLmZyPgpHWklQICAgICAgICA9IC9iaW4vZ3ppcCAtOSAtYwpT VFJJUCAgICAgICA9IHN0cmlwIC0tc3RyaXAtYWxsIC1SIC5jb21tZW50IC1SIC5ub3RlCgpCVUlM RCA9IGdsaWJjCgpPQkpTID0gZGV2bWFwX25hbWUubwpDRkxBR1MgPSAtcGlwZSAtZyAtV2FsbCAt V3VudXNlZCAtV3N0cmljdC1wcm90b3R5cGVzCgppZmVxICgkKHN0cmlwICQoQlVJTEQpKSxrbGli YykKCU9CSlMgKz0gJChsaWJkbSkKZWxzZQoJTERGTEFHUyA9IC1sZGV2bWFwcGVyCmVuZGlmCgpF WEVDID0gZGV2bWFwX25hbWUKCmFsbDogJChCVUlMRCkKCnByZXBhcmU6CglybSAtZiBjb3JlICou byAqLmd6CgpnbGliYzogcHJlcGFyZSAkKE9CSlMpCgkkKENDKSAkKE9CSlMpIC1vICQoRVhFQykg JChMREZMQUdTKQoJJChTVFJJUCkgJChFWEVDKQoJJChHWklQKSAkKEVYRUMpLjggPiAkKEVYRUMp LjguZ3oKCQoKY2xlYW46CglybSAtZiBjb3JlICoubyAkKEVYRUMpICouZ3oK 991 2005-07-15 02:53:09 +0400 2006-05-16 21:54:27 +0400 devmap_name.c devmap_name.c text/plain 1670 gns I2luY2x1ZGUgPHN0ZGlvLmg+CiNpbmNsdWRlIDxzdGRsaWIuaD4KI2luY2x1ZGUgPHN0cmluZy5o PgojaW5jbHVkZSA8Y3R5cGUuaD4KI2luY2x1ZGUgPHVuaXN0ZC5oPgojaW5jbHVkZSA8bGludXgv a2Rldl90Lmg+CiNpbmNsdWRlIDxsaWJkZXZtYXBwZXIuaD4KCnN0YXRpYyB2b2lkIHVzYWdlKGNo YXIgKiBwcm9nbmFtZSkgewoJZnByaW50ZihzdGRlcnIsICJ1c2FnZSA6ICVzIFstdCB0YXJnZXQg dHlwZV0gZGV2X3RcbiIsIHByb2duYW1lKTsKCWZwcmludGYoc3RkZXJyLCAid2hlcmUgZGV2X3Qg aXMgZWl0aGVyICdtYWpvciBtaW5vcicgb3IgJ21ham9yOm1pbm9yJ1xuIik7CglleGl0KDEpOwp9 CgppbnQgZG1fdGFyZ2V0X3R5cGUoaW50IG1ham9yLCBpbnQgbWlub3IsIGNoYXIgKnR5cGUpCnsK CXN0cnVjdCBkbV90YXNrICpkbXQ7Cgl2b2lkICpuZXh0ID0gTlVMTDsKCXVpbnQ2NF90IHN0YXJ0 LCBsZW5ndGg7CgljaGFyICp0YXJnZXRfdHlwZSA9IE5VTEw7CgljaGFyICpwYXJhbXM7CglpbnQg ciA9IDE7CgoJaWYgKCEoZG10ID0gZG1fdGFza19jcmVhdGUoRE1fREVWSUNFX1NUQVRVUykpKQoJ CXJldHVybiAxOwoKCWlmICghZG1fdGFza19zZXRfbWFqb3IoZG10LCBtYWpvcikgfHwKCSAgICAh ZG1fdGFza19zZXRfbWlub3IoZG10LCBtaW5vcikpCgkJZ290byBiYWQ7CgoJZG1fdGFza19ub19v cGVuX2NvdW50KGRtdCk7CgoJaWYgKCFkbV90YXNrX3J1bihkbXQpKQoJCWdvdG8gYmFkOwoKCWlm ICghdHlwZSkKCQlnb3RvIGdvb2Q7CgoJZG8gewoJCW5leHQgPSBkbV9nZXRfbmV4dF90YXJnZXQo ZG10LCBuZXh0LCAmc3RhcnQsICZsZW5ndGgsCgkJCQkJICAmdGFyZ2V0X3R5cGUsICZwYXJhbXMp OwoJCWlmICh0YXJnZXRfdHlwZSAmJiBzdHJjbXAodGFyZ2V0X3R5cGUsIHR5cGUpKQoJCQlnb3Rv IGJhZDsKCX0gd2hpbGUgKG5leHQpOwoKZ29vZDoKCXByaW50ZigiJXNcbiIsIGRtX3Rhc2tfZ2V0 X25hbWUoZG10KSk7CglyID0gMDsKYmFkOgoJZG1fdGFza19kZXN0cm95KGRtdCk7CglyZXR1cm4g cjsKfQoKaW50IG1haW4oaW50IGFyZ2MsIGNoYXIgKiphcmd2KQp7CglpbnQgYzsKCWludCBtYWpv ciwgbWlub3I7CgljaGFyICp0YXJnZXRfdHlwZSA9IE5VTEw7CgoJd2hpbGUgKChjID0gZ2V0b3B0 KGFyZ2MsIGFyZ3YsICJ0OiIpKSAhPSAtMSkgewoJCXN3aXRjaCAoYykgewoJCWNhc2UgJ3QnOgoJ CQl0YXJnZXRfdHlwZSA9IG9wdGFyZzsKCQkJYnJlYWs7CgkJZGVmYXVsdDoKCQkJdXNhZ2UoYXJn dlswXSk7CgkJCXJldHVybiAxOwoJCQlicmVhazsKCQl9Cgl9CgoJLyogc2FuaXR5IGNoZWNrICov CglpZiAob3B0aW5kID09IGFyZ2MgLSAyKSB7CgkJbWFqb3IgPSBhdG9pKGFyZ3ZbYXJnYyAtIDJd KTsKCQltaW5vciA9IGF0b2koYXJndlthcmdjIC0gMV0pOwoJfSBlbHNlIGlmIChvcHRpbmQgIT0g YXJnYyAtIDEgfHwKCQkgICAyICE9IHNzY2FuZihhcmd2W2FyZ2MgLSAxXSwgIiVpOiVpIiwgJm1h am9yLCAmbWlub3IpKQoJCXVzYWdlKGFyZ3ZbMF0pOwoKCWlmIChkbV90YXJnZXRfdHlwZShtYWpv ciwgbWlub3IsIHRhcmdldF90eXBlKSkKCQlyZXR1cm4gMTsKICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAKCXJldHVybiAwOwp9Cgo= 1490 2006-05-16 21:54:27 +0400 2006-05-16 21:54:27 +0400 поддержка LVM device nodes udev-091-alt-dmsetup-lvm.patch text/plain 747 gns LS0tIHVkZXYtMDkxL3VkZXYtcnVsZXMtMDkxLWFsdDIub3JpZy82MC1wZXJzaXN0ZW50LXN0b3Jh Z2UucnVsZXMJMjAwNi0wNS0xNiAyMDo0Njo0MCArMDMwMAorKysgdWRldi0wOTEvdWRldi1ydWxl cy0wOTEtYWx0Mi82MC1wZXJzaXN0ZW50LXN0b3JhZ2UucnVsZXMJMjAwNi0wNS0xNiAyMDo0Njoy MyArMDMwMApAQCAtNDUsNiArNDUsOCBAQAogS0VSTkVMPT0iKlshMC05XSIsIEVOVntJRF9FRER9 PT0iPyoiLCBTWU1MSU5LKz0iZGlzay9ieS1pZC9lZGQtJGVudntJRF9FRER9IgogS0VSTkVMPT0i KlswLTldIiwgRU5We0lEX0VERH09PSI/KiIsIFNZTUxJTksrPSJkaXNrL2J5LWlkL2VkZC0kZW52 e0lEX0VERH0tcGFydCVuIgogCi1LRVJORUw9PSJkbS1bMC05XSoiLCBBQ1RJT049PSJhZGQiLCBQ Uk9HUkFNPSIvc2Jpbi9kbXNldHVwIGluZm8gLWMgLS1ub29wZW5jb3VudCAtLW5vaGVhZGluZ3Mg LW8gbmFtZSAtaiAlTSAtbSAlbSIsIFNZTUxJTks9ImRpc2svYnktbmFtZS8lYyIKK0tFUk5FTD09 ImRtLVswLTldKiIsIElNUE9SVHtwcm9ncmFtfT0iL2V0Yy91ZGV2L3NjcmlwdHMvZG1faGVscGVy LnNoICVNICVtIgorS0VSTkVMPT0iZG0tWzAtOV0qIiwgU1lNTElOSys9ImRpc2svYnktbmFtZS8k ZW52e0RNX05BTUV9IgorS0VSTkVMPT0iZG0tWzAtOV0qIiwgRU5We0RNX0lEfT09IkxWTT8qIiwg U1lNTElOSys9IiRlbnZ7RE1fTkFNRV9MVk19IgogCiBMQUJFTD0icGVyc2lzdGVudF9zdG9yYWdl X2VuZCIK 1493 2006-05-17 20:34:18 +0400 2006-05-17 20:36:02 +0400 git patch for udev 091 udev-lvm.git.diff text/plain 2074 gns ZGlmZiAtLWdpdCBhL1NPVVJDRVMvZG1faGVscGVyIGIvU09VUkNFUy9kbV9oZWxwZXIKbmV3IGZp bGUgbW9kZSAxMDA3NTUKaW5kZXggMDAwMDAwMC4uYzVjMjgxMQotLS0gL2Rldi9udWxsCisrKyBi L1NPVVJDRVMvZG1faGVscGVyCkBAIC0wLDAgKzEsNSBAQAorIyEvYmluL3NoCitkbWluZm89JCgv c2Jpbi9kbXNldHVwIGluZm8gLWMgLS1ub29wZW5jb3VudCAtLW5vaGVhZGluZ3MgLWogJDEgLW0g JDIpCitlY2hvIERNX05BTUU9JChlY2hvICRkbWluZm8gfCBjdXQgLWQ6IC1mIDEpCitlY2hvIERN X0lEPSQoZWNobyAkZG1pbmZvIHwgY3V0IC1kOiAtZiA4ICkKK2VjaG8gRE1fTkFNRV9MVk09JChl Y2hvICRkbWluZm8gfCBjdXQgLWQ6IC1mIDEgfCBzZWQgJ3MsLSwvLGcnIHwgc2VkICdzLC8vLC0s ZycpCmRpZmYgLS1naXQgYS91ZGV2LXJ1bGVzLzYwLXBlcnNpc3RlbnQtc3RvcmFnZS5ydWxlcyBi L3VkZXYtcnVsZXMvNjAtcGVyc2lzdGVudC1zdG9yYWdlLnJ1bGVzCmluZGV4IDM0MGZjOWMuLjMy MTc2YjAgMTAwNjQ0Ci0tLSBhL3VkZXYtcnVsZXMvNjAtcGVyc2lzdGVudC1zdG9yYWdlLnJ1bGVz CisrKyBiL3VkZXYtcnVsZXMvNjAtcGVyc2lzdGVudC1zdG9yYWdlLnJ1bGVzCkBAIC00NSw2ICs0 NSw4IEBAIEtFUk5FTD09IipbITAtOV0iLCBJTVBPUlR7cHJvZ3JhbX09ImVkZF8KIEtFUk5FTD09 IipbITAtOV0iLCBFTlZ7SURfRUREfT09Ij8qIiwgU1lNTElOSys9ImRpc2svYnktaWQvZWRkLSRl bnZ7SURfRUREfSIKIEtFUk5FTD09IipbMC05XSIsIEVOVntJRF9FRER9PT0iPyoiLCBTWU1MSU5L Kz0iZGlzay9ieS1pZC9lZGQtJGVudntJRF9FRER9LXBhcnQlbiIKIAotS0VSTkVMPT0iZG0tWzAt OV0qIiwgQUNUSU9OPT0iYWRkIiwgUFJPR1JBTT0iL3NiaW4vZG1zZXR1cCBpbmZvIC1jIC0tbm9v cGVuY291bnQgLS1ub2hlYWRpbmdzIC1vIG5hbWUgLWogJU0gLW0gJW0iLCBTWU1MSU5LPSJkaXNr L2J5LW5hbWUvJWMiCitLRVJORUw9PSJkbS1bMC05XSoiLCBJTVBPUlR7cHJvZ3JhbX09ImRtX2hl bHBlciAlTSAlbSIKK0tFUk5FTD09ImRtLVswLTldKiIsIFNZTUxJTksrPSJkaXNrL2J5LW5hbWUv JGVudntETV9OQU1FfSIKK0tFUk5FTD09ImRtLVswLTldKiIsIEVOVntETV9JRH09PSJMVk0/KiIs IFNZTUxJTksrPSIkZW52e0RNX05BTUVfTFZNfSIKIAogTEFCRUw9InBlcnNpc3RlbnRfc3RvcmFn ZV9lbmQiCmRpZmYgLS1naXQgYS91ZGV2LnNwZWMgYi91ZGV2LnNwZWMKaW5kZXggMTczYzNlZi4u MDZjNDE5MCAxMDA2NDQKLS0tIGEvdWRldi5zcGVjCisrKyBiL3VkZXYuc3BlYwpAQCAtMzcsNiAr MzcsNyBAQCBCdWlsZFJlcXVpcmVzOiBsaWJzeXNmcy1kZXZlbCA+IDAuNC4wLWFsCiBTb3VyY2Uw OiAlbmFtZS0ldmVyc2lvbi50YXIKIFNvdXJjZTE6CSVuYW1lLXJ1bGVzLSV2ZXJzaW9uLSVyZWxl YXNlLnRhcgogU291cmNlNToJdWRldi5kdmItc2NyaXB0cy5iejIKK1NvdXJjZTY6CWRtX2hlbHBl cgogU291cmNlMTQ6ICAgICAgIHVkZXZkLmluaXQKIAogUGF0Y2gxOgkJdWRldi0wODgtY3JlYXRl LWZsb3BweS5wYXRjaApAQCAtNDQsNiArNDUsNyBAQCBQYXRjaDI6CQl1ZGV2LTAuNDYtYWx0LWNv bXBpbGVfd2FybmluZ3MuCiBQYXRjaDM6CQl1ZGV2LTA5MS11ZXZlbnRfc2VxbnVtLWNyZWF0ZS5w YXRjaAogCiBSZXF1aXJlczoJdWRldl9zdGF0aWMtYWRkb24KK1JlcXVpcmVzOglkbXNldHVwCiBD b25mbGljdHM6CWxpbnV4LWhvdHBsdWcKIAogJWRlc2NyaXB0aW9uCkBAIC0xMzIsNiArMTM0LDcg QEAgZm9yIGkgaW4gZXh0cmFzL3BhdGhfaWQgZXh0cmFzL2Zsb3BweSBleAogICAgICVtYWtlIHVk ZXZkaXI9L2RldiBFWFRSQVM9JGkgREVTVERJUj0lYnVpbGRyb290IGxpYmRpcj0vJV9saWIgdXNy bGliZGlyPSVfbGliZGlyIGluc3RhbGwKIGRvbmUKIAoraW5zdGFsbCAtbSAwNzU1ICVTT1VSQ0U2 ICVidWlsZHJvb3QvJV9saWIvdWRldi8KIAogJV9fcm0gLWYgJWJ1aWxkcm9vdCVfc3lzY29uZmRp ci91ZGV2L3VkZXYucGVybWlzc2lvbnMKICVfX3JtIC1mICVidWlsZHJvb3QlX3N5c2NvbmZkaXIv dWRldi91ZGV2LnJ1bGVzLmRldmZzCg==