SUSE / openSUSEThis Forum is for the discussion of Suse Linux.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
Distribution: openSUSE, Raspbian, Slackware. Previous: MacOS, Red Hat, Coherent, Consensys SVR4.2, Tru64, Solaris
Posts: 2,799
Rep:
/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.
# 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:
# 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?
# 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.
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.
Distribution: openSUSE, Raspbian, Slackware. Previous: MacOS, Red Hat, Coherent, Consensys SVR4.2, Tru64, Solaris
Posts: 2,799
Original Poster
Rep:
Quote:
Originally Posted by rknichols
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.
Distribution: openSUSE, Raspbian, Slackware. Previous: MacOS, Red Hat, Coherent, Consensys SVR4.2, Tru64, Solaris
Posts: 2,799
Original Poster
Rep:
Quote:
Originally Posted by colorpurple21859
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?
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
Distribution: openSUSE, Raspbian, Slackware. Previous: MacOS, Red Hat, Coherent, Consensys SVR4.2, Tru64, Solaris
Posts: 2,799
Original Poster
Rep:
Quote:
Originally Posted by colorpurple21859
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.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.