# Odd boot problem after installation **URL:** \ **Category:** Rocky Linux Help & Support\ **Tags:** rocky-linux-9\ **Created:** [September 21, 2023, 9:32pm UTC](https://forums.rockylinux.org/t/odd-boot-problem-after-installation/11370 "2023-09-21T21:32:57Z")\ **Posts on this page:** 6\ **Page:** 1
**Author:** ![boconnell22](https://avatars.discourse-cdn.com/v4/letter/b/eb9ed0/32.png) [@boconnell22](https://forums.rockylinux.org/u/boconnell22)\ **Post date:** [September 21, 2023, 9:32pm UTC](https://forums.rockylinux.org/t/odd-boot-problem-after-installation/11370/1 "2023-09-21T21:32:57Z")
Hello. I have installed Rocky 9.2 and I am experiencing a strange /boot partition problem. After installation (done via kickstart) when powered down, I add a second disk. Here is my basic kickstart config: ```auto # Generated using Blivet version 3.6.0 ignoredisk --only-use=sda # Partition clearing information clearpart --none --initlabel # Disk partitioning information part pv.515 --fstype="lvmpv" --ondisk=sda --size=1571839 part /boot --fstype="xfs" --ondisk=sda --size=1024 ``` When the install is completed, and powered off, add the second disk and boot the server back up, my boot partition seems to have been moved to /dev/sdb1. How can that be? ```auto [root@mars ~]# df -h /boot Filesystem Size Used Avail Use% Mounted on /dev/sdb1 1014M 273M 742M 27% /boot [root@mars ~]# cat /etc/fstab | grep boot UUID=79c66ebc-996a-4fe4-9569-0969b403bf1f /boot xfs defaults 0 0 ``` The install happens with only a single disk. How does it manage to carve out a slice of the second disk? I have the second disk sticktly for data, and thus the second disk becomes useless. Here are my vm options for the server: ![image](https://us1.discourse-cdn.com/flex020/uploads/rockylinux/original/2X/d/d3d1677d671c0f61df73099e60cd09e093e4ab2e.jpeg) Anything obvious I am missing? Any help would be greatly appreciated. Billy ---
**Author:** ![jbkt23](https://avatars.discourse-cdn.com/v4/letter/j/9fc29f/32.png) [@jbkt23](https://forums.rockylinux.org/u/jbkt23)\ **Post date:** [September 22, 2023, 1:03am UTC](https://forums.rockylinux.org/t/odd-boot-problem-after-installation/11370/2 "2023-09-22T01:03:48Z")
With systemd the assignment of /dev/sdx is arbitrary and done at boot. That is why you must use the UUID for all your mount points. I have three disks and it is common for sda to be assigned to a different disk than the prior boot. ---
**Author:** ![jlehtone](https://avatars.discourse-cdn.com/v4/letter/j/e9a140/32.png) [@jlehtone](https://forums.rockylinux.org/u/jlehtone)\ **Post date:** [September 22, 2023, 7:02am UTC](https://forums.rockylinux.org/t/odd-boot-problem-after-installation/11370/3 "2023-09-22T07:02:39Z")
The installer does add UUID-based entries into fstab, _except_ for LVM volumes, which are referred to with `/dev/mapper/vg-lv` style paths. I presume that the LVM auto-detects PVs and assembles VGs and LVs based on metadata within PVs. That way the _devname_ is not critical. * * * One can run: ```auto lsblk lsblk -f blkid ``` and look into `/dev/disk/by-*` to see how kernel sees things today. ---
**Author:** ![boconnell22](https://avatars.discourse-cdn.com/v4/letter/b/eb9ed0/32.png) [@boconnell22](https://forums.rockylinux.org/u/boconnell22)\ **Post date:** [September 23, 2023, 4:44pm UTC](https://forums.rockylinux.org/t/odd-boot-problem-after-installation/11370/4 "2023-09-23T16:44:12Z")
Thanks for the tips/pointers. I was unaware that /dev/sdx can be arbitrary, I had never seen that before. With that in mind, now I am trying to rewrite some scripts for automation and apparently, I can get the UUID, but then it seems to change during the script run. First I determine which disk is the boot disk, no problem. Then on the unformatted disk: ```auto mkfs.xfs -f /dev/sda meta-data=/dev/sda isize=512 agcount=4, agsize=16777216 blks = sectsz=512 attr=2, projid32bit=1 = crc=1 finobt=1, sparse=1, rmapbt=0 = reflink=1 bigtime=1 inobtcount=1 data = bsize=4096 blocks=67108864, imaxpct=25 = sunit=0 swidth=0 blks naming =version 2 bsize=4096 ascii-ci=0, ftype=1 log =internal log bsize=4096 blocks=32768, version=2 = sectsz=512 sunit=0 blks, lazy-count=1 realtime =none extsz=4096 blocks=0, rtextents=0 Discarding blocks...Done. ``` Then get the UUID of the disk, in this case /dev/sda: ```auto uuid=$(ls -l /dev/disk/by-uuid/ | grep sda | awk '{print $9}') sets uuid=12aa9e34-e0cc-4b45-97f9-63e6198dffce ``` And make the entry into /etc/fstab: ```auto UUID=12aa9e34-e0cc-4b45-97f9-63e6198dffce /data xfs defaults 0 0 ``` reload systemctl daemon and try to mount the partition. ```auto mount: /data: can't find UUID=12aa9e34-e0cc-4b45-97f9-63e6198dffce. ``` What, why? Looks like the UUID is changed: ```auto ls -l /dev/disk/by-uuid/ | grep sda | awk '{print $9}' 1156dadc-4014-46ff-9cf5-55632cfc2ff2 ``` I can then mount that manually and it is fine. Somewhere in the process I am missing something. ---
**Author:** ![jbkt23](https://avatars.discourse-cdn.com/v4/letter/j/9fc29f/32.png) [@jbkt23](https://forums.rockylinux.org/u/jbkt23)\ **Post date:** [September 24, 2023, 12:26pm UTC](https://forums.rockylinux.org/t/odd-boot-problem-after-installation/11370/5 "2023-09-24T12:26:07Z")
I’m going to guess that immediately after making the file system on sda that the information in /dev/ is stale and the UUID that you see first is that of sda1 prior to making the new file system. So you would need to rescan the devices before running your command to get the UUID and populate fstab. Another thing that troubles me is that usually you create a file system on a partition of a device not the device itself even if the partition spans the entire device. So the command should be: mkfs.xfs -f /dev/sda1 This also could be confusing the results of your script > [@boconnell22](#): > > `mkfs.xfs -f /dev/sda` ---
**Author:** ![system](https://us1.discourse-cdn.com/flex020/uploads/rockylinux/original/1X/91b7219eec10e30013422e4df76c1d898711a5d5.svg) [@system](https://forums.rockylinux.org/u/system)\ **Post date:** [November 23, 2023, 12:26pm UTC](https://forums.rockylinux.org/t/odd-boot-problem-after-installation/11370/6 "2023-11-23T12:26:43Z")
This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.