On Sun 11 Feb 2018 at 11:08:23 -0500, Gene Heskett wrote: > On Sunday 11 February 2018 10:19:16 David Wright wrote: > > > On Sun 11 Feb 2018 at 00:01:26 (-0500), Gene Heskett wrote: > > > I don't believe usbmount did this one, 60-persistent-storage.rule I > > > think did this one as I only kill sdd, and the phone, if the card > > > reader (sdd) is plugged in would have made the phone be sdf. > > > > > > Just so we're on the same page, David. :) > > > > Well I'd be interested to know which line in > > 60-persistent-storage.rules does anything much, other than juggle with > > names etc in its realm: /dev. I think it's more likely that some other > > subsystem is watching out for what udev does, and then acting on the > > information that it returns. There's also the possibility that > > something has inserted a >60 rule (99?) into /{etc,lib}/udev/. > > Otherwise, look to your DE configuration. > > > > The problem with your messing about in udev's rules is that you don't > > know what other subsystems are relying on its efficacy. > > > > Cheers, > > David. > > I will no doubt make an enemy here, but at 83, I've had the great good > fortune to have outlived the only real one I ever had. > > I am running out of patience with your attitude David. If I want to bring
Chill. Sit back in your comfy chair and think it through. > a sd card that boots a rock64 in here to a nice comfy chair, and work on > it in a comfortable environment, so I can make backup images of it that > resemble what you can download from raspian/ayufan/armbian et all, the > last thing I need is some automount utility grabbing it out from under a linuxcnc is an Xfce based system and that DE does the automounting. It is not usbmount or 60-persistent-storage.rules. I'm fairly sure there is a way of turning it off but haven't examined the situation. > running gparted that ought to have a lock on it but doesn't, with its > criminally pisspoor error reporting NOT telling you why the operation > failed. Nothing could be done. It took me 3 damned days to decide > to "save the details" when it failed, then wade thru a kilobyte of html > in the resultant file, to discover that the partition gparted had just > UNMOUNTED, was being autoMOUNTed by some other helpful utility before I > could click thru the menu's and ask it to start the partition shrink I > asked it to do, and all this BS is just me trying to run down and > terminate those OTHER utilities long enough for me to get that job done. Very aggravating, but complaining about all the bits and pieces doesn't get a solution. > The real problem is of coarse that there has not ever been 2 identical sd > cards made, so a dd image to the end of the card A, will not ever > install that image on another supposedly identical card B or C, they are > NOT the same size except in the salespersons mind. Therefore, the image > must be constrained to a gig or so beyond the end of the used portion of > the card. And some utility is then invoked to look at the card during > the initial bootup, that re-expands the last partition to encompass the > remainder of THAT card. That apparently self destructs after one > invocation so thats something else I'll have to figure out. Possibly by > useing gparted to re-expand the last partition once the real data has > been written by dd. In fact, my next test will be to do exactly that to > a 32GiB pny card and see if it will boot the rock64. Sounds like a plan. You have had a fair bit of expert advice to help you implement it. > So if you cannot contribute something helpfull David, and its extremely > obvious to me that YOU do NOT understand the problem, then just quit > trying to confuse the issue, and the rest of this lists readers. Which problem? Nobody but you has thrown 60-persistent-storage.rules and usbmount into the mix and taken a side-swipe at gparted at the same time. Not with any great justification, IMO. Look at what Xfce has to offer for the automounting issue. -- Brian.