Sunday, November 13, 2022

How to: restore Nouveua video drivers on Fedora 36 (Related: Clean up after failed Nvidia installs on Fedora 36 KDE-Plasma)

 Status

Confirmed by lack of nonoccurence of this issue.

 History

I recently "moved into" my new workstation at home. As usual, it came with a Microsoft product (which wasn't too bad, honestly) but I wanted to use Fedora KDE-Plasma.  I started the process and got a clean separation between "What Is Windows" and "What is Fedora".

As almost every other time in the past, I wanted to use NVidia video drivers.  And, as iwth almost every other time, I failed to get NVidia to install correctly for Fedora.  I don't think it's necessarily RedHat's fault, probably 1/3 NVidia's issue and the rest is my issue. I simply can't invest several days to teach myself how to build (easy), install (seemed easy but didn't work) and configure (never get that far.) 

So, I "rolled back" to the always working Nouveua video driver.  After a bit, I thought I had safely returned to the land of productive.  After a few kernel updates, I discovered I was wrong. 1024x768 worth of wrong.

 Overview

Prior NVidia video driver installs had left several, disabling files and configurations.

Constraints

Wanted to restore Nouveua video drivers to full operability without reinstalling the OS Fedora 36 KDE-Plasma.

Preparations

  1. Followed the instructions here: Uninstall the NVIDIA driver
  2. Taken from the console output of NVidia driver installer process, I removed:
    1. /usr/lib/modprobe.d/nvidia-installer-disable-nouveau.conf
    2. /etc/modprobe.d/nvidia-installer-disable-nouveau.conf
  3. rebooted, dnf updated and rebooted again

Process Issues

This process worked well for about 3 weeks. I kept my  OS and applications up to day (dnf and flatpak.)  However, after Fedora updates proved on 12 November arrived, these seemed to trigger an unexpected and silent event.  After shutdown and restart on 13 November, I was greeted with persistent, non-complaining 1024x768 and no options to restore functionality.  In contrast: I normally operate my video at 5120x1440.

Steps

Check Journal (inconclusive)

journalctl -p err..alert -b

Summary

I spend some time here as there is a lot of "red noise" to filter though. After a bit, I determined the issues displayed did not strong contributors to my display issue.

 Check XOrg (inconclusive)

less /var/log/Xorg.0.log

Summary

Nothing much to see here. I was looking here to see if XWindows listed what video driver it was using. 

Check Boot.log (inconclusive)

cat /var/log/boot.log

Summary

No errors found.

Check /boot (definitive)

grep -R nouveau /boot/

Summary

Here I found the core issue:

/boot/grub2/grub.cfg:  set kernelopts="root=UUID=0xxxxxx9-9xx1-4xx4-9xxc-axxxxxxxxxxf ro rootflags=subvol=root rhgb quiet rd.driver.blacklist=nouveau modprobe.blacklist=nouveau nvidia-drm.modeset=1 "

Nvidia's installation had disabled Nouveau when booting the kernel but NVidia's uninstall instructions did not handle the grub2 configuration nor do I recall seeing any mentioned else where.

Solution

grubby --update-kernel=ALL --remove-args='rd.driver.blacklist=nouveau'
grubby --update-kernel=ALL --remove-args='modprobe.blacklist=nouveau'
grubby --update-kernel=ALL --remove-args='nvidia-drm.modeset=1'

 
Summary
grubby is the official way to change values for the Grub2 boot configuration.

Note: these changes appear to be persistent after a reboot. I am uncertain if these changes alone are enough.  After the next kernel and/or Grub2 update, I should know for certain.

Summary

Grubby is used to modify the boot parameters for Fedora 36 installations.  It can be used to add and remove "at kernel boot time" configurations.  Responsible software vendors should pay equal attention to how their software is uninstalled as to how it is installed.

Resources

Other Resources

Disclaimer

