riscv64: Mount tmpfs to support unit-tests expecting /tmp

[TimePrinciple]

Summary of the PR

• As 9p rootfs documented [1], mount a tmpfs onto /tmp to avoid E: Unable to determine file size for fd 7 - fstat (2: No such file or directory).

Modify /etc/fstab to apply the mount operation during boot.

[1] https://wiki.qemu.org/Documentation/9p_root_fs#Let's_start_the_Installation

• Previous implementation uses netcat to test existence of
  pre-configured target port, but that port is occupied in advance of
  sshd inside VM is ready.

Replace netcat with ssh with ConnectTimeout set to directly verify
the connectivity of sshd.

Requirements

Before submitting your PR, please make sure you addressed the following
requirements:

• All commits in this PR have Signed-Off-By trailers (with
  git commit -s), and the commit message has max 60 characters for the
  summary and max 75 characters for each description line.
• All added/changed functionality has a corresponding unit/integration
  test.
• All added/changed public-facing functionality has entries in the "Upcoming
  Release" section of CHANGELOG.md (if no such section exists, please create one).
• Any newly added unsafe code is properly documented.

[TimePrinciple]

😵‍💫 Finally worked, going to flesh out this skeleton after dinner

[TimePrinciple]

This version (virtio-blk as rootfs):

9p as rootfs version:

[stefano-garzarella]

Please check the order of the patch. IMHO the first patch should be applied only when we have the new way to build the rootfs, otherwise we can break the bisectabiliy.
So you can move that patch after riscv64: Update container build workflow, or just merge with it.

[roypat]

Mh, shouldn't /tmp be an in-memory file system? Why does switching the storage driver from 9p to virtio-blk affect it at all? :o

[TimePrinciple]

Mh, shouldn't /tmp be an in-memory file system? Why does switching the storage driver from 9p to virtio-blk affect it at all? :o

I'm not sure about the cause of this issue :(

I normally develop and test in an normally booted vm, i.e., the virtio-blk as rootfs way, I never fail any case relates to /tmp.

I tried to address that issue with in 9p, originally I thought it was the sticky bit set which prevents them from passing, but I tried to turn that bit off, unfortunately those cases still fail 😵‍💫

[roypat]

Mh, shouldn't /tmp be an in-memory file system? Why does switching the storage driver from 9p to virtio-blk affect it at all? :o

I'm not sure about the cause of this issue :(

I normally develop and test in an normally booted vm, i.e., the virtio-blk as rootfs way, I never fail any case relates to /tmp.

I tried to address that issue with in 9p, originally I thought it was the sticky bit set which prevents them from passing, but I tried to turn that bit off, unfortunately those cases still fail 😵‍💫

I found some random documentation about using a 9p rootfs with qemu (https://wiki.qemu.org/Documentation/9p_root_fs#Let's_start_the_Installation). It seems similar to enough to what we're doing. Maybe this section also applies to us:

Important: now we need to mount a tmpfs on /tmp (inside the chroot environment that we are in now).

mount -t tmpfs -o noatime,size=500M tmpfs /tmp

If you omit the previous step, you will most likely get error messages like the following with the subsequent apt commands below:

E: Unable to determine file size for fd 7 - fstat (2: No such file or directory)

Could you try explicitly mounting a tmpfs inside the qemu guest?

[TimePrinciple]

Mh, shouldn't /tmp be an in-memory file system? Why does switching the storage driver from 9p to virtio-blk affect it at all? :o

I'm not sure about the cause of this issue :(
I normally develop and test in an normally booted vm, i.e., the virtio-blk as rootfs way, I never fail any case relates to /tmp.
I tried to address that issue with in 9p, originally I thought it was the sticky bit set which prevents them from passing, but I tried to turn that bit off, unfortunately those cases still fail 😵‍💫

I found some random documentation about using a 9p rootfs with qemu (https://wiki.qemu.org/Documentation/9p_root_fs#Let's_start_the_Installation). It seems similar to enough to what we're doing. Maybe this section also applies to us:

Important: now we need to mount a tmpfs on /tmp (inside the chroot environment that we are in now).
mount -t tmpfs -o noatime,size=500M tmpfs /tmp
If you omit the previous step, you will most likely get error messages like the following with the subsequent apt commands below:
E: Unable to determine file size for fd 7 - fstat (2: No such file or directory)

Could you try explicitly mounting a tmpfs inside the qemu guest?

Yes, I'll try it now

[TimePrinciple]

Mh, shouldn't /tmp be an in-memory file system? Why does switching the storage driver from 9p to virtio-blk affect it at all? :o

I'm not sure about the cause of this issue :(
I normally develop and test in an normally booted vm, i.e., the virtio-blk as rootfs way, I never fail any case relates to /tmp.
I tried to address that issue with in 9p, originally I thought it was the sticky bit set which prevents them from passing, but I tried to turn that bit off, unfortunately those cases still fail 😵‍💫

I found some random documentation about using a 9p rootfs with qemu (https://wiki.qemu.org/Documentation/9p_root_fs#Let's_start_the_Installation). It seems similar to enough to what we're doing. Maybe this section also applies to us:

Important: now we need to mount a tmpfs on /tmp (inside the chroot environment that we are in now).
mount -t tmpfs -o noatime,size=500M tmpfs /tmp
If you omit the previous step, you will most likely get error messages like the following with the subsequent apt commands below:
E: Unable to determine file size for fd 7 - fstat (2: No such file or directory)

Could you try explicitly mounting a tmpfs inside the qemu guest?

It worked 🎉, by mounting the tmpfs inside QEMU VM.

I just recollected I have tried something similar, I was mounting tmpfs from the outside, i.e. the container which prevents me from mounting 😵‍💫

I will repurpose this PR. Thanks to @roypat @stefano-garzarella :)