That your image grows tells me that you forgot to recompress again. There should be instructions how to do this.

rolfie

Load from Debian:

Paket openjdk-8-jre
stretch (oldstable) (java): OpenJDK-Java-Laufzeitumgebung, verwendet Hotspot JIT

and install with dpkg -i package.

rolfie

Followup on bad EFI memory:

Got two boards at home that suffer from strange EFI behaviour. Digged a bit in the internet and came across some threads that talk about that the Linux kernel tries to save some data in EFI variables when the computer crashes. I am pretty sure that happened to my hardware.

Is there any safe way to clear the EFI variables? ASUS denied it and told me to return the board.

Is there a way to prove my theory? To force ASUS to fix the lockup because that should not happen?

These rants also talk about that noefi as kernel parameter would stop the kernel to access the EFI variables. But that would mean the computer has to boot in BIOS mode. Am I right?

rolfie

Got the hint from here: https://sourceforge.net/p/veracrypt/dis … 04d12bba8/

There is some change between ASCII and Beowulf. This way it works.

rolfie

Well, found this hint in the net on https://wiki.archlinux.de/title/GNOME#Tipps_und_Tricks

Add export NO_AT_BRIDGE=1 to /etc/environment.

The dbind-warning error when calling up the script directly as shown in the previous post is gone.

Does not bring the complete solution. Still getting asked for user or root passwd.

rolfie

No, currently I am directly downloading the latest stuff from virtualbox.org and then using dpkg -i. I have been through all the methods from using the repo stuff, the following the sources.list setup as suggested by the VBox docs, then I found that I can ease my life. No enabling/disabling in sources.list, no key to care for .... Works for me.

Thanks, rolfie

Well, I had all pre-requisites present like kernel headers, build-essential, dkms. Installation of VBox went smooth without any errors.

Instructions I am talking about: Repeated vboxsetup, modprobe vboxdrv, rcvboxdrv setup: all run smooth, no errors, each of them fixes the issue temporarily. Just after any reboot everything seems to be forgotten.

Digged deeper into logs like the vbox logs, syslog and boot: nothing that caught my eye. The entry in /etc/init.d/vboxdrv is present, all permissions set correctly (afaik) ...

Then tried to add to /etc/modules: the entry vboxdrv was a game changer, the error when starting my Win7 VM changed. I saw that I needed to enter also vboxnetadp and vboxnetflt, and now it works.

Can't remember that I had to do this before, e.g. under Squeeze, Wheezy, or ASCII. Anyhow, I think I have got a solution now. Thanks for picking my brain, your hint to the /etc/modules finally did the job.

rolfie

PS: I used keywords like "virtualbox kernel module" and "kernel 5.6 virtualbox" and others and tags from the error messages and read through a bunch of pages without getting a clue, just an impression that kernel 5.5 works, while 5.6 seems to create issues.

Got Beowulf on kernel 5.6 running fine on two desktop machines. You must have individual hickups, hardware problems or a device that having issues.

rolfie

Ok, Lars thinks your CPU does support 64bit, and the 64bit Life media also runs. Lets take that as granted.

Then lets look at the media used for installation.

CD: You got old mature HW including an older CD/DVD drive (at least I assume this). When you use oldfashioned CD or DVD drives to burn and read the media, the chance is high that it should work if the media quality is ok. From my experience: burning a CD on a BR drive and reading it in another PC with a BR drive may not work. Tried this with a gparted life CD: starting gparted is a gamble. I got lots of IO errors, sometimes gparted starts ok, sometimes not. The CD itself is fine, it booted perfectly with no IO errors in an older DVD burner. Same happened with Beowulf alpha and beta versions burned to CD, and installations typically fail when IO errors appear.

Memory stick: On my modern hardware I now only use flash drives for installation. I also used rufus on Win7 to generate the bootable sticks. Done that for ASCII, Arch, Beowulf in various steps, and gparted life, all worked fine. 
Note: there are people around that insist in that only the dd copy is the correct way to generate a bootable flash drive. Never used this.

One thing that might cause an installation to fail is if the flash drive itself is dodgy. If you can exchange it and try a different brand. I use a Windows utility called h2testw to check the flash drives. Don't know if this is available in English too. 

Another hint what might help: look on the other consoles if you see any errors showing up there.

Good luck, rolfie

Perhaps because your CPU does not support x86_64 mode? You get: Architecture: i686, I think thats the i386 branch.

I am getting for a real 64 bit CPU:

# lscpu
Architecture:        x86_64
CPU op-mode(s):      32-bit, 64-bit
Byte Order:          Little Endian
Address sizes:       43 bits physical, 48 bits virtual
CPU(s):              16
On-line CPU(s) list: 0-15
Thread(s) per core:  2
Core(s) per socket:  8
Socket(s):           1
NUMA node(s):        1
Vendor ID:           AuthenticAMD
CPU family:          23
Model:               8
Model name:          AMD Ryzen 7 2700X Eight-Core Processor
Stepping:            2
CPU MHz:             2194.882
CPU max MHz:         3700,0000
CPU min MHz:         2200,0000
BogoMIPS:            7385.23
Virtualization:      AMD-V
L1d cache:           32K
L1i cache:           64K
L2 cache:            512K
L3 cache:            8192K
NUMA node0 CPU(s):   0-15
Flags:               fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt pdpe1gb rdtscp lm constant_tsc rep_good nopl nonstop_tsc cpuid extd_apicid aperfmperf pni pclmulqdq monitor ssse3 fma cx16 sse4_1 sse4_2 movbe popcnt aes xsave avx f16c rdrand lahf_lm cmp_legacy svm extapic cr8_legacy abm sse4a misalignsse 3dnowprefetch osvw skinit wdt tce topoext perfctr_core perfctr_nb bpext perfctr_llc mwaitx cpb hw_pstate sme ssbd sev ibpb vmmcall fsgsbase bmi1 avx2 smep bmi2 rdseed adx smap clflushopt sha_ni xsaveopt xsavec xgetbv1 xsaves clzero irperf xsaveerptr arat npt lbrv svm_lock nrip_save tsc_scale vmcb_clean flushbyasid decodeassists pausefilter pfthreshold avic v_vmsave_vmload vgif overflow_recov succor smca

Have you ever had a 64 bit distro working?

rolfie

There is a 5.6 kernel in the backports already. I am running this on two machines, and a 5.5 on my file server.

rolfie