Re: libgparted bug.
On Sunday 11 February 2018 10:19:16 David Wright wrote:
> On Sun 11 Feb 2018 at 00:01:26 (-0500), Gene Heskett wrote:
> > On Saturday 10 February 2018 23:34:12 David Wright wrote:
> > > On Sat 10 Feb 2018 at 22:06:05 (-0500), Gene Heskett wrote:
> > > > On Saturday 10 February 2018 18:04:30 Brian wrote:
> > > > > On Sat 10 Feb 2018 at 16:09:00 -0500, Gene Heskett wrote:
> > > > > > On Saturday 10 February 2018 15:27:09 David Wright wrote:
> > > > > > > On Sat 10 Feb 2018 at 15:08:58 (-0500), Gene Heskett wrote:
> > > > > > > > On Saturday 10 February 2018 11:57:38 David Wright wrote:
> > > > > > > > > On Sat 10 Feb 2018 at 09:10:40 (-0500), Gene Heskett
wrote:
> > > > > > > > > > And despite my emasculation of udev, disabling sdd,
> > > > > > > > > > according to the syslog, usbmount is still auto
> > > > > > > > > > mounting these cards, all 3 of them.
> > > > > > >
> > > > > > > You wrote: ↑↑↑↑↑↑↑↑
>
> This line is very lonely, having been torn from its referent.
>
> > > > > > > > > > So if I plan on working with these images on this
> > > > > > > > > > machine with gparted, I imagine I had better find
> > > > > > > > > > usbmount and remove its execute bits. But first make
> > > > > > > > > > my baby some breakfast.
> > > > > > > > >
> > > > > > > > > Oh my, what did you expect?
> > > > > > > >
> > > > > > > > For something as potentially obnoxious as that, an
> > > > > > > > easily thrown switch to enable/disable it. It is NOT in
> > > > > > > > /etc/init.d.
> > > > > > >
> > > > > > > What isn't in /etc/init.d? What do you expect to be in
> > > > > > > /etc/init.d?
> > > > > >
> > > > > > usbmount. I expected to find a starter script with a
> > > > > > recognizable name.
> > > > >
> > > > > Your expectations on where usbmount puts its files are
> > > > > completely and utterly unfounded.
> > > > >
> > > > > > > Why?
> > > > > >
> > > > > > Why not? At least that would give this hacker a target to
> > > > > > throw a hatchet at.
> > > > >
> > > > > David Wright meant - why did you expect usbmount (which you
> > > > > have determined is not on your machine) to put a file in
> > > > > /etc/init.d?
> > > > >
> > > > > > > > > Package: usbmount
> > > > > > > > >
> > > > > > > > > Description-en: automatically mount and unmount USB
> > > > > > > > > mass storage devices
> > > > > > > > >
> > > > > > > > > This package automatically mounts USB mass storage
> > > > > > > > > devices (typically USB pens) when they are plugged in,
> > > > > > > > > and unmounts them when they are removed. The
> > > > > > > > > mountpoints (/media/usb[0-7] by default), filesystem
> > > > > > > > > types to consider, and mount options are configurable.
> > > > > > > > > When multiple devices are plugged in, the first
> > > > > > > > > available mountpoint is automatically selected. If the
> > > > > > > > > device provides a model name, a symbolic link
> > > > > > > > > /var/run/usbmount/MODELNAME pointing to the mountpoint
> > > > > > > > > is automatically created.
> > > > > > > > >
> > > > > > > > > Cheers,
> > > > > > > > > David.
> > > > > > > >
> > > > > > > > No such critter on this wheezy box.
> > > > > > >
> > > > > > > So how do you explain the above? This is getting silly.
> > > > > >
> > > > > > Silly? Not in the least. At least I don't often equate silly
> > > > > > with frustrating. Something is starting this "usbmount"
> > > > > > thingy, and its not me.
> > > > >
> > > > > This is the "usbmount" thingy critter which is absent from
> > > > > your box?
> > > > >
> > > > > > sudo grep -R usbmount /etc/*
> > > > > > has been peeking under the covers in etc for around 5
> > > > > > minutes now, no hits.
> > > > >
> > > > > Not surprising if it doesn't exist.
> > > >
> > > > I didn't think it did, until htop caught it running yesterday.
> > > >
> > > > > > So in this admittedly corner case, the thing needs an on/off
> > > > > > switch so gparted CAN do its thing without fighting with
> > > > > > what somebody no doubt thought was one of their better
> > > > > > brainstorms. Its turned what should be a simple operation on
> > > > > > working 64GiB disk, whose last data is just past 4GiB, and I
> > > > > > want to then make another image file that only includes the
> > > > > > used area of the disk, into a major PAIN IN THE ASS. This is
> > > > > > how raspbian and ayufan prepare the images they release, so
> > > > > > why the hell can't I do it too?
> > > > > >
> > > > > > Grep finally found it, and it does have a switch, so for now
> > > > > > its turned off on this machine. Hopefully that will also
> > > > > > stop the cell phone icons from showing up when I plug it in
> > > > > > for charging.
> > > > >
> > > > > Where did it find it?
> > > >
> > > > /etc/usbmount/usbmount.conf. And it has exactly the switch I
> > > > was looking for. So ATM its turned off. But damn! I just now
> > > > plugged in the cell phone and the icon popped up in about a
> > > > second. But I guess thats because I didn't block it for sdf.
> > >
> > > Odd, that, because the README for usbmount says:
> > >
> > > USBmount is intended as a lightweight solution which is
> > > independent of a desktop environment. Users which would like an
> > > icon to appear when an USB device is plugged in should use other
> > > alternatives.
> >
> > 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
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
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.
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.
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.
--
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>
Reply to: