Web lists-archives.com

Re: libgparted bug.




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.