Linux - SoftwareThis forum is for Software issues.
Having a problem installing a new program? Want to know which application is best for the job? Post your question in this forum.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
I installed Devuan using the default installation procedure on sda. I've had serious problems with Windows 10 walking on my linux installations, especially during Windows updates, so I physically unplugged the linux hard drive and installed Windows 10 on the remaining hard drive, sdb. I figured I would install Windows, run update-grub, it would detect the Windows installation, and everything would be fine.
WRONG!
In the BIOS, I can choose to use the boot loader on either disk, and both work. It's just that grub can't detect Windows. I'd prefer to not change the BIOS settings each time. I've even gone so far as to setup the EFI partition in /etc/fstab. No joy.
I've done some research and I now believe what is wrong is Windows 10 is installed as UEFI and Devuan Linux is installed as legacy. (I hope I used the correct terms here.)
Here's the result of some possibly relevant terminal commands:
update-grub
Code:
root@XXXXX:~# update-grub
Generating grub configuration file ...
Found linux image: /boot/vmlinuz-4.9.0-12-amd64
Found initrd image: /boot/initrd.img-4.9.0-12-amd64
Found linux image: /boot/vmlinuz-4.9.0-11-amd64
Found initrd image: /boot/initrd.img-4.9.0-11-amd64
Found linux image: /boot/vmlinuz-4.9.0-6-amd64
Found initrd image: /boot/initrd.img-4.9.0-6-amd64
done
fdisk -l
Code:
root@XXXXX:~# fdisk -l
Disk /dev/sda: 931.5 GiB, 1000204886016 bytes, 1953525168 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disklabel type: dos
Disk identifier: 0x(hexadecimal)
Device Boot Start End Sectors Size Id Type
/dev/sda1 * 2048 2000895 1998848 976M 83 Linux
/dev/sda2 2000896 66000895 64000000 30.5G 82 Linux swap / Solaris
/dev/sda3 66000896 1066000383 999999488 476.9G 83 Linux
/dev/sda4 1066000384 1953523711 887523328 423.2G b W95 FAT32
Disk /dev/sdb: 465.8 GiB, 500107862016 bytes, 976773168 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disklabel type: gpt
Disk identifier: [hexadecimal and some dashes here]
Device Start End Sectors Size Type
/dev/sdb1 2048 1085439 1083392 529M Windows recovery environment
/dev/sdb2 1085440 1288191 202752 99M EFI System
/dev/sdb3 1288192 1320959 32768 16M Microsoft reserved
/dev/sdb4 1320960 976773119 975452160 465.1G Microsoft basic data
lsblk
Code:
root@XXXXX:~# lsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
sda 8:0 0 931.5G 0 disk
├─sda1 8:1 0 976M 0 part /boot
├─sda2 8:2 0 30.5G 0 part [SWAP]
├─sda3 8:3 0 476.9G 0 part /
└─sda4 8:4 0 423.2G 0 part /SHARED/local
sdb 8:16 0 465.8G 0 disk
├─sdb1 8:17 0 529M 0 part
├─sdb2 8:18 0 99M 0 part /EFI
├─sdb3 8:19 0 16M 0 part
└─sdb4 8:20 0 465.1G 0 part
sr0 11:0 1 1024M 0 rom
I suspect I'm going to have to zero both drives and reinstall Windows first so that Devuan can see the EFI partition and load in UEFI mode, right? Or is there some way to extricate myself from this morass without reinstalling?
This computer is a sandbox more or less. I need to figure out all this UEFI...stuff...before I replace the hard disks on my main desktop with SSDs. Do I need to tell Devuan to install as UEFI or will it figure this out from the existence of the EFI partition?
How do I keep future Windows updates from walking on my Devuan boot? I only use Windows for games that do not have a Linux version, so security isn't that much of an issue, but I'm pretty sure that on occasion, Windows doesn't ask if I want updates, it just steamrollers ahead with them.
I've done some research and I now believe what is wrong is Windows 10 is installed as UEFI and Devuan Linux is installed as legacy. (I hope I used the correct terms here.)
Very likely.
Quote:
I need to figure out all this UEFI...stuff...before I replace the hard disks on my main desktop with SSDs. Do I need to tell Devuan to install as UEFI or will it figure this out from the existence of the EFI partition?
Any half-decent installer should figure it out - however I am neither a Debian nor Devuan user. Leave Win10 alone, it's fine (for some value of "fine"). Reformat your Linux disk to gpt and re-install. Everything should be automatic, and yes, let it find the Win EFI partition - do not allocate another one on your Linux disk.
Don't worry about future Windows updates screwing your boot - with UEFI it's simply a matter of getting into the firmware menus (ala BIOS screens) and changing the default boot entry to whatever you want. No over-written MBR to worry about.
However - it might trash your Linux partitions; I've had this happen. Make sure you have good backups.
and yes, let it find the Win EFI partition - do not allocate another one on your Linux disk.
I had not imagined making another one.
Quote:
Don't worry about future Windows updates screwing your boot - with UEFI it's simply a matter of getting into the firmware menus (ala BIOS screens) and changing the default boot entry to whatever you want. No over-written MBR to worry about.
I had been doing MBR dual boots for years. The first time I ran into this UEFI crap, imagine my surprise when EVERYTHING WAS SCREWED.
Quote:
However - it might trash your Linux partitions; I've had this happen. Make sure you have good backups.
*^#$%*&% Windows. This is why it is only worthy of playing games from narrowminded game companies.
@OP- may be relevant or not, but is Windows hdd the Master, it appears not if sdb, but what do I know? In essence, looks like a hardware oversight, to me.
The /dev/sd[ab] designation is a Linux-ism. Typically (but not always) the hard-disk that was booted is assigned /dev/sda. The days of relying on hardware jumpers for master/slave disk are thankfully long past.
Thanks! I'm sure I used fdisk on the first go-around for the Linux disk. I'll find a utility disc or something that has gparted and use that for both disks next time. I had no idea there were new partitioning schemes. I thought partitioning was partitioning.
Quote:
Originally Posted by sp331yi
@OP- may be relevant or not, but is Windows hdd the Master, it appears not if sdb, but what do I know? In essence, looks like a hardware oversight, to me.
Happily these are SATA drives and thus do not have master and slave jumpers. However, I take your meaning. In my case, the 1 TB drive with Linux on it is plugged into SATA-0 on the motherboard and the 500 GB drive with Windows on it is plugged into SATA-1. If an O/S is installed there, by default, the BIOS will attempt to boot SATA-0 first.
Quote:
Originally Posted by syg00
The /dev/sd[ab] designation is a Linux-ism. Typically (but not always) the hard-disk that was booted is assigned /dev/sda. The days of relying on hardware jumpers for master/slave disk are thankfully long past.
I'm beginning to think I have screwed up this installation enough that zeroing the drives and starting over may be a shorter path to dual boot nirvana than any attempts at repair. While I'm at it, I'm going to put Windows and the local shared partition on the 1 TB at SATA-0 and Devuan on the 500 GB at SATA-1.
I certainly appreciate all the responses! I'm learning a lot here. Thanks for your assistance.
One way to fix without reinstalling
boot into a live iso in efi mode if you booted in efi mode /sys/firmware/efi will exist.
run gdisk /dev/sda in a terminal as root to convert sda from type dos to gpt.
chroot into your system, install the grub-efi package, mount the efi partition to /boot/efi and run grub-install and update-grub
add an entry to your /etc/fstab to mount the efi partition to /boot/efi
Thanks for your help.
Unfortunately, in the current installation, the /boot/EFI partition is on the second, SATA-1 drive, not the first SATA-0 drive that has Linux on it. I'm pretty sure I'd have to resize or rearrange the partitions in order to make room for it on the SATA-0 drive.
Let me make sure I understand correctly...gdisk is a replacement for fdisk, right? It installs a gpt type partition table by default (or only)?
I'm going to try this again from the start; as in wipe the disks and do-over. I'm going to leave the hardware as is, but switch the O/Ss around.
I have high hopes that if Windows (thinks it) owns the entire SATA-0 drive, that future Windows updates won't walk on the ability to boot Linux. And if they do, I suspect I'll be back here with another thread. This time, I'm going to keep track of exactly what I've done so I can document the install. This UEFI business is far more complicated than dual booting was in the MBR days.
I suspect I'm going to have to zero both drives and reinstall Windows first so that Devuan can see the EFI partition and load in UEFI mode, right? Or is there some way to extricate myself from this morass without reinstalling?
You don't have to do anything this drastic at all. All you have to do is convert the Linux installation from legacy BIOS to UEFI. You can easily convert the Linux disc to both GPT and then later UEFI boot by adding an EFI partition. This is a two stage process.
First you can use gdisk to convert a MBR formatted disk to a GPT formatted disk fairly easily. However you will lose anything that was in the "MBR gap" such as the grub2 second stage. To create a temporary BIOS/GPT system you need a BIOS-boot partition for the grub second stage.
Secondly you create about 200 MB of room for an EFI partition. You format this as vfat FAT32 and mount it in your fstab. You then use grub-install to install the efi grub.
The following guide is for Ubuntu. I don't know if the parent Debian would be any different.
Once Devuan is installed with grub-efi you can change your MB firmware to UEFI mode and both OSs will be in the same mode. update-grub will then either detect the Win10 installation or you can create a custom entry in custom.cfg.
Quote:
I'm beginning to think I have screwed up this installation enough that zeroing the drives and starting over may be a shorter path to dual boot nirvana than any attempts at repair.
Get all of this negativity out of your mind. Converting a Linux installation from MBR/BIOS to GPT/UEFI is a fairly straightforward operation.
You don't have to do anything this drastic at all. All you have to do is convert the Linux installation from legacy BIOS to UEFI. You can easily convert the Linux disc to both GPT and then later UEFI boot by adding an EFI partition. This is a two stage process.
First you can use gdisk to convert a MBR formatted disk to a GPT formatted disk fairly easily. However you will lose anything that was in the "MBR gap" such as the grub2 second stage. To create a temporary BIOS/GPT system you need a BIOS-boot partition for the grub second stage.
Secondly you create about 200 MB of room for an EFI partition. You format this as vfat FAT32 and mount it in your fstab. You then use grub-install to install the efi grub.
The following guide is for Ubuntu. I don't know if the parent Debian would be any different.
Once Devuan is installed with grub-efi you can change your MB firmware to UEFI mode and both OSs will be in the same mode. update-grub will then either detect the Win10 installation or you can create a custom entry in custom.cfg.
Get all of this negativity out of your mind. Converting a Linux installation from MBR/BIOS to GPT/UEFI is a fairly straightforward operation.
I certainly appreciate all the positive vibes you are sending my way!
Do I need an EFI partition on EACH disk? One already exists on the SATA-1 (Windows) disk. Once I convert from MBR to GPT, can I just use that one? I'm sure I'd have to tell the BIOS to boot from the SATA-1 drive--the one where Windows has already created the EFI partition.
After I get the dual boot working on this box, I'm likely to zero the drives and start over anyway. I want to install Windows and Devuan correctly on the first pass here before I tackle my main desktop computer. I'm going to do a better job of documenting the steps, too. As I said, this computer is my sandbox. There's nothing to lose or backup here. There's TONS of stuff on my main desktop to save/restore. Both sandbox and desktop are ASUS mobos, so I have high hopes they'll behave more or less the same way.
Do I need an EFI partition on EACH disk? One already exists on the SATA-1 (Windows) disk. Once I convert from MBR to GPT, can I just use that one?
The only problem would be the small 100 MB size. I don't know how much space Windows needs for its bootloader and how much space would be left over for grub-efi. You should mount this efi partition in Devuan and use df -h to determine the free space. Please post the results.
The recommended size for Linux alone is at least 128 MB with some distros recommending 200 MB or more. I'm not sure if Windows and Linux can share a small 100 MB EFI partition.
Quote:
I'm sure I'd have to tell the BIOS to boot from the SATA-1 drive--the one where Windows has already created the EFI partition.
With EFI you don't boot from a drive but from EFI variables stored in NVRAM. You would need to manually select the grub efi loader for the first boot and then use grub-install to put the grub EFI variables first in the list for succeeding boots.
Code:
grub-install --target=x86_64-efi /dev/sda
Reboot.
Change the BIOS from BIOS boot to UEFI boot.
Use the one-time boot menu to force boot the disk. You may have to navigate to the disk -> EFI -> ubuntu -> grubx64.efi.
Re-install GRUB's EFI bootloader to update the UEFI boot selector.
grub-install
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.
