Boot-Repair

Issues with ARCHlinux, openSUSE, Ubuntu & Windows in a multiboot enviornment

Asked by SmilingInSeattle

My main OS is Trusty Thar, but I'm experimenting with ARCHLinux and openSUSE (Tumbleweed), and I also have a Windows partition.

Generally, whenever I get an automatic update from Ubuntu, particularly with a Linux update, I'll open openSUSE and do a zypper update and open ARCH and do a pacman update. After an opensuse Linux versioning update, SUSE will do an "update-grub" which replaces my grub2 menu which was written from Ubuntu. I prefer the Ubuntu menu, so I go back into Ubuntu and run Boot Repair. However, after this I can't get into ARCH. I'm able to repair this by mounting the ARCH partition, mounting /proc and /sys in that partition, chrooting into the ARCH partition, modifying /etc/mkinitcpio to add "btrfs" before "udev" in the HOOKS parameter, after which remaking the ARCH's ramfs image with mkinitcpio -p linux. This is a pain. My wish is to be able to tell either SUSE's grub-update or Boot Repair to not change ARCH's mkinitcpio.conf back to its default. (Probably wouoldn't be a problem if Tumbleweed didn't use btrfs, but that's a price one must pay to check out the "cutting edge.") I note that since I installed btrfs-tools in Ubuntu that a part of the boot process acknowledges a search for btrfs file systems. I also tried installing ARCH's btrfs packages to my ARCH partition, but that did not help.

What I wonder is if Boot repair is "repairing" all file systems as it seems to say in the GUI t text box (as I also have another Windows virtual partition as well as a PC-BSD virtual partition on another drive) as it spends a lot of time "repairing" on that drive. If so, would it be possible to put a "Don't repair this:" box for all found Linux OSes found?

I did a lot of googling to try to understand os-prober, but nothing led me to understand how and where the changes are being made to the mkinitcpio.conf file in ARCH, or what is triggering recompilations of the initramfs in the various didtributions.

An insight would be helpful, if only to post a Bug (Want List) comment to the appropriate forum.

Question information

Language:
English Edit question
Status:
Solved
For:
Boot-Repair Edit question
Assignee:
No assignee Edit question
Solved by:
YannUbuntu
Solved:
Last query:
Last reply:
Revision history for this message
Best YannUbuntu (yannubuntu) said : 		#1

thanks for your feedback.
Please create a bug report, giving full details of eg, the contents of the mkinitcpio file before and after running Boot-Repair, and also the URL that appears after running Boot-Repair.

Revision history for this message
SmilingInSeattle (dixonhoyle) said : 		#2

Can do when new patches for the latest kernel are released as this problem probably happens during the "repairing file systems" phase of Boot Repair. Right now, there's nothing to repair as everything is up to date with the patches released this past week.

Revision history for this message
SmilingInSeattle (dixonhoyle) said : 		#3

My apology for taking a long time to respond, but I didn't want to be hasty as the problem was not consistent, and considering the number of variables, I wanted to find a pattern.

Unfortunately there is no pattern other than I've come to the conclusion that SuSE's version of grub-update Tumbleweed does not
"play" well with Arch and Ubuntu, so, since the addition of Tumbleweed was added to the distros I was trying out was experimental, I dropped it as unsuitable for me. I still see a need to add a "feature request" to Boot Repair, although, I can see what I will request could be forwarded to one of the other grub related developers. I'm still trying to "reverse engineer" Boot Repair to figure out where the best place to install my request would be, and post it to the proper forum. I think for now, I'll start with Boot Repair and let the current maintainer figure it out..

Revision history for this message
SmilingInSeattle (dixonhoyle) said : 		#4

Solved by dropping the distro deemed causing the problem.