Thank you. I’m getting ahead of the process. But I don’t know what error messages can be safely ignored. I have run into a few error messages on previous updates. Running them down usually came back to the old Bios and recommendations to update it. Unfortunately, that is not an option.
Ah, we didn’t know that, Preciousss. We doesn’t use Windowses. We hates it! We hates it forever!"
It’s probably under “Drive Controller” or “Boot Devices”, or something like that. I’m afraid I can’t be more specific, because everything depends on the exact make and version of the firmware. 
re: mkdir /var/lock/dmraid
if my bios is too old to support Raid (it is too old to support a VM option) is there a way around this? I will reboot and check the settings; but I suspect its not there. I loaded Manjaro on this laptop about 3 years ago. It has been functioning well (with the dual boot to Mr. Hyde) until I did the last update. IPrevious update problems I tracked down to the bios (the VM option it lacks, that the bios uses low memory location (and excluded it). I appreciate all the help and advice I have received. I’m going to shut down and check my bios settings.
Thank you again.
The setting should not be “RAID”. It should be “AHCI”. However, some firmware implementations do default this to “RAID”, so if that is the case, then you should change it to “AHCI”.
@Aragorn
There is no RAID or AHCI option in my 2007 Bios:). There is Internal, external , or Network.
and the CMOS battery is good. It’s late. and I should’ve realized it was good because the time and date where correct. However, I can now boot into Manjaro! Yay!!! I ran the update for Grub (sudo update-grub) after I booted to Manjaro and it did not find the Win7 on sda2. Thank you for getting back to usable system. However, I am back to the original problem that sent me into breaking my system. The update didn’t find Window7 (Windoze, i Like it), which I unfortunately need. And I know (We hates it!) but before the update everything worked. Would using Timeshift to revert the system to before the update be the appropriate way to get that grub boot option back?
No, because then we’d be running in circles. It would result in your system not being able to boot Manjaro anymore, and then we can start this whole thing all over again.
Did you — as suggested by @anon33601770 — run “sudo update-grub” again after rebooting into your installed system?
Yes. I ran it. Then I rebooted. Grub still lacks an entry for Win7.
I realized I forgot to run the mkinitcpio -P command while in Chroot. So, i rebooted into the USB version with the intent to rerun the 4 commands you gave me:
rm -f /var/lib/pacman/db.lck
pacman -Syu linux510 linux54
mkinitcpio -P
update-grub
Then reboot into the hard drive, rerun the update grub command and reboot again.
Does this sound logical?
Okay, just for giggles, because I’m not sure whether this will work — as I said, I don’t use Windows, and my system is installed in native UEFI mode — try this then… 
mkinitcpio -P
sudo grub-install --recheck --no-rs-codes && sudo update-grub
No need to chroot for any of these commands.
Now that I am running on the USB version of Manjaro, do I need to change paths to the hard drive installed system?
@Aragorn
The command prod uced this:
mkinitcpio -P
==> Building image from preset: /etc/mkinitcpio.d/linux614.preset: 'default'
==> Using default configuration file: '/etc/mkinitcpio.conf'
-> -k /boot/vmlinuz-6.14-x86_64 -g /boot/initramfs-6.14-x86_64.img
==> ERROR: Invalid option -g -- '/boot/initramfs-6.14-x86_64.img' must be writable
==> Building image from preset: /etc/mkinitcpio.d/linux614.preset: 'fallback'
==> Using default configuration file: '/etc/mkinitcpio.conf'
-> -k /boot/vmlinuz-6.14-x86_64 -g /boot/initramfs-6.14-x86_64-fallback.img -S autodetect
==> ERROR: Invalid option -g -- '/boot/initramfs-6.14-x86_64-fallback.img' must be writable
I am guessing that your filesystem is mounted read-only, which is the normal behavior after a system crash that leaves the filesystems in a dirty state.
I would recommend booting up from the live USB, and without mounting or chrooting, run a full fsck on the filesystem.
@Aragorn Thank you. I will try this. I did not realize this was a system crash or a interrupted update.
1 Like
Now that I’m thinking of it, if your Windows filesystem was mounted during that crash, then it too may have been rendered “dirty”, which is then probably why os-prober cannot find it. So you will need to use some Windows rescue CD or something to fix the ntfs drive.
Edit: You could try ntfsfix from within Manjaro to clear the dirty flag on the ntfs partition, but that’s all it does; it does not actually repair the filesystem — for that you need Windows’ own CHKDSK.EXE. But at least it might get os-prober to find your Windows partition again. 
I ran the command and this is the response.
sudo fsck -f -y /dev/sda3
fsck from util-linux 2.41
e2fsck 1.47.2 (1-Jan-2025)
Pass 1: Checking inodes, blocks, and sizes
Inode 1048996 extent tree (at level 1) could be shorter. Optimize? yes
Inode 1049323 extent tree (at level 1) could be shorter. Optimize? yes
Inode 1049489 extent tree (at level 1) could be shorter. Optimize? yes
Inode 1050923 extent tree (at level 1) could be shorter. Optimize? yes
Inode 1050952 extent tree (at level 1) could be shorter. Optimize? yes
Inode 1051140 extent tree (at level 1) could be shorter. Optimize? yes
Inode 1051166 extent tree (at level 1) could be shorter. Optimize? yes
Inode 1051391 extent tree (at level 1) could be shorter. Optimize? yes
Inode 2359773 extent tree (at level 1) could be shorter. Optimize? yes
Pass 1E: Optimizing extent trees
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information
/dev/sda3: ***** FILE SYSTEM WAS MODIFIED *****
/dev/sda3: 1768295/7692288 files (0.6% non-contiguous), 16140507/30762061 blocks
[manjaro@manjaro-cinnamon ~]$ echo $?
0
I understand a zero is no errors. windows booted from the Grub (with no problem) when Grub saw it. I used the Windows side ((booting from Grub)for the last week or so while i researched this problem. 
That is good, yes.
Sure, and if you were able to boot up in it again now, it would do the same, because Windows isn’t particularly picky about quality, and it will happily run from a damaged filesystem until it doesn’t.
But that’s irrelevant now. The issue is that os-prober cannot find your Wndows partition, and that this is most likely because it cannot read the filesystem due to it being marked “dirty” — whether it is or isn’t, the flag is set. And the Linux kernel is picky about quality.
So, try what I suggested and run ntfsfix on your Windows partition to clear the flag. If it really is damaged, then you can repair it from within Windows once you manage to boot up into it again.
But the issue now is getting os-prober to find your Windows partition, and if that “dirty” flag is set, then it won’t find Windows because it can’t mount the ntfs filesystem on that partition, and thus it can’t read what’s on there.
Edit: Make sure your Windows partition is actually mounted before running update-grub.
mount | grep ntfs
Thank you for the explanation.
1 Like
@Aragorn
ntfsfix returned:
Processing of $MFT and $MFTMirr completed successfully.
Checking the alternate boot sector... OK
NTFS volume version is 3.1.
NTFS partition /dev/sda2 was processed successfully.
This look good (cautiously). If I understand the extra edit, I need to:
mount the windows device,
Run update-grub.
wilco
1 Like
Correct. 
I did both. And rebooted. The Grub doesn’t have an entry for Win7:(