berkeley-cs162 / vagrant Goto Github PK

I met this git issue that said

ERROR: Repository not found.
fatal: Could not read from remote repository.

Please make sure you have the correct access rights
and the repository exists.

when trying to access my private cs162 git repo within the vagrant box and I have set up a id_rsa key on the host machine. But the problem is I how two id_rsa in my .ssh dir for my two different github account. But it seems like the vagrant box didn't forward the right one. Is there a way to update the vagrant file so that we can forward a specific id_rsa key to use?

I have had various issues (described later) with provisioning VMs using the existing Puppet method. If you have confidence in the Docker image,¹ as it seems you do, there is a different approach you can take which I find very elegant:

• You maintain a Dockerfile, as opposed to a Puppet configuration
  • This can be an incremental change: slowly remove dependencies from Puppet and bring them into Docker. For the sake of the general strategy, it doesn't matter whether you internally use Puppet; it only matters from an optimization and readability standpoint. The minimal change uses the existing Docker image. See #18 for optimization.²
• You as CS 162 build images with this Dockerfile
  • You can create different tags for different use cases. For example, if you don't need rustup (the autograder almost surely doesn't), you can shave about 1.2 GB off the image!
  • Your Docker build will be much faster than any student's Puppet provisioning, because yours will be cached and parallelized. It also only has to happen ~once.
• Students simply install docker/podman on their x86 machine, and pull and run the image.
  • Docker commit is now possible, in case ever necessary
    • For the most part, there is no state on the virtual machine besides git config, so you're not adding any duplicated work by using containers. Docker commit can be done by the student (or script) after setting up git, and then this new image should contain all necessary state for the remainder of the class session.
    • Of course, you can also use volumes or bind mounts as well
  • Non-x86-users can emulate at the Docker level (not recommended), or they can still run in a VM. But in this case, the VM is not a critical dependency, can be swapped with others, and is very fast and easy to provision.
  • Users not running in a VM will experience much better performance
  • The only issue I forsee in the entire end-to-end process is certain students (those on instructional machines) not having root access to run the daemon. I have no single solution for this use case,³ but most people will not have this issue because Docker on Mac is supposed to support most x86 images, and also direct use of QEMU is possible. It looks like the use of instructional machines is already discouraged, so this is probably not making the problem worse.

I spent over a week in compute just provisioning the VM, and had various issues at various stages on various machines.⁴ This effort would no longer be necessary.

Solution: merge main into cloud-setup

Currently build times are ~30 minutes using puppet. We can optimize this by utilizing docker staged builds which cache results of building programs. A new repo for this project should be created.

Hi,

I used the vagrant to build the virtual machine, when I try command pintos run, the system threw an error like pintos can not be found. I also try to update the PATH variable， but the $HOME/.bin does not exist. Could anyone give me some help? Thank you.

The current Docker image is huge—even with recent optimizations (#13, #16), it is around 3.9 GB!

Part of why is just that it has so many packages. But part of why is that it is oriented around the existing Puppet provisioner, which isn't amenable to the types of optimizations that container images are.

For example, it is a lot easier in a Dockerfile to initiate an install of some software, and then copy over only the relevant portions (leaving behind caches and even parts of the program which will never be used). You can download each dependency in a parallel stage, and selectively copy it over to the final image, dramatically improving performance of builds and rebuilds. Better, you can copy the software directly from prebuilt official images; the software providers have done the hard work of isolating the necessary components, and the software is already built.

Intentionally optimizing for containerized loads might be worthwhile. This is best done together with #17; see that issue for the general strategy, as well as other suggestions such as slim versions.¹

From a student:

When I tried running 'pintos run alarm-multiple' I got an error stating squish-pty couldn't be executed (cannot execute binary file: Exec format error). To fix this, I went into /home/vagrant/.bin and ran 'gcc squish-pty.c -o squish-pty'. I did this because the error message suggested that squish-pty had been compiled for a 64-bit arch. After this, 'pintos run alarm-multiple' worked fine and ran all the tests.

I just wanted to let the staff know about this in case the provisioner should be modified to build squish-pty from source during provisioning.

I tried downloading this repo and running vagrant up. I get the following output.

The following SSH command responded with a non-zero exit status.
Vagrant assumes that this means the command failed!

/sbin/ifdown 'enp0s8' || true
/sbin/ip addr flush dev 'enp0s8'
# Remove any previous network modifications from the interfaces file
sed -e '/^#VAGRANT-BEGIN/,$ d' /etc/network/interfaces > /tmp/vagrant-network-interfaces.pre
sed -ne '/^#VAGRANT-END/,$ p' /etc/network/interfaces | tac | sed -e '/^#VAGRANT-END/,$ d' | tac > /tmp/vagrant-network-interfaces.post

cat \
  /tmp/vagrant-network-interfaces.pre \
  /tmp/vagrant-network-entry \
  /tmp/vagrant-network-interfaces.post \
  > /etc/network/interfaces

rm -f /tmp/vagrant-network-interfaces.pre
rm -f /tmp/vagrant-network-entry
rm -f /tmp/vagrant-network-interfaces.post

/sbin/ifup 'enp0s8'

Stdout from the command:



Stderr from the command:

bash: line 5: /sbin/ifdown: No such file or directory
bash: line 21: /sbin/ifup: No such file or directory

To Fix:
After running vagrant up run
vagrant ssh
sudo apt-get install ifupdown
Reload the VM.

I do not know if we can install this beforehand to avoid this issue.