This solution worked for me. It may or may not work for you. I am not responsible for your actions nor the your results of your actions should you act on what you read here. I do not claim expertise in this very specific area and only convey my experience. There is no warranty on this (and most) free information.

 

 

 

 

Sunday, December 6, 2015

How To: Rescue Windows 7 Boot Manager / "Bootmgr is missing"


Overview


Constraints


Preparations

  1. REQUIRED: Windows 7 rescue disk
    1. To create:  navigate to Control Panel | System and Security | Back up your computer  and select Create a system repair disc and then follow the direction as appropriate for your situation.

Steps

Step 1: Boot from Windows 7 rescue disk and answer language and keyboard layout questions for your situation.
Step 2: Select your OS and check the Use recovery tools that can help fix problems starting Windows

Step 3: On the System Recovery Options window, select Command Prompt 
  • Note: I recommend skipping down to Other Observations before you continue on Step 4.
Step 4: Enter each of these commands, waiting for each to finish before starting the next one:
bootrec /rebuildbcd
bootrec /fixmbr
bootrec /fixboot
 
Step 5: Remove Windows 7 Rescue disk and reboot
Step 6: If it boots normally, you're done. If not: execute Steps 1-3 again and then continue on Step 7
  • Note: I used the following steps without checking the results at Step 5 and Step 6.  While probably not recommended, it does appear to be OK.
Step 7: Execute these commands, waiting for each one to finish before starting the next one:
diskpart
Inside diskpart, type each following line:
select disk 0
list volume
Step 8: Locate your Windows 7 Rescue disk (IE CD/DVD) and note the drive letter and then type exit to exit diskpart.

Step 9: Execute these commands, waiting for each one to finish before starting the next one:
Change to what ever the drive letter was listed in diskpart for the Windows 7 Rescue disk listed in Step 7
Example: D:
Continue with these commands:
cd boot
dir
bootsect /nt60 SYS /mbr
Step 10: remove Windows 7 Rescue disk and reboot






Observations

This process is likely to remove any custom Boot Manager options you have previous setup.  See the Other Resources link to learn how to perform backups on you Windows 7 Boot Manager configuration before putting it at risk on Step 4

Summary

Assuming you have only unlinked your MBR from the boot process for Windows 7, these instructions should repair this minor, MBR-based mis-configuration.  If there is more extensive OS file damage or physical hard drive damage, these steps may not provide any assistance.

Resources

Here is where I got my information from:   
  1. Fix the MBR – Guide for Windows XP, Vista, 7, 8, 8.1

Other Resources

Here are additional resources which might be useful, depending on your situation:
  1.  How to Use the BCDEDIT Command Line Tool

Disclaimer

This solution worked for me. It may or may not work for you. I am not responsible for your actions nor the your results of your actions should you act on what you read here. I do not claim expertise in this very specific area and only convey my experience. There is no warranty on this (and most) free information.






Sunday, April 13, 2014

Solved: Restoring the Master Boot Record (MBR) to the boot drive


Context: Missing or corrupted Master Boot Record (or MBR) can and usually will prevent the


Problem: Having botched a Linux installation, the Master Boot Record (MBR) was destroyed. To recover and boot the computer again, the MBR must be restored to work order.


Constraints:
  1. No floppy drive
  2. BIOS doesn't support USB booting
  3. CD ROM limited on ability to read different CDs
  4. Windows booted from the MBR directly so I could not use Microsoft's fdisk
  5. Lilo was not found on the Fedora 9 Live CD
  6. Grub-install on the Fedora 9 Live CD did not function according to expectation

Details: Installing Fedora 9 Live CD to an Dell Latitude C600, I didn't allow enough room for the Live CD install (I misremembered options for a selective install.) Additionally, a previous GRUB installation on the Master Boot Record was not clean off before installation started. Near the end of the installation, an error occurred (out of space.) The result was a damaged MBR record. The exact cause of the damage was not known.


