Bump Linux kernel

[ChinYikMing]

Latest v6.1.y is v6.1.121 .

[visitorckw]

Linux v6.1 is an LTS kernel with weekly minor updates. How often should we update?

[ChinYikMing]

Linux v6.1 is an LTS kernel with weekly minor updates. How often should we update?

Updating to avoid make build-linux-image fails. Any suggestion?

[visitorckw]

Updating to avoid make build-linux-image fails. Any suggestion?

I don't have any ideas at the moment, but if we need frequent updates like weekly, maybe we could consider automating the process?

[ChinYikMing]

Updating to avoid make build-linux-image fails. Any suggestion?

I don't have any ideas at the moment, but if we need frequent updates like weekly, maybe we could consider automating the process?

Seems applicable. I found dependabot and wondered if it can help.

[jserv]

How about downloading from stable kernel mirror sites instead of running git clone?

[ChinYikMing]

How about downloading from stable kernel mirror sites instead of running git clone?

Since we use the SHA-1 value to verify the integrity of downloaded images, downloading from stable kernel mirror sites also presents the same issue which requiring the SHA-1 value to be updated after minor patches?

[jserv]

How about downloading from stable kernel mirror sites instead of running git clone?

Since we use the SHA-1 value to verify the integrity of downloaded images, downloading from stable kernel mirror sites also presents the same issue which requiring the SHA-1 value to be updated after minor patches?

We can follow the development of buildroot to get the stable v6.1 release files along with SHA-256. See https://github.com/buildroot/buildroot/blob/master/linux/linux.hash

[ChinYikMing]

How about downloading from stable kernel mirror sites instead of running git clone?

Since we use the SHA-1 value to verify the integrity of downloaded images, downloading from stable kernel mirror sites also presents the same issue which requiring the SHA-1 value to be updated after minor patches?

We can follow the development of buildroot to get the stable v6.1 release files along with SHA-256. See https://github.com/buildroot/buildroot/blob/master/linux/linux.hash

Here is a compressed 6.1.y Linux source in here(see the download label). Unfortunately, it lacks an associated SHA value, which would give us more confidence. Using this compressed 6.1.y instead of the mirror version would reduce the frequent Linux version bumps in mk/external.mk. However, is there a corresponding SHA value that I simply missed?

If the officially verified SHA value is unavailable, we will proceed with storing it alongside the SHA value of the compressed 6.1.y. If the SHA value is available, we may skip storing it ourselves. In any case, the plan will be as follows:

1. Create a cron job in rv32emu-prebuilt that runs weekly to download and check the SHA value of the compressed 6.1.y. If the SHA differs from the previous one, indicating a new version, rebuild the Linux image and store it in the release along with the locally calculated SHA value of the compressed 6.1.y. This way, rv32emu would always run the latest Linux image. In addition, when the build linux image script is executed, it downloads the compressed 6.1.y file and its SHA value (stored in rv32emu-prebuilt), then calculates the SHA value locally to verify data integrity.
2. The mk/external.mk would only need to update the MAJOR or MINOR version, which changes less frequently compared to patches. This would eliminate the need for frequent version bumps.

[vacantron]

Unfortunately, it lacks an associated SHA value, which would give us more confidence.

Could we use the *.tar.sign files with sha1sum command to generate the identification, such as cat linux-6.1.121.tar.sign | sha1sum ?