LinuxQuestions.org

LinuxQuestions.org (/questions/)
-   SUSE / openSUSE (https://www.linuxquestions.org/questions/suse-opensuse-60/)
-   -   /boot is not allowing symbolic link creation (https://www.linuxquestions.org/questions/suse-opensuse-60/boot-is-not-allowing-symbolic-link-creation-4175682262/)

rnturn 09-17-2020 12:29 AM

/boot is not allowing symbolic link creation
 
I've got two openSUSE systems: one running Tumbleweed (current as of a few days ago) and another running Leap 15.1 (some pending updates).

The Tumbleweed system will not allow any symbolic links to be created in /boot. This has caused some system updates to fail -- specifically Xen -- because there are missing symbolic links in /boot. I've tried to recreate them ``by hand'' but cannot---even as root (see below). Not having Xen updated is not critical as I selected it during the initial installation but have never used it. Zypper updates have a problem due to the missing symbolic links (which I have to ignore).

Comparing the two systems:

The output of "mount" for the two systems:

Leap:
Code:

# mount | grep boot
/dev/sde1 on /boot/efi type vfat (rw,relatime,fmask=0022,dmask=0022,codepage=437,iocharset=iso8859-1,shortname=mixed,errors=remount-ro)

TW:
Code:

# mount | grep boot
/dev/sdc1 on /boot type vfat (rw,relatime,fmask=0022,dmask=0022,codepage=437,iocharset=iso8859-1,shortname=mixed,errors=remount-ro)

Other than the mount point, I see nothing different. Both mounted read/write.

At the filesystem level I see:

Leap:
Code:

# ls -dl /boot
drwxr-xr-x 4 root root 4096 Sep  5 11:46 /boot

TW:
Code:

# ls -dl /boot
drwxr-xr-x 3 root root 16384 Dec 31  1969 /boot

The links column initially looked odd but the TW system has no /boot/efi directory. (And the date is pretty strange as well. If memory serves, the system was built w/o any network connection available so no NTP access.) Again, both are mounted read/write. But when I try to touch a file and link to it in /boot on both systems, what I see is:

Leap:
Code:

# touch /tmp/a.file
# cd /boot
# ln -s /tmp/a.file .
#

TW:
Code:

# touch /tmp/a.file
# cd /boot
# ln -s /tmp/a.file .
ln: failed to create symbolic link './a.file': Operation not permitted

Which sort of makes sense in that I've always been operating under the assumption that vfat filesystems didn't support symbolic links anyway. Yet... there they are in the /boot directory on the Leap system. [scratches head}

I've run fsck.vfat on the Tumbleweed system's /boot filesystem but all it reported was not having been properly umounted. (Surely from the power failure a while back.) It did not change the behavior when attempting to create a symlink in /boot.

One more tidbit: I have plans to move the Tumbleweed system to Leap 15.2 in the near future. The system is "transitioning" from simply a LAN file server to one hosting web sites as well as its (light) file serving duties and I'm looking to run it with an OS that isn't getting a large number of updates every week (I'd rather spend time on the web sites and not on patching quite so frequently). Maybe living with the strange boot partition is OK until that transition takes place?

Any thoughts?

Any simple fixes?

Any information I've forgotten that would be useful?


TIA...

fatmac 09-17-2020 03:29 AM

Permissions problem in the directory you are trying to put the link into(?).

rknichols 09-17-2020 08:51 AM

Quote:

Originally Posted by rnturn (Post 6166799)
The output of "mount" for the two systems:

Leap:
Code:

# mount | grep boot
/dev/sde1 on /boot/efi type vfat (rw,relatime,fmask=0022,dmask=0022,codepage=437,iocharset=iso8859-1,shortname=mixed,errors=remount-ro)

TW:
Code:

# mount | grep boot
/dev/sdc1 on /boot type vfat (rw,relatime,fmask=0022,dmask=0022,codepage=437,iocharset=iso8859-1,shortname=mixed,errors=remount-ro)

Other than the mount point, I see nothing different. Both mounted read/write.

Note that "/boot/efi" is not "/boot".

On your Leap system, /boot is part of the root filesystem. On that system, you can create symlinks in /boot, but you would not be able to in /boot/efi.

On your TW system, /boot is a separate filesystem formatted vfat, and does not support symlinks.

colorpurple21859 09-17-2020 09:16 AM

sdc1 is mounted on /boot and is fat32. I don’t think you can use symlinks on a fat32 filesystem

rnturn 09-17-2020 01:11 PM

Quote:

Originally Posted by colorpurple21859 (Post 6166985)
sdc1 is mounted on /boot and is fat32. I don’t think you can use symlinks on a fat32 filesystem

So "mount" is fibbing to me? It says "/boot" is "vfat" on both systems.

rknichols 09-17-2020 01:36 PM

Quote:

Originally Posted by rnturn (Post 6167127)
So "mount" is fibbing to me? It says "/boot" is "vfat" on both systems.

No, it does not. As I pointed out in #3, it says that "/boot/efi" is vfat on the Leap system. That is not the same as "/boot" -- separate mountpoint, different filesystem.

colorpurple21859 09-17-2020 01:49 PM

post the output of
Code:

sudo parted -l

rnturn 09-17-2020 02:15 PM

Quote:

Originally Posted by rknichols (Post 6166967)
Note that "/boot/efi" is not "/boot".

On your Leap system, /boot is part of the root filesystem. On that system, you can create symlinks in /boot, but you would not be able to in /boot/efi.

On your TW system, /boot is a separate filesystem formatted vfat, and does not support symlinks.

Great catch. That just didn't "click" while typing this up last night. So (ouch!) the problem stems from the initial installation. (Part of a weekend from hell recovering from two hardware failures.)

Would it be possible to umount the "/boot" filesystem on the TW system, temporarily mount it somewhere else, and copy everything contained in it into the empty "/boot" mount point? Once that was done, any symbolic links point to the kernel and initrd images can be created. I expect that re-running the grub configuration would likely be necessary. There is no "/boot/efi" directory on the TW system which isn't a real surprise since /etc/sysconfig/bootloader specifies "grub2" instead of "grub2-efi" (also explains the difference in mount points). Any "gotchas" to watch out for if I go this route?

BTW, thanks for this reply. Another pair of eyes is always helpful.

colorpurple21859 09-17-2020 02:23 PM

are both TW and Leap on the same computer or different computers? Post the /etc/fstab on both systems if on the same computer, and parted -l for TW

rnturn 09-17-2020 04:38 PM

Quote:

Originally Posted by colorpurple21859 (Post 6167173)
are both TW and Leap on the same computer or different computers? Post the /etc/fstab on both systems if on the same computer, and parted -l for TW

Different systems. See other reply for the parted info for the boot disks.

rnturn 09-17-2020 04:53 PM

Quote:

Originally Posted by colorpurple21859 (Post 6167144)
post the output of
Code:

sudo parted -l

Hmm... I thought I'd posted this. Here's a re-reply:

Leap system boot device:
Code:

Model: ATA ST1000DM003-1CH1 (scsi)
Disk /dev/sde: 1000GB
Sector size (logical/physical): 512B/4096B
Partition Table: gpt
Disk Flags:

Number  Start  End    Size    File system  Name  Flags
 1      1049kB  19.3GB  19.3GB  fat32              boot, esp      # vfat on /boot/efi
 2      19.3GB  127GB  107GB  ext4              legacy_boot    # root
 3      127GB  1000GB  874GB  ext4                              # user data

TW system boot device:
Code:

Model: ATA TOSHIBA HDWD105 (scsi)
Disk /dev/sdc: 500GB
Sector size (logical/physical): 512B/4096B
Partition Table: gpt
Disk Flags: pmbr_boot

Number  Start  End    Size    File system    Name  Flags
 1      1049kB  525MB  524MB  fat16                boot, legacy_boot, esp  # vfat on /boot
 2      525MB  17.7GB  17.2GB  linux-swap(v1)        swap
 3      17.7GB  125GB  107GB  ext4                  raid            # root fs (member of md0)
 4      125GB  500GB  375GB  ext4                  raid            # user data (member of md1)

###  Shown as it's partially mirrored to /dev/sdc  ###

Model: ATA TOSHIBA HDWD105 (scsi)
Disk /dev/sdd: 500GB
Sector size (logical/physical): 512B/4096B
Partition Table: gpt
Disk Flags:

Number  Start  End    Size    File system    Name  Flags
 1      1049kB  525MB  524MB                        bios_grub
 2      525MB  17.7GB  17.2GB  linux-swap(v1)        swap
 3      17.7GB  125GB  107GB  ext4                  raid      # member of md0
 4      125GB  500GB  375GB  ext4                  raid      # member of md1

Is it reasonable to think that I could: Backup everything on the vfat filesystem (it'll easily fit onto a spare USB drive), reconfigure partition 1 as ext4, restore the old vfat contents into the new ext4, then move the "legacy_boot" flag from partition 1 to partition 3?

colorpurple21859 09-17-2020 07:51 PM

Your booting leap in efi mode and TW in legacy mode.
In theory it should work. I would suggest to leave the boot flag on partition 1. The only issue I see is the partition flagged bios-grub is not on the same disk as the boot partition. If the grub boot loader is using the code in the bios-grub partition to boot yes it should work. If not there is a good chance you will get the infamous grub-rescue prompt and will need to have a means to boot into the system from a live iso and reinstall grub.

On a side not the partition flagged bios-grub only needs to be 1MB

rnturn 09-19-2020 09:33 AM

Quote:

Originally Posted by colorpurple21859 (Post 6167288)
Your booting leap in efi mode and TW in legacy mode.
In theory it should work. I would suggest to leave the boot flag on partition 1. The only issue I see is the partition flagged bios-grub is not on the same disk as the boot partition. If the grub boot loader is using the code in the bios-grub partition to boot yes it should work. If not there is a good chance you will get the infamous grub-rescue prompt and will need to have a means to boot into the system from a live iso and reinstall grub.

Thanks. I've got plenty of DVDs with rescue boot options laying around. Just in case.

Quote:

On a side not the partition flagged bios-grub only needs to be 1MB
I tend to keep the partition tables on disks that have partitions that are members of RAIDsets the same regardless of whether some space is left over on one. (Old habit from my days using LSM and copying disk labels from one disk to another to ensure subdisks and plexes were identical sizes.) Disk space is relatively cheap nowadays. Shees, it's hard to find anything under 1TB in the spinning rust category these days.

Again, thanks.


All times are GMT -5. The time now is 07:39 AM.