# pve-diy: one shell script that rewires a Proxmox VE host for passthrough and dashboard readings

> pve-diy is a shell script collection for Proxmox VE 7.x through 9.x that swaps the apt mirrors, silences the subscription nag, and patches the web interface so CPU temperature, CPU frequency and NVMe disk temperature appear on the node summary. It is a convenience wrapper around edits you could make by hand, and it carries real risk to the host it runs on.

**xiangfeidexiaohuo/pve-diy** — Proxmox VE 7.x~9.x 换源、关掉订阅提示、直通、配置CPU模式一键脚本。

- Repository: https://github.com/xiangfeidexiaohuo/pve-diy
- Stars: 929 · Forks: 191
- Language: Shell
- License: not declared
- Published: 2026-10-20 · Updated: 2026-10-20 · Language: en
- Canonical page: https://hysenlabs.com/projects/xiangfeidexiaohuo-pve-diy

## The script edits a Proxmox host in place, and it says so twice

This is a collection of shell scripts for Proxmox VE, the KVM management platform, aimed at the Chinese-language community of users who want three specific things on a home lab: an apt mirror that works from their network, an interface without the subscription prompt, and hardware readings on the node summary page that stock Proxmox does not show.

The scope is stated in the description, which covers PVE 7.x through 9.x, mirror switching, removing the subscription notice, device passthrough and CPU mode configuration as a one click script. The improvements listed over the original script are specific: dynamic detection of NVMe disks, AMD CPU temperature support including the integrated graphics, and CPU frequency and temperature rendering that lays out four cores per line so a sixteen core chip produces four rows rather than one unreadable block. There is also a function to remove old kernels, flagged in the documentation as a dangerous operation.

The provenance is stated too. The original script comes from shidahuilang/pve, and this repository is a fork of it with parts of the code optimised and support for PVE 9 added.

The risk warning is not subtle. The documentation says modifying PVE carries risk, asks you to back up important data, and says any risk is yours to bear. That is the right framing for a tool that rewrites apt sources, patches the Perl API modules and edits the JavaScript that renders the web interface.

## Running the installer: curl first, then a one-liner

The installation is one command, and the prerequisite is that the host has curl, wget, sudo and bash available. The documentation warns that on a system without curl the one click script cannot run, and gives the command that installs the missing pieces first.

```sh
apt-get update -y && apt-get install curl wget sudo bash -y
```

With that in place the script itself is fetched and piped straight into bash.

```sh
bash -c "$(curl -fsSL https://raw.githubusercontent.com/xiangfeidexiaohuo/pve-diy/master/pve.sh)"
```

The mechanics of that line are worth noticing, because they define how you should think about the tool. The file is fetched over HTTPS from the repository's master branch and executed immediately in a subshell. There is no checksum, no signature check, no prompt before anything is written, and no package to inspect first. Whatever the current master branch contains runs as root against the host.

The documentation does offer a middle path for one specific case. If the CPU has many cores, or you want a particular Proxmox storage line to be visible and the panel is too short, the instruction is to download the script to your local machine, edit line 69 to a suitable number such as 80 or 100, and then run it from there. That is the only documented way to change a parameter, and it is worth using whenever the layout comes out wrong.

## Upgrading from PVE 8 to PVE 9 in five documented commands

A separate section of the documentation covers the move from PVE 8 to PVE 9, and it is worth reading because it shows how much of this repository is really about mirror management. The release name changes from bookworm to trixie, so the source list has to be rewritten before anything else.

The first step is the ordinary upgrade, which the documentation assumes you have already switched mirrors, otherwise it says to run the one click script first.

```sh
apt update
apt dist-upgrade
```

Then the upgrade check that Proxmox provides for this transition.

```sh
pve8to9
```

The documentation adds a blunt instruction about that check: if it reports many errors, give up and reinstall from an image instead. That is an unusual thing to see written down, and it tells you the author has seen the upgrade path fail in ways that are not recoverable by continuing.

The source list is then rewritten from bookworm to trixie, in the main file and in the drop-in directory.

```sh
sed -i 's/bookworm/trixie/g' /etc/apt/sources.list
sed -i 's/bookworm/trixie/g' /etc/apt/sources.list.d/*.list
```

After that the same update and dist-upgrade pair runs again, and the host is rebooted. The documentation notes that if a dialog appears during the upgrade and you do not understand it, press Enter to accept the default. The final instruction is to run the one click script again once the reboot is done, so that the temperature and frequency work matches the new version.

## The 7.x manual instructions show exactly what the script automates

The repository keeps the older PVE 7.x walkthroughs and marks them as deprecated, but says they still have reference value. Reading them is the clearest way to see what the one click script does on your behalf, because every step is spelled out.

