Conversion exits with error even after removing Grub

[brainchild0]

I have provisioned a Debian 11 bullseye system for "hijacking" conversion into a Bedrock system.

The system is QEMU/KVM guest running on a x86/64-bit host.

Not knowing about the limitations from the combination of Btrfs and Grub, I encountered an error when running the conversion script.

However, it was insufficient to eliminate this error even by achieving successful boot entirely through rEFInd.

In fact, each of the following increasingly more aggressive steps have failed to eliminate the error:

1. Install rEFInd and achieve working boot entirely without Grub.
2. Remove Grub system utilities from system.
3. Same, but with purge command given to APT package manager utility.
4. Remove file /boot/grub/grub.cfg.
5. Remove entire directory /boot/grub.
6. Remove all Grub binaries from EFI partition.
7. Include argument --force-update in invocation of conversion utility.

I am seeking advice on how to proceed.

I would also suggest an option for manually overriding the check. As long as the boot process is not dependent on Grub, and as long as the update routine would not set Grub as the default boot loader, then the mere presence of Grub should not cause problems. Ideally, drastic steps would not be necessary to proceed with system conversion, if a user chooses instead simply to force the conversion utility to proceed.

Presently, even after completing all steps listed above, the conversion utility proceeds as shown in the following output capture:

$ sudo sh ./bedrock-linux-0.7.28-x86_64.sh --hijack 
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
*                                                               *
* Continuing will:                                              *
* - Move the existing install to a temporary location           *
* - Install Bedrock Linux on the root of the filesystem         *
* - Add the previous install as a new Bedrock Linux stratum     *
*                                                               *
* YOU ARE ABOUT TO REPLACE YOUR EXISTING LINUX INSTALL WITH A   *
* BEDROCK LINUX INSTALL! THIS IS NOT INTENDED TO BE REVERSIBLE! *
*                                                               *
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *

Please type "Not reversible!" without quotes at the prompt to continue:
> Not reversible!

__          __             __      
\ \_________\ \____________\ \___  
 \  _ \  _\ _  \  _\ __ \ __\   /  
  \___/\__/\__/ \_\ \___/\__/\_\_\ 
          Bedrock Linux 0.7.28 Poki

[1/6 ( 16%)] Performing sanity checks
ERROR: Detected BTRFS mount and GRUB reference in /boot.  GRUB can get confused when updating its configuration in this scenario.  Either use another filesystem or another bootloader.

Yet, it is puzzling what is mean by the "GRUB reference in /boot".

Following represents the current contents of /boot:

$ sudo find /boot -maxdepth 4
/boot
/boot/efi
/boot/efi/EFI
/boot/efi/EFI/refind
/boot/efi/EFI/refind/refind_x64.efi
/boot/efi/EFI/refind/drivers_x64
/boot/efi/EFI/refind/keys
/boot/efi/EFI/refind/icons
/boot/efi/EFI/refind/refind.conf
/boot/efi/EFI/refind/BOOT.CSV
/boot/efi/EFI/refind/grubx64.efi
/boot/efi/EFI/refind/shimx64.efi
/boot/efi/EFI/refind/mmx64.efi
/boot/efi/EFI/refind/icons-backup
/boot/efi/EFI/refind/refind.conf-sample
/boot/efi/EFI/refind/shimx64.efi~
/boot/efi/EFI/refind/mmx64.efi~
/boot/efi/EFI/refind/refind.conf~
/boot/efi/EFI/tools
/boot/System.map-5.10.0-10-amd64
/boot/config-5.10.0-10-amd64
/boot/vmlinuz-5.10.0-10-amd64
/boot/initrd.img-5.10.0-10-amd64
/boot/System.map-5.10.0-19-amd64
/boot/config-5.10.0-19-amd64
/boot/vmlinuz-5.10.0-19-amd64
/boot/initrd.img-5.10.0-19-amd64
/boot/refind_linux.conf

Thank you for the support, and for considering the suggestion.

[paradigm]

The check is a bit aggressive, as I'd prefer false positives than missing something which results in an unbootable system.

This is the sanity check you're tripping on. I think it's upset by setting file:

/boot/efi/EFI/refind/grubx64.efi

I can look at improving it to remove that false positive in the next update. I'll also look at improving the message so it's easier to know what it's complaining about - it wouldn't have been hard to have it just print the file it's complaining about.

Other people have reported using rEFInd with BTRFS without issue; I'm surprised to see this come up here and now for the first time.

If you're comfortable with a null-safe editor, you should be able to just comment that check out from the install script and continue without issue. If you're not, you can remove it from the source code and build the Bedrock installer. Absent those options, you may need to wait until the check is improved.

I would also suggest an option for manually overriding the check.

I've been badly burned by people utilized similar mechanisms in the past then blamed me for when things went wrong. I know it's annoying, but I'd rather require people jump through hoops to bypass sanity checks like this than open myself up to such things again.

A work-around for the GRUB bug is planned for 0.8.0. We shouldn't have to deal with this particular concern over the long term.

