From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on sa.local.altlinux.org X-Spam-Level: X-Spam-Status: No, score=-0.1 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,FREEMAIL_FROM autolearn=ham autolearn_force=no version=3.4.1 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-transfer-encoding:content-language; bh=oC6IhjHUIB8qQL5cdxNPZ+uokmrWt52A4C2zbMw9W2M=; b=Ga1F64Amz9PQ/BY0AiOiE6pt2Dr0QmjvSvEAEuLXDJveLKuzu7ELxKcqkpIDw/7fc9 V1CjkTzNIW5fgZZQTTXOFxY8tKuDOX8sPMgBkI2i4YFl8MAA5obdnzO3XpWh5s7LoPje 6i/9xXJAFj3TVTZZ/zwdqofzx5BdnbOrM3Tmpt1DaLB/KzX9PucPBtcoVHQYeqQnx8GH QBbn20KMw1LHxV3H6R+WI8n+getAcCSQS0WpnN2Umx9e8TBQi5nfFEj+kYr4q7yi2gMn uFQdauEJSHnRtyl5lyGMDBYZXI3Gk7WUenyZknxEDfrSoE0VcDlYFi2TgZuxK6bM6jts vYIQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=oC6IhjHUIB8qQL5cdxNPZ+uokmrWt52A4C2zbMw9W2M=; b=PYC5nZvH4fRL1an+Z11U/bGyzAi39Qw4UsQEEFD+zR/SPdpHpFlVPhF/P8z1FHzYGR G7qxZe+PHjvROngGnP/KT7UZWtOeMn67jD5YhQYjmAWugtSrFcy//kriMUS62aZLhRAu BRhpcZY8rvLsoRkRM98jhxeEV4hL79N2PnfOtlpOwfWR2gB7A/bkYdroQsqCU0LUO1BS nJVfhWWGXwYE9AP3mD1c65TtwSE6d8hHSnKqqIC4JKeqPTnV9rkuiBB6Jw9BsgJWLS1S I+z3Jhn1QwX26nEW8nCyRifOgRmoVFai/MUV22m6v8R2ANOUtvgTCF0xr2evEaZ+tb1/ sGvQ== X-Gm-Message-State: APjAAAWVrES/xc0ua6Nyr1jDPEaeVuO+LQga5zSP31xVkIZ0l31pUN1J yHLERaBjHqGuQQ80+E/03jjYYscu X-Google-Smtp-Source: APXvYqzPxrAnYRwj1apZkHz62pcyJS2x9UPZUGMCsqJO6J3AQLqBYGMbnMIeEPV0CoWWlpk13kGVXw== X-Received: by 2002:a2e:89c8:: with SMTP id c8mr33804576ljk.73.1556553368823; Mon, 29 Apr 2019 08:56:08 -0700 (PDT) To: make-initrd@lists.altlinux.org References: <20190426123558.GM9023@dhcp129-178.brq.redhat.com> <0e3a3ef2-8637-4ca4-1e95-a5c39841996f@complife.ru> <20190429121835.GV9023@dhcp129-178.brq.redhat.com> <20190429144901.GW9023@dhcp129-178.brq.redhat.com> From: Leonid Krivoshein Message-ID: <8179f21e-383f-65bd-8999-47824bb3121e@gmail.com> Date: Mon, 29 Apr 2019 18:53:50 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: ru Subject: Re: [make-initrd] master updated X-BeenThere: make-initrd@lists.altlinux.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: make-initrd@lists.altlinux.org List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Apr 2019 15:56:14 -0000 Archived-At: List-Archive: 29.04.2019 18:39, Michael A. Kangin пишет: > On 04/29/2019 04:49 PM, Alexey Gladkov wrote: > >>>> root=/dev/nfs это не моё изобретение: >>>> https://github.com/torvalds/linux/blob/master/Documentation/filesystems/nfs/nfsroot.txt#L46 >>>> >>> >>> Я просто задумался, если NFS (и другие фичи) рассматривать и как >>> транспорт, то чей root= в итоге будет. Ну да ладно, у вас там свои идеи >>> наверное есть :) >> >> В каком смысле чей будет ? > > Мм, мне трудновато с непривычки выразиться корректно и понятно :) > > Я имею ввиду, когда несколько фич могут быть самодостаточными, а могут > и использовать друг-друга в качестве промежуточного транспорта - как > они договорятся, которая из них будет обрабатывать параметр root=? > По цепочке все фичи парсят /proc/cmdline, в результате что-то оказывается в глобальной $INITRD_ROOT. Видимо, кто первый, тот и транспорт, и так каждый следующий. А кто последний, тот и root. > > Ну вот допустим есть некая фича "squash-boot", которая использует > nfsroot как транспорт. Мы говорим root=/dev/nfs, чтобы у нас nfs > вообще заработало. Тогда этой squash-boot мы должны дать какой-то > другой параметр вместо root= ? > > Хорошо, допустим мы ей будем давать squash-root= > А в ситуации, когда "squash-boot" будет пользоваться как транспортом > http или iSCSI - мы вообще без root= останемся? > > > Или разделить нынешнюю nfsroot на транспортную фичу, которая будет > хотеть nfsroot= и непосредственно монтировочную (как бы назвать такую > финальную фичу - которая предоставляет подготовленный /root), которая > будет активироваться root=/dev/nfs? > > т.е. например если мы скажем > nfsroot=192.168.0.1:/nfsshare/mysystem root=/dev/nfs > то, как сейчас, 192.168.0.1:/nfsshare/mysystem смонтируется на /root > Кажется излишним такой синтаксис. > а если > nfsroot=192.168.0.1:/nfsshare/images root=nfs:/image1.squash > тогда 192.168.0.1:/nfsshare/images должно быть смонтировано куда-то не > в /root, а дальше пусть разбирается "squash-boot" со своим параметром > root=, который она поймёт как процессить > И такой тоже. Что-то вроде этого напрашивается: root=nfs:server:/nfsshare/images;squash:livecd > > Кстати, в каком объёме нужна будет поддержка NFS? > tcp/udp? v. 3 / 4? kerberos? > > > >>> Если закомментить упоминания syslog: >> А куда у тебя логи идут в этом случае ? > > Чьи, самого дропбира? Пока вникуда. Да они вроде и не нужны особенно.. > Cейчас с сетью, мне кажется нужно думать за ремотные сислоги. > > Вот, говорят, busybox'ный syslog вроде как умеет отсылать: > https://developer.ridgerun.com/wiki/index.php/How_to_Configure_Remote_Syslog_Logging > > > И у меня есть смутная идея - возможно удалось бы экспортировать по > сети /dev/log какой-нибудь хитрой магией netcat/socat > -- Best regards, Leonid Krivoshein.