fstab getting overwritten?
-
@crackulator if you only want to access shares from filemanager then this solution may work
https://forums.ubports.com/post/31279
I believe fstab is overwritten because /etc is on the system partition which is overwritten with every OTA because of image based updates.
-
@nogoogle said in fstab getting overwritten?:
I believe fstab is overwritten because /etc is on the system partition which is overwritten with every OTA because of image based updates.
Yes that is correct.
That's why modifying the rootfs is deprecated by UBports.How do you mount your SMB partition, there might be a way. I don't modify my fstab on my desktop to mount a partition wherever I want...
-
@applee It's not just overwriting it during an update, it's overwriting it every boot. So maybe there is an upstream source of it that I could edit instead.
On a desktop system, it would make no sense to overwrite fstab during an update or reboot; it maps the UUIDs of all your drives and partitions to locations within your directory tree. Your install usually sets it up for you, and if you put your home folder on a different partition or drive than the root system, those details would be in fstab. You'd have to modify it manually if, for example, you put several distros on different partitions and have them all share a Documents folder. Mapping SMB shares is just the same, it's just that the for-example Documents folder is on a network server, which is what I'm doing. I believe this is all quite normal, expected Linux behavior.
UBPorts seems to be doing quite a bit of remapping in fstab, from a glance looks like it's mapping the android parts of the tree to the linux parts, and otherwise bringing parts of the tree to places that linux expects. So it makes sense that it would want to update it, as it's a pretty complex mapping. It looks like the UBPorts system doesn't need to map the UUIDs as desktop linux does, as the android blob takes care of that.
But I believe brutally overwriting fstab is subverting part of its purpose. Perhaps less important in a portable context, as you don't have partitions, and wouldn't usually have permanent servers available, but there are use cases.
I have documents and music and videos on my servers which I'd like to access from my devices, when I'm on my home network. To use these with anything besides File Manager, they need to be mapped somewhere in the root tree. I can hack fstab with a script as I'm doing, but that subverts UBPorts in that I have to make the root system r/w. Perhaps there is another way to mount SMB shares dynamically without putting them in fstab, I just don't know it. Obviously the system can do this with pluggable devices. If anybody can point me in that direction, I'd like to learn about it.
-
@crackulator I don't have an Ubuntu Touch device at the moment to test.
Have you tried smbmount ?
This is for me the "normal" way of mounting a remote SMB partition. Modifying fstab is interesting if you want to mount it at each boot and if the SMB server is always reachable. That's a pretty specific use case in my opinion but there is no such thing as the right method to do things and if it works for you than that's fine. -
@applee Well, that's a good point. fstab is probably not doing anything besides automatically mounting shares that could as easily be dynamically mounted by a script. smbmount seems to be obsolete but it looks like one can do it with mount.cifs in just the same way as with fstab. I'll work that out and report back.
-
@applee so yeah, my swapping-out of fstab isn't really bringing anything to the dynamic-mounting party. One can do it just as easily with:
sudo mount -t cifs -o username=<username>,password=<password>,rw,uid=32011,gid=32011,sec=ntlmssp //<server>/<share> <mount path>(With appropriate replacements for <these fields>). The uid and gid numbers are those for the phablet user that UBPorts gave, as shown with the "id" command).
However I still think that changing fstab is better in some ways, since the shares should mount automatically, that is, if UBPorts wasn't clobbering the fstab. It seems like it should be possible to share that function with UBPorts' remappings. Of course it would fail to mount automatically if the network or share is not available, but that seems to be ok on other distros, it just doesn't mount, and you mount it manually later. It also lets the admin set it up so a user can mount it without having the technicals. But again that's a bit different on UBPorts, since it isn't really multi-user.
It seems like there are other things in /etc/ that are generally necessary to modify, /etc/ssh/ssh_config comes to mind. Isn't that where any systemwide config would be? I'm not sure how that could be unmodifyable.
Maybe I'm just expecting too much Linux out of it...
-
@crackulator said in fstab getting overwritten?:
Maybe I'm just expecting too much Linux out of it...
I understand your point of view but the way you put it is a bit sensitive here.
Ubuntu Touch is Linux but not for desktop PC and so has specific constraints (bootloader, firmware, partitioning, power saving, ...)To fit Ubuntu Touch in the partitions made for android is not an easy task. I'm no expert here, but I guess the partitioning is source of a lot of non standard solution found to overcome these constraints.
I don't have an explanation for the fstab file but I suspect it has something to do with how the partitions are made.At least you have a working solution for your need and if you wish to dig deeper to understand what is at play here, I'll be happy to understand it.
-
Hi all,
Has anyone succeeded in finding the fstab "generator"? -
@crackulator
I worked for the same purpose for several days, and finally I succeeded.
In the<boot partition>/ramdisk/scripts/halium, you can find this:echo "/dev/root / rootfs defaults,ro 0 0" >>$FSTABThat's where fstab is being rewritten.
See github:
https://github.com/Halium/initramfs-tools-halium/blob/halium/scripts/halium#L315 -
@kuzmi4 yes, I did it. ↑ See my previous post. ↑
