Without superuser privileges
It is as simple as reading the following file:
$ cat /sys/class/dmi/id/bios_version
With superuser privileges
$ sudo dmidecode -s bios-version
Also, you might have to install this package, which is available in:
Linux i386, x86-64, ia64
FreeBSD i386, amd64
NetBSD i386, amd64
OpenBSD i386, amd64
To create a bootable USB, you can follow the steps below:
Go to the website of the OS you wish to install, and find an iso image to download. In your case, since you want to run a Debian OS, here is a link to its iso options: https://www.debian.org/distrib/netinst
Choose an iso image from the options, and click on it. This should automatically ...
I found the answer from this thread (http://ubuntuforums.org/showthread.php?t=2114055) over at ubuntuforums.org.
It seems with newer Gigabyte mainboards (at least) there is a BIOS option called IOMMU Controller that is disabled by default and gives no clue or indication as to what it is for.
Enabling this setting and rebooting "magically" restores all my ...
I'm curious as to exactly why you'd want to run such a command if you think it might damage your computer...
/dev/nvram provides access to the non-volatile memory in the real-time clock on PCs and Ataris. On PCs this is usually known as CMOS memory and stores the BIOS configuration options; you can see the information stored there by looking at /proc/driver/...
That is not a Linux problem, but a BIOS problem, which affects only quite old systems (the first limit was about 504MiB; logical CHS addressing allowed for up to about 8GiB). The BIOS must be capable of using LBA (INT 13h Extensions, defined 1998 with virtually unlimited address space (64 bit)) for Linux to boot from behind 8GiB. There are several versions ...
You can try using biosdecode.
It is a command line utility to parses the BIOS memory and prints information about all structures (or entry points) it knows of. It finds out information about hardware such as:
Type of memory and speed
Electrical Current Probe
Processor and Memory Information
It probably could but it depends on your BIOS. See this related problem with EFI configuration where a laptop was bricked by clearing EFI variables. If some BIOS can't handle cleared variables, it's likely that some might not handle random garbage in nvram any better.
At the very least, before you try this, see if there's a nvram reset procedure for your ...
There are several virtual machine emulators that can emulate an x86 processor and peripherals. Each comes with a BIOS, several of them with an open-source BIOS. You should look at QEMU, which operates completely independently of the host (it can run on any machine, though it has mechanisms to run faster if the emulated machine is the same architecture as the ...
I think what you're looking for is flashrom. Provided that your system is supported, you can read your BIOS content by issuing
# flashrom -r <outputfile>
If you only want to save the so called CMOS RAM (those extra-bytes you save configuration to, like alarm on RTC et al) the kernel's nvram driver and device might help you:
It sounds like you enabled the "fast boot" option in your BIOS setup which disables the F2 setup and F12 boot menu prompts.
Power-off your laptop and hold down the F2 key, then power it on for the BIOS setup utility. Disable "fast boot", save and reboot.
Flashing with FreeDOS, one reboot and no removable devices
Ensure you are using GRUB2 (check if you have the package grub-pc installed on Ubuntu)
Get hold of SYSLINUX's MEMDISK. On Ubuntu, install the package syslinux-common and your memdisk will reside in /usr/lib/syslinux/memdisk
Download fdboot.img, save it in your home directory, or some other directory ...
This isn’t something the firmware tracks, as far as I’m aware. Even BMCs don’t measure total uptime.
This won’t help with past uptime from previous boots, but you can start recording uptimes now, by installing a tool such as uptimed and setting it up so that it never discards values (set LOG_MAXIMUM_ENTRIES to 0 in uptimed.conf). That will measure operating ...
If other tools are not available or cannot be used, here is a way to make an educated guess as to what region of memory to dump.
For instance, from within a VirtualBox VM, I successfully dumped its BIOS by doing:
$ grep ROM /proc/iomem # https://www.kernel.org/doc/Documentation/ABI/testing/sysfs-firmware-memmap
000c0000-000c7fff : Video ROM
It would probably be fixable either because the firmware will notice it fails checksum and reset it (on the next boot), or alternatively by pulling the CMOS battery and/or using a CMOS clear jumper. Of course, buggy firmware may decide otherwise.
I personally would not recommend trying it. Just as I'd not recommend you test a GFI outlet by sticking a fork ...
You can use lshw , hwinfo , inxi and hardinfo (DMI):
# lshw -class memory
# hwinfo --bios
$ inxi -M
The above command should work after installing them through your package manager.
Only the first answer proposed by @cuonglm allow you the get bios information without installing an additional package:
$ cat /sys/class/dmi/id/bios*
Follow these steps:
Start up Windows just like you normally would, and download the latest (non-test) version of Plop Boot Manager here.
Extract the zip and open the folder "Windows" in it.
If you have Windows XP, double-click the file InstallToBootMenu.bat.
If you have Windows Vista, Windows 7 or Windows 8, right-click the file InstallToBootMenu.bat, ...
1. Load hardware module
Firstly, in order to actually 'feed' the watchdog, you need to have the watchdog hardware module loaded. This may not happen automatically as most watchdog drivers are blacklisted in case there is no watchdog daemon (e.g. in /etc/modprobe.d/blacklist-watchdog.conf on an Ubuntu/Debian system). Check to see if /dev/watchdog (or similar)...
After using ghex to examine my "BOOTX64.EFI" file in the efi partition I found this line.
search.fs_uuid a43d1f11-6ebe-477d-8be3-321a33bc37f9 root hd2,gpt4
This shows that the information for the location of grub (the boot partition) has been embedded by grub2-install into the BOOTX64.EFI file generated for the system.
grub itself does not care about boot flags.
An EFI System partition is distinguished by its GUID type C12A7328-F81F-11D2-BA4B-00A0C93EC93B, not by a boot flag. Yes, this partition needs to be formatted FAT32. Not all FAT32 partitions are EFI System partitions, only one of them, and that one, if present, is small and has a special purpose. On a computer which ...
As it happens, it looks like a bug in debian's package of grub.
The -kernel grub.img approach works if I only include the grub modules I need upon grub-mkimage.
The -bios grub.bin works with the newer grub package from experimental (2.00-7). However, the grub.bin that comes with it is not very useful.
It comes with a memdisk that comes with the grub.cfg. ...
cat /proc/cpuinfo and see if there is vmx (Intel) or svm for AMD based.
or Try dmidecode it should provide a lot of information about your BIOS settings.
From thier website:
dmidecode is packaged for several Linux and BSD distributions (Debian, Gentoo, openSUSE and FreeBSD among others), either as a single package or included in a more generic ...
I just learned, with my GA-990FXA-UD7, that for both the USB 2.0 and USB 3.0 controllers and the onboard Ethernet controller to function properly in Linux (I'm using Mint 17.1) it required the following settings in the BIOS:
xHCI handoff - Enabled
EHCI handoff - Enabled
IOMMU controller - Enabled
Don't forget to disable UEFI and change all boot options to "...
GRUB can't pass over the CD drive; this is something setup in BIOS. Either your Windows installation media isn't bootable for some reason or the laptop BIOS is set to try booting from the hard drive before the CD drive.
When your laptop is first turned on a message will appear, something like "Press XXX to enter Setup", where XXX is some key sequence. Use ...
If the images are too large for a floppy, the same Arch Linux wiki has the instructions.
If your flash image is too large for a floppy, go to the FreeDos bootdisk website, and download the 10Mb hard-disk image. This image is a full disk image, including partitions, so adding your flash utility will be a little trickier:
# modprobe loop
# losetup /dev/loop0 ...
Please see: http://wiki.osdev.org/RSDP
The first step in retrieving the ACPI tables is finding the Root System Description Pointer, or RSDP.
On UEFI systems, it is conveniently given within the EFI_SYSTEM_TABLE.
On traditional BIOS systems, two memory areas need to be searched. First, in 16-bit real mode address 0x40E there will be a 2-byte segment ...
Sounds like a feature of kexec. If you don't like it, try coldreboot (from kexec-tools) or set LOAD_KEXEC=false in /etc/default/kexec (as mentioned here).
You could proably also just remove the packagekexec-tools
Oddly enough, even though I have an almost identical setup (same motherboard, FX8350 processor), enabling the IOMMU didn't make any difference for me. Still no USB, networking, etc.
What did help, though, was adding "iommu=soft" to the kernel command line. Now it all works fine (except that, for some strange reason, my Logitech Zone Touch Mouse doesn't work)...