Can't you mount something to multiple mount points? In other words just ignore the automount and mount it where you want it in parallel?
One automount culprit on a Pi anyway is the GUI file manager. In Preferences -> Volume Management there are 3 checkboxes related to automount. Another could be if you have auto entries in your /etc/fstab. I killed all I could find months ago, don't remember where they were. Or grep the output of mount or lsof for the mount points. I usually look at the output of dmesg when I plug an SD in to see what partitions it has and how to mount (what they're called). Or sfdisk -l if that fails. gparted is handy to have around too. On 4/22/18, Gene Heskett <[email protected]> wrote: > On Sunday 22 April 2018 00:46:42 Chris Moore wrote: > >> Hi, >> >> Le 21/04/2018 à 08:04, Gene Heskett a écrit : >> > On Saturday 21 April 2018 00:24:55 Chris Moore wrote: >> >> Hi, >> >> >> >> Le 20/04/2018 à 17:32, Gene Heskett a écrit : >> >>> The new kernel just installed is: >> >>> Linux rock64 4.4.77-rockchip-ayufan-136 #1 SMP Thu Oct 12 09:14:48 >> >>> UTC 2017 aarch64 GNU/Linux >> >>> >> >>> Note the build date, almost 6 months ago. >> >> >> >> If you uncomment the last line of >> >> /etc/apt/sources.list.d/ayufan-rock64.list you can get Ayufan's >> >> recent pre-release updates. They work much better for me. >> >> Also Ayufan has promised a new official release after the release >> >> of Ubuntu Bionic Beaver which is due in a few days. >> >> >> >> Cheers, >> >> Chris >> > >> > I used aptitude to upgrade 2 kernel files that pulled in 6 or 7 >> > more. I assume its trying to reboot, but did not close the two >> > logins I had into it, so they are locked up until I go out and to a >> > powerdown reset I expect. Its nearly 2 am, and the door that gives >> > me quick access to where it is would wake the missus, so it can sit >> > and stew in its own juices till daytime. For a change, aptitude did >> > not erase 90% of the system according to the action trace it left on >> > the konsole screen here. >> > >> > rock64@rock64:/etc/apt/sources.list.d$ sudo aptitude >> > Performing actions... >> > Selecting previously unselected package libfile-fnmatch-perl. >> > (Reading database ... 141458 files and directories currently >> > installed.) Preparing to unpack >> > .../0-libfile-fnmatch-perl_0.02-2+b3_arm64.deb ... Unpacking >> > libfile-fnmatch-perl (0.02-2+b3) ... >> > Selecting previously unselected package debsums. >> > Preparing to unpack .../1-debsums_2.2.2_all.deb ... >> > Unpacking debsums (2.2.2) ... >> > Selecting previously unselected package >> > linux-headers-4.4.120-rockchip-ayufan-209. >> > Preparing to >> > unpack >> > .../2-linux-headers-4.4.120-rockchip-ayufan-209_0.6.31_arm64.deb ... >> > Unpacking linux-headers-4.4.120-rockchip-ayufan-209 (0.6.31) ... >> > Selecting previously unselected package >> > linux-image-4.4.120-rockchip-ayufan-209. >> > Preparing to >> > unpack >> > .../3-linux-image-4.4.120-rockchip-ayufan-209_0.6.31_arm64.deb ... >> > Unpacking linux-image-4.4.120-rockchip-ayufan-209 (0.6.31) ... >> > Selecting previously unselected package device-tree-compiler. >> > Preparing to unpack .../4-device-tree-compiler_1.4.2-1_arm64.deb ... >> > Unpacking device-tree-compiler (1.4.2-1) ... >> > Preparing to unpack .../5-linux-rock64_0.6.31_arm64.deb ... >> > Unpacking linux-rock64 (0.6.31) over (0.5.15) ... >> > Preparing to unpack .../6-linux-rock64-package_0.6.31_all.deb ... >> > Unpacking linux-rock64-package (0.6.31) over (0.5.15) ... >> > Selecting previously unselected package u-boot-rock64. >> > Preparing to unpack .../7-u-boot-rock64_0.6.31_all.deb ... >> > Unpacking u-boot-rock64 (0.6.31) ... >> > Setting up linux-image-4.4.120-rockchip-ayufan-209 (0.6.31) ... >> > update-initramfs: Generating >> > /boot/initrd.img-4.4.120-rockchip-ayufan-209 Warning: root device >> > does not exist >> > live-boot: core filesystems devices utils udev wget blockdev dns. >> > >> > And the trace ends there. I'll see if I can get it to reboot in the >> > morning. >> > > > It did not late yesterday, but I was talking to the next door neighbor, > and did not do a full powerdown restart. The text on screen says eth0 is > up, but its unreachable. It also was unable to mount and talk to a usb3 > 1T hard drive. > > Since the original update replaced the kernel it twigs me that I saw the > old version go by, so I expect it needs a full powerdown to bring in the > newly installed one. The missus is awake, so I'll go check that now. > BRB. No, its stuck in a loop: root account is locked > press enter to continue > And from what I see on the boot screen, the screwing with the usb3 port > has trashed the 1T drive that was plugged in, neither sector 0 nor > sector 1 is readable. And that means I've lost several months work > because I was doing that work in the /media/slash/home/rock64 directory. > >> > Now, about the afu locale, the list file in /usr/lib, contains no >> > en_US entries. And the locale shown on its own terminals, the first >> > in some list I've not found yet with grep, shows as aa_DJ? And >> > nothing I do changes it. My logins from this machine show the >> > correct en_US.XXX and work as expected, but its own terminals orage >> > and menu's are afu. >> > >> > Maybe this will fix that... >> > >> > Thanks Chris. >> >> Selecting locales after "sudo dpkg-reconfigure locales" fixed the >> locales problem for me. >> >> However I must admit that I am running the (Debian derived) Ubuntu >> Xenial Xerus not pure Debian. >> Worse it is on a (RK3328 based) Scishion V88 Piano TV box not a real >> Rock64 :( >> However I don't see why things should be worse with Debian Stretch on >> a real Rock64. >> >> I hope I haven't misled you into bricking your Rock64 :( >> (Luckily unbricking should be fairly easy.) >> > Unbricking it is as easy as plugging in another u-sd card. I just tried 5 > of them, with unknown images on them, one won't even try to boot, 4 of > them can't get to a x login now. The one that won't even try to boot > probably has an rpi image on it. > > But I have 2 universal readers, and 5 32 to 64 GB sd cards. > But in order to write to those cards, I've had to kill any automounter > stuff on this machine, otherwise the automount would grab it before dd > could get started, or would take it away from dd and trash the image > write. Major pain in the ass figureing THAT out. > > But that apparently means I can't mount and unmount these cards to find > out whats on them, and the cache has all rpi stuff in it, regardless of > which card reader or card is plugged in, or if nothing is plugged in. > > Is there some way I can cause the sd card cache to be flushed, and reread > to refresh the caches data when I plug in a different card? And yet keep > it from grabbing the card and trashing the dd write? On wheezy, this > seems impossible, and the disabling of automounter was several months > back and I can no longer recall what I did to disable it. > > So I need a guru. > > I've since found usbmount was disabled in /etc/usbmount/usbmount.conf on > this machine, I've re-enabled it and I've now taken the spinningrust > label back out of the rock64's /etc/fstab with a # in front of it. Next > is to see if it will now boot. > > And I still need a guru... > >> Cheers, >> Chris > > Thanks Chris. > > -- > Cheers, Gene Heskett > -- > "There are four boxes to be used in defense of liberty: > soap, ballot, jury, and ammo. Please use in that order." > -Ed Howdershelt (Author) > Genes Web page <http://geneslinuxbox.net:6309/gene> > > -- ------------- No, I won't call it "climate change", do you have a "reality problem"? - AB1JX Impeach Impeach Impeach Impeach Impeach Impeach Impeach Impeach
