Screwed Up The Partitions Trying To Upgrade MX Linux

jaje · Post by **jaje** » Sun Oct 31, 2021 2:13 am

Puppy's my main everyday OS, but I have several other partitions with other Linux distros plus the original Windows 10. When trying to upgrade MX Linux from 19 to 21, I remembered that it would't boot from Puppy's Grub4Dos (64 bit vs 32 bit?), so I went to Puppy Package Manager and found Grub2 and installed and ran it. Maybe I'm getting senile.

Now it created an "sda" icon (a folder with a gear on top of it) at the bottom along with the usual "sda1," "sda2," etc. Computer still booted into the Grub4Dos menu, so I ran the "Grub4Dos bootloader config" again (from the frugal installed Puppy on the hard drive and again from a USB flash drive) and it gives me the following error in the grub4dosconfig.log file:

LPART:/dev/sda|vfat|976762584
The first partition starts from: (LBA)
mount-FULL: /mnt/sda: /dev/sda already mounted or mount point busy.
MYPUPPY=sda6/puppy_fossapup64_9.5.sfs
sda6/puppy_fossapup64_9.5.sfs,initrd.gz|puppy_fossapup64_9.5
sda7/puppy_slacko64_7.0.sfs,initrd.gz|puppy_slacko64_7.0
sda5/boot/vmlinuz-5.10.0-9-amd64|Unknown
sda8/initrd.img,/vmlinuz|Debian_GNU/Linux_10_(buster)
sda2/bootmgr|Windows
sda1/menu.lst|Puppy_fossapup64_9.5_(sda6)
sda2/menu.lst|grub2
sda2/bootmgr|Windows

WIN:sda2/bootmgr|Windows
mount-FULL: /mnt/sda: /dev/sda already mounted or mount point busy.
/dev/sda Bootalbe: yes,

Gparted only lists "sda" and gives this warning:

"Unable to detect file system! Possible reasons are:
- The file system is damaged
- The file system is unknown to GParted
- There is no file system available (unformatted)
- The device entry /dev/sda is missing"

What can I do to get back to normal? How to get rid of the superfluous "sda"? The more I learn, the less I know...

Thanks for any advice.

williams2 · Post by **williams2** » Sun Oct 31, 2021 9:07 am

it would't boot from Puppy's Grub4Dos (64 bit vs 32 bit?)

No, I don't think grub4dos supports gpt.

Before UEHI, the BIOS would copy the 512 bytes of the first block of data of a hard drive (the master boot record) to ram and execute it.

UEHI is smarter, and can find files in file systems, and use those files (usually in .boot/) to boot.

I'm not sure, but i don't think Grub should be written to the mbr of a hard drive with a gpt partition table.
I think it writes over the partition table.

it created an "sda" icon

For whatever reason, you seem to have the entire drive formatted (vfat/fat32) like a floppy disk.
/dev/sda is the entire hard drive.
/dev/sda1, /dev/sda2, /dev/sda3 etc etc are partitions of a hard drive.
Each partition can be formatted with a file system.
/dev/sda is not a partition. It should not be formatted so that it contains a file system.

If you format a partition or a floppy disk, it basically erases everything in the partition or in the floppy disk.

PCPARTS:
/dev/sda|vfat|976762584

This shows that /dev/sda, which is the entire drive, is formatted with a vfat file system.
I'm not saying it is, but grub4dos thinks it is.
Something seems to have corrupted the gpt partition table.

You should not try to mount /dev/sda

What can I do to get back to normal? How to get rid of the superfluous "sda"?

If you have the blocks of data from the beginning of the drive backed up somewhere, you could try restoring them.

There might be a program that can repair a damage gpt.
Search for something like "gpt repair"

It's probably better to repair Win10 first, then fix Linux later.
It's possible that an attempted repair of the gpt will cause the Linux partitions to disappear.
You can backup everything on the drive to an external usb drive, before trying any repairs.

I don't know anything about https://www.cgsecurity.org/wiki/TestDisk

snoring_cat · Post by **snoring_cat** » Sun Oct 31, 2021 11:39 am

If you can boot up the computer, probably via Puppy Linux on flash disk, can you please provide the output of the following commands

Code: Select all

fdisk -l /dev/sda
fdisk -l /dev/sdb

