You are not logged in.
# My partition situation
```paste
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINTS
loop0 7:0 0 173M 0 loop /run/wine
sda 8:0 0 476.9G 0 disk
├─sda1 8:1 0 8G 0 part [SWAP]
├─sda2 8:2 0 97.3G 0 part /
├─sda3 8:3 0 477M 0 part /boot/efi
├─sda4 8:4 0 195.6G 0 part /home
├─sda5 8:5 0 4G 0 part
├─sda6 8:6 0 166.3G 0 part
└─sda7 8:7 0 5.4G 0 part
```
## Description
`sda7 partition` is a partition I created by resizing `sda1 partition` (intended as another swap partition of arch), and `sda5 partition` is the original swap partition of arch.
# Problem
After using `mkswap and swapon` commands to mount sda 7 partition, write the `uuid` of sda 7 to the `/etc/fstab` file of arch. The swap partition expansion is realized normally. **But**, on the night of mounting, I restarted and found that the system boot time slowed down, and found that the uuid of sda 7 partition in `/etc/fstab` changed, which was inconsistent with the uuid of `lsblk -f`. I restarted three times and found that the result was still the same. I didn't understand the reason, but I only knew the solution: `set the label of sda7 partition` and mount it by label.
Tomorrow morning, I found that the uuid did not change again. I continued to restart several times and found that the uuid did not change again.
**Excuse me, what is the reason for the change of uuid, but the uuid did not change after tomorrow morning???**
Last edited by ice345 (2024-10-24 02:49:51)
Offline
**Excuse me, what is the reason for the change of uuid, but the uuid did not change after tomorrow morning???**
I created by resizing `sda1 partition`
I restarted and found
tlr;dr, changing partitions will get them new UUIDs, mostly relevant after the reboot (when they're looked up for fstab mouting)
In doubt, partprobe is your friend (though fdisk etc. do this anyway), so it's basically down to when and where and how *exactly* you looked up the UUID and what you did then.
I only knew the solution: `set the label of sda7 partition` and mount it by label.
You could just have used the proper UUID?
lsblk -f
Please use [code][/code] tags, the BBS predates markdown by approximately your age.
Edit your post in this regard.
Offline
Please use tags, the BBS predates markdown by approximately your age.
Thank you for your reply and your suggestions.
I will explain the situation in a simple way.
After I separated sda7 and
mkswap and swapon
, I never used these commands again. After I used
sudo blkid
to check the uuid of sda7, I wrote this uuid into the fstab file according to the structure of
UUID=46a7022a-0328-4742-a0a3-dcfcfe45f5a3 none swap sw 0 0
. But when I restarted the computer that night, the boot time increased significantly. Then I checked the fstab file and found that there was no change. I used
sudo blkid
again and found that the uuid of sda7 was different from the uuid of fstab. I restarted the computer several times and found that the uuid of sda7 changed when I used sudo blkid to check it.
---
I restarted the computer several times tomorrow morning and found that the uuid of sda7 partition no longer changed when I used sudo blkid command.
Offline
Please use tags, the BBS predates markdown by approximately your age.
Thank you for your reply and your suggestions.I sincerely hope you can read the following brief content.
I will explain the situation in a simple way.
After I separated sda7 and
mkswap and swapon
, I never used these commands again. After I used
sudo blkid
to check the uuid of sda7, I wrote this uuid into the fstab file according to the structure of
UUID=46a7022a-0328-4742-a0a3-dcfcfe45f5a3 none swap sw 0 0
. But when I restarted the computer that night, the boot time increased significantly. Then I checked the fstab file and found that there was no change. I used
sudo blkid
again and found that the uuid of sda7 was different from the uuid of fstab. I restarted the computer several times and found that the uuid of sda7 changed when I used sudo blkid to check it.
---
I restarted the computer several times tomorrow morning and found that the uuid of sda7 partition no longer changed when I used sudo blkid command.
Offline
Well, the on-disk UUID would only change when something writes a new one, e.g. by re-running mkswap.
One case where this does happen automatically is crypttab swap with a random key. Every boot, a new crypt mapping is created and mkswapped. The old swap does not survive because the key is different every time.
Can't think of why it would happen the way you describe, though.
Offline
sudo blkid
blkid may use cached values, though not for UID0 - sure about the sudo?
I restarted the computer several times and found that the uuid of sda7 changed when I used sudo blkid to check it.
You mean you got a new UUID every boot? Did you ever update the fstab? Or respond in any other way to this?
the uuid of sda7 partition no longer changed when I used sudo blkid command
But no longer? What changed?
Offline
Well, the on-disk UUID would only change when something writes a new one, e.g. by re-running mkswap.
I think so too!!
One case where this does happen automatically is crypttab swap with a random key. Every boot, a new crypt mapping is created and mkswapped. The old swap does not survive because the key is different every time.
But I didn't encrypt my swap partition.I do not have /etc/crypttab this file.
lkid may use cached values, though not for UID0 - sure about the sudo?
I am sure that I use the command : sudo blkid.
You mean you got a new UUID every boot? Did you ever update the fstab? Or respond in any other way to this?
Yes, every time I boot up and use the sudo blkid command, I find that the uuid of sda7 changes, but the uuid of the fstab file does not change.
But no longer? What changed?
Yes, no longer. I didn't do anything extra and I also don't understand this.
Offline
New one every run or did you cycle between two values?
(the device files aren't deterministic, so if you've two disks, sda and sdb can change places any time)
Do you still have journals of the affected boots?
Eg.
sudo journalctl -b -5 | curl -F 'file=@-' 0x0.st
and
sudo journalctl -b -6 | curl -F 'file=@-' 0x0.st
to upload the journals from the 5th and 6th last boots
Offline
to upload the journals from the 5th and 6th last boots
Because this happened a few days ago, I can only generate log files for you to view.
Because I had problems using 0x0.st, I used file.iow by time period.
New one every run or did you cycle between two values?
New one when I restart
Offline
Oct 20 00:11:40 YING sudo[4351]: ice : TTY=pts/1 ; PWD=/home/ice ; USER=root ; COMMAND=/usr/bin/mkswap /dev/sda7
Oct 20 00:18:27 YING sudo[5202]: ice : TTY=pts/0 ; PWD=/home/ice ; USER=root ; COMMAND=/usr/bin/mkswap -L myswap /dev/sda7
Oct 20 00:23:33 YING sudo[3717]: ice : TTY=pts/1 ; PWD=/home/ice ; USER=root ; COMMAND=/usr/bin/mkswap /dev/sda7
Well, the on-disk UUID would only change when something writes a new one, e.g. by re-running mkswap.
"Duh"
Please always remember to mark resolved threads by editing your initial posts subject - so others will know that there's no task left, but maybe a solution to find.
Thanks.
Offline
frostschutz wrote:
Well, the on-disk UUID would only change when something writes a new one, e.g. by re-running mkswap.
Thank you for your help and reply!!!:) and
I have sorted out my thoughts. I think I separated sda7 from sda1 before, and wrote the old uuid into the fstab file without checking the latest uuid of sda7 after using mkswap. After that, I restarted and found that the boot became slower. I checked the change of sda7 uuid and mkswap again. (It is my fault. Before, I simply understood mkswap as setting a partition as a swap partition, and did not understand that a new uuid would be generated)
Offline