From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from aws-us-west-2-korg-lkml-1.web.codeaurora.org (localhost.localdomain [127.0.0.1]) by smtp.lore.kernel.org (Postfix) with ESMTP id 7AB59C282EC for ; Tue, 18 Mar 2025 03:17:10 +0000 (UTC) Subject: Issue: /var/tmp does not persist due to /var/volatile being tmpfs in fstab #scarthgap To: openembedded-core@lists.openembedded.org From: "Vish" X-Originating-Location: San Ramon, California, US (107.141.38.29) X-Originating-Platform: Linux Chrome 127 User-Agent: GROUPS.IO Web Poster MIME-Version: 1.0 Date: Mon, 17 Mar 2025 20:17:01 -0700 Message-ID: Content-Type: multipart/alternative; boundary="bXj3DJ3ZDz2T5NSB0ukd" List-Id: X-Webhook-Received: from li982-79.members.linode.com [45.33.32.79] by aws-us-west-2-korg-lkml-1.web.codeaurora.org with HTTPS for ; Tue, 18 Mar 2025 03:17:10 -0000 X-Groupsio-URL: https://lists.openembedded.org/g/openembedded-core/message/213134 --bXj3DJ3ZDz2T5NSB0ukd Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable The current Yocto basefiles fstab mounts /var/volatile as tmpfs, which resu= lts in the loss of all files stored in /var/tmp upon reboot. fstab in base-files: https://git.yoctoproject.org/poky/tree/meta/recipes-core/base-files/base-fi= les/fstab?h=3Dscarthgap&id=3D3cc8c3520cedb66500757f843f757646da69ab30#n7 Since /var/volatile is a tmpfs, its contents are lost on reboot. This commit might have introduced the issue - s ince /var/volatile/tmp is i= nside a tmpfs mount, it gets wiped on reboot, meaning /var/tmp is also clea= red. Commit - https://git.yoctoproject.org/poky/commit/meta/recipes-core/systemd= /systemd/00-create-volatile.conf?h=3Dscarthgap&id=3D3cc8c3520cedb66500757f8= 43f757646da69ab30 ( https://git.yoctoproject.org/poky/commit/meta/recipes-c= ore/systemd/systemd/00-create-volatile.conf?h=3Dscarthgap&id=3D3cc8c3520ced= b66500757f843f757646da69ab30 ) This commit links /var/tmp to /var/volatile/tmp *Expected Behavior* * /var/tmp should retain files across reboots, as per standard Linux behavi= or. * Using a symlink to a volatile tmpfs directory contradicts this expectatio= n. *Impact* * Any application expecting persistent temporary storage in /var/tmp will l= ose data after a reboot. * This behavior may break software relying on the standard /var/tmp persist= ence. Should /var/tmp continue following standard Linux behavior by *not being li= nked to /var/volatile/tmp* , or is this change intentional for specific use= cases? If persistence is desired, this approach seems problematic. Would appreciate input from the maintainers on whether this is a bug or int= ended behavior. --bXj3DJ3ZDz2T5NSB0ukd Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable
The cu= rrent Yocto basefiles fstab mounts /var/volatile as tmpfs, which results in= the loss of all files stored in /var/tmp upon reboot.
 
fstab = in base-files:

= Since /var/volatile is a tmpfs, its contents are lost on reboot.
 
This commit might have introduced the issue - since /var/volatile/tmp is inside a tmpfs mount, it gets wiped = on reboot, meaning /var/= tmp = is also cleared.
 
This commit links /var/tmp= to /var/volatile/tmp

 

Expected Behavior

  • /var/tmp should retain files across reboots, as per stand= ard Linux behavior.
  • Using a symlink to a volatile tmp= fs directory contradicts this expectation.

 

Impact

  • Any application expecting persist= ent temporary storage in /var/t= mp will lose data after a reboot.
  • This behavior may break software = relying on the standard /var/tm= p persistence.

 

Should /var/tmp continue following standard Linux behavior= by not being linked to /var/volatile/tmp, o= r is this change intentional for specific use cases? If persistence is desi= red, this approach seems problematic.

Would appreciate input from the ma= intainers on whether this is a bug or intended behavior. 

<= /p>

--bXj3DJ3ZDz2T5NSB0ukd--