OKay, I was able to fix the grub-probe issue by detaching the faulted drive and thus also stopping the resilvering.
Grub-install is noz working and I'm running it on all disks 1 by 1. Hope I can boot soon now!!
@avw It appears that I have grub indeed.
I managed to mount ZFS on Ubuntu Live USB and can run a few commands there.
A few things I am noticing:
1) is that the partition table on all drives is identical, except for the replacement drive. It lacked a partition at the beginning, but otherwise...
After some more research, I believe I understand what I did wrong, but still unsure about how to fix.
Is it possible that after doing a “zfs replace” you’re supposed to update grub as well? I did not update grub after the new disk was inserted, so maybe that’s what’s going on?
how to best...
If I boot from a Ubuntu 20.04 USB drive (which has also ZFS support), I can see the disks.
So, if I could just repair or re-install grub from this Ubuntu, that would help.
What's the command for this?
I have Proxmox 6.2 with 6x 6TB disks in a RAID-Z2 configuration.
Since a few days ago disk 3 failed and the rpool was degraded.
I replaced the faulty disk with another identical one, but after a few hours I got the message that this disk was also faulty.
The resilvering process did continue...
This helps yes. The random dir is a great idea.
What I'm trying to do is create a script that migrates VMs from an old Proxmox to a new Proxmox. They aren't in a cluster and I have mounted a dir from the new Proxmox on the old one, so I can dump straight to the new machine instead of dumping...
I can do "ls" but what if the dir contains multiple files from different backups at different times?
Finding the right file is a pain:
- Use a regex for this? Tricky...
- Use the latest created file? Dangerous...
So maybe using --stdout > file.ext is the best solution?
I would need to hard...
With vzdump 100 --dumpdir --mode stop I can dump a single VM to a dir, but how can I know the resulting filename of that dump?
The man page does not tell anything about the output of vzdump
This is to be used in a bash script, so it should be non-interactive.
I already know about the backup...
The restore of the VM worked on another Proxmox, so looks indeed like a hardware issue.
I have ordered a new server (same type) and will restart everything...
Fingers crossed.
At the datacenter they did a full hardware scan. Turns out a fan was faulty and they replaced it. However... still same problem.
This time the server froze at 20% during the restore.
This time I also had KVM connected. At the time of freezing, the video signal just went dead.
The datacenter...
Yeah, you're right. Proxmox is stable. At least in my past experience. Should not have said so, sorry. I'm just really frustrated at this simple install, yet breaking big time. Wasted a whole day on this and no positive outlook :(
Maybe the latest version, ZFS or the hardware might be unstable...
Well, this is a brand new server. Fresh install, no VMs on it. Not doing anything.
Have been using Proxmox for many years, but never ran into this.
I could not find anything in /var/log/syslog Just a big hole where the freeze/reboot was.
What can I check?
I just installed the latest version of Proxmox (version 6.2-4), using ZFS RAID1.
Installed a few tools for ZFS, like auto-snapshot en ZFS-ZED,
setup a zfs-auto-snapshot schedule in /etc/cron.d/zfs-auto-snapshot
and enabled Let's Encrypt,
nothing else (so you see I did very very little to the...
I noticed that the `Discard` (sometimes called `Trim`) option is turned off by default.
This is needed to keep backups smaller as disk space can be reclaimed on SSD disks.
I'd like to understand:
- Why is the Discard option disabled by default?
- Can't Proxmox auto-detect if the underlying...
@oguz and @adamb turns out the disk image is damaged.
I ran a ZFS scrub and it found that 1 file was damages: the VM's disk image:
zpool status -v rpool
pool: rpool
state: ONLINE
status: One or more devices has experienced an error resulting in data
corruption. Applications may be...
@oguz this started happening for no reason. It's a server that we don't touch. Both the hypervisor or the VM were unchanged for months.
Running fsck without dry-run on the mounted filesystem does not work. It refuses to do so.
Only thing I can think of is that maybe the disk repair from the...
Hi @oguz ,
I have done a few things, but no success.
When i run fsck on the VM in dry-run mode, it reports a few problems:
fsck -fn /dev/mapper/roompot--vg-root
fsck from util-linux 2.31.1
e2fsck 1.44.1 (24-Mar-2018)
Warning! /dev/mapper/roompot--vg-root is mounted.
Warning: skipping journal...
This site uses cookies to help personalise content, tailor your experience and to keep you logged in if you register.
By continuing to use this site, you are consenting to our use of cookies.