Newbie dual boot issues

I am new to silverlight but not to linux. Over the years I have done the usual distro wandering over the last 25 years from Slackware > SuSE > Debian > Redhat > RHEL > Debian > [MacOS] > [ChromeOS] > [ChromeOS with Debian] > Ubuntu > Debian > Fedora > Debian (with a sideline of IoT with Raspbian)

I have an old lenovo thinkpad with an internal (/dev/sda) hard drive partitioned with a grub booter that handles the Debian (daily driver) & Windows 10 dual booting.

I have now added a 128gb SSD in the DVD bay and the other day decided to see how Fedora has progressed since I last used it. When I looked at the Fedora site I noticed silverblue and took to reading a little about it

Finding it technically interesting I decided to install a second drive (/dev/sdb) in my Thinkpad and installed silverblue to take it for a prolonged test drive to see if it would do me as a daily driver

But I am having some issues sorting out grub booting.

The UEFI disabled bios sees both drives … I can boot either drive via the choosing the drive via the bios menu interrupting the boot process manually.

However, try as I can I can’t seem to get grub to see the drive

I’ve added an entry as a type=Linux using grub-customizer pointing to /dev/sdb1 (ext4), /initd.img, /vmlinuz
boot sequence=
set root=‘(hd1,1)’
search --no-floppy --fs-uuid --set=root c36f613f-21ed-4ce0-896a-66492bca2487
linux /vmlinuz root=UUID=c36f613f-21ed-4ce0-896a-66492bca2487
initrd /initrd.img
grub-customizer saves and installs and then I reboot

When I reboot and select this option I can’t boot silverblue.

I’ve also tried the same options but pointing to the /dev/sdb2 LVM partition without any success.

Good day @iandstanley,

My use case is a bit similar. I triple boot Windows 10, Fedora Silverblue and Haiku. My box (UEFI) initially had Windows 10 and Ubuntu, both in separate drives, and I wiped out Ubuntu drive for Silverblue and added a new drive for Haiku, so each System has its Own Drive.

It’s “documented” that multibooting with Silverblue is tricky, I experienced it as in fact I still need to fix the booting of Haiku, but for now, I can dual boot Windows and Silverblue through GRUB.

Actually, in my case, installing Silverblue was some sort of an easy task following some hints, and I must say I did a custom partitioning, but being aware of the advise provided, which is:
1- create an EFI boot partition (this does not apply in your case as you are not using UEFI)
2- create a /boot partition (ext4)
3- create an LVM volume group with two volumes, / and /var/home

In this scenario, now I have 2 EFI boot partitions, one on the Windows drive and another on the Silverblue drive. Then I pick Silverblue’s drive in the UEFI BIOS as the selected drive to boot. That way, Silverblue boots, and Silverblue’s GRUB manages the booting process. It does see the Windows bootloader too. (My issues here deal with Haiku, but that is another story).

So presumably, your issue deals with the location of the boot, at least, as far as I know, the /boot should be in its separate partition. I can’t certify this as I’m also a Silverblue newbie, and others here have way more knowledge than me.

What I would do in your case would be to install GRUB and /boot on your Silverblue drive, select this drive as your primary boot drive in the BIOS, and then fix the Debian GRUB entry inside the Silverblue boot process. For now seems Silverblue is a bit faddy in many aspects.

I can´t think of any other way.
Regards,
RR

It looks like you are using the same UUID (c36f613f-21ed-4ce0-896a-66492bca2487) on both the search line and the vmlinuz line. That might be correct if you are using the same partition for / and /boot. But if you have only one partition, I expect that your vmlinuz and initrd.img files would be under /boot/{vmlinuz,initrd.img}, not under /. I’m not familiar with silverblue and it is possible that you’ve placed your kernel and initrd.img (or links to them) at the root of your root partition, but it looks like you might have a slight configuration error – root=UUID=… should probably be a different value from --set=root …

Also, if /dev/sdb2 is LVM and that is your root partition, I think there may be some extra kernel options that are needed to get it to mount. I don’t know what they are off hand though.