From mboxrd@z Thu Jan 1 00:00:00 1970 X-GM-THRID: 7361699629460619264 X-Received: by 2002:a2e:a4d2:0:b0:2e1:a8da:fa33 with SMTP id p18-20020a2ea4d2000000b002e1a8dafa33mr30807ljm.29.1714663030371; Thu, 02 May 2024 08:17:10 -0700 (PDT) X-BeenThere: isar-users@googlegroups.com Received: by 2002:a2e:9b06:0:b0:2e1:5684:c5bf with SMTP id 38308e7fff4ca-2e1bd263300ls4731391fa.2.-pod-prod-04-eu; Thu, 02 May 2024 08:17:08 -0700 (PDT) X-Google-Smtp-Source: AGHT+IFOXqjQ51IuOiTNmRIo9HFRJpDFpNBVctNGF9om/hUE2xgIoMUh1nEVidygm1m/XL4ZCu6v X-Received: by 2002:a2e:9410:0:b0:2df:907e:6de3 with SMTP id i16-20020a2e9410000000b002df907e6de3mr23211ljh.35.1714663025646; Thu, 02 May 2024 08:17:05 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1714663025; cv=none; d=google.com; s=arc-20160816; b=UGFDN7l1uOMRkxx6uIo5cv7Yio7s4Jtg8zOUObRtDSnU0vrXSmXcuwHoIB+ty35ZNu YXrncCHSRdKBHvdRIpS80UqkHz3/o8sPuhf7tSObcBNsrbubh4hPyzRRc1OoJieYhhJE C/s4LS+f4doZed6O2TjGrS6qYenv9HmfAqAFtWEl9Y11q0PXSUlibOzvPzpDrbXm5wVM Ek5Su7jnE+nepMQTLkDuuyNchcYS+70TGe1VKkPhg6JYwnLvYl/M/fhqdltggkE16t/6 +qi5Iw7iFrn441fpHGoepytCVG7DBX8lckTtzwhFkN/h5OcVc58nFXsnBHG4P86yRAZr 9ADQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=in-reply-to:content-transfer-encoding:content-disposition :mime-version:references:mail-followup-to:message-id:subject:cc:to :from:date; bh=Igw+PhleXzgg9x97mVDSzBS6I+U9D3SHtA7/xoHZaCI=; fh=GEU1Jpbq8rDQjc/QdOD3jFf7r9H6tezXqux0rbj8SNM=; b=Din5NOIoi0UHUJoQVec+rJLdh9hMmgB1yit7ALBHN+nGexn5AtZMTkBd+PoSGIw1zi giVR82tceGRxrnOzU/AFWuErSjuyFrML5gcd04tYGXAPmg+7tv/Cd9EmmrMIt3IdhBOZ umKUmFaVjiv7TikD4asGp8DeDrCpncmd1w52E6ZByXJ3y4EECdGQedRdZ6ZQmZ1rAVyX dw9nfIWr0WsWDe575fhzmxZcJLebcjcoJdNJxd4rGkmYX4qmKMtjA4SnMAw3NjrQWMtg NMRlVvdNZb6U4UG3lrgfBQj6QHp/5+Tjgk+xGtkAMutanCqxB6ekU/7wsKw2ylIT/hFy PFHQ==; dara=google.com ARC-Authentication-Results: i=1; gmr-mx.google.com; spf=pass (google.com: domain of ibr@radix50.net designates 85.214.156.166 as permitted sender) smtp.mailfrom=ibr@radix50.net Return-Path: Received: from shymkent.ilbers.de (shymkent.ilbers.de. [85.214.156.166]) by gmr-mx.google.com with ESMTPS id f12-20020a0564021e8c00b005727dc54dfbsi31589edf.3.2024.05.02.08.17.05 for (version=TLS1_2 cipher=ECDHE-ECDSA-CHACHA20-POLY1305 bits=256/256); Thu, 02 May 2024 08:17:05 -0700 (PDT) Received-SPF: pass (google.com: domain of ibr@radix50.net designates 85.214.156.166 as permitted sender) client-ip=85.214.156.166; Authentication-Results: gmr-mx.google.com; spf=pass (google.com: domain of ibr@radix50.net designates 85.214.156.166 as permitted sender) smtp.mailfrom=ibr@radix50.net Received: from ilbers.de (host-80-81-17-52.static.customer.m-online.net [80.81.17.52]) (authenticated bits=0) by shymkent.ilbers.de (8.15.2/8.15.2/Debian-8+deb9u1) with ESMTPSA id 442FH3Ru004151 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 2 May 2024 17:17:04 +0200 Date: Thu, 2 May 2024 17:16:58 +0200 From: Baurzhan Ismagulov To: Isar users Cc: Quirin Gylstorff , "Kiszka, Jan" , "MOESSBAUER, Felix" Subject: Re: [PATCH v2] classes/rootfs: remove content of /dev, /run and vmlinux old Message-ID: Mail-Followup-To: Isar users , Quirin Gylstorff , "Kiszka, Jan" , "MOESSBAUER, Felix" References: <20240425071419.292013-1-Quirin.Gylstorff@siemens.com> <4d8b12fc7f61c76496aa4cbaaf84c461f9d44fed.camel@siemens.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-9 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <4d8b12fc7f61c76496aa4cbaaf84c461f9d44fed.camel@siemens.com> X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED autolearn=unavailable autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on shymkent.ilbers.de X-TUID: GelobZ9pAjLb On 2024-04-26 12:13, MOESSBAUER, Felix wrote: > On Fri, 2024-04-26 at 10:55 +0200, Baurzhan Ismagulov wrote: > > On 2024-04-25 09:13, 'Quirin Gylstorff' via isar-users wrote: > > > `/dev` and `/run` contain artifacts from the ISAR build clean them > > > up for reproducability. > > > > Suggest "Isar" and "reproducibility". > > > > > > > diff --git a/meta/classes/image.bbclass > > > b/meta/classes/image.bbclass > > > index 98741da0..4af0d448 100644 > > > --- a/meta/classes/image.bbclass > > > +++ b/meta/classes/image.bbclass > > > @@ -427,12 +427,17 @@ do_rootfs_finalize() { > > > ������������ rmdir --ignore-fail-on-non-empty ${ROOTFSDIR}/base-apt > > > � > > > �������� mountpoint -q '${ROOTFSDIR}/dev' && \ > > > -����������� umount -l ${ROOTFSDIR}/dev > > > +����������� umount -l -R ${ROOTFSDIR}/dev && \ > > > +����������� rm -rf ${ROOTFSDIR}/dev/* > > > + > > > �������� mountpoint -q '${ROOTFSDIR}/proc' && \ > > > ������������ umount -l ${ROOTFSDIR}/proc > > > �������� mountpoint -q '${ROOTFSDIR}/sys' && \ > > > ������������ umount -l ${ROOTFSDIR}/sys > > > � > > > +������� rm -rf ${ROOTFSDIR}/run/* > > > +������� rm -f ${ROOTFSDIR}/vmlinuz.old > > > + > > > > Could you provide the list of the specific files that you want to > > have removed? > > > > Debian normally has /dev populated even though devtmpfs is mounted > > later on top > > This is probably just an artifact of the bootstrapping, but not written > in any debian policy. As debian uses systemd (and we anyways only > support this init system), we should follow the "man file-hierarchy". > There a devtmpfs is always mounted on /dev. What's the point then to > still keep the dirs and files there? > > > of it. If the problem is that the entries have different timestamps > > on > > different builds, then the question is not limited to /dev but > > applies to any > > files created in postinstall scripts. I don't think the general > > approach should > > be to remove such files at the meta level. > > The timestamps are already clamped by the rootfs postprocessing, > however this is a leak of host resources into the rootfs. Which files > are under /dev depends on the devtmpfs implementation - which depends > on the host kernel. > > I propose to just clear these directories. Thanks Felix for the details, 1. Regarding /dev, I agree that it looks like an artifact of bootstrapping and installation. However, I don't see that the contents are copied from devtmpfs; could you please provide a sample command line and the list of files to confirm the host leak? After both debootstrap and d-i, I see the fixed list of console, fd, full, null, ptmx, pts, random, shm, stderr, stdin, stdout, tty, urandom, zero. I do think we can safely remove /dev/* for our use cases (although file-hierarchy(7) says devtmpfs is only *usually* mounted), but I'd like to document the reason for removal if we later find out that some software has different expectations. We see different tools expecting at least /dev/null, /proc, /dev/pts and /dev/shm and I also couldn't find any documentation on this. In the good case, they fail (sometimes with cryptic messages), but often they crash or hog the CPU (which is fun to debug from under e.g. CI + qemu). Some indirectly related examples and discussion: https://salsa.debian.org/installer-team/debootstrap/-/commit/a10e577675896b693c66ac77eace7ff76199da2c https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=571136 2. For /run, I'd still like to see the list of the files, because I'd expect Isar to leave it in a clean (= empty) state; maybe we have something that we should clean up elsewhere in Isar. 3. Regarding "vmlinux old", I assume it's about /vmlinuz.old (and I suggest to update the commit title for better understanding -- or we can do that when applying if it's ok for you) -- that should disappear by itself when we multistrap the final rootfs directly from multiple apt repos. I'm fine applying this part. With kind regards, Baurzhan