If you can mount any of the drives that you had Linux and Windows installed on, please let us know if you can see files on those partitions that were there prior to working on installing MX Linux. Try this command after mounting those partitions, and also post the output from it

Code: Select all

df -Th

I agree with williams2 in that there is a chance that you might have accidentally merged your partitions into one big partition (i.e sda1, sda2, sda3 all got merged into sda). If you did merge your partitions accidentally, we have to find a way to get back your old partitios list, called the partition table. williams2 did explain that there is a hidden section of a disk that isn't merged. This section holds the partition table. So that would explain why you get a grub4dos menu even if you merged all of your data.

Programs like gparted, testdisk, photorec, etc. should allow you to look for and load a backup of your partition table. However using such commands incorrectly can really jumble up your data on your hard drives. Also, we do not know if MX Linux was told to overwrite data that was on your partitions.

The more information that you can supply, the easier it would be to prevent you from having to find a service to do disk partition repair and data recovery.

Regarding Grub

grub4dos uses a file called menu.lst for configuration

grub2 uses a file called grub.cfg for configuration

Even if you have grub2 installed, your hidden section on your disk might still be told to boot up with grub4dos. If you can find he menu.lst and/or grub.cfg (which might be under /boot) files on your hard disk, please attach them to your reply.

jaje · Post by **jaje** » Sun Oct 31, 2021 5:52 pm

I can boot into Puppy (fossapup) on the hard drive (sda6), and, when I tried last night, Slackopup, Debian, and Windows 10. Not MX. I can access all the files on all the partitions exactly as before.

root# fdisk -l /dev/sda
Disk /dev/sda: 931.53 GiB, 1000204886016 bytes, 1953525168 sectors
Disk model: ST1000DM003-1ER1
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: 0x68e6bf3a

Device Boot Start End Sectors Size Id Type
/dev/sda1 63 80324 80262 39.2M de Dell Utility
/dev/sda2 * 81920 50876415 50794496 24.2G 7 HPFS/NTFS/exFAT
/dev/sda3 50876416 260591615 209715200 100G 7 HPFS/NTFS/exFAT
/dev/sda4 260591616 1953523711 1692932096 807.3G 5 Extended
/dev/sda5 260593664 302536703 41943040 20G 83 Linux
/dev/sda6 302538752 344481791 41943040 20G 83 Linux
/dev/sda7 344483840 386426879 41943040 20G 83 Linux
/dev/sda8 386428928 428371967 41943040 20G 83 Linux
/dev/sda9 428374016 470317055 41943040 20G 83 Linux
/dev/sda10 470319104 485523455 15204352 7.3G 82 Linux swap / Solaris
/dev/sda11 485525504 1953523711 1467998208 700G 7 HPFS/NTFS/exFAT

Partition 1 does not start on physical sector boundary.

root# fdisk -l /dev/sdb
Disk /dev/sdb: 232.91 GiB, 250059348992 bytes, 488397166 sectors
Disk model: Storage Device
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x000afac4

Device Boot Start End Sectors Size Id Type
/dev/sdb1 2048 488396799 488394752 232.9G b W95 FAT32

root# df -Th
Filesystem Type Size Used Avail Use% Mounted on
/dev/sda6 ext4 20G 7.1G 12G 38% /initrd/mnt/dev_save
tmpfs tmpfs 7.9G 485M 7.4G 7% /initrd/mnt/tmpfs
unionfs aufs 20G 7.1G 12G 38% /
/dev/loop0 squashfs 97M 97M 0 100% /initrd/pup_ro2
/dev/loop1 squashfs 40M 40M 0 100% /initrd/pup_f
/dev/loop2 squashfs 27M 27M 0 100% /initrd/pup_z
/dev/loop3 squashfs 229M 229M 0 100% /initrd/pup_a
devtmpfs devtmpfs 3.9G 0 3.9G 0% /dev
shmfs tmpfs 1.8G 56M 1.7G 4% /dev/shm
/dev/loop4 squashfs 90M 90M 0 100% /initrd/pup_ro3
/dev/loop5 squashfs 111M 111M 0 100% /initrd/pup_ro4
/dev/sda2 fuseblk 25G 12G 14G 46% /mnt/sda2
/dev/sda1 vfat 40M 372K 39M 1% /mnt/sda1
/dev/sda3 fuseblk 100G 83G 18G 83% /mnt/sda3
/dev/sda5 ext4 20G 6.0G 13G 33% /mnt/sda5
/dev/sda7 ext4 20G 544M 19G 3% /mnt/sda7
/dev/sda8 ext4 20G 11G 8.4G 56% /mnt/sda8
/dev/sda9 ext4 20G 44M 19G 1% /mnt/sda9
/dev/sda11 fuseblk 700G 210G 491G 30% /mnt/sda11

