over_clox comments on Deleting Windows from dual boot Linux/Windows computer

Deleting Windows from dual boot Linux/Windows computer (lemmy.world)

submitted 1 year ago by Demonmariner@lemmy.world to c/linux@lemmy.ml

33 comments fedilink hide all child comments

I have a PC currently configured to dual boot Windows 10 and Linux Mint. I don't need Windows anymore, but Mint is working just fine and I'd rather avoid wiping the whole thing and starting over. Is there a safe way to just get rid of Windows?

[–] over_clox@lemmy.world 2 points 1 year ago* (9 children)

You sound like you know some things that perhaps I don't know.

Slightly different question...

I have a 128GB SSD with Linux Mint MATE 20.3, and I did a full and successful dd backup to my 4TB backup drive.

I have a 100GB external USB hard drive as a test medium for Mint MATE 22.1. I am happy with my test setup, and tried to dd that over to the 128GB SSD. But it wouldn't boot.

I restored the original 128GB SSD image and all is good right now, but why the hell didn't the 100GB>128GB even boot?

Edit: Secure Boot has been disabled all along, screw that headache.

permalink

fedilink

source

parent

hideshow 9 child comments

[–] MentalEdge@sopuli.xyz 6 points 1 year ago* (8 children)

I'm not sure.

AFAIK dd will create an IDENTICAL environment. This is actually not desirable as it will cause UUID conflicts where multiple partitions in a system have the same UUID.

Unless you're restoring something you imaged, dding one disk onto another requires fiddling with the UUIDs and fstab, to make the partitions unique again, so the kernel can tell them apart.

permalink

fedilink

source

parent

hideshow 8 child comments

[–] over_clox@lemmy.world 0 points 1 year ago* (7 children)

The goal was to migrate the 100GB to the 128GB, hopefully expand it, and format the 100GB for future temporary/experimental use.

I never planned on having both drives actively running at the same time, so I don't think there should have been any UUID issues, nor did I run across any errors suggesting such an issue.

But even without expanding the partition, the dd command should have 1:1 copied the 100GB, with space to spare, and be bootable, right? Or so I thought...

I had no problem dd restoring the original 128GB contents though, so at least I didn't bork everything. Also the 100GB external USB is still fine. 👍

🤷

permalink

fedilink

source

parent

hideshow 7 child comments

[–] FauxLiving@lemmy.world 2 points 1 year ago* (last edited 1 year ago) (6 children)

Is your SSD an NVME drive? It's possible that there are non-UUID references (maybe /etc/fstab, or GRUB's config) to the drive that are involved in the boot process.

Maybe it is looking for /dev/sda2, which is correct on the USB disk, but now everything is on /dev/nvme0n1p2.

Solution: Live disk, mount the root and boot partitions, look at the config files and fix the references.

-Or-

It could be that your boot manager has an an entry for the 128GB drive already, just pointed at the wrong .efi file.

If you were originally on Arch for example(, btw) on the 128GB drive. During the installation of the bootloader you would have inserted an entry into the boot manager like:

HD(1,MBR,0xe89l2937594, 0x3823, 0x2398734987)/\EFI\Linux\arch-linux.efi)

But now, since you're on Mint, arch-linux.efi isn't there and the boot manager falls over.

Solution: Live disk, use efibootmgr (https://wiki.archlinux.org/title/Unified_Extensible_Firmware_Interface#efibootmgr), to delete the bad entry (\arch-linux.efi) and add one pointing to the correct file (\mint.efi ? grubx64.efi?).

e: It looks like Mint uses grub, so you could also live disk -> chroot into the environment -> run grub-install (https://wiki.archlinux.org/title/GRUB#Installation) to create the entry. You will still have a 'bad' entry which you can delete with efibootmgr.

permalink

fedilink

source

parent

hideshow 6 child comments

[–] over_clox@lemmy.world 1 point 1 year ago* (last edited 1 year ago) (5 children)

My 128GB is meant as an integrated NVME drive.

Meant to be. I literally cut a service panel hole under the laptop to remove or reinstall it whenever I feel like, or maybe eventually upgrade it.

I've been booting off of other devices, like my 8GB USB flash, 100GB USB HDD, and even Live Boot USB DVD drive. It's actually been very convenient, as I can boot off of whatever the hell I want from USB.

My backup is on a 4TB, so really no worries to me, I can more or less freely experiment around with whatever OS I want, and if it doesn't work right, I can just dd my backup over whatever again, and it just works.

But why doesn't the dd 100GB>128GB work as I'd expect?

Obviously that's not the exact dd command I used, for privacy reasons.

🤷

permalink

fedilink

source

parent

hideshow 5 child comments

[–] FauxLiving@lemmy.world 1 point 1 year ago* (4 children)

There's not many things that are happening at boot: the UEFI Boot Manager points to GRUB which boots your system.

It's almost certainly one of them. The Boot Manager's entries can be fixed with efibootmgr

Most likely you'll also have an issue after it boots because of the swap from being on /dev/sda to /dev/nvme0n1. Your home directory or swap file from the USB drive probably in the fstab like:

/dev/sda3     /home    ext4    options   0 0
/dev/sda4     /swap    swap    options   0 0

Now /dev/sda doesn't exist anymore, because you're on an NVME drive. Now those directories will be at /dev/nvme0n1p3 and /dev/nvme0n1p4. You'll have to edit fstab manually to fix this. If fstab is using UUIDs then it'll work as-is since the partition UUIDs would have been part of the image.

Obviously that’s not the exact dd command I used, for privacy reasons.

Unless you did

dd /dev/urandom /dev/nvme0n1

Then you're probably fine.

permalink

fedilink

source

parent

hideshow 4 child comments

[–] over_clox@lemmy.world 1 point 1 year ago (3 children)

Wait wait, I just double checked.

Apparently my 128GB is a SATA M2.

Fuck I'm still learning this new hardware. 🤦‍♂️

permalink

fedilink

source

parent

hideshow 3 child comments

[–] FauxLiving@lemmy.world 2 points 1 year ago (2 children)

In almost all cases it'll be the same situation. The boot manager is pointing the wrong way. You added the entry to the 100GB drive when you (or whatever Mint uses to install) ran grub-install. You also have an existing entry for the OS on the 128GB drive.

The only way it would have worked seamlessly is if you plugged the 128GB drive into the same connection that the 100GB drive was on AND both the original OS and Mint both use grub AND install it in the same location.

It's an easy fix once you know what to look for (just run efibootmgr --unicode and you'll see the boot entries).

Apparently my 128GB is a SATA M2.

permalink

fedilink

source

parent

hideshow 2 child comments

[–] over_clox@lemmy.world 2 points 1 year ago* (1 child)

I hear ya there, but..

I be getting really confused when one config boots from /dev/sda, but when I have my backup drive attached (not the boot device), it boots from /dev/sdb

Hell I dunno, I probably confused the hell out of my laptop plus myself with my cutout mod reconfiguration, but it's happy to boot from almost anything now.

Almost...

Hey, at least I know how to restore to my previous state from backup via dd 👍

permalink

fedilink

source

parent

hideshow 1 child comment

[–] FauxLiving@lemmy.world 2 points 1 year ago

I be getting really confused when one config boots from /dev/sda, but when I have my backup drive attached (not the boot device), it boots from /dev/sdb

Hell I dunno, I probably confused the hell out of my laptop plus myself with my cutout mod reconfiguration, but it’s happy to boot from almost anything now.

You probably just have multiple boot entries and some are higher priority, so if you plug in a drive it's boot config is higher in the boot order and since it is available it'll boot that.

Just run

efibootmgr --unicode