Virtualbox: cannot start or recover saved machine - virtualbox

I'm running Virtualbox 5.1.14 r112924 on a Windows 7 Professional machine. I have installed a Debian Testing guest. Several days ago I tried to save the machine, unfortunately I do not recall the exact circumstances, but I think it had to do with the guest having no network any more after the host came back from suspend-to-RAM.
Anyway, I now have a saved machine with which I cannot do anything: I cannot start it, I cannot delete the saved state, I cannnot clone it and I cannot even delete the entire machine. All these options are greyed out in the VB Manager window. Also, I don't get any errors, so I'm rather clueless what to do.
I include below parts of the most recent log file which I thought are relevant, I didn't want to paste the whole thing.
What sort of witchcraft can bring my machine back to life?
Many thanks, and best regards,
Enno
02:37:32.316550 Changing the VM state from 'RUNNING' to 'SUSPENDING'
02:37:32.319680 AIOMgr: Endpoint for file 'D:\Users\EnnoMiddelberg\VirtualBox VMs\Debian_Testing\Debian_Testing.vdi' (flags 000c0781) created successfully
02:38:32.373466 PDMR3Suspend: 60 056 883 803 ns run time
02:38:32.373494 Changing the VM state from 'SUSPENDING' to 'SUSPENDED'
02:38:32.373520 Console: Machine state changed to 'Paused'
02:38:32.373700 VMR3Suspend:
02:38:32.393131 RUNNING -> SUSPENDING, RUNNING_LS -> SUSPENDING_EXT_LS failed, because the VM state is actually SUSPENDED
02:38:32.393177 VMSetError: F:\tinderbox\win-5.1\src\VBox\VMM\VMMR3\VM.cpp(3619) int __cdecl vmR3TrySetState(struct VM *,const char *,unsigned int,...); rc=VERR_VM_INVALID_VM_STATE
02:38:32.452926 VMSetError: VMR3Suspend failed because the current VM state, SUSPENDED, was not found in the state transition table (old state RUNNING_LS)
02:38:32.501235 ERROR [COM]: aRC=VBOX_E_VM_ERROR (0x80bb0003) aIID={872da645-4a9b-1727-bee2-5585105b9eed} aComponent={ConsoleWrap} aText={Could not suspend the machine execution (VERR_VM_INVALID_VM_STATE)}, preserve=false aResultDetail=0
02:38:32.605107 Console: Machine state changed to 'Saving'
02:38:32.635604 Changing the VM state from 'SUSPENDED' to 'SAVING'
02:38:32.747945 VUSB: Detached 'HidMouse' from port 1
02:38:40.213749 SSM: Footer at 0x23d179e4 (600930788), 34 directory entries.
02:38:40.213777 VUSB: Attached 'HidMouse' to port 1
02:38:40.231560 SSM: Successfully saved the VM state to 'D:\Users\EnnoMiddelberg\VirtualBox VMs\Debian_Testing\Snapshots\2017-05-23T14-48-18-411341300Z.sav'
02:38:40.231578 Changing the VM state from 'SAVING' to 'SUSPENDED'
02:38:40.316839 Console::powerDown(): A request to power off the VM has been issued (mMachineState=Saving, InUninit=0)
02:38:40.342613 Display::handleDisplayResize: uScreenId=0 pvVRAM=000000000c0a0000 w=1920 h=1106 bpp=32 cbLine=0x1E00 flags=0x1
02:38:40.342664 GUI: UIFrameBufferPrivate::NotifyChange: Screen=0, Origin=0x0, Size=1920x1106, Sending to async-handler
02:38:40.350656 Changing the VM state from 'SUSPENDED' to 'POWERING_OFF'
02:38:40.356473 ****************** Guest state at power off for VCpu 0 ******************
...
...
...
02:38:40.406031 ************** End of Guest state at power off ***************
02:38:41.753488 PDMR3PowerOff: Driver 'AUDIO'/0 on LUN#0 of device 'ichac97'/0 took 1 344 979 632 ns to power off
02:38:41.753791 PDMR3PowerOff: 1 347 726 353 ns run time
02:38:41.762544 Changing the VM state from 'POWERING_OFF' to 'OFF'
02:38:41.983956 Changing the VM state from 'OFF' to 'DESTROYING'
02:38:41.984097 ************************* Statistics *************************
...
...
...
02:38:41.990221 ********************* End of statistics **********************
02:38:41.997747 VUSB: Detached 'HidMouse' from port 1
02:38:42.377555 NAT: Zone(nm:mbuf_cluster, used:90)
02:38:42.378711 NAT: Zone(nm:mbuf_packet, used:90)
02:38:42.378737 NAT: Zone(nm:mbuf, used:90)
02:38:42.378763 NAT: Zone(nm:mbuf_jumbo_pagesize, used:0)
02:38:42.379768 NAT: Zone(nm:mbuf_jumbo_9k, used:0)
02:38:42.380260 NAT: Zone(nm:mbuf_jumbo_16k, used:0)
02:38:42.380639 NAT: Zone(nm:mbuf_ext_refcnt, used:0)
02:39:42.706185 GIM: KVM: Resetting MSRs
02:39:42.720224 Changing the VM state from 'DESTROYING' to 'TERMINATED'
02:39:42.723143 Console: Machine state changed to 'Saved'
02:39:42.723504 GUI: Request to close Runtime UI because VM is powered off already.
02:39:42.888614 GUI: Passing request to close Runtime UI from machine-logic to UI session.

