Forged on Jan 01 1970

Bluefin
1

My fastfetch output reckons that I’ve been running bluefin for 55 years. :smiling_face_with_sunglasses: At least, it has since the update to 42. It happened on both machines I’m running bluefin on.

I’ve seen this mentioned a couple of times in various threads over the past month or two, and remember seeing someone say that it’s related to the switch to composefs; is this true? Did it happen to everyone?

Also, is there any way of getting the real date back short of reinstalling? touch / fails obviously.

Is there any reason why it would be related to my custom build?

2

:person_facepalming: don’t mind me, I have an old version of the fastfetch.jsonc in my dotfiles that I had been using as an override. The current version uses a different command to fetch the “Forged on” date, which does seem related to the composefs update since the filesystem root looks like this since fedora 42
dr-xr-xr-x. 12 root root 4.0K Jan 1 1970

3 Likes
3

Oh nice. Thanks for pointing that out. I saw someone else testing the beta images describing forged on epoch.

I see this:

$ ls -ld /
dr-xr-xr-x. 12 root root 4096 Dec 31  1969 /

So apparently this root was built when I was 8 years old. Good trick …

4

:thinking: it’s interesting that it’s different. I thought that Jan 01 1970 was the earliest possible date for a UNIX epoch or something like that

5

Negative values, on systems that support them, indicate times before the Unix epoch, with the value decreasing by 1 for every non-leap second before the epoch. For example, 00:00:00 UTC on 1 January 1969 is represented in Unix time as −31536000.

I ran void linux with f2fs for a couple of years and the filesystem root there also showed 01 Jan 1970; some filesystems don’t support all of the information that a tool like stat can show, and maybe this is what’s going on with composefs. You would expect that modification time would be supported. If I remember correctly though, f2fs doesn’t support a parameter called btime, while ext4 does.

This is all speculation though; I haven’t really looked into what composefs actually is.

6

It is just something goofy that composefs is doing with a stat request for ‘/’. Someone mentioned earlier that there was a bug around this.

stat(1) is a UNIX tool that is a front end for the stat(2) system call. On UNIX systems it is the filesystem driver that is responsible for fulfilling those requests.

The problem has to be with whatever the fs driver (erofs?) for composefs is doing for the stat(2) request for /. There is an issue filed for this (regarding size) - composefs#420.

If I do ls -ld /sysroot - suggested by the discussion in the issue above - I see the correct date.

Bluefin creates an alias for fastfetch to point to a shell script at /usr/libexec/ublue-fastfetch.

That script points to a config file at /usr/share/ublue-os/fastfetch.jsonc. That file has this command registered for the Forged on date:

{
  "type": "command",
  "key": "<U+F0520>",
  "text": "date -d$(ls -alct /var/log --time-style=full-iso|tail -1|awk '{print $6}') +'Forged on %b %d %G'",
  "shell": "/bin/bash"
},

I also noticed that everything served from composefs seems to have the same date near the epoch.

E.g., ls -l /usr or ls -l /usr/bin.

nautilus on bluefin displays no date for those dirs / files. So apparently it has been taught to ignore those dates, as also suggested in the aforementioned issue.

So there you go. Mystery solved.