[brainchild0]

Thank you for the explanation. I am glad more action is planned concerning the limitation for interoperability with Grub, and would like to learn more about the upcoming improvements. Meanwhile, if less aggressive checking and any kind of manual override are both out of the question, it might be well to consider more thorough reporting of what has been detected as a problem for any invocation, as you have suggested. It is indeed unfortunate that the current message is completely opaque. It would seem to me that the component of rEFInd that integrates with Grub should cause no problems, but also Grub itself simply being resident on the EFI partition should also be allowed.

[paradigm]

Thank you for the explanation.

You're very welcome :)

I am glad more action is planned concerning the limitation for interoperability with Grub, and would like to learn more about the upcoming improvements.

There isn't a good single resource for all of the changes, as:

• A lot is still in flux, and I don't like making announcements, getting hopes up, and then rescinding them. I've already had a number of other people commit to working on some things for 0.8 and then flake.
• Announcing too much leads to extended discussions about them which eats the very limited time that otherwise would have gone into development. Everyone has opinions and preferences :shrug:
• There are some things I'm hoping to keep back as surprises.

That said, a few highlights that seem reasonably locked-in for 0.8.0 at this point are:

• Manual install option (where you do things like manually format your partitions, create directories, etc; similar-ish to other more hands-on distros).
• Full and hosted install options modes (that we've discussed elsewhere).
• GRUB bug work-around.
• A bedrock-chroot tool which allows for chroot-like workflow for full Bedrock installs.
• A subsystem to automate updating cross-stratum caches for things like fonts and application lists, which are a known limitation of 0.7.
• A rework of the cross-stratum resource generation code to make it easier to add new resources.
• Various performance improvements, most notably/significantly the boot-time overhead.
• /bedrock directory organization rework, which should help with discovery/intuition about how Bedrock itself works
• General polish.

Some hopeful's but not guaranteed for 0.8.x (possibly after 0.8.0):

• man pages
• Have /bedrock location be configurable at install time rather than fixed.
• A pmm rewrite that can do operations in parallel. (UX for this is tricky, as package managers often do things like prompt for user input)
• Public key management for brl fetch.
• Cross-stratum services, e.g. installing Debian's openssh-server can result in sshd booting with Void's init.
• A service manager manager (smm) utility to manage the various services available across your strata.
• Cross-stratum desktop environments (which is dependent on and will have to be after cross-stratum services).

Meanwhile, if less aggressive checking and any kind of manual override are both out of the question, it might be well to consider more thorough reporting of what has been detected as a problem for any invocation, as you have suggested. It is indeed unfortunate that the current message is completely opaque. It would seem to me that the component of rEFInd that integrates with Grub should cause no problems, but also Grub itself simply being resident on the EFI partition should also be allowed.

Agreed. I'll work on it as soon as time allows.

[brainchild0]

Have /bedrock location be configurable at install time rather than fixed.

It would be good to be able to place it somewhere under /var, as to follow the standard hierarchy, and I have felt similarly for other systems, such as the way Guix installs the store under /gnu, though the choice instead easily might have been /var/lib/gnu.

[paradigm]

Have /bedrock location be configurable at install time rather than fixed.

It would be good to be able to place it somewhere under /var, as to follow the standard hierarchy, and I have felt similarly for other systems, such as the way Guix installs the store under /gnu, though the choice instead easily might have been /var/lib/gnu.

Very early versions of Bedrock actually did put it under /var, abusing it as a sort of "miscellaneous" directory. People correctly pointed out to me at the time that this was explicitly against FHS. The concept /bedrock offers doesn't reasonably fit anywhere in the FHS model, and thus the current practice of putting it outside FHS. Consider the "H" in FHS: FHS systems are explicitly intended hierarchical while Bedrock systems are not hierarchical.

I'm adding the ability to make /bedrock configurable for the same reason I'm adding hosted installs: people keep finding Bedrock, making often understandable but incorrect assumptions about it rather than taking the time to really understand it, then making suggestions (or, sometimes, demands) based on their incorrect model. The pattern appears to be that they see that Bedrock is different from what they expect, then rather than reconciling this by adjusting their mental model they try to reconcile this by adjusting Bedrock.

I'm sympathetic to the human condition that leads to this, but dealing with it for over a decade now it's exhausting and a frustratingly, directly observable limiting factor on Bedrock's available development time.

Consider taking a bit more time to familiarize yourself with Bedrock. Read through its official documentation, install and play with it (maybe in a test environment). Don't just try to make it do what you want it to do, but try to find the envelope of what it actually is designed to do.

[brainchild0]

As you say, there may be factors I have not considered. However, based on my understanding, placing the directory under /var would seem to be consistent with the FHS and the systems that adhere to it. I believe using it as a miscellaneous location is in some sense the pattern, though many would not consider the characterization quite fair.

At any rate, cluttering /var/lib is far less unattractive than cluttering root, which is forbidden.