I 'm not sure I’m completely a newbie - but this makes me feel like one!
I have an /boot/efi directory that for some reason is not allowing reads. Attempts to change it have gotten nowhere - not working with sudo, not with sudo -s not with su. I even attempted to jump to a console, and the console wouldn’t accept my login! When I add the -v option to chmod, it SAYS the change was made, but another look at the ls-la shows no such thing. Here’s the readout:
Actual destination is 744 - but I just wanted it to CHANGE. Any ideas what’s going on?
Also - no research yet - but what would prevent any login from a console?
Is your /boot/efi vfat/fat32? If so, that volume won’t support real POSIX permissions so you won’t be able to use chmod(or anything else) to change permissions. The permissions are set at mount time.
Probably lots of things but a bad keyboard mapping is one common problem. What happens when you try to login?
Hadn’t thought about the fat problem - I’ve been mostly ignoring Windows since ME! So - look through the mount process might yield some dividends… got it.
As for the login - it LOOKS normal, but nothing I can type is accepted - not username/pwd not root/pwd.
IS it misinterpreting en_CA as having a Canadian French keyboard somehow? No idea how to approach a fix for that! (yet)
Here’s my /etc/fstab - but it doesn’t seem the - into research mode
# /etc/fstab: static file system information.
#
# Use 'blkid' to print the universally unique identifier for a device; this may
# be used with UUID= as a more robust way to name devices that works even if
# disks are added and removed. See fstab(5).
#
# <file system> <mount point> <type> <options> <dump> <pass>
UUID=C3B1-5E71 /boot/efi vfat umask=0077 0 2
UUID=ae5707fc-c2cc-4bb2-9680-afd46eee797c / ext4 defaults,noatime 0 1
UUID=d2a430ec-1210-4ecb-aec6-ade4159bc0fa swap swap defaults,noatime 0 2
UUID=a65a3550-4089-4a7a-ab0a-29774f2248d0 /home ext4 defaults,noatime,discard 0 2
UUID=1f17eda9-6476-4789-b953-e8a983041b21 /mnt/data ext4 defaults,noatime 0 2
Sounds about right. I tried 0033 - and got a change, but it isn’t quite what I want yet! Thanks you guys - I am on the trail now.
Still wondering about the console login though (it hasb’t been a problem, because I usually sidestep from a working install on this multi-boot if I need to fix something…
Well - I had some high hope that the 2 issues might have some connection, but no luck on the logging in problem yet. I’ll have to go after that separately. What I solved the directory access problem with was what I put together on my straight Arch build in fstab - and it works the way I thought it ‘should’. Here is the modified /etc/fstab
# /etc/fstab: static file system information.
#
# Use 'blkid' to print the universally unique identifier for a device; this may
# be used with UUID= as a more robust way to name devices that works even if
# disks are added and removed. See fstab(5).
#
# <file system> <mount point> <type> <options> <dump> <pass>
UUID=C3B1-5E71 /boot/efi vfat rw,relatime,fmask=0022,dmask=0022,codepage=437,iocharset=iso8859-1,shortname=mixed,utf8,errors=remount-ro 0 2
#UUID=C3B1-5E71 /boot/efi vfat umask=0033 0 2
UUID=ae5707fc-c2cc-4bb2-9680-afd46eee797c / ext4 defaults,noatime 0 1
UUID=d2a430ec-1210-4ecb-aec6-ade4159bc0fa swap swap defaults,noatime 0 2
UUID=a65a3550-4089-4a7a-ab0a-29774f2248d0 /home ext4 defaults,noatime,discard 0 2
UUID=1f17eda9-6476-4789-b953-e8a983041b21 /mnt/data ext4 defaults,noatime 0 2
A slightly different approach, with fmask and dmask both at 0022, and note taken of the codepage and iocharset as well. But- it DOES work
Can’t get at /boot/efi/EFI without it
I am often in there making changes to rEFInd etc - I couldnt write the wikis without access! I could always get there (open as root from thunar - or sudo -s in term) but it is much easier if you can, say, check if a file made it there - or has the right contents without having (W)rite access necessarily…
As I don’t know much about rEFInd I want to ask: is it mandatory to have those rEFInd files in the /boot/efi folder? Of course efi files are there, but why rEFInd files?
Yup - they have to be there. as far as I understand what’s going on there, refind-x64.efi is what gets started first, then it scans all the likely (and configured) places for bootable entries and presents them for your choice. The rest of the files it has in there are things like conf files, icons, keys for secure boot, and drivers for alternate filesystems that it needs to be able to scan if they are present. It is also nice that it is accessible from ALL install UEFI systems, and the configuration applies to them all from there.
I guess that’s why I do this - or maybe just to prove I’m not too old (yet) to do so!
BTW - a minor typo in the case study - but I can’t remember right now whether the ion I typed should have been in or on