Solution: Restore MBR from

  1. Boot Fedora 9 Live CD
  2. Confirm presents of file usr/lib/syslinux/mbr.bin
  3. Open a Xterm or other shell
  4. Log in as root or superuser
  5. Umount the targeted drive partition. In my case:
    • umount /sda1
  6. Write the replace MBR to the drive:
    • dd if=/usr/lib/syslinux/mbr.bin of=/dev/sda bs=1
  7. reboot

Note!: This was a "long shot" action on my behalf and thus poses a risk on your behalf. The contents of the file mbr.bin were a guess on my part as was application of dd. While this works, you should know that your results may vary greatly. Use these instructs only as a last resort!


References:

Disclaimer:
This solution worked for me. It may or may not work for you. I am not responsible for your actions nor the your results of your actions should you act on what you read here. I do not claim expertise in this very specific area and only convey my experience. There is no warranty on this
(and most) free information.

How To: Mount a broken ODroid (U2) boot images from Windows


How To: Mount a broken ODroid (U2) boot image from Windows

 

Sat In A Box For A While...


http://com.odroid.com/sigong/_Files/2012/201211/images/201211251432377371.jpg

Almost a year and a half ago, I purchased an ODROID U2 from Hardkernel from HardKernel.com.  Since then, the U2 sat in a box and was replaced by the ODROID U3 product line. Earlier this year I finally had time to get it out.

Overview

In brief, the ODroid U2 is a ARM processor board which can boot from an SD card or an EMMC card.  It supports Android and Linux operation systems (and probably more) with some extra drivers.  Think of it as a Smart Phone motherboard with full size USB and network connections.

Side note: I did look at Rasberry PI first, then bought the ODroid.

After moving between countries with the growing family, I finally had time to get the device out and explore.  After "fixing" the boot partition layout of the EMMC card (which I had initially destroyed by writing an SD images to the EMMC card), I was finally able to reach my short term goal: booting Linux on this tiny device.  I started customizing the settings to suit myself and testing out available software in preparation for a larger project.
Not long after this, I destroyed the boot-able image on the EMMC.

Step 1: Assessment

While glossing over the specifics, I had removed all the boot files, kernels and related details which make the EMMC bootable.
Yes, in fact it doesn't boot any more, displaying only the D.S.B.L. (Dreaded Solid Blue Light); when the ODroid U2 is powered-up, there is a blinking blue light to indicate that the system is booted and operational where as a solid blue light is for other, "non-positive" cases.

Step 2: Planning

Since I used an .img file to write the EMMC image to start with, I could have easily re-burn the same starting .img file to the EMMC again.  But, this would mean losing the current, customized setup ( and more importantly my notes for that setup ) and starting again.  So, my goal was 1) to recover my notes and 2) repair the system.

What I found was the .img file is really a kind of direct 'disk' image of OS, including (and importantly) the boot and other OS partitions.

I am currently using Windows 7 at home.  While Windows doesn't understand these other partition types, Linux readily does.  The plan is to mount the partitions, repair and copy off data and retest.

Step 3: Make an .IMG

I needed to make a new .img file of the corrupted EMMC Linux "disk" from the EMMC.  This allowed me to experimenter while not damaging the original image, providing a "fall back option" if needed.

I placed the EMMC card in to the eMMC Module Reader and plug into Windows host.  Windows saw it and prompted me for some not-so-useful options, such as reformatting.  Cancel all the windows options and let it mount unmodified.

Using Win32 Disk Imager, I configured it to read from the eMMC Module Reader (with the EMMC attached) and selected a target directory and name for the .img file.

In my case, I read from H:\ and wrote to c:\temp\odroid-rescue.img. Your drive and targets will probably be different. I will use this for the reminder of these instructions; adjust your settings as needed.

IMPORTANT: as the tool will remind you, make sure you are very clear where you are reading from and where you intend to write to.  This tool can easily erase a media.

Once configured, click on the Read button.  This will read from H:\ and write to c:\temp\odroid-rescue.img

With a larger EMMC, this can take a while as it is making a bit-for-bit copy of the media.

Step 4: Mounting Folders

