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 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.
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:
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 ...
This issue is faced by many users using dual boot win10/linux. GRUB seems to have some incompatibility with windows 10 fast boot process. Win 10 default shutdown does not actually shut down the whole system instead it saves computer's system files to a hibernation file which helps win 10 to boot faster the next time you power on your system. More info about ...
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.
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 ...
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 ...
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, ...
You should see a longer help text for this config option. It offers two reasons.
int "Amount of low memory, in kilobytes, to reserve for the BIOS"
range 4 640
Specify the amount of low memory to reserve for the BIOS.
The first page contains BIOS data structures that the kernel
must not use, so that page must ...
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) ...
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 "...
Depending on exactly what the warnings said, and what exact choices you made when installing Ubuntu, the installation process may have done one of a few things:
It may have converted the partitioning from MBR to GPT style to install UEFI-style, keeping (or resizing) the existing partitions. This is the best option: you'll just need to install a UEFI-style ...
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 ...
Something caused a memory corruption, which was propagated to the root filesystem (to its journal, to be precise). So XFS shutdown itself down. To correct the issue, boot from a live CentOS disk and execute xfs_repair.
After that, you had to determine what caused the memory corruption. I see two main possibilities (other than bad luck):
a RAM module ...
I was wandering in /sys folder then I went into /sys/firmware/dmi/tables then got two files DMI and smbios_entry_point. If you read DMI file then in my case first word was LENOVO and second word was BIOS version. I know this is not simple and straight answer but you can get more information regarding your pc from this file.
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)...