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.
Reply to: