From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wm1-f43.google.com (mail-wm1-f43.google.com [209.85.128.43]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 726CA31A7E1 for ; Fri, 20 Feb 2026 19:11:59 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.128.43 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1771614721; cv=none; b=WlZarci2Y2r54tveZeKmkdgg65wlvPMXN33XT4bsraBgVQyb2pXuO9jds/ic9Z9upNjDkYKexDd3tf605RRMisiuCALdaSSf2hoHglPQfDysfoTsolKrc8mznWn8aZ9aUk5iRZctnd6MyYcblivSGEEVy2oXru4Hw1lxsvnCSzo= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1771614721; c=relaxed/simple; bh=M8P+BbQ1YqZa4ng6H3k/8o1frpPX12XdeZj5ECuK2xs=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=AnFgfkRXKwqTlIcbQdoaAjExa9j4SDG9Kt3zmPCWIJUTjOpXVTdipJoGc7nZKkTebDvMLf66wKwQCcWrtyIpA7Z38yJVirJQo3ixGw4A6eQ3U2RWuWkxuKQ+qAq2WcIGfuWVZYrbRyPrgTUt06jmSWw6sbX8v1pWCkliNusEHCQ= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=XeURJjEP; arc=none smtp.client-ip=209.85.128.43 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="XeURJjEP" Received: by mail-wm1-f43.google.com with SMTP id 5b1f17b1804b1-48336a6e932so15678515e9.3 for ; Fri, 20 Feb 2026 11:11:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1771614718; x=1772219518; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=zp4Hmr4tnrGJtnxnP1S6eBYh/Nilm6oZrfuoKYFMN2U=; b=XeURJjEPAhhsPz8gwaYzwl8B171cOhVK1QrAju+c45qH0I/E7RF3hSgmwVhCgw/g7R umW/c8CcInLV7DGnspPCOzaZh8IlctKLK3xx/VR+79sYJnswdy6HNXQUdbreUWw9kYzA YsgRq/9UvZWYPx7n2DodWrNIDXDUUVrjU9Q7xnNPy6vzdjiiQP5jIEl00rO+sLebmlum FmYrYuWL6Ia/4QWgk2+woZvH2hLL62go09TzukFizZbP/46i1WigYjU+7KI0zSriFcwx wGwy0CTwl8bYLKZYNWzNOdm76rNcL2IHp9IAYOwMh8lc+NqpgU/BllAuYibUnsTebnwx wwXg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1771614718; x=1772219518; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=zp4Hmr4tnrGJtnxnP1S6eBYh/Nilm6oZrfuoKYFMN2U=; b=UWn7+A8sjjTTtI4QIItMJ2ctpvcRxAaZXKAjAS+Ss4RtK1n6hs2Feq4/8PAuq3Nqgf s6hC1ecykrafREVHBWcy06YEuezqBdxYfM+WsKjhIhmJcDWm3YPMUOz343oWTIgai299 shcP2tmhDa9td1cPBbAG8ixG8TxPwtMzU27+MQSq3PrSGZ8aarO3JN1C7FZZuKsv1Vwh 30EXE2cHMooKKRLp0dDjCp48J2l3UYpUsGUAR9IsUNIYlvthjiGqByFE8cSKtQduVPRp PzUqnCNJseUVWw4qZmxTwqRFw63lZZbsiREx9FiU/joX7R+WGoZWz38PLEij8+UAkh6q 1UKA== X-Forwarded-Encrypted: i=1; AJvYcCVSJ/7FKdbkCsaKX2ei30xcalpHRStlbKuZb/9mdWMrbEIWMeLgje42ERi4CB3PYjln/PNT3BAVn7Ejhl8=@vger.kernel.org X-Gm-Message-State: AOJu0YzwZu1l04VwQSFJFdN1km2n+pexDjR+v1pjTNhsZEpZCzlUqwb7 n6cQxqeuKKEMKTnHqm34Y94fVQ/Rkhjhm/GpA4PVg7pXE+QQ9uN/S7D2 X-Gm-Gg: AZuq6aIdEqQVsIo8MDY5Ytf/L1ddn/ZTBYlC1e1eK7zn8in3g1Ygra4bC1dJeL3UNXM r/U0b5IF6ePip/ebVzmP0iU/m9nHsz+X4hvc2ASNpvG09jxI04prgD65hU2duS0K5p3jY5TV7CU 3DqdwQLKerrTaHaYtUFlbxS3fD0nxI8vlhHKbgCGHBU4VwMdftpu0d9ITzOLr76+EqgCpGA7KXL j7JNCeFU08VPJzuDrq+kZmA18mRFegVQufV/F0zs+aQycW7p9JJCEDMk5e0cxWAxdFfmpM/yvO9 Dl//w1iivUieJQLI1XBbhj2aTeML8JQv28e9s7l1fZ4ksxoS15VJfPbTf0AFw5F7hSUXnNUR3d9 9VAWSk7bFsdo5BsJ6haurnQsBlTcvG15hrBOgNGSkUf8i72Y+yj3npJlPb3vytj1sNysP7zrV8f 4hP7iMqPy8fyqsOWkuv7N5FEmR3RTo5A== X-Received: by 2002:a05:600c:3516:b0:483:a21:7744 with SMTP id 5b1f17b1804b1-483a9637590mr8799125e9.26.1771614717583; Fri, 20 Feb 2026 11:11:57 -0800 (PST) Received: from localhost ([212.73.77.104]) by smtp.gmail.com with UTF8SMTPSA id 5b1f17b1804b1-483a9b21ceasm3704985e9.0.2026.02.20.11.11.55 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 20 Feb 2026 11:11:56 -0800 (PST) From: Askar Safin To: ddiss@suse.de Cc: brauner@kernel.org, initramfs@vger.kernel.org, jack@suse.cz, linux-fsdevel@vger.kernel.org, linux-kbuild@vger.kernel.org, linux-kernel@vger.kernel.org, nathan@kernel.org, nsc@kernel.org, patches@lists.linux.dev, rdunlap@infradead.org, rob@landley.net, viro@zeniv.linux.org.uk Subject: Re: [PATCH 1/2] init: ensure that /dev/console is (nearly) always available in initramfs Date: Fri, 20 Feb 2026 22:11:50 +0300 Message-ID: <20260220191150.244006-1-safinaskar@gmail.com> X-Mailer: git-send-email 2.47.3 In-Reply-To: <20260220105913.4b62e124.ddiss@suse.de> References: <20260220105913.4b62e124.ddiss@suse.de> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit David Disseldorp : > I'd prefer not to go down this path: > - I think it's reasonable to expect that users who override the default > internal initramfs know what they're doing WRT /dev/console creation. > - initramfs can be made up of concatenated cpio archives, so tools which > insist on using GNU cpio and run into mknod EPERM issues could append > the nodes via gen_init_cpio, while continuing to use GNU cpio for > everything else. This cannot be done in proper way. Let's assume we want to build *builtin* initramfs using GNU cpio and then concatenate to it an archive made by gen_init_cpio. Then we want CONFIG_INITRAMFS_SOURCE to accept already existing cpio archive AND file in gen_init_cpio format. But, according to CONFIG_INITRAMFS_SOURCE docs in usr/Kconfig, this is not possible (I didn't check whether this is true, I just have read the docs.) This means that we should do this: 1. Generate an archive by invoking gen_init_cpio and concatenate it to our preexisting archive 2. Create kernel config, while specifying resulting archive in CONFIG_INITRAMFS_SOURCE 3. Build the kernel Unfortunately, this will not work, because to invoke gen_init_cpio you should build it first. And you cannot build it if there is no config (I checked this). So, we should do this: 1. Create kernel config, while specifying an archive in CONFIG_INITRAMFS_SOURCE, which *DOES NOT EXISTS YET* 2. Build gen_init_cpio by invoking "make usr/gen_init_cpio" 3. Create an archive by invoking gen_init_cpio and concatenate it to our preexisting archive. Put resulting archive to the path specified in CONFIG_INITRAMFS_SOURCE 4. Build the kernel Unfortunately, this will not work, either, because command "make usr/gen_init_cpio" doesn't work in clean kernel tree even if config exists (I checked this). This means that the only remaining way is this: 1. Create *fake* kernel config 2. Build whole kernel (!!!) 3. Create an archive by invoking gen_init_cpio and concatenate it to our preexisting archive 4. Create config, this time for real. Specify archive created in previous step as CONFIG_INITRAMFS_SOURCE 5. Build the kernel, this time for real I hope you agree that this is totally insane. So, there is no proper way to create builtin initramfs by concatenating archives created by GNU cpio and gen_init_cpio. I think this is a bug in kbuild, and it probably needs to be fixed. But I think that my patchset is a better approach. My patchset simply ensures that /dev/console and /dev/null are always available, no matter what. And thus my patchset side steps the whole issue. Here are additional arguments in favor of my patchset. * The kernel itself relies on presence of /dev/console in console_on_rootfs. There is even comment there that currently says that opening of /dev/console should never fail. (The comment is wrong, and this patchset fixes it.) So, if you happen to supply builtin initramfs without /dev/console, then you will build kernel, which violates its own assumptions. This will not be detected until we actually try to boot the kernel. And even then it will be hard to understand what exactly went wrong. Why should we allow this failure mode? Let's instead ensure that this will never happen. I. e. let's make sure that the kernel's asssumptions are always true! * My patchset makes the kernel not more complex, but more simple! (28 insertions(+), 33 deletions(-).) Moreover, my patchset makes it simpler not only in LoC sense, but in conceptual sense, too! Currently codes in usr/default_cpio_list and init/noinitramfs.c are very similar. It is possible that they will be out of sync in some point of future. By the way, noticing that they are out of sync is *very* hard. Consider this scenario: usr/default_cpio_list contains this line: nod /dev/null 0666 0 0 c 1 3 and init/noinitramfs.c contains this line: init_mknod("/dev/null", S_IFCHR | 0666, new_encode_dev(MKDEV(1, 3))); Are these lines equivalent? You may think they are, but they are not. init_mknod function above in fact creates node with different rights due to umask of kernel thread. (And thus unprivileged users will be unable to write to /dev/null...) My patchset merges both codes into a single helper, thus making sure they will never be out of sync. And thus my patchset reduces complexity of the kernel. * Currently it is okay not to put /dev/console to external initramfs. But it is not okay not to put it to builtin initramfs. Why creating builtin initramfs is harder than creating external initramfs? Why we make lifes of developers in one of these cases harder without any reason? Consider this scenario: somebody built kernel and external initramfs. Everything works. Now they make this initramfs to be builtin. Of course, they expect that everything will continue to work as before. But it doesn't work. PID 1 doesn't print anything to console, and you cannot even debug this, because it doesn't print anything to console and you cannot see your debug printfs! This clearly violates principle of least surprise. -- Askar Safin