I have an up-to-date version of Virtual Box on Windows with Fedora 14 which I have used for years now.  I used it because it was already set and available but any modern Linux distro installed in a virtual machine should work.

Using VirtualBox, I setup this Linux VM to share a directory with my Windows host.  In this directory I copied my odroid-rescue.img image.

Note: instructions for using VirtualBox and shared folders are not in the scope of this article.  An alternative is to copy the .img inside the Linux VM but be aware of the size of your .img file before taking this approach.

I started and logged into the Linux VM.  In the Linux VM, I verified both the shared directory was accessible and the .img file was available.  I changed/su-ed to the root account to avoid excessive sudos.

Step 5: Measuring The Partitions

So, now I am in Linux VM as root and I can see the .img file.  Inside this particular .img file, I know there could be one or more partitions.  As such, I will need to survey the contents on the .img file before mounting parts of it.

cd /path/to/odroid-rescue.img
fdisk -lu odroid-rescue.img


Note: this .img file contains an xubuntu 3.10 image. Other Linux distribution's partitions any vary significantly.

Here are the results with key aspects bolded in red:

Disk odroid-u2-emmc-64G-xbuntu13.1.img: 62.5 GB, 62537072640 bytes
255 heads, 63 sectors/track, 7603 cylinders, total 122142720 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x000c4046

                            Device Boot      Start         End      Blocks   Id  System
odroid-u2-emmc-64G-xbuntu13.1.img1            4096      266239      131072    b  W95 FAT32
odroid-u2-emmc-64G-xbuntu13.1.img2          266240   122142719    60938240   83  Linux

So, in my case I have:
  • Bytes per sector are 512 (first bold number)
  • two partitions:
    • one FAT32 partition which starts on 4096 (second bold number)
      • boot files are here!
    • one Linux partition which starts on 266240 (third bold number)

Step 6: Mounting Partitions

In the Linux VM, cd /mnt and create directories: /mnt/boot and /mnt/odroid.

To mount the boot partition I used:
mount -t auto -o loop,offset=$((512*4096)) odroid-rescue.img  /mnt/odroid-boot/
Note: the 4086 comes from the "start" column of the fdisk command and the 512 from the sector size.

To mount the other partition I used:

mount -t auto -o loop,offset=$((512*266240)) odroid-rescue.img  /mnt/odroid/
Note: the 266240 comes from the "start" column of the fdisk command and the 512 from the sector size.


         
Note: see references for whom to created for this section.

Step 7: Explore, Repair And Copy (as needed)

Here you have access to the partitions of the .img file for exploration and/or repairs as you wish.

In my case, I needed to put the correct files back in the /mnt/odroid-boot and backup files from /mnt/odroid. 

IMPORTANT: All changes your make to the mounted .img file are "live and persistent" like any other disk operation so do be careful!

Step 8: Release The Image and Un-Mount Partitions

After you finish you changes, close all editors and any other open files into the mounted image partitions.  Then:
umount /mnt/odroid
umount /mnt/odroid-boot

Makes certain there are no issues with the umount commands.  As an alternative catch all" move, shutdown the Linux VM to ensure you are completely disconnected from the .img file.

Step 9: Re-burn the ,img to the EMMC card

Back in the Windows host and using Win32 Disk Imager again, this time you will setup to read from the odroid-rescue.img and write to H:\ after connecting the EMMC to your eMMC Module Reader and load it into Windows.

IMPORTANT: as the tool will remind you, make sure you are very clear where you are reading from and where you intend to write to.  This tool can easily erase an media.

Once configured, click on the Write button.  This will write c:\temp\odroid-rescue.img to H:/

Step 10: Boot EMMC card

You are now ready to "check our work" by replacing the EMMC card in the powered off ODroid device, powering it up.  A blinking blue light means success while a stead blue light means try again.

Summary

We have described:
  1. discovering partition information about an .img file
  2. the basics of mounting an .img file
  3. described the use of the Win32 Disk Imager
  4. described how to perform a rescue operation of a Linux .img file from a Windows OS using VirtualBox