Attached are (from sda1 where they normally reside): menu.lst, menu-advanced.lst, and menu-2021-05-23-203532.lst (I had to rename to text file to upload.)
It's not letting me upload the grub.cfg files on sda2. I will try in a new message...

jaje · Post by **jaje** » Sun Oct 31, 2021 5:55 pm

Here are the grub files that were on sda2. The menu.lst has on old date on it, so it may be irrelevant.

Thanks for taking the time!

williams2 · Post by **williams2** » Sun Oct 31, 2021 6:44 pm

I see that your partition table is dos not gpt
That seems strange to me, with Win10 installed.
If Win10 came with the machine, I would expect gpt.

Code: Select all

root# fdisk -l /dev/sda
Disklabel type: dos

And it shows that all of your Linux partitions are logical partitions in an extended partition (sda4)

Code: Select all

/dev/sda4 260591616 1953523711 1692932096 807.3G 5 Extended
/dev/sda5 260593664 302536703 41943040 20G 83 Linux
/dev/sda6 302538752 344481791 41943040 20G 83 Linux
/dev/sda7 344483840 386426879 41943040 20G 83 Linux
/dev/sda8 386428928 428371967 41943040 20G 83 Linux
/dev/sda9 428374016 470317055 41943040 20G 83 Linux
/dev/sda10 470319104 485523455 15204352 7.3G 82 Linux swap / Solaris
/d

Which is what you would expect for a dos (not gpt) partition table.

So you don't want to use tools to fix the gpt, because you don't have a gpt.

I think there are some corrupted bytes that makes it look like you have /dev/sda with a vfat file system
but you don't have that (and should not have that) and trying to mount /dev/sda fails
which is good because if you mounted /dev/sda rw it could corrupt all the file systems on the entire drive.

So what you need is some way to fix the dos partition table,
which should be in the MBR (the first 512 bytes of the drive)
Very often when a boot loader like grub installs, and writes to the MBR, it will backup the MBR first, automatically. If you have the MBR backup somewhere, you could just write it back.

snoring_cat · Post by **snoring_cat** » Sun Oct 31, 2021 10:21 pm

Hmmm,

williams2, do you have a suggestion as to how the sda reference can be removed? It looks like MX modified the MBR. jaje, glad that you have your data! That was a little scary. I know of ways to address your problem, but don't know how to relay commands you should run. One wrong command and your hard drives get jumbled. I can only say that testdisk and gparted can be used. But whatever you do, this is the time you do complete backups...before you make changes to your MBR, partition table, etc.

williams2 · Post by **williams2** » Sun Oct 31, 2021 11:25 pm

williams2, do you have a suggestion as to how the sda reference can be removed?

I've never has this exactly happen to me.

I don't know exactly which bits and bytes determine that sda is considered to be a super floppy formatted with vfat.

It's possible that chkdsk.exe could fix it. Or not.

It's possible that any attempt to repair the mbr would erase everything.