The mirror swap for 7.x starts by removing the enterprise repository file and then writing a placeholder for the enterprise source that is commented out.

```sh
rm -rf /etc/apt/sources.list.d/pve-install-repo.list
echo "#deb https://enterprise.proxmox.com/debian/pve Bullseye pve-enterprise" > /etc/apt/sources.list.d/pve-enterprise.list
```

The no-subscription repository and the Ceph repository are then pointed at a Chinese mirror, the Proxmox download host is rewritten inside the Perl Ceph module, and the Debian mirror and security host are redirected in the sources list.

```sh
echo "deb https://mirrors.ustc.edu.cn/proxmox/debian/pve bullseye pve-no-subscription" > /etc/apt/sources.list.d/pve-no-subscription.list
echo "deb https://mirrors.ustc.edu.cn/proxmox/debian/ceph-pacific bullseye main" > /etc/apt/sources.list.d/ceph.list
sed -i.bak "s#http://download.proxmox.com/debian#https://mirrors.ustc.edu.cn/proxmox/debian#g" /usr/share/perl5/PVE/CLI/pveceph.pm
```

The last line is the one that gives the old manual method its reputation. It edits a Perl module that belongs to Proxmox, not to you, and does so with a backup copy left in place by the .bak suffix. The same trick is applied to the Debian mirror entries in the sources list.

The manual path also documents the requirement the script cannot satisfy for you, that the host must be able to reach the network for a mirror change to work at all.

## Removing the subscription nag means editing shipped JavaScript

The subscription prompt is not a setting, so there is nothing to toggle. The documented approach is to open a file that Proxmox ships, find the code that checks the subscription status, and delete the block that produces the message.

The file is /usr/share/javascript/proxmox-widget-toolkit/proxmoxlib.js, and the documentation suggests opening it over WinSCP and editing it locally, with a backup recommended. The search target is `data.status.toLowerCase`, and the screenshots in the repository show the block before and after removal.

There is a version caveat that matters for anyone applying this by hand. The documentation says that if you update to PVE 7.1-5 or later and find the edit has no effect, a second occurrence of the same `data.status.toLowerCase` expression needs the same treatment. In other words, the check exists in more than one place in that file, and finding one of them is not the same as finishing the job.

The verification step is the refresh in the Proxmox interface followed by a check on the update page, where the prompt should no longer appear.

A detail on the general approach: every file this project touches is a file the vendor shipped. Editing them means the next Proxmox upgrade can overwrite the change, and a partial upgrade can leave a Perl module patched while the JavaScript beside it is not.

## Sensor readings arrive by patching Nodes.pm and pvemanagerlib.js

The dashboard readings are the most interesting part, because they need data from the hardware to travel through the API layer and then through the JavaScript that renders the node summary. The tutorial does it in two hops.

First the sensors are installed and probed.

```sh
apt-get install lm-sensors
```

The documentation then asks you to run `sensors-detect` and accept the defaults, and to run `sensors` to see the output. The output is annotated in the screenshots: the temp1 entry is the motherboard temperature, while Package id 0 and core0 through core5 are the CPU package and per core values, with one entry per core present.

The API side is a one line addition to /usr/share/perl5/PVE/API2/Nodes.pm, inserted under the line that sets the Proxmox version.

```sh
$res->{thermalstate} = `sensors`;
```

The front end side is a new item definition added to /usr/share/pve-manager/js/pvemanagerlib.js, which reads a field named thermalstate and renders a string with the CPU and motherboard temperatures. A longer variant of the same renderer is documented for people who want every core and every board sensor listed, with the author noting that past four cores the listing becomes ugly and per core output is not recommended.

The CPU frequency display follows the same pattern, adding a second field to the same two files.

```sh
$res->{cpusensors} = `lscpu | grep MHz`;
```

The matching JavaScript item parses the CPU MHz, CPU min MHz and CPU max MHz values out of that output and shows current, minimum and maximum frequency. The NVMe disk temperature is a third variant of the same idea, matching a Composite value in the sensors output for the M.2 drive and appending it to the same string.

After every one of these edits the documentation asks for the same command, and the panel picks the change up on reload.

```sh
systemctl restart pveproxy
```

## No rollback, no releases, no licence, and a warning in the docs

The failure modes are not hypothetical here, because the script modifies a running hypervisor host.

There is no rollback procedure documented. The instructions for the sensor display tell you to back up files before editing them by hand, but the one click script path does not describe how to revert the changes it has already made to /etc/apt sources, to the Perl modules, to the JavaScript, or to the kernel arguments it writes for the bootloader. If the script leaves the host in a state you cannot boot into, the manual 7.x instructions are the only reference available, and they describe forward edits rather than reversal.