Resources

Here is where I got my information from:
  1.  [SOLVED] how to mount .img file
  2.  Win32 Disk Imager
  3.  VirtualBox

Friday, November 20, 2009

Solved/Enhancement: Fedora 11/Fedora 12 Speed Improvement for YUM updates

Context:
The typical mechanism for updating (or even upgrading) Fedora 11 and Fedora 12 distributions is through Yum and/or it's graphic user interface counter-part gpk-update-viewer. In brief, Yum collects local installation information and comparies it to available updates through a series of mirror sites holding updates for Fedora installations.


Problem:
While running a Beta version of Fedora 12, at some point most the mirror sites that provided Fedora 12 with updates stopped working for me. And, because these sites were scattered around the world, it took a while for Yum to look through all of them to find one that worked.


Constraints:
None


Details:
It's not clear why the mirror sites stopped working. Some reported "404" errors, some "50x" errors and some returned unknown result codes. Eventually, either by retrying or getting lucky, Yum would succeed. I suspect that as Fedora 12 beta moved to Fedora 12 official release, some testing sites for upgrades were taken down.

Note: this problem also affected the GUI front end for Yum: gpk-update-viewer.


Solution:
  1. As an initial step, I executed su -c "yum clean all". I do not know it this assisted with the process of correcting the issue but it is worthy of noting.
  2. Next I executed su -c "yum install yum-fastestmirror". After a few tries, the package as located and installed.

Results
:
On the next yum action, I found the following output:
Loaded plugins: fastestmirror, refresh-packagekit
Determining fastest mirrors
* fedora: fedora.xxxx.xxx
* updates: ftp.xxx.xxx
Setting up Update Process
...
Where the xxxx sites were geographically closer to my current location than the previous sites and were working as Yum expected. The completion of this Yum action and subsequent others was much faster and error free.


References:


Disclaimer
This solution worked for me. It may or may not work for you. I am not responsible for your actions nor your results of your actions should you act on what you read here. I do not claim expertise in this very specific area and only convey my experience. There is no warranty on this (and most) free information.

Friday, August 28, 2009

(Followup) Fedora 11: TCP Performance Tuning [script available]

Context:
Using Fedora 11's default installation configuration, reliable network services are provided.

Problem:
No specific issue but performance-related improvements investigated. TCP settings, set for very small "data windows" (small packet sizes), require more packets, creating more network traffic. If set too small, the overhead for sending more packets could cause slower network performance and possibly higher CPU usage.

Constraints:
I had no specific constraints, although I did want a solution that did not require installation of third-party software or other non-standard elements for a Fedora 11 distribution.

Details:
For root or super user accounts, most Linux installations offer access to TCP settings. These settings tell the network card (NIC) and Linux kernel how to manage transmission data. By adjusting these settings, you can affect how much time the computer and NIC spend at these various networking tasks.

Solutions:
After doing some research, I found this site which describe changes that would or could improve network performance. Since I needed to apply these changes on more than one computer, I decided to script the process. Also, since this task was mostly a new domain for me, I decided to backup the existing TCP settings before writing new TCP settings.

The results is a "simple in nature" script for improving TCP performance. Rather than posting an almost 200 line BASH script on the blog, you can get it from this link:
In general terms, this script increases the size of the TCP packets being sent. There are other features enabled which I did not fully research, most explained in the first resource link.

Script Features:
  1. Supports -h and --help command line arguments to get limited help
  2. Simple to use: just execute the script and follow the directions (mostly pressing the space bar or CTRL C to quit)
  3. Confirms necessary tools are available before starting the process
  4. Backs up current settings into a uniquely named file [default name provided, uniqueness handled by the script and reported to the user]
  5. Backup file is formatted (but not tested) to be executable for restoring previous settings
  6. Detects the currently "in use" NIC to make any card-specific setting changes
  7. Requires root via sudo access to execute changes. (not required to perform the setting backups)

