Why does changing a device UUID prevent boot?
While trying to recover my ec2 instance, I noticed I could not mount the root volume of that instance on other machine without generating a new UUID using
xfs_admin -U generate /dev/xdfg.
(This is due to a the system saying it couldn't mount the drive due to having a duplicate UUID, I still don't know why it said that)
This allowed me to access the volume. However, when attempting to mount it back and boot on the original ec2 instance the boot fails and produced a
unknown filesystem error and prompted to use grub rescue.
To resolve this, I mounted the drive back on the secondary machine and changed its UUID back to it's original, luckily I had it in my console history.
xfs_admin -U xxxxxxxx-xxxx-Mxxx-Nxxx-xxxxxxxxxxxx /dev/xdfg
This allowed me to boot back into the machine.
Question
So for the sake of curiosity what about the UUID prevents the system to boot? When mounted on a separate machine with both UUID, the system knew that the filesystem was xfs.
amazon-ec2 aws xfs
asked Feb 7 at 16:30
KaitoKaito
1062
|
show 1 more comment
While trying to recover my ec2 instance, I noticed I could not mount the root volume of that instance on other machine without generating a new UUID using
xfs_admin -U generate /dev/xdfg.
(This is due to a the system saying it couldn't mount the drive due to having a duplicate UUID, I still don't know why it said that)
This allowed me to access the volume. However, when attempting to mount it back and boot on the original ec2 instance the boot fails and produced a
unknown filesystem error and prompted to use grub rescue.
To resolve this, I mounted the drive back on the secondary machine and changed its UUID back to it's original, luckily I had it in my console history.
xfs_admin -U xxxxxxxx-xxxx-Mxxx-Nxxx-xxxxxxxxxxxx /dev/xdfg
This allowed me to boot back into the machine.
Question
So for the sake of curiosity what about the UUID prevents the system to boot? When mounted on a separate machine with both UUID, the system knew that the filesystem was xfs.
amazon-ec2 aws xfs
asked Feb 7 at 16:30
KaitoKaito
1062
This sounds like it's not about Ubuntu. If true, please move the question to unix.stackexchange.com, and delete this question here on AU. Thanks!
– heynnema
Feb 7 at 16:53
Looks like it cannot be deleted as there is an answer. @heynnema
– Kaito
Feb 7 at 18:33
"still don't know why it said that" If new machine and old machine were created from the same source AMI, I would expect them to both have the same UUID on the root volume, from the original AMI snapshot.
– Michael - sqlbot
Feb 8 at 0:55
@Michael-sqlbot UUID's are semi-randomly generated. https://unix.stackexchange.com/questions/284593/understanding-uuid-assignment
– Charles Green
Feb 8 at 6:11
@CharlesGreen of course... but typically, in EC2, virtual machines are initially created by cloning of entire disk images, and not by a format & fresh OS install... so the UUIDs on the disks of two VMs with the same machine image ancestry have a pretty good chance of having been cloned, as well.
– Michael - sqlbot
Feb 8 at 13:25
|
show 1 more comment
While trying to recover my ec2 instance, I noticed I could not mount the root volume of that instance on other machine without generating a new UUID using
xfs_admin -U generate /dev/xdfg.
(This is due to a the system saying it couldn't mount the drive due to having a duplicate UUID, I still don't know why it said that)
This allowed me to access the volume. However, when attempting to mount it back and boot on the original ec2 instance the boot fails and produced a
unknown filesystem error and prompted to use grub rescue.
To resolve this, I mounted the drive back on the secondary machine and changed its UUID back to it's original, luckily I had it in my console history.
xfs_admin -U xxxxxxxx-xxxx-Mxxx-Nxxx-xxxxxxxxxxxx /dev/xdfg
This allowed me to boot back into the machine.
Question
So for the sake of curiosity what about the UUID prevents the system to boot? When mounted on a separate machine with both UUID, the system knew that the filesystem was xfs.
amazon-ec2 aws xfs
asked Feb 7 at 16:30
KaitoKaito
1062
While trying to recover my ec2 instance, I noticed I could not mount the root volume of that instance on other machine without generating a new UUID using
xfs_admin -U generate /dev/xdfg.
(This is due to a the system saying it couldn't mount the drive due to having a duplicate UUID, I still don't know why it said that)
This allowed me to access the volume. However, when attempting to mount it back and boot on the original ec2 instance the boot fails and produced a
unknown filesystem error and prompted to use grub rescue.
To resolve this, I mounted the drive back on the secondary machine and changed its UUID back to it's original, luckily I had it in my console history.
xfs_admin -U xxxxxxxx-xxxx-Mxxx-Nxxx-xxxxxxxxxxxx /dev/xdfg
This allowed me to boot back into the machine.
Question
So for the sake of curiosity what about the UUID prevents the system to boot? When mounted on a separate machine with both UUID, the system knew that the filesystem was xfs.
amazon-ec2 aws xfs
amazon-ec2 aws xfs
asked Feb 7 at 16:30
KaitoKaito
1062
asked Feb 7 at 16:30
KaitoKaito
1062
asked Feb 7 at 16:30
KaitoKaito
1062
asked Feb 7 at 16:30
KaitoKaito
1062
asked Feb 7 at 16:30
KaitoKaito
1062
1062
This sounds like it's not about Ubuntu. If true, please move the question to unix.stackexchange.com, and delete this question here on AU. Thanks!
– heynnema
Feb 7 at 16:53
Looks like it cannot be deleted as there is an answer. @heynnema
– Kaito
Feb 7 at 18:33
"still don't know why it said that" If new machine and old machine were created from the same source AMI, I would expect them to both have the same UUID on the root volume, from the original AMI snapshot.
– Michael - sqlbot
Feb 8 at 0:55
@Michael-sqlbot UUID's are semi-randomly generated. https://unix.stackexchange.com/questions/284593/understanding-uuid-assignment
– Charles Green
Feb 8 at 6:11
@CharlesGreen of course... but typically, in EC2, virtual machines are initially created by cloning of entire disk images, and not by a format & fresh OS install... so the UUIDs on the disks of two VMs with the same machine image ancestry have a pretty good chance of having been cloned, as well.
– Michael - sqlbot
Feb 8 at 13:25
|
show 1 more comment
This sounds like it's not about Ubuntu. If true, please move the question to unix.stackexchange.com, and delete this question here on AU. Thanks!
– heynnema
Feb 7 at 16:53
Looks like it cannot be deleted as there is an answer. @heynnema
– Kaito
Feb 7 at 18:33
"still don't know why it said that" If new machine and old machine were created from the same source AMI, I would expect them to both have the same UUID on the root volume, from the original AMI snapshot.
– Michael - sqlbot
Feb 8 at 0:55
@Michael-sqlbot UUID's are semi-randomly generated. https://unix.stackexchange.com/questions/284593/understanding-uuid-assignment
– Charles Green
Feb 8 at 6:11
@CharlesGreen of course... but typically, in EC2, virtual machines are initially created by cloning of entire disk images, and not by a format & fresh OS install... so the UUIDs on the disks of two VMs with the same machine image ancestry have a pretty good chance of having been cloned, as well.
– Michael - sqlbot
Feb 8 at 13:25
This sounds like it's not about Ubuntu. If true, please move the question to unix.stackexchange.com, and delete this question here on AU. Thanks!
– heynnema
Feb 7 at 16:53
This sounds like it's not about Ubuntu. If true, please move the question to unix.stackexchange.com, and delete this question here on AU. Thanks!
– heynnema
Feb 7 at 16:53
Looks like it cannot be deleted as there is an answer. @heynnema
– Kaito
Feb 7 at 18:33
Looks like it cannot be deleted as there is an answer. @heynnema
– Kaito
Feb 7 at 18:33
"still don't know why it said that" If new machine and old machine were created from the same source AMI, I would expect them to both have the same UUID on the root volume, from the original AMI snapshot.
– Michael - sqlbot
Feb 8 at 0:55
"still don't know why it said that" If new machine and old machine were created from the same source AMI, I would expect them to both have the same UUID on the root volume, from the original AMI snapshot.
– Michael - sqlbot
Feb 8 at 0:55
@Michael-sqlbot UUID's are semi-randomly generated. https://unix.stackexchange.com/questions/284593/understanding-uuid-assignment
– Charles Green
Feb 8 at 6:11
@Michael-sqlbot UUID's are semi-randomly generated. https://unix.stackexchange.com/questions/284593/understanding-uuid-assignment
– Charles Green
Feb 8 at 6:11
@CharlesGreen of course... but typically, in EC2, virtual machines are initially created by cloning of entire disk images, and not by a format & fresh OS install... so the UUIDs on the disks of two VMs with the same machine image ancestry have a pretty good chance of having been cloned, as well.
– Michael - sqlbot
Feb 8 at 13:25
@CharlesGreen of course... but typically, in EC2, virtual machines are initially created by cloning of entire disk images, and not by a format & fresh OS install... so the UUIDs on the disks of two VMs with the same machine image ancestry have a pretty good chance of having been cloned, as well.
– Michael - sqlbot
Feb 8 at 13:25
|
show 1 more comment
1 Answer
1
active
oldest
votes
While the part of the question has been already answered here: https://unix.stackexchange.com/questions/137862/why-does-fstab-use-uuid-instead-of-the-actual-file-system-name
I will try to provide another explanation. Currently you are using UUID to mount the root filesystem via fstab. This has one advantage when adding a hardware you always refer to the same disk. When you are changing your boot disk make sure you change the UUID in your fstab. Use blkid command to get a new disk UUID. This is fairly easy when you attach both disks to the same system, get the new UUID and change the UUID in the fstab and before removing the old disk you need to copy the root file system to the new disk.
You may use another way without specifying the UUID in the fstab. You will need to refer for instance to /dev/sda and specify the file system in fstab. You may later on fail when you attach a second drive and the system changes /dev/sda of the root disk to /dev/sdb for instance. This is where the UUID comes handy.
Embedded systems and also some other systems might have the boot directory together with /etc/fstab on their own partition, so when you supply wrong UUID at the boot time and system does not find it, the system will simply not boot.
So before changing the disk, you will need to check the boot partition layout, the fstab location and mounting the devices at the boot time.
answered Feb 7 at 16:55
kukulokukulo
1,435418
The only thing that I would add to this, is that when reading /etc/fstab the system is looking for a drive to mount as '/' - this is the drive which has a 'new' UUID
– Charles Green
Feb 8 at 6:23
add a comment |
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "89"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2faskubuntu.com%2fquestions%2f1116436%2fwhy-does-changing-a-device-uuid-prevent-boot%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
While the part of the question has been already answered here: https://unix.stackexchange.com/questions/137862/why-does-fstab-use-uuid-instead-of-the-actual-file-system-name
I will try to provide another explanation. Currently you are using UUID to mount the root filesystem via fstab. This has one advantage when adding a hardware you always refer to the same disk. When you are changing your boot disk make sure you change the UUID in your fstab. Use blkid command to get a new disk UUID. This is fairly easy when you attach both disks to the same system, get the new UUID and change the UUID in the fstab and before removing the old disk you need to copy the root file system to the new disk.
You may use another way without specifying the UUID in the fstab. You will need to refer for instance to /dev/sda and specify the file system in fstab. You may later on fail when you attach a second drive and the system changes /dev/sda of the root disk to /dev/sdb for instance. This is where the UUID comes handy.
Embedded systems and also some other systems might have the boot directory together with /etc/fstab on their own partition, so when you supply wrong UUID at the boot time and system does not find it, the system will simply not boot.
So before changing the disk, you will need to check the boot partition layout, the fstab location and mounting the devices at the boot time.
answered Feb 7 at 16:55
kukulokukulo
1,435418
The only thing that I would add to this, is that when reading /etc/fstab the system is looking for a drive to mount as '/' - this is the drive which has a 'new' UUID
– Charles Green
Feb 8 at 6:23
add a comment |
While the part of the question has been already answered here: https://unix.stackexchange.com/questions/137862/why-does-fstab-use-uuid-instead-of-the-actual-file-system-name
I will try to provide another explanation. Currently you are using UUID to mount the root filesystem via fstab. This has one advantage when adding a hardware you always refer to the same disk. When you are changing your boot disk make sure you change the UUID in your fstab. Use blkid command to get a new disk UUID. This is fairly easy when you attach both disks to the same system, get the new UUID and change the UUID in the fstab and before removing the old disk you need to copy the root file system to the new disk.
You may use another way without specifying the UUID in the fstab. You will need to refer for instance to /dev/sda and specify the file system in fstab. You may later on fail when you attach a second drive and the system changes /dev/sda of the root disk to /dev/sdb for instance. This is where the UUID comes handy.
Embedded systems and also some other systems might have the boot directory together with /etc/fstab on their own partition, so when you supply wrong UUID at the boot time and system does not find it, the system will simply not boot.
So before changing the disk, you will need to check the boot partition layout, the fstab location and mounting the devices at the boot time.
answered Feb 7 at 16:55
kukulokukulo
1,435418
The only thing that I would add to this, is that when reading /etc/fstab the system is looking for a drive to mount as '/' - this is the drive which has a 'new' UUID
– Charles Green
Feb 8 at 6:23
add a comment |
While the part of the question has been already answered here: https://unix.stackexchange.com/questions/137862/why-does-fstab-use-uuid-instead-of-the-actual-file-system-name
I will try to provide another explanation. Currently you are using UUID to mount the root filesystem via fstab. This has one advantage when adding a hardware you always refer to the same disk. When you are changing your boot disk make sure you change the UUID in your fstab. Use blkid command to get a new disk UUID. This is fairly easy when you attach both disks to the same system, get the new UUID and change the UUID in the fstab and before removing the old disk you need to copy the root file system to the new disk.
You may use another way without specifying the UUID in the fstab. You will need to refer for instance to /dev/sda and specify the file system in fstab. You may later on fail when you attach a second drive and the system changes /dev/sda of the root disk to /dev/sdb for instance. This is where the UUID comes handy.
Embedded systems and also some other systems might have the boot directory together with /etc/fstab on their own partition, so when you supply wrong UUID at the boot time and system does not find it, the system will simply not boot.
So before changing the disk, you will need to check the boot partition layout, the fstab location and mounting the devices at the boot time.
answered Feb 7 at 16:55
kukulokukulo
1,435418
While the part of the question has been already answered here: https://unix.stackexchange.com/questions/137862/why-does-fstab-use-uuid-instead-of-the-actual-file-system-name
I will try to provide another explanation. Currently you are using UUID to mount the root filesystem via fstab. This has one advantage when adding a hardware you always refer to the same disk. When you are changing your boot disk make sure you change the UUID in your fstab. Use blkid command to get a new disk UUID. This is fairly easy when you attach both disks to the same system, get the new UUID and change the UUID in the fstab and before removing the old disk you need to copy the root file system to the new disk.
You may use another way without specifying the UUID in the fstab. You will need to refer for instance to /dev/sda and specify the file system in fstab. You may later on fail when you attach a second drive and the system changes /dev/sda of the root disk to /dev/sdb for instance. This is where the UUID comes handy.
Embedded systems and also some other systems might have the boot directory together with /etc/fstab on their own partition, so when you supply wrong UUID at the boot time and system does not find it, the system will simply not boot.
So before changing the disk, you will need to check the boot partition layout, the fstab location and mounting the devices at the boot time.
answered Feb 7 at 16:55
kukulokukulo
1,435418
answered Feb 7 at 16:55
kukulokukulo
1,435418
answered Feb 7 at 16:55
kukulokukulo
1,435418
answered Feb 7 at 16:55
kukulokukulo
1,435418
1,435418
The only thing that I would add to this, is that when reading /etc/fstab the system is looking for a drive to mount as '/' - this is the drive which has a 'new' UUID
– Charles Green
Feb 8 at 6:23
add a comment |
The only thing that I would add to this, is that when reading /etc/fstab the system is looking for a drive to mount as '/' - this is the drive which has a 'new' UUID
– Charles Green
Feb 8 at 6:23
The only thing that I would add to this, is that when reading /etc/fstab the system is looking for a drive to mount as '/' - this is the drive which has a 'new' UUID
– Charles Green
Feb 8 at 6:23
The only thing that I would add to this, is that when reading /etc/fstab the system is looking for a drive to mount as '/' - this is the drive which has a 'new' UUID
– Charles Green
Feb 8 at 6:23
add a comment |
Thanks for contributing an answer to Ask Ubuntu!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2faskubuntu.com%2fquestions%2f1116436%2fwhy-does-changing-a-device-uuid-prevent-boot%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
This sounds like it's not about Ubuntu. If true, please move the question to unix.stackexchange.com, and delete this question here on AU. Thanks!
– heynnema
Feb 7 at 16:53
Looks like it cannot be deleted as there is an answer. @heynnema
– Kaito
Feb 7 at 18:33
"still don't know why it said that" If new machine and old machine were created from the same source AMI, I would expect them to both have the same UUID on the root volume, from the original AMI snapshot.
– Michael - sqlbot
Feb 8 at 0:55
@Michael-sqlbot UUID's are semi-randomly generated. https://unix.stackexchange.com/questions/284593/understanding-uuid-assignment
– Charles Green
Feb 8 at 6:11
@CharlesGreen of course... but typically, in EC2, virtual machines are initially created by cloning of entire disk images, and not by a format & fresh OS install... so the UUIDs on the disks of two VMs with the same machine image ancestry have a pretty good chance of having been cloned, as well.
– Michael - sqlbot
Feb 8 at 13:25