There is also no release history. The repository has no GitHub releases, so the script is tracked only by commits, and the last push was on 2026-08-30. The repository is not archived.

The licensing position is unclear, and it is worth a note. The licence field for the repository records nothing that GitHub can classify, and no licence terms appear in the documentation. The upstream original from shidahuilang/pve has its own position, which this fork inherits or does not. If you plan to run this on anything you care about, or to redistribute the changes it makes, ask the author rather than infer terms.

The device passthrough part deserves the same scrutiny as the mirror part. Passthrough configuration means binding a physical device to a guest, and the documentation gives it one line in the feature summary without the detail it gives to temperatures. Treat that as a boundary of the documentation rather than an omission you can fill in by inference.

Finally, the tool is designed for a single host that you administer yourself. There is no configuration management, no inventory of what it changed on each node, and no way to ask it what state a host is in.

## The fork of shidahuilang/pve and the manual route are the two real alternatives

Two alternatives are worth naming, and the first is already inside the repository.

The upstream original, shidahuilang/pve, is where the script came from. The documentation describes this repository as an optimisation of it with PVE 9 support added, along with the NVMe detection and the AMD integrated graphics temperature handling. If you want the version that matches what most people have already run, the upstream is the reference, and the differences between them are the features listed at the top of this documentation. Running the upstream instead means running an older script against a newer Proxmox release, which is exactly the gap this fork claims to close.

The other alternative is doing it yourself, and the repository hands you the manual instructions for 7.x even while marking them deprecated. That is a genuine option with a real difference in approach: every edit is visible, reversible and yours, at the cost of doing the work on each node and keeping up with the vendor files changing between releases. The script version is one command and consistency across nodes; the manual version is no surprises and no third party code executing as root.

There is a third path the documentation itself points at for immutable systems, though it is outside the scope of this repository: on Bazzite, Bluefin and Aurora the `ujust` tooling performs a similar job. For a Proxmox host running a conventional Debian-based installation, that is not an option.

The real trade is between convenience and inspectability. The script gives you the edits in one command and a uniform result across a cluster; the manual route gives you an audit trail of what you changed and a way back.

## Conclusion

pve-diy suits a home lab operator on Proxmox VE 7.x, 8.x or 9.x who wants a mirror swap, a quiet dashboard and temperature readings without hand-editing Perl and JavaScript shipped by the vendor. It does not suit a production cluster, since the script patches vendor files in place, the repository documents no rollback, and the licence field records nothing you can rely on. Before running it, take the backup the author asks for, and if you want the same result without a third party script, work through the manual 7.x instructions in the repository and apply them to your own version.

## FAQ

### How do I run the pve-diy script on my Proxmox VE host?

First make sure curl, wget, sudo and bash are present with `apt-get update -y && apt-get install curl wget sudo bash -y`, then run `bash -c "$(curl -fsSL https://raw.githubusercontent.com/xiangfeidexiaohuo/pve-diy/master/pve.sh)"`. The script is fetched from the master branch and executed immediately, so downloading it locally first lets you edit it before running.

### Does pve-diy support Proxmox VE 9?

Yes. The description covers PVE 7.x through 9.x, and the documentation includes a section on upgrading from PVE 8 to PVE 9, which involves rewriting the apt source list from bookworm to trixie and running `pve8to9` first.

### How does pve-diy add CPU and disk temperature to the Proxmox dashboard?

It patches /usr/share/perl5/PVE/API2/Nodes.pm so the node API returns the output of `sensors` and `lscpu | grep MHz`, then adds a matching renderer to /usr/share/pve-manager/js/pvemanagerlib.js that parses those values and prints them on the node summary.

### Can I undo the changes the pve-diy script makes?

The documentation does not describe a rollback for the one click script. It does describe the manual edits behind it, and it recommends backing up files such as proxmoxlib.js and pvemanagerlib.js before editing them by hand.

### Where did the pve-diy script come from?

The original script comes from shidahuilang/pve, and this repository is described as an optimisation of it with parts of the code improved and support for PVE 9 added, including dynamic NVMe detection and AMD CPU temperature support.

## Sources

- [Issues](https://github.com/xiangfeidexiaohuo/pve-diy/issues)
- [README](https://github.com/xiangfeidexiaohuo/pve-diy/blob/master/README.md)
- [xiangfeidexiaohuo/pve-diy on GitHub](https://github.com/xiangfeidexiaohuo/pve-diy)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/xiangfeidexiaohuo-pve-diy