Note:
Read this script thoroughly before executing it. If you do not understand it or you are not comfortable with it, I strongly suggest you do not execute it. This script was designed specifically for Fedora 11 distributions and it may or may not work on your Linux distribution. This script is platform-specific and is not expected to work on any other platform (i.e. Windows, Mac, etc)

Results:
I did not develop a metric for testing the results before hand. Here are my subjective observations afterward:
  • Web: it appears that before the changes I could sometimes see web pages loading individual elements. After it appears that web pages "snap" onto the screen quickly.
  • SSH: appears to have no significant impact on SSH. This most likely do to two issues with SSH it's self: limited packet size and single-threaded (de)encryption services.
  • Downloads (web): I don't have any specific impressions of previous speeds but I believe there is an improvement. I have a good ISP so I am seeing 1.7M (peaking at 2.2M) transfer rates per second from a relatively close-by commercial site, which seems higher than before.

References:
Additional reading here:

Disclaimer:
This solution worked for me. It may or may not work for you. I am not responsible for your actions nor your results of your actions should you act on what you read here or execution of the script I provided for this blog entry. I do not claim expertise in this very specific area and only convey my experience. There is no warranty on this (and most) free information.

Followup (August 30, 2009)
It appears that the default settings in the provided version 0.2 script may have introduced an issue with some web sites, most noticeably with streaming audio and video with Flash. Using a previous configuration I used that didn't appear to have this issue at the time, I have updated the script (0.4) with some less aggressive settings. This update also has a more execution-friendly backup file format. Additional testing so far seems more consistent.

Followup (September 2, 2009)
The problems I experienced seems to be related to a kernel update for Fedora 11. More details here:
As the problems I experienced are not related to the TCP Tuning, I plan to update the script to support multiple types of settings from minor to aggressive TCP tuning.


Followup (September 3, 2009)
I have updated the tcpTuning.sh script to 0.5. I have added 3 different tuning profiles:

  1. -0 = tune TCP performance to near-default installation settings
  2. -1 = tune moderate TCP performance settings
  3. -2 = tune aggressive TCP performance settings
tcpTuning.sh still supports -h and --help in case you forget these options.

Sunday, August 24, 2008

(Followup) Solved: Fedora 9 default settings for shared memory /tmp

Context:
Using Fedora 9's default installation configuration, the "temp directory" (using another OS's terms) is utilized as /tmp. This special directory is a shared file system and resides in memory known as tmpfs.

Problem:
The default settings for a tmpfs is half of the available memory.

Constraints:
Fedora 9's default set up uses an in-memory solution for /tmp.


Details:
My system has 2 gigabyte of memory. However, the average usage for /tmp on my machine is less than one 1 megabyte. So, more then 1023 megabytes of memory was allocated and never used.

Solution:
I needed to control the size of the /tmp. This is mounted at boot time using the description in /etc/fstab. After a forum search, I looked at the man page for the mount command to determine the need to use the size option during mount /tmp. I decided to try only having 2 megabytes for /tmp.

Original /etc/fstab:
tmpfs    /dev/shm    tmpfs    defaults    0 0
New fstab:
tmpfs    /dev/shm    tmpfs    defaults,size=2097152    0 0

After making these changes as super user or root, I rebooted my system to get th e settings to become active.

References:

Note:
The other options for providing /tmp are:
  1. disk based /tmp, mounting (via /etc/fstab) a disk partition at boot time (preferred)
  2. directory based /tmp on the boot root partition (not preferred for security reasons)

Disclaimer:
This solution worked for me. It may or may not work for you. I am not responsible for your actions nor the your results of your actions should you act on what you read here. I do not claim expertise in this very specific area and only convey my experience. There is no warranty on this (and most) free information.

Followup (July 26, 2009):
A simpler way to control the /tmp size through the /etc/fstab is using a percentage:

In fstab:
tmpfs /dev/shm tmpfs defaults,size=10% 0 0