2

I noticed one of my google cloud computers stopped connecting to ssh, and when I looked at the serial log, it seems like its not booting up at all. I use the machine for rendering, so I thought maybe the disk filled up, but when I took a snapshot of the disk the file was only 15GB and the disk itself is supposed to be 40 GB. Does anyone know how I can get this disk to boot again?

Here's my serial log:

[2J[01;01H[=3h[2J[01;01H[2J[01;01H[=3h[2J[01;01H[2J[01;01H[=3h[2J[01;01H[0m[35m[40m[2J[01;01H[=3h[2J[01;01H[0m[37m[40m[2J[01;01H[=3h[2J[01;01H[0m[35m[40m[0m[37m[40mBdsDxe: loading Boot0001 "UEFI Google PersistentDisk " from PciRoot(0x0)/Pci(0x3,0x0)/Scsi(0x1,0x0)
BdsDxe: starting Boot0001 "UEFI Google PersistentDisk " from PciRoot(0x0)/Pci(0x3,0x0)/Scsi(0x1,0x0)

UEFI: Attempting to start image.
Description: UEFI Google PersistentDisk 
FilePath: PciRoot(0x0)/Pci(0x3,0x0)/Scsi(0x1,0x0)
OptionNumber: 1.

[0m[30m[40m[2J[01;01H[0m[37m[40merror: syntax error.

error: Incorrect command.

error: syntax error.

error: syntax error.

error: Incorrect command.

error: syntax error.

Loading Linux 5.0.0-1034-gcp ...

Loading initial ramdisk ...

error: syntax error.

error: Incorrect command.

error: syntax error.

error: syntax error.

error: Incorrect command.

error: syntax error.
5
  • 1
    Welcome to Server Fault. Were you able to boot the machine before posting? – LeRouteur Sep 24 '20 at 6:17
  • 1
    Snapshots are compressed while creating so the fact it's just 15GB's doesn't mean that the disk isn't full. Easiest way to rule out lack of space is increasing disk size (add 1GB and try booting). – Wojtek_B Sep 24 '20 at 9:14
  • Thanks for the responses. The instance was working for a great a few weeks and then stopped all of a sudden. I also tried increasing the drive from 40GB to 45GB, but still wouldn't boot – Steven Baltay Sep 24 '20 at 21:49
  • Is the serial console output the same after you increased the disk ? If so then make a snapshot of the disk, create a new VM and add the snapshot as an additional disk, try to repair any corrupted files (or partitions) and then create another VM and try to boot it from this disk. – Wojtek_B Sep 29 '20 at 11:48
  • Have you solved your issue? – Serhii Rohoza Dec 23 '20 at 16:43
0

Looks like your partition or file system got damaged. You need to address this but since your VM won't boot you need to use another one for this task.

First create a snapshot of the faulty'S VM persisten disk. Next create a disk from your snapshot (lets call it disk2 in this example). After that create a new VM with default settings with the exception that you want to attach disk2 to new VM.

Now you can try to repair any damage on disk2 but you have to use some troubleshooting skills and tools. First try to check if the partitions on the disk2 ore OK - you can use for example [fsck][3] tool. You may find this discussion helpful too - how to repir partition in Linux.

When you find (and hopefully repair) any errors on the disk2 you can try to create another VM and use this disk as a system one and try if it boots. Or you can try attach it to your original VM (but it's not the safest way, unless you know it will boot).

2
  • Thanks, I followed everything carefully, but it has the same problem. The new instance starts, cant connect via SSH, and the serial console reads: UEFI: Attempting to start image. Description: UEFI Google PersistentDisk FilePath: PciRoot(0x0)/Pci(0x3,0x0)/Scsi(0x1,0x0) OptionNumber: 1. [0m[30m[40m[2J[01;01H[0m[37m[40merror: syntax error. error: Incorrect command. error: syntax error. Loading Linux 5.0.0-1034-gcp Loading initial ramdisk error: syntax error. error: Incorrect command. – Steven Baltay Oct 4 '20 at 1:50
  • 1
    Please try the troubleshooting methods fro GCP and let me know if this helped in any way. – Wojtek_B Oct 5 '20 at 9:13
0

I agree with @Wojtek_B

However I’m going to summarize a possible workaround in order to solve this kind of issue. Since we agree that it looks like your partition or file system got damaged, you could try the following steps:

  1. Create a snapshot of the corrupted disk.
  2. Create a disk from the snapshot already created.
  3. Create a new VM, with the default options.
  4. When the new VM is already created, attach the new disk as a secondary one.
  5. Connect via SSH to your new VM and mount the new disk in a directory without formatting it.

mount /dev/sdXX /mnt

  1. After attaching the disk, you would have two useful disks; use chroot to change root directory into your broken system.

chroot /mnt

  1. Now all commands are executed as if you were in the broken system so you can try to repair any damage on your damaged disk. This link could help you.

Another workaround could be also to install OS Login and update the guest environment. You have further information about this topic here.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.