Manual or automatic partitioning?
1 Like
Manual without home, / is on /dev/sdc4. GRUB on sdc + bios_grub sdc1. But whatever i try, it is not working with a separate /home on /dev/sdc6 either.
1 Like
Are you remembering to create /boot? Have you tried going to manual partitioning, select the option to auto-create partitions, and then manually adjusting them to how you want?
1 Like
Been getting the same error for the past couple days:
Dec 03 08:37:36 noname anaconda[1881]: program: /sbin/grub2-mkconfig: line 268: /boot/grub2/grub.cfg.new: No such file or directory
In addition, the installer is creating nested directories: /boot/efi/EFI/EFI...
I have tried with automatic partitioning as well as with manual partitioning - same error.
Screenshots
3 Likes
Are you dual booting? If not, can you try deleting the ESP and installing again? If you are, can you try selecting manual partitioning → hit the button to create the partitions → remove the /boot/efi mount point and re-create it as a new partition?
1 Like
Well, in my case, i got it to work on /dev/sda with default options. But that SSD was due for a secure erase, so … yeah. I dont want Silverblue on /dev/sda. I will happily wait another two years until the Silverblue team got their anaconda sorted out, so i can finally install it on /dev/sdc4 with multiboot.
1 Like
Every time I try to install Silverblue on a drive with pre-existing EFI partition (dual booting), I get the message “failed to write boot loader configuration”. The installation log is showing the same above messages, and I confirm the nested directories /boot/efi/EFI/EFI... too. Is this a known bug for Anaconda?
If anyone is interested, this worked for me:
Run this from the shell when the error dialog box comes up, and then ignore the error and continue the installation (replace <deploy_id>.0 with the existing folder):
chroot /mnt/sysimage/ostree/deploy/fedora-workstation/deploy/<deploy_id>.0 /bin/sh
mv /boot/efi/EFI/EFI/* /boot/efi/EFI
rm -r /boot/efi/EFI/EFI
grub2-mkconfig -o /boot/efi/EFI/fedora/grub.cfg
exit
4 Likes
It might be this one: https://bugzilla.redhat.com/show_bug.cgi?id=1168118
I ran into it trying to install Fedora Workstation 29 on my laptop. Said laptop is currently dual-booted Antergos Linux and Windows 10 Pro, so I know dual-booting is possible. It also was dual-booted with Ubuntu 18.04 at one time.
Any Anaconda experts here?
1 Like
Hmm that doesn’t seem like the same bug, I recognized @erubio0’s case as one I ran into as well that’s Silverblue-specific. IIRC Anaconda just copies the EFI directory without checking if it’s already present in the ostree variant?
1 Like
¿You know? You saved my day. This bug seems a little bit absurd TBH.
FTR to enter shell: Ctrl+Alt+F1; then Ctrl+B 2
1 Like
After doing this and finally having a working Fedora Silverblue, the grub screen doesn’t use any default value. I always have to select one deployment. Any suggestions to fix that?
Also I have:
Fedora 31.20191220.0 (Workstation Edition) (ostree:0)
Fedora 31.1.9 (Workstation Edition) (ostree:1)
I have no idea on which one is the good one, or what do ostree:1/0 mean… wasn’t it supposed to be using ostree always? 
1 Like
Hello @yajo, Welcome to the discussion.
The commits are listed from newest to oldest so 0 is the newest (an default selection) and 1 is the previous commit. The commits are always Ostree, what you are seeing is the variant of Fedora used for Silverblue (Workstation).
I too see the most recent commits at Grub menu, if I wait the most recent one boots, or I can select which one, there is time (~5 seconds in my case).
2 Likes
Thanks for your replies 
Yes, but in my case it will never choose one automatically, no matter what I do.
1 Like
Sorry @yajo, I have been away for a bit. Did you solve your problem with Grub? If so could you comment about the solution here for future info, and if not let’s see what we can figure out.
1 Like
Unfortunately, this bug is still alive. Here’s the workaround update for Silverblue 31:
chroot /mnt/sysimage/ostree/deploy/fedora/deploy/<deploy_id>.0 /bin/sh
mv /boot/efi/EFI/EFI/BOOT/* /boot/efi/EFI/BOOT/
mv /boot/efi/EFI/EFI/fedora /boot/efi/EFI/
rm -r /boot/efi/EFI/EFI
grub2-mkconfig -o /boot/efi/EFI/fedora/grub.cfg
3 Likes
This is a real pain. I’m not even able to do the workaround since my keyboard is bluetooth one and we have no bluetooth here in Anaconda!
So let’s please file this bug in the end if it wasn’t already. Anyone aware of the situation?
PS: also, the installer seem doesn’t allow to continue the installation, so not sure if workaround is enough…
1 Like
Apparently, there are a lot of this bug reports already, starting from 2017, but the bug is still there:
https://bugzilla.redhat.com/show_bug.cgi?id=1483818
https://bugzilla.redhat.com/show_bug.cgi?id=1575957
1 Like
Ok I found the issue and provided the fix:
https://github.com/rhinstaller/anaconda/pull/2329
Not sure why is should had to take 3 years if one is really care…
1 Like
Wow! Just that to solve an x-years problem?!
Silly, yeah? Actually, I’m just going to test it 
1 Like