You are not logged in.
I'm not going to sugarcoat this. I am VERY new to Arch Linux. We're talking less than 24 hours.
I'm serious about learning the system but my moderate experience with various Ubuntu issues was hardly enough to limp me through the installation. In addition, I'm not going to pretend that something crazy happened here, my knowledge of this system is fragmented bits and pieces and that's exactly why I missed a few big things here.
My build is on a UEFI System, my intention was to establish 3 partitions:
Partition 1, as an EFI System type, with a FAT (32-bit) file structure. I am under the assumption that it is required for an EFI System.
Partition 2, as a Swap Space type, with no file structure because honestly, I wasn't sure what it was supposed to be so I figured it might work or just need to be reconfigured later.
Partition 3, as the root/home directory. To my understanding, this is where the operating system was installed to.
I had no issue creating these partitions, but clearly I ran into issues implementing them because every startup I get a message that the swap partiton failed.
Which isn't all that surprising because checking fstab reveals:
#Static information about the filesystems.
# See fstab(5) for details.
# <file system> <dir> <type> <options> <dump> <pass>
# /dev/sdb3
UUID=6688ddda-c245-4f70-97d2-f80e3fe48fae / ext4 rw,relatime 0 1
Nothing is here other than the home partition. The other thing I notice is the third partition is labeled as sdb3 which is consistant with my installation as my boot-drive was sda. However, a quick fdisk returns:
root@TheArch ~]# fdisk -l
Disk /dev/sda: 238.49 GiB, 256060514304 bytes, 500118192 sectors
Disk model: SanDisk X400 M.2
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: gpt
Disk identifier: 40657620-EA7A-40CE-A029-95D061BE2891
Device Start End Sectors Size Type
/dev/sda1 2048 2099199 2097152 1G EFI System
/dev/sda2 2099200 23070719 20971520 10G Linux swap
/dev/sda3 23070720 500118158 477047439 227.5G Linux filesystem
So the partitions are there, but with the flash drive removed, the locations seem to have reverted back to sda from sdb. Is this an issue or does the UUID prevent one?
And how should I go about resolving my patition Issue? To be honest, how does this computer even work without the EFI partition mounted? I am fairly certain most of this comes from an inadequate knowledge.of drive mounting and structure.
I have tried to search the forums and found solutions in one case or another, however I wasn't able to translate that into a solution as the ones most related to the partition issues seem to be primarily for bad installs, and the Swap solutions are more towards a single missing piece of the partition structure. I really do not know how this system is functioning without the EFI mounted. Any help would be greatly appreciated.
Offline
Welcome to the arch linux forums TheBuilder.
As the fstab is using UUID based identification sdb becoming sda should not be an issue.
You can check the UUID is correct using the output of (# means run as root)
# blkidThe bootloader on the ESP loads the kernel. The kernel loads the initrd. The initrd loads the root filesystem.
systemd (systemd-fstab-generator) converts /etc/fstab in systemd mount units which are required by local-fs.target.
Once the boatloder is finished nothing in the running system needs the ESP for normal use.
You could infact have an empty fstab if you passed the root filesystems mount options to the kernel.
Edit:
I would suggest having a look in the journal for details on the swap failure.
See also Swap#Swap_partition
It could be you have not formatted the swap partition but systemd has detected it even without an fstab entry based on its type GUID.
Oh also please use code tags for commands and their outputs.
Last edited by loqs (2020-02-06 01:06:45)
Offline
Thanks for the welcome to the forum loqs and I appreciate your response. To your point of validating the UUID:
# blkid
/dev/sda1: UUID="64A6-38E6" BLOCK_SIZE="512" TYPE="vfat" PARTUUID="53a57847-2a38-f749-975e-e0db6fa09efa"
/dev/sda2: PARTUUID="ea989999-d8fa-5748-9bc0-e403a85a09fc"
/dev/sda3: UUID="6688ddda-c245-4f70-97d2-f80e3fe48fae" BLOCK_SIZE="4096" TYPE="ext4" PARTUUID="0e1f9918-bebf-4f45-8617-9e7c0b85b629"
So you are correct, the UUID checks out on both ends regardless of if it is labeled as sda3 or sdb3.
To your other point of the ESP, I don't disagree. If the ESP needed to be mounted to run the System, there's no way I could have even made it this far.
The main reason I was concerned is referencing other posts, take this one for example:
Output of cat /etc/fstab
[clinton@clinton-pc ~]$ cat /etc/fstab
# /dev/sda2
UUID=6e8e9616-92e4-4c46-8938-c8781049cdda / ext4 rw,relatime,data=ordered 0 1
# /dev/sda1
UUID=95A2-FED3 /boot vfat rw,relatime,fmask=0022,dmask=0022,codepage=437,iocharset=iso8859-1,shortname=mixed,errors=remount-ro 0 2
# /dev/sda3
UUID=e7c69c75-166e-4212-a3d6-0602ba79c569 /var ext4 rw,relatime,data=ordered 0 2
# /dev/sda5
UUID=3673a968-9361-402b-9e31-0b75bf41c90b /home ext4 rw,relatime,data=ordered 0 2
# /dev/sda4
UUID=6b801c07-b62e-4ae9-8870-8ff8e23eff22 none swap defaults 0 0
It at least appears to me that their sda1 is their ESP. If that is the case, how come theirs shows up as mounted during runtime and mine does not? Also, they have it mounted as boot which seems preferable to index the partition than to just leave it floating at the begining of the storage drive.
I'm going to check the journal and swap#swap_partition now.
Offline
If the fstab has a valid entry that would mount it to /boot then it would be mounted to /boot by systemd.
As you do not have such an entry it is not. Now as /boot contains the kernel and initrd when you next update the kernel package
if you do not have the ESP mounted to /boot the kernel will be written to the boot directory of the root filesystem not the ESP.
This will cause issues on the next boot as the old kernel on the ESP will still be used but the kernel modules located in /usr/lib/modules will be for the new kernel.
The easiest way to ensure the ESP is mounted before such an update is with an fstab entry. EFI_system_partition#Alternative_mount_points
Offline
Dredged up from the depths of the Journal:
Feb 05 21:09:02 TheArch kernel: MDS CPU bug present and SMT on, data leak possible. See https://www.kernel.org/doc/html/latest/ … n/mds.html for more details.
Feb 05 21:09:02 TheArch kernel: TAA CPU bug present and SMT on, data leak possible. See https://www.kernel.org/doc/html/latest/ … abort.html for more details.
Feb 05 21:09:02 TheArch kernel: i8042: PNP: PS/2 appears to have AUX port disabled, if this is incorrect please boot with i8042.nopnp
Feb 05 21:09:02 TheArch kernel: i8042: Warning: Keylock active
Feb 05 21:09:02 TheArch kernel: usb: port power management may be unreliable
Feb 05 21:09:02 TheArch kernel: ACPI: [Firmware Bug]: BIOS _OSI(Linux) query ignored
I mean there are a few random problems sprinkled in there but I couldn't find any log of the Swap activation failure. Maybe I missed it? It's a long log file but I know the swap error comes up in red text on startup before the GUI loads.
Offline
Those messages are irrelevant.
Please post the complete journal, you can use https://wiki.archlinux.org/index.php/Pastebin to directly feed it into a pastebin service.
Offline