Ok, so I got the machine back up by removing the *.sav file in the guest's "Snapshots" subdirectory. It had to sort out its file system when booting, but everything is running as it should now.
Thanks for listening, anyway...

Related

Process replayd killed by jetsam reason highwater

Recently I add a broadcast upload extension to my host app to implement system wide screen cast.I found the broadcast upload extension sometimes stopped for unknown reason.If I debug the broadcast upload extension process in Xcode, it stopped without stopping at a breakpoint(If the extension is killed for 50M bytes memory limit, it will stopped at a breakpoint, and Xcode will point out that it's killed for 50M bytes memory limit).For more imformation, I read the console log line by line.Finally, I found a significant line:
osanalyticshelper Process replayd [26715] killed by jetsam reason highwater
It looks like the ReplayKit serving process 'replayd' is killed by jetsam, and the reason is 'highwater'.So I searched the internet for more imformation.And I found a post:
https://www.jianshu.com/p/30f24bb91222
After reading that,I checked the JetsamEvent report in device, and found that when the 'replayd' process was killed it occupied 100M bytes memory.Is there a 100M bytes memory limit for 'replayd' process?How can I avoid it to occupy more than 100M bytes memory?
Further more, I found that this problem offen occured if the previous extension process is stopped via RPBroadcastSampleHandler's finishBroadcastWithError method.If I stop the extension via control center button, this rarely occured.
As comparison, when the 'Wemeet' app stop it's broadcast upload extension, it raraly cause this problem.I compared the console log when 'Wemeet' stop it's broadcast extension and the log my app stop it's broadcast extension.I found this line is different:
Wemeet:
mediaserverd MEDeviceStreamClient.cpp:429 AQME Default-InputOutput: client stopping: <ZenAQIONodeClient#0x1080f7a40, sid:0x3456e, replayd(30213), 'prim'>; running count now 0
My app:
mediaserverd MEDeviceStreamClient.cpp:429 AQME Default-InputOutput: client stopping: <ZenAQIONodeClient#0x107e869a0, sid:0x3464b, replayd(30232), 'prim'>; running count now 3
As we can see, the 'running count' is different.

STM32cubeide with stm32f103c8t6 could not verify ST device

I am new to embedded and stm32cubeide, self teaching so I can use it in a group project related to university studies.
After purchasing a "blue pill" from aliexpress, I realized I might of bought a clone chip. I followed the instructions shown here (stm32 community site), and I'm still getting an error that the ide cannot verify my ST device.
Here is what I have as output:
Open On-Chip Debugger 0.11.0+dev-00443-gcf12591 (2022-02-09-13:33) [ST Internal]
Licensed under GNU GPL v2
For bug reports, read
http://openocd.org/doc/doxygen/bugs.html
swv
Info : Listening on port 6666 for tcl connections
Info : Listening on port 4444 for telnet connections
Info : STLINK V2J39S7 (API v2) VID:PID 0483:3748
Info : Target voltage: 3.286227
Info : clock speed 4000 kHz
Info : stlink_dap_op_connect(connect)
Info : SWD DPIDR 0x2ba01477
Info : STM32F103C8Tx.cpu: Cortex-M3 r2p1 processor detected
Info : STM32F103C8Tx.cpu: target has 6 breakpoints, 4 watchpoints
Info : starting gdb server for STM32F103C8Tx.cpu on 3333
Info : Listening on port 3333 for gdb connections
Info : accepting 'gdb' connection on tcp/3333
Info : device id = 0x20036410
Info : flash size = 128kbytes
Warn : GDB connection 1 on target STM32F103C8Tx.cpu not halted
undefined debug reason 8 - target needs reset
O.K.
O.K.:0xE00FFFD0
Info : dropped 'gdb' connection
shutdown command invoked
I see in the console "undefined debug reason 8 - target needs reset", is this the problem? If so what can I do to solve this? If not, then what do I do other than purchasing another board?
Below is my test Debug.cfg, in case I need to change something in there:
# This is an genericBoard board with a single STM32F103C8Tx chip
#
# Generated by STM32CubeIDE
# Take care that such file, as generated, may be overridden without any early notice. Please have a look to debug launch configuration setup(s)
source [find interface/stlink-dap.cfg]
set WORKAREASIZE 0x5000
transport select "dapdirect_swd"
set CHIPNAME STM32F103C8Tx
set BOARDNAME genericBoard
# Enable debug when in low power modes
set ENABLE_LOW_POWER 1
# Stop Watchdog counters when halt
set STOP_WATCHDOG 1
# STlink Debug clock frequency
set CLOCK_FREQ 4000
# Reset configuration
# use software system reset if reset done
reset_config none
set CONNECT_UNDER_RESET 0
set CORE_RESET 0
# ACCESS PORT NUMBER
set AP_NUM 0
# GDB PORT
set GDB_PORT 3333
# BCTM CPU variables
source [find target/stm32f1x.cfg]
# SWV trace
set USE_SWO 0
set swv_cmd "-protocol uart -output :3344 -traceclk 16000000"
source [find board/swv.tcl]
Thanks
I found some FT232 that I had in spare, and I was able to program the chip using the stm32 programmer software and a generated hex file from the ide.
I'll use this method if ever I run into cloned chips and the st link v2 if ever I get a genuine board.

GCP CloudSql Connection limit from Dataflow Job/compute engine

I have a dataflow job that is connecting to cloudsql and persisting some data.
On average I have about 75 active connections (a few spikes to just over 100 connections once in a while). I was therefore wondering if there is a maximum number of connections. The documentation doesn't seem to indicate. (https://cloud.google.com/sql/docs/mysql/connect-admin-ip)
Backstory and for some context: I am getting an error with one of my jobs, it seems to just lock randomly and stops persisting data:
Operation ongoing in step X for at least 305h20m00s without outputting or completing in state start
at sun.misc.Unsafe.park (Native Method)
at java.util.concurrent.locks.LockSupport.park (LockSupport.java:175)
at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await (AbstractQueuedSynchronizer.java:2039)
at org.apache.commons.pool2.impl.LinkedBlockingDeque.takeFirst (LinkedBlockingDeque.java:590)
at org.apache.commons.pool2.impl.GenericObjectPool.borrowObject (GenericObjectPool.java:425)
at org.apache.commons.pool2.impl.GenericObjectPool.borrowObject (GenericObjectPool.java:346)
at org.apache.commons.dbcp2.PoolingDataSource.getConnection (PoolingDataSource.java:134)
at org.apache.commons.dbcp2.BasicDataSource.getConnection (BasicDataSource.java:809)
at org.apache.commons.dbcp2.DataSourceConnectionFactory.createConnection (DataSourceConnectionFactory.java:83)
at org.apache.commons.dbcp2.PoolableConnectionFactory.makeObject (PoolableConnectionFactory.java:355)
at org.apache.commons.pool2.impl.GenericObjectPool.create (GenericObjectPool.java:874)
at org.apache.commons.pool2.impl.GenericObjectPool.borrowObject (GenericObjectPool.java:417)
at org.apache.commons.pool2.impl.GenericObjectPool.borrowObject (GenericObjectPool.java:346)
at org.apache.commons.dbcp2.PoolingDataSource.getConnection (PoolingDataSource.java:134)
at x.io.jobs.common.mysql.function.MySqlReadAllFn.setup (MySqlReadAllFn.java:57)
at x.io.jobs.tracer.function.ReadAggTraceStatusByIdFn$DoFnInvoker.invokeSetup (Unknown Source)
at org.apache.beam.runners.dataflow.worker.DoFnInstanceManagers$ConcurrentQueueInstanceManager.deserializeCopy (DoFnInstanceManagers.java:83)
at org.apache.beam.runners.dataflow.worker.DoFnInstanceManagers$ConcurrentQueueInstanceManager.get (DoFnInstanceManagers.java:75)
at org.apache.beam.runners.dataflow.worker.SimpleParDoFn.reallyStartBundle (SimpleParDoFn.java:296)
at org.apache.beam.runners.dataflow.worker.SimpleParDoFn.processElement (SimpleParDoFn.java:326)
at org.apache.beam.runners.dataflow.worker.util.common.worker.ParDoOperation.process (ParDoOperation.java:44)
at org.apache.beam.runners.dataflow.worker.util.common.worker.OutputReceiver.process (OutputReceiver.java:49)
at org.apache.beam.runners.dataflow.worker.GroupAlsoByWindowsParDoFn$1.output (GroupAlsoByWindowsParDoFn.java:185)
at org.apache.beam.runners.dataflow.worker.GroupAlsoByWindowFnRunner$1.outputWindowedValue (GroupAlsoByWindowFnRunner.java:108)
at org.apache.beam.runners.dataflow.worker.repackaged.org.apache.beam.runners.core.ReduceFnRunner.lambda$onTrigger$1 (ReduceFnRunner.java:1060)
Thanks.
There is a connection limit for Cloud SQL, which can be changed by setting the max_connections flag on an instance. There's more info on setting and viewing the value of database flags on an instance here: https://cloud.google.com/sql/docs/mysql/flags

Ember CLI build killed

I build my Ember CLI app inside a docker container on startup. The build fails without an error message, it just says killed:
root#fstaging:/frontend/source# node_modules/ember-cli/bin/ember build -prod
version: 1.13.15
Could not find watchman, falling back to NodeWatcher for file system events.
Visit http://www.ember-cli.com/user-guide/#watchman for more info.
Buildingember-auto-register-helpers is not required for Ember 2.0.0 and later please remove from your `package.json`.
Building.DEPRECATION: The `bind-attr` helper ('app/templates/components/file-selector.hbs' # L1:C7) is deprecated in favor of HTMLBars-style bound attributes.
at isBindAttrModifier (/app/source/bower_components/ember/ember-template-compiler.js:11751:34)
Killed
The same docker image successfully starts up in another environment, but without hardware constraints. Does Ember CLI have hard-coded hardware constraints for the build process? The RAM is limited to 128m and swap to 2g.
That is likely not enough memory for Ember CLI to do what it needs. You are correct in that, the process is being killed because of an OOM situation. If you log in to the host and take a look at the dmesg output you will probably see something like:
V8 WorkerThread invoked oom-killer: gfp_mask=0xd0, order=0, oom_score_adj=0
V8 WorkerThread cpuset=867781e35d8a0a231ef60a272ae5d418796c45e92b5aa0233df317ce659b0032 mems_allowed=0
CPU: 0 PID: 2027 Comm: V8 WorkerThread Tainted: G O 4.1.13-boot2docker #1
Hardware name: innotek GmbH VirtualBox/VirtualBox, BIOS VirtualBox 12/01/2006
0000000000000000 00000000000000d0 ffffffff8154e053 ffff880039381000
ffffffff8154d3f7 ffff8800395db528 ffff8800392b4528 ffff88003e214580
ffff8800392b4000 ffff88003e217080 ffffffff81087faf ffff88003e217080
Call Trace:
[<ffffffff8154e053>] ? dump_stack+0x40/0x50
[<ffffffff8154d3f7>] ? dump_header.isra.10+0x8c/0x1f4
[<ffffffff81087faf>] ? finish_task_switch+0x4c/0xda
[<ffffffff810f46b1>] ? oom_kill_process+0x99/0x31c
[<ffffffff811340e6>] ? task_in_mem_cgroup+0x5d/0x6a
[<ffffffff81132ac5>] ? mem_cgroup_iter+0x1c/0x1b2
[<ffffffff81134984>] ? mem_cgroup_oom_synchronize+0x441/0x45a
[<ffffffff8113402f>] ? mem_cgroup_is_descendant+0x1d/0x1d
[<ffffffff810f4d77>] ? pagefault_out_of_memory+0x17/0x91
[<ffffffff815565d8>] ? page_fault+0x28/0x30
Task in /docker/867781e35d8a0a231ef60a272ae5d418796c45e92b5aa0233df317ce659b0032 killed as a result of limit of /docker/867781e35d8a0a231ef60a272ae5d418796c45e92b5aa0233df317ce659b0032
memory: usage 131072kB, limit 131072kB, failcnt 2284203
memory+swap: usage 262032kB, limit 262144kB, failcnt 970540
kmem: usage 0kB, limit 9007199254740988kB, failcnt 0
Memory cgroup stats for /docker/867781e35d8a0a231ef60a272ae5d418796c45e92b5aa0233df317ce659b0032: cache:340KB rss:130732KB rss_huge:10240KB mapped_file:8KB writeback:0KB swap:130960KB inactive_anon:72912KB active_anon:57880KB inactive_file:112KB active_file:40KB unevictable:0KB
[ pid ] uid tgid total_vm rss nr_ptes nr_pmds swapents oom_score_adj name
[ 1993] 0 1993 380 1 6 3 17 0 sh
[ 2025] 0 2025 203490 32546 221 140 32713 0 npm
Memory cgroup out of memory: Kill process 2025 (npm) score 1001 or sacrifice child
Killed process 2025 (npm) total-vm:813960kB, anon-rss:130184kB, file-rss:0kB
It might be worthwhile to profile the container using something like https://github.com/google/cadvisor to find out what kind of memory maximums it may need.

HP ProLiant 100 G5/G6/G7 Servers Series - Showing Uncorrectable ECC Events Occurred in SEL Log

HP Insight Diagnostics Version 8.4.0.3521A (x86_64)
Computer Name: ezsetupsystem3c4a927c9e88
During Device test it gives following error
Total Memory-ECC test Failed
Description- Uncorrectable ECC Events occurred in SEL log Device, Ran on CPU 0
Recommended Repair- Please refer IPMI Sensor Event Log for ECC events
Error Code- 021278
Please help me n finding why is this error coming.
Is it because of WAMP server installation??
This means that the server has a DIMM which has exceeded it's acceptable ECC error count. It's location is denoted in the error. Depending on the platform, you can identify the specific slot. Which HP ProLiant model is this? This is standard warranty repair.
You have faulty memory. To identify the faulty memory run HPS Reports:
http://update.external.hp.com/HPS/HPSreports/
Once completed you have to unzip the archive an open the index.html file insite.
It will collect all hardware information and highlight in
RED
the faulty components.