F5F Stay Refreshed Software Operating Systems Removing Disk in Dual Boot Environment

Removing Disk in Dual Boot Environment

Removing Disk in Dual Boot Environment

G
Gabester12
Member
229
12-14-2016, 05:17 AM
#1
I operate on a dual-boot setup with two distinct SSDs. One is connected to my main system via an M2 drive, while the other resides on a SATA drive stored in a removal bay. Typically, I only need the primary drive active and use the secondary occasionally. If I disconnect the removable drive and restart, what occurs? I aim to avoid damaging the boot manager or requiring complex BIOS adjustments. Similarly, if I later plug it back in, will both operating systems recognize their presence? Both are Windows-based systems.
G
Gabester12
12-14-2016, 05:17 AM #1

I operate on a dual-boot setup with two distinct SSDs. One is connected to my main system via an M2 drive, while the other resides on a SATA drive stored in a removal bay. Typically, I only need the primary drive active and use the secondary occasionally. If I disconnect the removable drive and restart, what occurs? I aim to avoid damaging the boot manager or requiring complex BIOS adjustments. Similarly, if I later plug it back in, will both operating systems recognize their presence? Both are Windows-based systems.

A
angelcake_11
Senior Member
540
12-14-2016, 06:22 AM
#2
It all depends. Boot can load directly to an o/s, or it can chain boot (one bootloader can run another bootloader; the BIOS and the bootloaders are essentially micro operating systems). If the disk which is told to boot in BIOS is the same disk you normally go to, then this should be ok, although picking the other disk in that bootloader (e.g., GRUB2) would then fail saying media not found (or something like that). If the disk pulled out was the primary boot device, then it depends on BIOS settings whether it will try the other device or not, and then you have to ask again about settings to know if that other bootloader will find the right partition. This is complicated by the fact that disks can be picked by an ordered numbering, or sometimes by a UUID of sorts; if the bootloaders want a UUID (or partition UUID), then they will tend to find the right disk...but that doesn't guarantee something in the boot chain itself might rely on disk numbering and not some more unique identifier (one UUID is assigned to a disk; another UUID is assigned to each partition, and they are all unique and do not depend on disk bring-up order).
Mostly I would say you can pull the disk while it is turned off (make sure it isn't in any kind of hibernation or sleep mode), and try it. If there is an immediate failure, then you know that the disk you pulled is the one with the boot record. If it works, and then picking the o/s which is still present fails, then it probably chain loads or depends on disk enumeration instead of a UUID. If it still works for one of the picked o/s, then all is good.
What I would say is to go into your BIOS and write down all of the boot details, especially disk order during boot. This shouldn't change by trying to boot, but if it did, then you could put the disk back in and set boot order and it should work again.
There are some cases with Windows where a missing partition might change a setting, most notably with virtual memory (swap). If that disk you removed had any content which Windows recognizes (e.g., an NTFS filesystem and not ext4), then it might mark that device as gone (and you'd have to tell it to use that device again when it is in place). It is just very unpredictable what will or won't work unless you go through the entire boot chain to see disk order, partition type, chain boot versus direct boot, so on. There is risk of a change by trying boot without the device, but that risk is rather minimal if you don't "fix" something while it is missing.
A
angelcake_11
12-14-2016, 06:22 AM #2

It all depends. Boot can load directly to an o/s, or it can chain boot (one bootloader can run another bootloader; the BIOS and the bootloaders are essentially micro operating systems). If the disk which is told to boot in BIOS is the same disk you normally go to, then this should be ok, although picking the other disk in that bootloader (e.g., GRUB2) would then fail saying media not found (or something like that). If the disk pulled out was the primary boot device, then it depends on BIOS settings whether it will try the other device or not, and then you have to ask again about settings to know if that other bootloader will find the right partition. This is complicated by the fact that disks can be picked by an ordered numbering, or sometimes by a UUID of sorts; if the bootloaders want a UUID (or partition UUID), then they will tend to find the right disk...but that doesn't guarantee something in the boot chain itself might rely on disk numbering and not some more unique identifier (one UUID is assigned to a disk; another UUID is assigned to each partition, and they are all unique and do not depend on disk bring-up order).
Mostly I would say you can pull the disk while it is turned off (make sure it isn't in any kind of hibernation or sleep mode), and try it. If there is an immediate failure, then you know that the disk you pulled is the one with the boot record. If it works, and then picking the o/s which is still present fails, then it probably chain loads or depends on disk enumeration instead of a UUID. If it still works for one of the picked o/s, then all is good.
What I would say is to go into your BIOS and write down all of the boot details, especially disk order during boot. This shouldn't change by trying to boot, but if it did, then you could put the disk back in and set boot order and it should work again.
There are some cases with Windows where a missing partition might change a setting, most notably with virtual memory (swap). If that disk you removed had any content which Windows recognizes (e.g., an NTFS filesystem and not ext4), then it might mark that device as gone (and you'd have to tell it to use that device again when it is in place). It is just very unpredictable what will or won't work unless you go through the entire boot chain to see disk order, partition type, chain boot versus direct boot, so on. There is risk of a change by trying boot without the device, but that risk is rather minimal if you don't "fix" something while it is missing.

C
Creeperman3
Senior Member
454
12-19-2016, 06:09 PM
#3
It relies on the specific installation of the operating systems.
If both devices were linked during the second installation, it's likely the boot information was copied to the first drive.
Deleting that drive will prevent a boot.
Alternatively, if each OS was installed with only its own drive connected, everything should work fine.
C
Creeperman3
12-19-2016, 06:09 PM #3

It relies on the specific installation of the operating systems.
If both devices were linked during the second installation, it's likely the boot information was copied to the first drive.
Deleting that drive will prevent a boot.
Alternatively, if each OS was installed with only its own drive connected, everything should work fine.

M
MikeDragon159
Senior Member
661
01-01-2017, 06:31 AM
#4
Thank you for your response. I was concerned about trying without more confirmation. The only available boot method in the BIOS is Windows Boot Manager. My primary boot disk is Disk 0, which holds a UEFI partition and appears as the listed drive in the BIOS. My second drive, Drive 1, is one I occasionally want to remove. Although it has a bootable partition and another Windows OS, it lacks a UEFI partition. Removing and then reinstalling this drive should be fine. The main operating system does not share files like swap or hiberfiles with the second disk (Disk 1). Are you sure I'm in the right?
M
MikeDragon159
01-01-2017, 06:31 AM #4

Thank you for your response. I was concerned about trying without more confirmation. The only available boot method in the BIOS is Windows Boot Manager. My primary boot disk is Disk 0, which holds a UEFI partition and appears as the listed drive in the BIOS. My second drive, Drive 1, is one I occasionally want to remove. Although it has a bootable partition and another Windows OS, it lacks a UEFI partition. Removing and then reinstalling this drive should be fine. The main operating system does not share files like swap or hiberfiles with the second disk (Disk 1). Are you sure I'm in the right?

D
doffenmatta
Junior Member
18
01-01-2017, 07:15 AM
#5
Display a screenshot of your Disk Management window showing both drives connected.
D
doffenmatta
01-01-2017, 07:15 AM #5

Display a screenshot of your Disk Management window showing both drives connected.

Y
yoyoposay
Member
115
01-01-2017, 09:47 AM
#6
If you remove the bootloader disk and the other disk lacks a bootloader (except possibly through a chain for an alternative boot), and if the partitions on the second disk are not paired with the first disk, testing should proceed without issues.

Considering Windows is installed on the first disk, if the second disk doesn’t have a compatible Windows partition (such as NTFS instead of ext4), there will be no changes.

Should a Windows-compatible partition exist on the second disk, and if you created a shortcut on the Windows desktop of the first disk (a matter of legal precision!), that link may break or disappear. Reinserting the second disk could restore it. Shortcuts in this scenario should function normally.

If an application from the first disk was added to the second disk, registry entries might become corrupted. These could either be fixed or remain broken after reinserting the disk. However, if the second disk has no Windows partitions at all, there will be no program registry links, making it acceptable.
Y
yoyoposay
01-01-2017, 09:47 AM #6

If you remove the bootloader disk and the other disk lacks a bootloader (except possibly through a chain for an alternative boot), and if the partitions on the second disk are not paired with the first disk, testing should proceed without issues.

Considering Windows is installed on the first disk, if the second disk doesn’t have a compatible Windows partition (such as NTFS instead of ext4), there will be no changes.

Should a Windows-compatible partition exist on the second disk, and if you created a shortcut on the Windows desktop of the first disk (a matter of legal precision!), that link may break or disappear. Reinserting the second disk could restore it. Shortcuts in this scenario should function normally.

If an application from the first disk was added to the second disk, registry entries might become corrupted. These could either be fixed or remain broken after reinserting the disk. However, if the second disk has no Windows partitions at all, there will be no program registry links, making it acceptable.