[nmglug] UUID

Brian O'Keefe okeefe at cybermesa.com
Sun Aug 10 13:43:53 PDT 2025


Thanks Paul

That seems pretty simple. Still wonder why the motherboard is in upside 
down and screws not accessible to lift it out. Weird.

I actually cloned one drive to another, larger drive. I've done this 
many times and would just take out the old drive and install the cloned 
drive. I did this as I required more data storage. However, I can't 
remove the factory drive as it's not accessible. If I could I would do 
what I said. Clone the computer's drive to a larger drive, swap them out 
and boot happily away with the larger drive. Changing the UUID made 
sense but I didn't know how to do that.

On 8/10/25 12:23PM, Paul wrote:
> It sounds like you may have cloned one partition to the other? This 
> would explain them having the same uuid. You need to change the uuid 
> of one of the partitions.
>
> Let's say you want to change the uuid of /dev/sdb1. Make sure the 
> partition is not mounted, then use:
>
> `sudo tune2fs -U random /dev/sdb1`
>
> That should do it.
>
> This is untested on my part, so please do all the necessary backing 
> up, etc. before trying.
>
> On Sat, Aug 9, 2025 at 1:20 PM Brian O'Keefe <okeefe at cybermesa.com> wrote:
>
>     Hello All
>
>     I'm revisiting an issue I expressed many months (if not years. I
>     have an ASUS laptop in which I wanted to install a 500GB SSD in
>     the vacant bay. I said at the time that the motherboard is up side
>     down so I can't remove the existing drive (a SSD PLUS M.2 NVMe^TM
>     SSD,) and replace with the 500GB SSD drive. I was able to get the
>     regular SSD into the bay and plug it in. It shows up in the BIOS
>     as two separate UUIDs (I have a bootable 313 GB partition and a
>     free space 193 GB partition. When I choose to try and boot the 313
>     GB partition the computer reverts to the drive stick. I checked
>     the UUIs and the 313GB has a different UUID than the internal
>     stick drive but the same as the 193 SSD. So for some reason, even
>     though I change the boot order so the 313GB boots, the computer
>     reverts to the onboard UUID and boots that. I don't know how the
>     193 GB drive got the same UUID but it did.
>
>     When I boot the computer I get the option of booting Ubuntu 20.04
>     but 16.04 is also listed. That is the 313 GB which I was planning
>     to wipe and install 25.04. Perhaps I can wipe it with GParted and
>     try installing 25.04 on it.
>
>     Sorry about the long screed! I'd love to get the 313GB to boot
>     25.04 so I can see if it works on the old cloned 313GB drive with
>     16.04. If that worked I'd have a current back-up (I have one, the
>     unbootable 313GB drive which won't boot). I would then upgrade the
>     313 GB drive after cloning the onboard drive. If the cloned 313GB
>     drive updated then I would have my current mountains of data on
>     the 313GB drive. But if it won't boot now why would it boot later,
>     after all of the work?
>
>     Many thanks if anyone wants to help. If not I completely understand
>
>     Best
>
>     Brian
>
>     _______________________________________________
>     nmglug mailing list
>     nmglug at lists.nmglug.org
>     http://lists.nmglug.org/listinfo.cgi/nmglug-nmglug.org
>
-- 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.nmglug.org/pipermail/nmglug-nmglug.org/attachments/20250810/4017b6ce/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.png
Type: image/png
Size: 3913 bytes
Desc: not available
URL: <http://lists.nmglug.org/pipermail/nmglug-nmglug.org/attachments/20250810/4017b6ce/attachment.png>


More information about the nmglug mailing list