Using Win10 to restore the MBR (not to gpt) might fix the partition table,
(Grub can restore an MS compatible mbr, even if Win10 can't.)
It would erase part of grub, but grub can be reinstalled later.
I have syslinux on a usb flash drive, which I plug in when I want to boot Puppy.

There are a number of programs that supposedly might be able to fix such problems.
For example, https://www.diskgenius.com/
I do not know anything about diskgenius.

jaje · Post by **jaje** » Mon Nov 01, 2021 12:36 am

williams2 wrote: Sun Oct 31, 2021 6:44 pm
I see that your partition table is dos not gpt
That seems strange to me, with Win10 installed.
If Win10 came with the machine, I would expect gpt.

I think it originally came with Win7 and updated at some point to Win10.

williams2 wrote: Sun Oct 31, 2021 6:44 pm
And it shows that all of your Linux partitions are logical partitions in an extended partition (sda4)
Which is what you would expect for a dos (not gpt) partition table.

That is correct. Windows was using up the first three partitions so I shrank the main Windows partition and made the fourth one an extended partition with five logical partitions for Linux, a Linux swap partition, and the rest for my files.

williams2 wrote: Sun Oct 31, 2021 6:44 pm
Very often when a boot loader like grub installs, and writes to the MBR, it will backup the MBR first, automatically. If you have the MBR backup somewhere, you could just write it back.

There is a "sda_mbr.bak" dated 30 Oct 2021 in sda2. (Also one in sda1 from back in May.)

snoring_cat wrote: Sun Oct 31, 2021 10:21 pm
But whatever you do, this is the time you do complete backups...before you make changes to your MBR, partition table, etc.

Yes, I think that is what I'll be doing for the next few days!
Thanks!

williams2 · Post by **williams2** » Mon Nov 01, 2021 3:49 am

There is a "sda_mbr.bak" dated 30 Oct 2021 in sda2

That looks promising.
That is probably the mbr before grub changed it.
If so, you can write it back, and hopefuly, fix the problem.

First, you should backup the mbr in case writing over it makes the situation worse.
Something like:
dd if=/dev/sda of=sda_mbr2.bak bs=512 count=1
or
dd if=/dev/sda of=sda_mbr2.bak bs=4096 count=1

And you should copy the mbr backups to a backup drive
(preferably a bootable Puppy usb flash drive)
because, if restoring the mbr doesn't work properly, then the mbr bak files (and any other files) may no longer exist.

Anyway, you would restore the mbr from a bak file like this:
dd if=sda_mbr.bak of=/dev/sda bs=512 count=1

rcrsn51 · Post by **rcrsn51** » Mon Nov 01, 2021 12:14 pm

It sounds like the MX updater got confused and flagged the MBR as "protective".

jaje · Post by **jaje** » Wed Nov 10, 2021 2:21 pm

It's been a while, I went out of town last weekend and everybody needs fires put out at work.

williams2 wrote: Mon Nov 01, 2021 3:49 am
Anyway, you would restore the mbr from a bak file like this:
dd if=sda_mbr.bak of=/dev/sda bs=512 count=1

I tried that and it's still the same. This may be what's happening:

(From https://www.howtogeek.com/193669/whats- ... g-a-drive/ )

"GPT drives tend to include a “protective MBR.” This type of MBR says that the GPT drive has a single partition that extends across the entire drive. If you try to manage a GPT disk with an old tool that can only read MBRs, it will see a single partition that extends across the entire drive. This protective MBR ensures the old tools won’t mistake the GPT drive for an unpartitioned drive and overwrite its GPT data with a new MBR. In other words, the protective MBR protects the GPT data from being overwritten."

Some things (like gparted and partimage) only see the whole drive sda, while others see individual partitions. I'm still backing up - it's not been easy. Clonezilla (I tried a few versions) hangs up after the first few screens. I was able to pudd a couple of partitions to files last night.

Another thing, no matter which OS I'm booting into, it takes maybe 5-10 minutes to boot.

jaje · Post by **jaje** » Wed Nov 10, 2021 2:32 pm

rcrsn51 wrote: Mon Nov 01, 2021 12:14 pm
It sounds like the MX updater got confused and flagged the MBR as "protective".

Yes, I missed your post before I my previous post.

rcrsn51 · Post by **rcrsn51** » Wed Nov 10, 2021 2:59 pm

If restoring the backup MBR did not fix this, then I don't know how to "unflag" it.

Maybe run Gparted and see if there is a "protective" flag that you can remove.

jaje · Post by **jaje** » Fri Nov 12, 2021 1:52 pm

Now that I've almost got everything backed up, would it be a good idea to just switch to GPT? In my BIOS there's a setting where you can choose Legacy or UEFI so I'm guessing it's possible?

Specifically, if I pudd-copied Win10 (or Fossapup, etc.) to a file from the Legacy MBR system and then restored it after I partitioned to GPT, would it work with no (or minimal) problems?

Thanks,
John

rcrsn51 · Post by **rcrsn51** » Fri Nov 12, 2021 2:19 pm

Legacy vs UEFI is a separate issue from MBR vs GPT.

In the original setup, who provided the primary bootloader - Windows, MX, Puppy?

jaje · Post by **jaje** » Fri Nov 12, 2021 4:08 pm

Puppy provided the primary bootloader originally.

Prior to that it was a Windows-only machine. I shrank the Windows partition and added the others when I got it second hand when my company closed.

rcrsn51 · Post by **rcrsn51** » Fri Nov 12, 2021 5:09 pm

Since your Windows install started in a Legacy Mode setup, I doubt if you can restore its backup image file into a UEFI boot framework.

Reformatting the hard drive as GPT would get rid of the extended partition and all its logical volumes, but there is a catch. Grub4Dos won't work with GPT, so you would have to switch your primary bootloader to GRUB2.

In the DebLive Starter Kit, this is a routine procedure, but I don't know how easy it is in Puppy.

mikeslr · Post by **mikeslr** » Fri Nov 12, 2021 6:45 pm

rcrsn51 wrote: Fri Nov 12, 2021 5:09 pm
Since your Windows install started in a Legacy Mode setup, I doubt if you can restore its backup image file into a UEFI boot framework.

Reformatting the hard drive as GPT would get rid of the extended partition and all its logical volumes, but there is a catch. Grub4Dos won't work with GPT, so you would have to switch your primary bootloader to GRUB2.

In the DebLive Starter Kit, this is a routine procedure, but I don't know how easy it is in Puppy.

I think shinobar's recently published Grub2config, viewtopic.php?p=29703#p29703 can handle it. But, best to post, asking.

jaje · Post by **jaje** » Sun Nov 14, 2021 2:13 am

I tried grub2config and it seems to have cleared up the slow booting, but I still have the extra "sda" drive.
Below, gdisk knows I have MBR only. When I hit "r" for Recovery & Transformation" menu, and then "o" for "Print protective MBR data" it looks like it thinks there is one partition over the entire disk.

root# gdisk /dev/sda
GPT fdisk (gdisk) version 1.0.4

Partition table scan:
MBR: MBR only
BSD: not present
APM: not present
GPT: not present

***************************************************************
Found invalid GPT and valid MBR; converting MBR to GPT format
in memory. THIS OPERATION IS POTENTIALLY DESTRUCTIVE! Exit by
typing 'q' if you don't want to convert your MBR partitions
to GPT format!
***************************************************************

Exact type match not found for type code DE00; assigning type code for
'Linux filesystem'

Command (? for help): r

Recovery/transformation command (? for help): o

Disk size is 1953525168 sectors (931.5 GiB)
MBR disk identifier: 0x00000000
MBR partitions:

Number Boot Start Sector End Sector Status Code
1 1 1953525167 primary 0xEE

Recovery/transformation command (? for help):

baldronicus · Post by **baldronicus** » Sun Nov 14, 2021 4:33 am

I don't know how to help, and the following may not be relevant, but I thought I should mention it just in case.
When I had tried installing (i.e. not upgrading) MX21, the new installer didn't seem to want to know about extended partitions. I can't remember the exact messages (and I might have misinterpreted things), but I think if it encountered an MSDOS partition setup with more than four partitions it would want to reformat to a GPT scheme. However, it gave warnings that that was what it was going to do. I don't know if those warnings might appear with an upgrade, but you'd hope so.
However, given your problem ....

Thanks.

[Edit- I think I might be confusing things- was the change noticed after using the Puppy Grub2, or after upgrading MX? Either way, this doesn't help your current situation. Apologies for distracting from the real help.]

[Edit2- Hopefully it won't come to it, but if you have to reformat the drive, would you be able to image your Windows 10 installation, setup the drive with GPT, add a BIOS-GRUB partition (small, I think spec is 2MB (but I make it 4), unformatted, partition with the BIOS-GRUB flag) and then use Grub2 as the main bootloader to boot Windows and the larger Linux setups? There would be the problem of booting the Pups (unless maybe Shinobar's Grub2Config could be used in this situation (I haven't tried it yet)). I tend to use the 40_custom approach, but others setup their own configs under 41_custom as it is less annoying updating things (I haven't got there yet). Another approach might be FrugalPup. I think when FrugalPup is used on a GPT partitioned drive it sets the boot option in the boot menu rather than on the drive. This way you might be able to access the Pups via hitting the relevant Boot Menu function key on startup. Another option might be the Legacy boot through Grub2 option that rcrcn51 has described in the past (apologies, I can't remember in which thread).
Others might have better approaches.

However, if it does come to it, I would await other's opinions regarding any of this, as I have been fortunate, and haven't had to deal with Windows10 (it is, however, good that others have pursued things in this regard). Hence, I don't know the intricacies in dealing with it. Thanks.]

jaje · Post by **jaje** » Mon Nov 15, 2021 1:36 pm

baldronicus wrote: Sun Nov 14, 2021 4:33 am
[Edit- I think I might be confusing things- was the change noticed after using the Puppy Grub2, or after upgrading MX? Either way, this doesn't help your current situation. Apologies for distracting from the real help.]

I noticed it after using the Puppy Grub2, the upgrade to MX didn't change anything - I just couldn't boot into it.

I'm still digesting the rest of your suggestions. It seems if I can only delete the superfluous sda partition, it may be all right. When I try to delete it in gdisk it doesn't recognize the sda, just the sda1, sda2, etc. But still:

jaje wrote: Sun Nov 14, 2021 2:13 am
When I hit "r" for Recovery & Transformation" menu, and then "o" for "Print protective MBR data" it looks like it thinks there is one partition over the entire disk.

Gparted ONLY recognizes the sda, and recognized it as "Unknown type".

rcrsn51 · Post by **rcrsn51** » Mon Nov 15, 2021 2:16 pm

jaje wrote: Sun Oct 31, 2021 5:52 pm
I can boot into Puppy (fossapup) on the hard drive (sda6), and, when I tried last night, Slackopup, Debian, and Windows 10. Not MX. I can access all the files on all the partitions exactly as before.

If that statement is still true, I think that you should leave well enough alone and not worry about the MX.

The chances of making things worse are too great.

mikeslr · Post by **mikeslr** » Mon Nov 15, 2021 6:17 pm

Ditto what rcrsn51 wrote. But this is also the time to begin thinking about obtaining an external drive (or hard-drive with USB-Adapter) to use to backup your Puppys and Windows; or at least your data. At some point you may want to try a new Linux Distro or unscramble the mess you've got. If things go bonkers you'll be happy that you can recover.

jaje · Post by **jaje** » Tue Nov 16, 2021 11:39 pm

mikeslr wrote: Mon Nov 15, 2021 6:17 pm
Ditto what rcrsn51 wrote. But this is also the time to begin thinking about obtaining an external drive (or hard-drive with USB-Adapter) to use to backup your Puppys and Windows; or at least your data. At some point you may want to try a new Linux Distro or unscramble the mess you've got. If things go bonkers you'll be happy that you can recover.

Yes, I've got everything backed up on an external drive, but I think I'm getting another one to have a second backup just in case. Then I'll feel free to experiment.

Puppy Linux Discussion Forum

Screwed Up The Partitions Trying To Upgrade MX Linux

Screwed Up The Partitions Trying To Upgrade MX Linux

Re: Screwed Something Up When Trying To Upgrade MX

Re: Screwed Something Up When Trying To Upgrade MX

Re: Screwed Something Up When Trying To Upgrade MX

Re: Screwed Up The Partitions Trying To Upgrade MX Linux

Re: Screwed Up The Partitions Trying To Upgrade MX Linux

Re: Screwed Up The Partitions Trying To Upgrade MX Linux

Re: Screwed Up The Partitions Trying To Upgrade MX Linux

Re: Screwed Up The Partitions Trying To Upgrade MX Linux

Re: Screwed Up The Partitions Trying To Upgrade MX Linux

Re: Screwed Up The Partitions Trying To Upgrade MX Linux

Re: Screwed Up The Partitions Trying To Upgrade MX Linux

Re: Screwed Up The Partitions Trying To Upgrade MX Linux

Re: Screwed Up The Partitions Trying To Upgrade MX Linux

Re: Screwed Up The Partitions Trying To Upgrade MX Linux

Re: Screwed Up The Partitions Trying To Upgrade MX Linux

Re: Screwed Up The Partitions Trying To Upgrade MX Linux

Re: Screwed Up The Partitions Trying To Upgrade MX Linux

Re: Screwed Up The Partitions Trying To Upgrade MX Linux

Re: Screwed Up The Partitions Trying To Upgrade MX Linux

Re: Screwed Up The Partitions Trying To Upgrade MX Linux

Re: Screwed Up The Partitions Trying To Upgrade MX Linux

Re: Screwed Something Up When Trying To Upgrade MX

Re: Screwed Up The Partitions Trying To Upgrade MX Linux

Re: Screwed Up The Partitions Trying To Upgrade MX Linux