Re: libgparted bug.

[Gene Heskett]

On Monday 12 February 2018 17:29:58 David Wright wrote:

> On Mon 12 Feb 2018 at 15:32:50 (-0500), Gene Heskett wrote:
> > On Monday 12 February 2018 13:44:04 Brian wrote:
> > > On Mon 12 Feb 2018 at 08:17:23 +0100, deloptes wrote:
> > > > Gene Heskett wrote:
> > > > >> TDE has support channels. People there are far more likely to
> > > > >> be familiar with wheezy (unsupported on Debian) and their own
> > > > >> packages (not in Debian) and any automounting issues.
> > > >
> > > > there is no automount - Gene might remove usbmount package and
> > > > see if this
> > >
> > > Sound advice.
> > >
> > > > helps. The package is not  required by any TDE package.
> > >
> > > No package in Debian reverse depends on it; it would have to be
> > > explicitly installed. Gene Heskett put it there; Gene Heskett can
> > > take it away.
> >
> > And that prompted me to go take a look in /var/cache/apt/archives,
> > and its there, showing as version 0.0.22_all.deb, dated 8 August
> > 2011, which would have to about the time this install was done, from
> > a customized version of wheezy compiled by the linuxcnc guys as an
> > installer .iso.
>
> I'm so glad you've resolved your problems, and am sorry that my
> suggestions regarding usbmount and the DE weren't of any help
> with your version of linux.
>
> Do note that the timestamps on the packages in /var/cache/apt/archives
> are when they were made, not when they were downloaded and installed,
> in case you should ever find yourself needing to rely on them.
> Unfortunately the history logs in /var/log/apt/ only span a year
> unless log rotation has been stopped or reconfigured by the LCNC team.

Or me.  ;-) I have moved some of the logs the system keeps of stuff that 
runs as me to /home/gene/logs, which avoids all the permission bull crap 
when I want to tail a log to see how things are working, then I trained 
logrotate to handle them there. Lots less trouble over the long haul.

> Cheers,
> David.
>
> Sundry disclaimers…



-- 
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 

Re: libgparted bug.

[David Wright]

On Mon 12 Feb 2018 at 15:32:50 (-0500), Gene Heskett wrote:
> On Monday 12 February 2018 13:44:04 Brian wrote:
> 
> > On Mon 12 Feb 2018 at 08:17:23 +0100, deloptes wrote:
> > > Gene Heskett wrote:
> > > >> TDE has support channels. People there are far more likely to be
> > > >> familiar with wheezy (unsupported on Debian) and their own
> > > >> packages (not in Debian) and any automounting issues.
> > >
> > > there is no automount - Gene might remove usbmount package and see
> > > if this
> >
> > Sound advice.
> >
> > > helps. The package is not  required by any TDE package.
> >
> > No package in Debian reverse depends on it; it would have to be
> > explicitly installed. Gene Heskett put it there; Gene Heskett can
> > take it away.
> >
> And that prompted me to go take a look in /var/cache/apt/archives, and 
> its there, showing as version 0.0.22_all.deb, dated 8 August 2011, which 
> would have to about the time this install was done, from a customized 
> version of wheezy compiled by the linuxcnc guys as an installer .iso.

I'm so glad you've resolved your problems, and am sorry that my
suggestions regarding usbmount and the DE weren't of any help
with your version of linux.

Do note that the timestamps on the packages in /var/cache/apt/archives
are when they were made, not when they were downloaded and installed,
in case you should ever find yourself needing to rely on them.
Unfortunately the history logs in /var/log/apt/ only span a year
unless log rotation has been stopped or reconfigured by the LCNC team.

Cheers,
David.

Sundry disclaimers…

Re: libgparted bug.

[Gene Heskett]

On Monday 12 February 2018 16:29:43 deloptes wrote:

> Gene Heskett wrote:
> > usbmount has been disabled.  That would I think, have fixed the
> > original problem that started all this hoohaw.
> >
> > My apologies to the list in that case.
>
> With full respect, Gene, we are glad it worked for you once again!
>
> regards

And regards back at you Deloptes, your advice is about 99% spot on when 
the question is properly posed.


-- 
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 

Re: libgparted bug.

[deloptes]

Gene Heskett wrote:

> I, based on the previous post, scanned thru the trinity control center,
> and found the automount unchecked, but mount as user is checked. That
> seems like its handy, so I left it checked.

Yes, indeed, I found it too

automount is unchecked
mount as user is checked

+ learned something

regards

Re: libgparted bug.

[deloptes]

Gene Heskett wrote:

> usbmount has been disabled.  That would I think, have fixed the original
> problem that started all this hoohaw.
> 
> My apologies to the list in that case.

With full respect, Gene, we are glad it worked for you once again!

regards

Re: libgparted bug.

[Gene Heskett]

On Monday 12 February 2018 15:16:47 Brian wrote:

> On Mon 12 Feb 2018 at 14:14:56 -0500, Gene Heskett wrote:
> > I have restored everything that I played with in the udev dept. And
> > re-enabled usbmount in its config, exactly as installed originally.
>
> Mmm.
>
> > I have unmounted both visible partitions of this sd card, and they
> > have not remounted in several hours, no little arrow point beside
> > the two icons. But I just pulled the card reader out of the 4 port
> > usb hub laying here with the keyboard and mouse dongles plugged into
> > it. Icons gone in miliseconds.
> >
> > Plug it back in and it only takes 4 or 5 seconds for both icons to
> > re-appear, mounted at /media/usb0 and /media/usb1.
> > gene@coyote:~/rock64.imgs$ ls /media/usb0
> > dtb  extlinux  Image  initrd.img
> > gene@coyote:~/rock64.imgs$ ls /media/usb1
> > bin  boot  dev  etc  home  lib  lost+found  media  mnt  opt  proc 
> > root run  sbin  srv  sys  tmp  usr  var
>
> Patient: Doctor, Doctor. I get the most terrible chest pains when I
> let my dog Usbmutt into the house.
>
> Doctor: Stop doing it then.
You forgot the smiley Brian.
;-)
We will see how doing without it works, its disabled again.


-- 
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 

Re: libgparted bug.

[Gene Heskett]

On Monday 12 February 2018 14:00:42 deloptes wrote:

> Brian wrote:
> >> I don't know what you mean, but I read and post to both lists
> >> (user/devel)
> >
> > January was a busy time on the list.
>
> I didn't have that impression if you mean TDE. It is a small community
> (at least the posting part of it).
>
> >> Unfortunately I upgraded long time ago from jessie to stretch and
> >> don't know whats the status with wheezy.
> >
> > You mean - nobody has to stick with an outdated and unsupported
> > wheezy?
>
> I didn't say that, because everyone has the freedom to do what he or
> she might thing is best.
> I just referred to my experience, that I upgraded long time ago and
> can't recall exactly how it looked like. I even think that with wheezy
> I still used KDE3 and KDE3 was fully transitioned to TDE when I moved
> to Jessie.
>
And grown very very stable, into the Just Works(TM) category.  And one 
thing I have noted, every update in recent history has resulted in 
smaller files on disk, sometimes quite a few megabytes at a time as the 
two programmers at the head of the table clean up kde's loose ends that 
existed at the time of the fork, circa kde-3.5.

usbmount has been disabled.  That would I think, have fixed the original 
problem that started all this hoohaw.

My apologies to the list in that case.

> regards



-- 
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 

Re: libgparted bug.

[Gene Heskett]

On Monday 12 February 2018 13:44:04 Brian wrote:

> On Mon 12 Feb 2018 at 08:17:23 +0100, deloptes wrote:
> > Gene Heskett wrote:
> > >> TDE has support channels. People there are far more likely to be
> > >> familiar with wheezy (unsupported on Debian) and their own
> > >> packages (not in Debian) and any automounting issues.
> >
> > there is no automount - Gene might remove usbmount package and see
> > if this
>
> Sound advice.
>
> > helps. The package is not  required by any TDE package.
>
> No package in Debian reverse depends on it; it would have to be
> explicitly installed. Gene Heskett put it there; Gene Heskett can
> take it away.
>
And that prompted me to go take a look in /var/cache/apt/archives, and 
its there, showing as version 0.0.22_all.deb, dated 8 August 2011, which 
would have to about the time this install was done, from a customized 
version of wheezy compiled by the linuxcnc guys as an installer .iso.

I still have the last 2 such LCNC installer iso's, but its not listed in 
the TOC of either iso. I think that means I did install it, but there 
been a few trillion gallons of water down the West Fork River since and 
I've no recollection at this late date.  Its disabled by an option it 
its config. so I'll do it.  And see what problem I was trying to fix 
comes back. :)

> > In Stretch TDE  would sense the plugged usb and list it unmounted.
> > User may click on the item and it will mount. I never experienced
> > automount.
>
> You can use gparted with peace of mind, then.
>
> > > Their mailing list turned into a black hole around 9 months back.
> > >  And I'm subscribed.
> >
> > I don't know what you mean, but I read and post to both lists
> > (user/devel)
>
> January was a busy time on the list.
>
> > Unfortunately I upgraded long time ago from jessie to stretch and
> > don't know whats the status with wheezy.
>
> You mean - nobody has to stick with an outdated and unsupported
> wheezy?



-- 
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 

Re: libgparted bug.

[Brian]

On Mon 12 Feb 2018 at 14:14:56 -0500, Gene Heskett wrote:

> I have restored everything that I played with in the udev dept. And 
> re-enabled usbmount in its config, exactly as installed originally.

Mmm.

> 
> I have unmounted both visible partitions of this sd card, and they have 
> not remounted in several hours, no little arrow point beside the two 
> icons. But I just pulled the card reader out of the 4 port usb hub 
> laying here with the keyboard and mouse dongles plugged into it. Icons 
> gone in miliseconds.
> 
> Plug it back in and it only takes 4 or 5 seconds for both icons to 
> re-appear, mounted at /media/usb0 and /media/usb1.
> gene@coyote:~/rock64.imgs$ ls /media/usb0
> dtb  extlinux  Image  initrd.img
> gene@coyote:~/rock64.imgs$ ls /media/usb1
> bin  boot  dev  etc  home  lib  lost+found  media  mnt  opt  proc  root  
> run  sbin  srv  sys  tmp  usr  var

Patient: Doctor, Doctor. I get the most terrible chest pains when I let
 my dog Usbmutt into the house.

Doctor: Stop doing it then.

-- 
Brian.

Re: libgparted bug.

[Gene Heskett]

On Monday 12 February 2018 13:36:43 deloptes wrote:

> Curt wrote:
> > On 2018-02-11, Gene Heskett  wrote:
> >> On Sunday 11 February 2018 18:19:00 Brian wrote:
> >>> On Sun 11 Feb 2018 at 17:07:03 -0500, Gene Heskett wrote:
> >>> > On Sunday 11 February 2018 15:31:13 Brian wrote:
> >>> > > 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.
> >>> >
> >>> > And again the system doing the work is NOT the rock64, but this
> >>> > machine here in the house, a 32 bit wheezy install running TDE
> >>> > as the DE.
> >>>
> >>> TDE has support channels. People there are far more likely to be
> >>> familiar with wheezy (unsupported on Debian) and their own
> >>> packages (not in Debian) and any automounting issues.
> >>
> >> Their mailing list turned into a black hole around 9 months back. 
> >> And I'm subscribed.
> >
> > A person on the trinity-users mailing list opined that there is a
> > right-click-on-the-automounted-usb contextual menu in TDE, and deep
> > within that menu somewhere is an option to turn off automounting by
> > unchecking the relevant menu item.
> >
> > I can't vouch for the veracity, or even the pertinence, of this
> > info, but there you go.
> >
> > https://www.spinics.net/lists/trinity-users/msg01436.html
>
> no idea what it refers to. The only option I see is a checkbox for
> "use default mount options". Perhaps it is related to something that I
> don't have here on my PC
>
> I use "system:/media" and then click on USB does mount and open and
> context menu has unmount, open with, safe remove etc
>
> in the properties there is the checkbox I mentioned above
>
> regards

I, based on the previous post, scanned thru the trinity control center, 
and found the automount unchecked, but mount as user is checked. That 
seems like its handy, so I left it checked.

Thanks Deloptes.

-- 
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 

Re: libgparted bug.

[Brian]

On Mon 12 Feb 2018 at 20:00:42 +0100, deloptes wrote:

> Brian wrote:
> 
> >> I don't know what you mean, but I read and post to both lists
> >> (user/devel)
> > 
> > January was a busy time on the list.
> > 
> I didn't have that impression if you mean TDE. It is a small community (at
> least the posting part of it).

trinity-users had some 90 posts. Quite a respectable number. I do not
know what "black hole" means in that context.

> >> Unfortunately I upgraded long time ago from jessie to stretch and don't
> >> know whats the status with wheezy.
> > 
> > You mean - nobody has to stick with an outdated and unsupported wheezy?
> 
> I didn't say that, because everyone has the freedom to do what he or she
> might thing is best.

Indeed. Make your bed and lie in it.

-- 
Brian.

Re: libgparted bug.

[Gene Heskett]

On Monday 12 February 2018 02:17:23 deloptes wrote:

> Gene Heskett wrote:
> >> TDE has support channels. People there are far more likely to be
> >> familiar with wheezy (unsupported on Debian) and their own packages
> >> (not in Debian) and any automounting issues.
>
> there is no automount - Gene might remove usbmount package and see if
> this helps. The package is not  required by any TDE package.
> In Stretch TDE  would sense the plugged usb and list it unmounted.
> User may click on the item and it will mount. I never experienced
> automount.

I have restored everything that I played with in the udev dept. And 
re-enabled usbmount in its config, exactly as installed originally.

I have unmounted both visible partitions of this sd card, and they have 
not remounted in several hours, no little arrow point beside the two 
icons. But I just pulled the card reader out of the 4 port usb hub 
laying here with the keyboard and mouse dongles plugged into it. Icons 
gone in miliseconds.

Plug it back in and it only takes 4 or 5 seconds for both icons to 
re-appear, mounted at /media/usb0 and /media/usb1.
gene@coyote:~/rock64.imgs$ ls /media/usb0
dtb  extlinux  Image  initrd.img
gene@coyote:~/rock64.imgs$ ls /media/usb1
bin  boot  dev  etc  home  lib  lost+found  media  mnt  opt  proc  root  
run  sbin  srv  sys  tmp  usr  var

That 32GiB card had a new stretch-minimal-rock64-0.5.15-136-arm64.img
written to it as I was leaving for and appointment with a vampire at my 
local clinic this  morning, as my shaman wanted a fresh blood panel.

> > Their mailing list turned into a black hole around 9 months back.
> >  And I'm subscribed.
>
> I don't know what you mean, but I read and post to both lists
> (user/devel)
>
I have seen your posts there in the past. What is the valid address of 
that list today, perhaps its been moved from the original at 
pearsoncomputing and I missed the memo?

> Unfortunately I upgraded long time ago from jessie to stretch and
> don't know whats the status with wheezy.
>
I am still getting regular updates of all of it (TDE and Wheezy) via 
synaptic. This and the dell on my g0704 are the only 2 with horsepower 
enough to spare to run kde/tde. Everything else is running xfce or lxde. 
Not impressed with lxde.

> regards

Thanks Deloptes.


-- 
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 

Re: libgparted bug.

[deloptes]

Brian wrote:

>> I don't know what you mean, but I read and post to both lists
>> (user/devel)
> 
> January was a busy time on the list.
> 

I didn't have that impression if you mean TDE. It is a small community (at
least the posting part of it).

>> Unfortunately I upgraded long time ago from jessie to stretch and don't
>> know whats the status with wheezy.
> 
> You mean - nobody has to stick with an outdated and unsupported wheezy?

I didn't say that, because everyone has the freedom to do what he or she
might thing is best.
I just referred to my experience, that I upgraded long time ago and can't
recall exactly how it looked like. I even think that with wheezy I still
used KDE3 and KDE3 was fully transitioned to TDE when I moved to Jessie. 

regards

Re: libgparted bug.

[Brian]

On Mon 12 Feb 2018 at 08:17:23 +0100, deloptes wrote:

> Gene Heskett wrote:
> 
> >> TDE has support channels. People there are far more likely to be
> >> familiar with wheezy (unsupported on Debian) and their own packages
> >> (not in Debian) and any automounting issues.
> > 
> 
> there is no automount - Gene might remove usbmount package and see if this

Sound advice.

> helps. The package is not  required by any TDE package.

No package in Debian reverse depends on it; it would have to be
explicitly installed. Gene Heskett put it there; Gene Heskett can
take it away.

> In Stretch TDE  would sense the plugged usb and list it unmounted. User may
> click on the item and it will mount. I never experienced automount.

You can use gparted with peace of mind, then.
 
> > Their mailing list turned into a black hole around 9 months back.  And
> > I'm subscribed.
> 
> I don't know what you mean, but I read and post to both lists (user/devel)

January was a busy time on the list.

> Unfortunately I upgraded long time ago from jessie to stretch and don't know
> whats the status with wheezy.

You mean - nobody has to stick with an outdated and unsupported wheezy?

-- 
Brian.

Re: libgparted bug.

[deloptes]

Curt wrote:

> On 2018-02-11, Gene Heskett  wrote:
>> On Sunday 11 February 2018 18:19:00 Brian wrote:
>>
>>> On Sun 11 Feb 2018 at 17:07:03 -0500, Gene Heskett wrote:
>>> > On Sunday 11 February 2018 15:31:13 Brian wrote:
>>> > > 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.
>>> >
>>> > And again the system doing the work is NOT the rock64, but this
>>> > machine here in the house, a 32 bit wheezy install running TDE as
>>> > the DE.
>>>
>>> TDE has support channels. People there are far more likely to be
>>> familiar with wheezy (unsupported on Debian) and their own packages
>>> (not in Debian) and any automounting issues.
>>
>> Their mailing list turned into a black hole around 9 months back.  And
>> I'm subscribed.
>>
> 
> A person on the trinity-users mailing list opined that there is a
> right-click-on-the-automounted-usb contextual menu in TDE, and deep
> within that menu somewhere is an option to turn off automounting by
> unchecking the relevant menu item.
> 
> I can't vouch for the veracity, or even the pertinence, of this info,
> but there you go.
> 
> https://www.spinics.net/lists/trinity-users/msg01436.html

no idea what it refers to. The only option I see is a checkbox for "use
default mount options". Perhaps it is related to something that I don't
have here on my PC

I use "system:/media" and then click on USB does mount and open and context
menu has unmount, open with, safe remove etc

in the properties there is the checkbox I mentioned above

regards

Re: libgparted bug.

[David Wright]

On Sun 11 Feb 2018 at 17:07:03 (-0500), Gene Heskett wrote:
> On Sunday 11 February 2018 15:31:13 Brian wrote:
> > On Sun 11 Feb 2018 at 11:08:23 -0500, Gene Heskett wrote:
> > > On Sunday 11 February 2018 10:19:16 David Wright wrote:

> > > > […] Otherwise, look to your DE configuration. […]

> > > 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 […]
> >
> > > 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.
> >
> > > 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.
> >
> Plenty of justification IMNSHO.  If I launch a root session of gparted, 
> giving it the device name as a command line argument, gparted should 
> claim ownership of the storage device and anything else that comes 
> snooping around should rightfully be told to go pound sand.

Another disclaimer: I don't use gparted (unless it's built into the
installer, in which case I have unwittingly used it) but fdisk and
gdisk as appropriate.

When you run those programs, they don't AFAICT claim ownership of the
device. You can happily run two instances of them without any problem,
though I haven't tested what happens with the second if you change the
partition table with the first (and the kernel rescans it).

Are you expecting a lock file to be created by fdisk and gdisk?
Even if you could "protect" the device with the partitioning
program, as soon as you exit it, there's a race condition between
your fingers/mouseclicks and the automounter, which the latter is
likely to win.

So my advice remains disable/uninstall the automounter and check
your DE options.

YAD (yet another disclaimer):
In looking through automounting issues on this list, I happened upon
https://lists.debian.org/debian-user/2016/11/msg00857.html
Regardless of the topic in (1), paragraphs (2) and (3) might make
a good signature for some of my posts.

> Throw in the 
> fact that unless you want to read its logs for failures, you need to do 
> it with a web browser. I don't know about you, but where I learned 
> programming, you read the logs with a text reader. And some of my 
> programs were so well checked there was nothing left to log. The need 
> for a log is to me, sloppy coding. But we no longer write our RCA-1802 
> code by looking up the memonic in the programmers manual and use that to 
> convert our source code into hex to be entered in a hex monitor.  That 
> code, and the machine I built to execute it, turned out to be so usefull 
> at KRCR-tv in Redding CA, that it was still in daily use 15 years later, 
> in the summer of 1994. That code was heavily self modifying, never 
> crashed that I know of once I said it was ready. So don't lecture me on 
> quality code.

And my anecdote (also OT):

Having done the steps in (bump, bump)
https://lists.debian.org/debian-user/2018/02/msg00466.html
(which might be too uncommon (mixing FAT and LUKS) or too technical
for this list), one instance of Windows10 (and only one) keeps
pestering with this drive about wanting to format F: (E: is the NTFS
filesystem). The only way to stop it is not to answer; just leave the
dialog box hidden underneath the normal windows. Dangerous, I know,
as one might accidentally click it after closing all the other windows.

But it made me think about whether you could stop the automounter by
setting a peculiar partition type on the device. Probably not; ho hum…

Cheers,
David.

Re: libgparted bug.

[Curt]

On 2018-02-11, Gene Heskett  wrote:
> On Sunday 11 February 2018 18:19:00 Brian wrote:
>
>> On Sun 11 Feb 2018 at 17:07:03 -0500, Gene Heskett wrote:
>> > On Sunday 11 February 2018 15:31:13 Brian wrote:
>> > > 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.
>> >
>> > And again the system doing the work is NOT the rock64, but this
>> > machine here in the house, a 32 bit wheezy install running TDE as
>> > the DE.
>>
>> TDE has support channels. People there are far more likely to be
>> familiar with wheezy (unsupported on Debian) and their own packages
>> (not in Debian) and any automounting issues.
>
> Their mailing list turned into a black hole around 9 months back.  And 
> I'm subscribed.
>

A person on the trinity-users mailing list opined that there is a
right-click-on-the-automounted-usb contextual menu in TDE, and deep
within that menu somewhere is an option to turn off automounting by
unchecking the relevant menu item.

I can't vouch for the veracity, or even the pertinence, of this info,
but there you go.

https://www.spinics.net/lists/trinity-users/msg01436.html


-- 
I think it’s more like we both had this rich neighbor named Xerox and I broke
into his house to steal the TV set and found out that you had already stolen
it.”  Gates telling Jobs why Apple didn't really get ripped off by Microsoft.

Re: libgparted bug.

[deloptes]

Gene Heskett wrote:

>> TDE has support channels. People there are far more likely to be
>> familiar with wheezy (unsupported on Debian) and their own packages
>> (not in Debian) and any automounting issues.
> 

there is no automount - Gene might remove usbmount package and see if this
helps. The package is not  required by any TDE package.
In Stretch TDE  would sense the plugged usb and list it unmounted. User may
click on the item and it will mount. I never experienced automount.

> Their mailing list turned into a black hole around 9 months back.  And
> I'm subscribed.

I don't know what you mean, but I read and post to both lists (user/devel)

Unfortunately I upgraded long time ago from jessie to stretch and don't know
whats the status with wheezy.

regards

Re: libgparted bug.

[Gene Heskett]

On Sunday 11 February 2018 18:19:00 Brian wrote:

> On Sun 11 Feb 2018 at 17:07:03 -0500, Gene Heskett wrote:
> > On Sunday 11 February 2018 15:31:13 Brian wrote:
> > > 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.
> >
> > And again the system doing the work is NOT the rock64, but this
> > machine here in the house, a 32 bit wheezy install running TDE as
> > the DE.
>
> TDE has support channels. People there are far more likely to be
> familiar with wheezy (unsupported on Debian) and their own packages
> (not in Debian) and any automounting issues.

Their mailing list turned into a black hole around 9 months back.  And 
I'm subscribed.

-- 
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 

Re: libgparted bug.

[Brian]

On Sun 11 Feb 2018 at 17:07:03 -0500, Gene Heskett wrote:

> On Sunday 11 February 2018 15:31:13 Brian wrote:
> 
> > 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.
> >
> And again the system doing the work is NOT the rock64, but this machine 
> here in the house, a 32 bit wheezy install running TDE as the DE.

TDE has support channels. People there are far more likely to be
familiar with wheezy (unsupported on Debian) and their own packages
(not in Debian) and any automounting issues.

-- 
Brian.

Re: libgparted bug.

[Gene Heskett]

On Sunday 11 February 2018 15:31:13 Brian wrote:

> 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.
>
And again the system doing the work is NOT the rock64, but this machine 
here in the house, a 32 bit wheezy install running TDE as the DE.

linuxcnc and xfce have zero dependencies, I have it running on almost 
every different DE on my various machines. Its happy as long as the gui 
does Xorg method gfx.

> > 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.
>
Plenty of justification IMNSHO.  If I launch a root session of gparted, 
giving it the device name as a command line argument, gparted should 
claim ownership of the storage device and anything else that comes 
snooping around should rightfully be told to go pound sand. Throw in the 
fact that unless you want to read its logs for failures, you need to do 
it with a web browser. I don't know about you, but where I learned 
programming, you read the logs with a text reader. And some of my 
programs were so well checked there was nothing left 

Re: libgparted bug.

[Gene Heskett]

On Sunday 11 February 2018 12:35:54 Thomas Schmitt wrote:

> Hi,
>
> Gene Heskett wrote:
> > 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.
>
> You could install a bumper partition 8 at the end of the card.
> Whatever automat you suffer from, it would have to be extra stupid to
> expand partition 7 into the range of the bumper.
>
> Let's assume a minimum size of rounded up 16 billion with a "16 GB"
> medium. Then let's subtract a coward's reserve of 100 million bytes,
> and divide by the block size:
>   ( 15.5e9 - 100e6 ) / 512 = 30078125
>
> So if you create partition 8 starting at block 30,078,125 and reaching
> up to the end of the usable block range, then the image from block 0
> to the end of partition 7 should be portable to any "16 GB" medium.
>
> Ideally you should delete partition 8 before copying from the original
> medium. So it does not confuse partition editors after the image was
> copied to a new medium.
>
> The GPT header and the backup GPT would have to be re-created with the
> new medium size. Partition 8 would have to be re-created from the same
> start block up to the end of the usable block range.
> gdisk seems to be able to do this.
>
> Start blocks for bumpers:
> Rounded up "8 GB"  -  50 MB :  14,550,781
> Rounded up "16 GB" - 100 MB :  30,078,125
> Rounded up "32 GB" - 200 MB :  61,132,812
> Rounded up "64 GB" - 500 MB : 123,046,875
>
This is all making sense, gee, I wish you were in charge of the man pages 
for all this.

I am atm, pulling a new copy out to count=16501000, which is, or should 
be, a wee bit past the end of partition 7. Then I'll write it to a 32GiB 
card, and have gparted extend #7 to the end of the disk. I did this 
earlier today, but all that got me was a kernel panic. But the write to 
the 32GiB card was likely broken as dd nearly locked up the machine and 
I finally just ejected the card as I couldn't kill dd even as root.

That new copy is made, swap cards wash, rinse & repeat in reverse to a 
32G card.

>
> Have a nice day :)
>
You too Thomas. And thank you.

> Thomas



-- 
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 

Re: libgparted bug.

[David Wright]

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. :)

The point is: we're not.

> > 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.
[…]
> 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, […] the 
> last thing I need is some automount utility

Agreed—and you wrote "despite my emasculation of udev, disabling sdd,
according to the syslog, usbmount is still auto mounting these cards".

Hence my abrupt comment "Oh my, what did you expect?" and the rather
obvious point that usbmount advertises itself as an automounter.

Then you denied that usbmount was installed: "No such critter on this
wheezy box." Hence my "This is getting silly."

Then, having admitted that you do have it installed, you now blamed it
or udev for doing something on your Desktop, which they probably know
nothing about; udev is operating only just above the kernel.

So at this point I pointed out that it might not be wise to fiddle
about with udev's files too much because rather a lot of subsystems
may rely on its working properly.

> The real problem is of coarse that there has not ever been 2 identical sd 
> cards made, […]

and that is the problem that Thomas has been helping you with, in a
far better way than I ever could.

> 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.

If I have an attitude, it's this. The list's readers will be familiar
with the fact that you often seem to run into problems where others
find no difficulty. Often, you post some of the actions to take in
trying to fix such problems. Ofttimes again, these steps appear to be
fighting the system rather than working with it.

What I saw here was you cudgelling udev when something else was to blame.
The persistent-storage rules are meant to allow the system to recognise
what device changes are taking place so that it can assign the right
names both for you and for subsystems further up the chain.

My goal was to help steer you in the direction of what might be causing
your specific automounting problem so that you might reach a better
solution without breaking other things.

In the meantime, I can't just post an easy fix because, again as we
all know, you run a mixture of systems of different ages, much of it
oldoldstable, on different architectures, and with kernels that are
not even Debian's. Add to all that the fact that I don't have any
experience of configuring DEs because I've only briefly seen them
when I have booted from a live stick, so I can only try and ask
Socratic questions that might suggest where you could look.

And, because this is just a list, you can always ignore any
suggestions I make.

Cheers,
David.

Re: libgparted bug.

[Brian]

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.

Re: libgparted bug.

[Thomas Schmitt]

Hi,

Gene Heskett wrote:
> 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.

You could install a bumper partition 8 at the end of the card.
Whatever automat you suffer from, it would have to be extra stupid to
expand partition 7 into the range of the bumper.

Let's assume a minimum size of rounded up 16 billion with a "16 GB" medium.
Then let's subtract a coward's reserve of 100 million bytes, and divide
by the block size:
  ( 15.5e9 - 100e6 ) / 512 = 30078125

So if you create partition 8 starting at block 30,078,125 and reaching up
to the end of the usable block range, then the image from block 0 to the
end of partition 7 should be portable to any "16 GB" medium.

Ideally you should delete partition 8 before copying from the original
medium. So it does not confuse partition editors after the image was copied
to a new medium.

The GPT header and the backup GPT would have to be re-created with the
new medium size. Partition 8 would have to be re-created from the same
start block up to the end of the usable block range.
gdisk seems to be able to do this.

Start blocks for bumpers:
Rounded up "8 GB"  -  50 MB :  14,550,781 
Rounded up "16 GB" - 100 MB :  30,078,125
Rounded up "32 GB" - 200 MB :  61,132,812
Rounded up "64 GB" - 500 MB : 123,046,875


Have a nice day :)

Thomas

Re: libgparted bug.

[Gene Heskett]

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 

Re: libgparted bug.

[David Wright]

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 

Re: libgparted bug.

[Gene Heskett]

On Sunday 11 February 2018 06:23:35 deloptes wrote:

> Gene Heskett wrote:
> > /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.
>
> The icon itself is not an issue. It should not be automounted. The
> icon appears to assist you if you want to mount it.

You're right, it does not appear to be mounted. Humm. And  needs root to 
change it.

-- 
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 

Re: libgparted bug.

[deloptes]

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.

I don't think you need usbmount at all, but I am not at 100% sure for wheezy

regards

Re: libgparted bug.

[deloptes]

Gene Heskett wrote:

> /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.
> 

The icon itself is not an issue. It should not be automounted. The icon
appears to assist you if you want to mount it.

Re: libgparted bug.

[Gene Heskett]

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:
> > > > >
> > > > > > > > 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. :)
> Cheers,
> David.



-- 
Cheers, Gene Heskett
--
"There are four boxes to be used in 

Re: libgparted bug.

[David Wright]

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

Cheers,
David.

Re: libgparted bug.

[Gene Heskett]

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

>
> Looking for hairs on the palms of your hands sounds a more useful
> exercise than the one you have undertaken. Bet you find those too. :)

None on the palms of these hands, never has been in 83+ years, they are 
too busy.

-- 
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 

Re: libgparted bug.

[Brian]

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:
> >
> > > > > 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.
  
> 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?

Looking for hairs on the palms of your hands sounds a more useful
exercise than the one you have undertaken. Bet you find those too. :)

-- 
Brian.

Re: libgparted bug.

[Gene Heskett]

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

> Why?

Why not? At least that would give this hacker a target to throw a hatchet 
at.

> > >  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.

sudo grep -R usbmount /etc/*
has been peeking under the covers in etc for around 5 minutes now, no 
hits.
 
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.

> Cheers,
> David.

Thanks David.

-- 
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 

Re: libgparted bug.

[Gene Heskett]

On Saturday 10 February 2018 15:12:21 Thomas Schmitt wrote:

> Hi,
>
> i proposed (poking with a long stick in the fog):
> > >   dd if=/dev/sdd bs=512 skip=16500703 count=66 \
> > >  of=rock-img-shrunk.img seek=16500703
>
> Gene Heskett wrote:
> > Which was an instant return claiming 66 blocks had been copied.
>
> Yeah. Fast. But sufficient only if i did not miscalculate again.
> The full copy with 131072 chunks of 64 KiB from fully unmounted
> /dev/sdd* would be the safer variant.
>
> > gdisk is still fussing.
> > gene@coyote:~/rock64.imgs$ gdisk -l rock-img-shrunk.img
> >7  26214416500735   7.7 GiB 8300  root
>
> But at least we seem to have defaced the backup GPT which caused the
> gdisk refusal after gdisk itself wrote it to that place.
>
> The file size of rock-img-shrunk.img should now be 8,448,393,728
> bytes.
 8,448,393,728 IP added the comma's.>
> If so, then it should be safe to let gdisk fix the problems which it
> detected in the partition tables. But as said, this is of interest
> mainly on the final storage device, where the backup GPT is a good
> protection against mishaps by clumsy partition editors.
>
> > All three of these cards will boot the rock64, but two snags.
> > [...]
> > Oh, and 3. it did not autoresize part7 during the boot, so I am
> > assuming a need to touch a file to make that happen again.
>
> Should the booted system do that ?

It does so on the initial boot.
 
> Did i miss you mentioning this ?

Maybe, and maybe I didn't mention it prior to this. Can I blame it on 
oldtimers? :(

> Googling "rock64": The power of a 10 year old workstation in the size
> of a credit card. Zero noise, i hope.

It has a small sink that runs hot. No fan on it ATM. So yes, dead silent. 
I'll probably do it like the pi it will replace, I have a video card fan 
on it, very quiet. Due to the almost vanishingly short cable from a 
teeny breakout board on the pi's 40 pin gpio, the pi is upside down and 
the cable with the spi bus to the Mesa 7i90HD interface card is only 
about 3/4" long. It is after all running at 42 megabits one way, and 25 
for the readback channel, 32 bit packets at a time.

> > Many Thanks, Thomas Schmitt.
>
> Give your wife a big hug from little Thomas from germany.

With only about 80 lbs of skin & bones left, COPD is taking her out 
eventually, the hugs are gentle and too far apart.

>
> Have a nice day :)
>
You too, and thanks.

> Thomas



-- 
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 

Re: libgparted bug.

[Brian]

On Sat 10 Feb 2018 at 15:08:58 -0500, Gene Heskett wrote:

> On Saturday 10 February 2018 11:57:38 David Wright wrote:
> 
> >  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.

You don't have it? So why did you refer to it earlier?

 > ... usbmount is still auto mounting these cards .

A figment of the imagination?

It's not that important in the context of what you are trying to do, but
some degree of precision and accururacy is expected.

-- 
Brian

Re: libgparted bug.

[David Wright]

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:

> > > 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? Why?

> >  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.

Cheers,
David.

Re: libgparted bug.

[Thomas Schmitt]

Hi,

i proposed (poking with a long stick in the fog):
> >   dd if=/dev/sdd bs=512 skip=16500703 count=66 \
> >  of=rock-img-shrunk.img seek=16500703

Gene Heskett wrote:
> Which was an instant return claiming 66 blocks had been copied.

Yeah. Fast. But sufficient only if i did not miscalculate again.
The full copy with 131072 chunks of 64 KiB from fully unmounted /dev/sdd*
would be the safer variant.


> gdisk is still fussing.
> gene@coyote:~/rock64.imgs$ gdisk -l rock-img-shrunk.img
>7  26214416500735   7.7 GiB 8300  root

But at least we seem to have defaced the backup GPT which caused the
gdisk refusal after gdisk itself wrote it to that place.

The file size of rock-img-shrunk.img should now be 8,448,393,728 bytes.

If so, then it should be safe to let gdisk fix the problems which it
detected in the partition tables. But as said, this is of interest
mainly on the final storage device, where the backup GPT is a good
protection against mishaps by clumsy partition editors.


> All three of these cards will boot the rock64, but two snags.
> [...]
> Oh, and 3. it did not autoresize part7 during the boot, so I am assuming 
> a need to touch a file to make that happen again.

Should the booted system do that ?
Did i miss you mentioning this ?

Googling "rock64": The power of a 10 year old workstation in the size
of a credit card. Zero noise, i hope.


> Many Thanks, Thomas Schmitt.

Give your wife a big hug from little Thomas from germany.


Have a nice day :)

Thomas

Re: libgparted bug.

[Gene Heskett]

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.
> > 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.

>  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.

Now I am puzzled. This  machine just did an unrequested reboot. I have 
gkrellm watching things and I don't see a thing out of line. Temps are 
all 40C or below, voltages are nominal + maybe 5%, stable as always. I 
had to kill several copies of kmail before I found them all, then 
restarted bin/mailwatcher, and it restarted kmail at exactly where it 
was shut down.  One of those things that make you go hum.

Twasn't a power bump, there was no blink to the overhead lights, and 
there is a ups that will run it right past a failure long enough to 
start the 20kw standby. So I have not a clue.

-- 
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 

Re: libgparted bug.

[Gene Heskett]

On Saturday 10 February 2018 10:53:25 Thomas Schmitt wrote:

> Hi,
>
> and again a miscalculation by differing block sizes.
>
> The adventurous proposal would be useless because working somewhere
> in the still undamaged part of the image file.
> skip= and seek= must be the numbers for blocks of 512 bytes rather
> than of 64 KiB.
>
> So this proposal should have been
>
>   dd if=/dev/sdd bs=512 skip=16500703 count=66 \
>  of=rock-img-shrunk.img seek=16500703
>
>
Which was an instant return claiming 66 blocks had been copied.

gdisk is still fussing.
gene@coyote:~/rock64.imgs$ gdisk -l rock-img-shrunk.img
GPT fdisk (gdisk) version 0.8.5

Warning! Disk size is smaller than the main header indicates! Loading
secondary header from the last sector of the disk! You should use 'v' to
verify disk integrity, and perhaps options on the experts' menu to repair
the disk.
Caution: invalid backup GPT header, but valid main header; regenerating
backup header from main header.

Warning! Error 25 reading partition table for CRC check!
Warning! One or more CRCs don't match. You should repair the disk!

Partition table scan:
  MBR: protective
  BSD: not present
  APM: not present
  GPT: damaged


Caution: Found protective or hybrid MBR and corrupt GPT. Using GPT, but 
disk
verification and recovery are STRONGLY recommended.

Disk rock-img-shrunk.img: 16500769 sectors, 7.9 GiB
Logical sector size: 512 bytes
Disk identifier (GUID): 1C7D4C86-35A6-4E6A-B3E3-2A6BEB44FDD0
Partition table holds up to 128 entries
First usable sector is 34, last usable sector is 125171678
Partitions will be aligned on 64-sector boundaries
Total free space is 108670973 sectors (51.8 GiB)

Number  Start (sector)End (sector)  Size   Code  Name
   1  648063   3.9 MiB 8300  loader1
   280648191   64.0 KiB8300  reserved1
   38192   16383   4.0 MiB 8300  reserved2
   4   16384   24575   4.0 MiB 8300  loader2
   5   24576   32767   4.0 MiB 8300  atf
   6   32768  262143   112.0 MiB   0700  boot
   7  26214416500735   7.7 GiB 8300  root
gene@coyote:~/rock64.imgs$
> Have a nice day :)
>
> Thomas

All three of these cards will boot the rock64, but two snags.

1. at around 7 to 10 seconds into the boot, after having discovered the 
spinning rust drive plugged into the usb-3 port, everything stops for 90 
seconds, and it been doing this for quit a while. I assume its doing a 
silent e2fsck. Then after some more blather,

2. it reports the root account is locked and that I should press enter. 
Nothing else seems to happen until I press enter, at which point it 
starts xfce into what looks like a normal gui. And it appears everything 
except synaptic works from the menu's. And to get synaptic to run on 
stretch is different from jessie, whereas on wheezy its a simple 
synaptic-pkexec, from any login on my net, put in the passwd for myself 
and bob's your uncle. Somebodies paranoia is excessive IMNSHO.

Oh, and 3. it did not autoresize part7 during the boot, so I am assuming 
a need to touch a file to make that happen again.
So now I have 3 cards that will all boot and run.

Now I have to learn how to do a manual make install, probably with mc 
since this is a "u-boot" booter.  No grub , no lilo.

I wonder who that expert might be?

Many Thanks, Thomas Schmitt.

-- 
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 

Re: libgparted bug.

[David Wright]

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. 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?

 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.

Re: libgparted bug.

[Thomas Schmitt]

Hi,

and again a miscalculation by differing block sizes.

The adventurous proposal would be useless because working somewhere
in the still undamaged part of the image file.
skip= and seek= must be the numbers for blocks of 512 bytes rather than
of 64 KiB.

So this proposal should have been

  dd if=/dev/sdd bs=512 skip=16500703 count=66 \
 of=rock-img-shrunk.img seek=16500703


Have a nice day :)

Thomas

Re: libgparted bug.

[Thomas Schmitt]

Hi,

Gene Heskett wrote:
> Warning! Secondary partition table overlaps the last partition by
> 33 blocks!

Sorry, my mistake. I should have staid with my first rough estimation
of 8 GiB = 131072 * 64 KiB.
Actually i missed the safe size by just one chunk of 64 KiB.

128913 would have been enough. But 131072 looks more like a lucky number.
And safer against my miscalculations !

All was well before gdisk was allowed to write to the image file.
Now its last 33 blocks of 512 bytes are spoiled.

Do not forget to umount all partitions of the original /dev/sdd before
starting again to copy it to the image file.

After the next copy from original sdd to file, first copy the file to
the new card, and only then let gdisk access it for tests.

Let gdisk repair the backup GPT on the new card, because it must be
adapted to that storage size anyway.

---
What happened and why i am to blame:

> gene@coyote:~/rock64.imgs$ /sbin/gdisk  rock-img-shrunk.img
> Warning! Disk size is smaller than the main header indicates!

True. The "disk" is now the data file. But the GPT header still knows
the block address of the backup GPT header, which is the last usable
block on the original storage medium.

> Caution: invalid backup GPT header

True. "Not there" is surely "invalid".

> Warning! One or more CRCs don't match. You should repair the disk!

True. We will let gdisk handle these GPT damages ...
... but i should have thunk in advance and should have warned of
letting gdisk write to the image file.

On the second run of gdisk:
> gene@coyote:~/rock64.imgs$ /sbin/gdisk  rock-img-shrunk.img
> ...
> Warning! Secondary partition table overlaps the last partition by
> 33 blocks!

Duh. When telling the dd size i forgot to account for a new backup GPT.
As said, the backup GPT header goes to the last block of the "disk".
Obviously gdisk wrote it and 32 blocks before that position
for the backup GPT array with 128 possible partition slots.

Stupid enough to do it, smart enough to tell us that we now need
to repair it. Grrr at gdisk.
And this all for a backup GPT which becomes invalid again after the
image is copied onto a real storage device. Grrr at myself.
(You did not by chance copy the image to sdd before the first write
 by gdisk, did you ?)

Partition 7 ends at 512-byte block 16500735, including it. 
So safe against gdisk's repair work would be at least
16500736 + 33 = 16500769 blocks.
In chunks of 64 KiB that's 128912.2578125. Rounded up: 128913


If you are adventurous enough and if the original sdd partition 7 was
not mounted since you made the recent copy to rock-img-shrunk.img,
then you could make a small block copy from original card to the image
file. Just enough to repair the overwritten partition end and to add
enough room for the backup GPT:

  dd if=/dev/sdd bs=512 skip=128879 count=66 \
 of=rock-img-shrunk.img seek=128879

This would restore the 33 overwritten blocks and add 33 victim blocks
for gdisk - if you at all let it touch the image file before it is safely
copied to the memory card.
A higher count= would add more safety bumper to the image end.

But do this only if there is surely no risk that a filesystem driver had
write access to partition 7.
Else repeat the whole copying with surely all partitions of the card
not being mounted.


Have a nice day :)

Thomas

Re: libgparted bug.

[Gene Heskett]

On Saturday 10 February 2018 03:57:57 Thomas Schmitt wrote:

> Hi,
>
> i wrote:
> > > your count=122070 was too small. It should have been 128912.
>
> Gene Heskett wrote:
> > the backup GPT table, if it exists, is actually at the end
> > of the disk, after another 50Gb of of 's. But how do I "fix" the
> > file?
>
> Partition editors suitable for GPT are supposed to be able to create
> a new backup GPT at the end of the storage medium. Of course this
> makes few sense in the image file, because it does not have the final
> medium size and also because yours is too short anyway.
>
> > Blame that on gparted which did not update the ending GPT table when
> > I shrank part 7 from 59.6 GB to about 7
>
> The backup GPT is always at the very end of the storage device. Not
> necessarily directly after the last allocated partition.
> (That's why GPT is less suitable for image files as would be MBR
> partition table, which has reference to the size of the final storage
> medium.)
>
> > gdisk /dev/sdd
> > x
> > e
> > w
> > seems to have fixed that, gparted is now as happy as a clam.
>
> Formally your GPT is ok now. But to my computation, the last ~ 450 MB
> of your partition 7 are not filled with bytes from the original card.
> This range rather contains bytes which were on the new card already
> before you copied the image file onto it. (Not really random, but
> quite surely not matching the data which were valid on the original
> card.)
>
> You could test this with the image file, by mounting partition 7 and
> checking whether all its data files are fully readable:
>
>   mkdir /mnt/partition7
>   mount -o loop,offset=134217728 rock-img-shrunk.img /mnt/partition7
>   tar cf /dev/null /mnt/partition7
>   umount /mnt/partition7
>   rmdir /mnt/partition7
>
> (134217728 = partition start 262144 * 512 bytes per block)
>
> If the directory tree of the filesystem in partition 7 refers to files
> in a missing end piece of the partition, then you should see an i/o
> error from tar while it copies all file content into /dev/null.
>
> This will not yield i/o errors on /dev/sdd, because there you have
> readable bytes at the end of the partition. They are just not those
> which should sit there, to my theory.
>
>
> But i seem to be out of sync with your endeavor:
>
> How did you now manage to get rock-img-shrunk.img onto the new
> /dev/sdd ? To my account, this was not yet achieved when you sent the
> mail with Date: Fri, 9 Feb 2018 12:22:54 -0500
> which reported an MBR partition table with partition 1 starting at
> block 32768 and containing "HPFS/NTFS/exFAT".
>
Have 3 identical 64gb samsungs laying here, its possible I wrote the 2nd 
one twice, and that was in fact an unwritten new card. Writing to it 
again was successfull.

But I have now used the src card to regenerate the file, which is now 
844837683 bytes long, and perhaps a valid file. But not yet according to 
gdisk:
=Disk rock-img-shrunk.img: 16500736 sectors, 7.9 GiB
Logical sector size: 512 bytes
Disk identifier (GUID): 1C7D4C86-35A6-4E6A-B3E3-2A6BEB44FDD0
Partition table holds up to 128 entries
First usable sector is 34, last usable sector is 125171678
Partitions will be aligned on 64-sector boundaries
Total free space is 108670973 sectors (51.8 GiB)

Number  Start (sector)End (sector)  Size   Code  Name
   1  648063   3.9 MiB 8300  loader1
   280648191   64.0 KiB8300  reserved1
   38192   16383   4.0 MiB 8300  reserved2
   4   16384   24575   4.0 MiB 8300  loader2
   5   24576   32767   4.0 MiB 8300  atf
   6   32768  262143   112.0 MiB   0700  boot
   7  26214416500735   7.7 GiB 8300  root

So:
gene@coyote:~/rock64.imgs$ /sbin/gdisk  rock-img-shrunk.img
GPT fdisk (gdisk) version 0.8.5

Warning! Disk size is smaller than the main header indicates! Loading
secondary header from the last sector of the disk! You should use 'v' to
verify disk integrity, and perhaps options on the experts' menu to repair
the disk.
Caution: invalid backup GPT header, but valid main header; regenerating
backup header from main header.

Warning! Error 25 reading partition table for CRC check!
Warning! One or more CRCs don't match. You should repair the disk!

Partition table scan:
  MBR: protective
  BSD: not present
  APM: not present
  GPT: damaged
==
snip some gdisk blather
==
gxpert command (? for help): v

Caution: The CRC for the backup partition table is invalid. This table 
may
be corrupt. This program will automatically create a new backup partition
table when you save your partitions.

Warning! Secondary partition table overlaps the last partition by
33 blocks!
You will need to delete this partition or resize it in another utility.

Identified 2 problems!

Expert command (? for help): disk is still unhappy:

And it won't write. Sigh.
>
> Have a nice day :)
>
> Thomas

And despite 

Re: libgparted bug.

[Gene Heskett]

On Saturday 10 February 2018 02:55:08 deloptes wrote:

> David Wright wrote:
> > Well, as I explained, I don't use a DE so I wouldn't have a clue.
> > There presumably are people here who use TDE. I see it mentioned
> > a lot.
>
> I use the 14.1 - DEV version, but also in previous one I have never
> experienced automounting.
> Could be that Gene installed automount package and it is not working
> as expected?
>
> I don't have that big file to test khexedit - I test with 1GB+, but it
> displayed properly.
>
> regards

It loaded slow, but displayed ok. Biggest problem is only one way to 
scroll, one 16 byte line at a time. Would have taken an indeterminate 
but measured in days time, to scroll thru an 8Gb file. The recommened 
hexdump -C did the scrolling about 25x faster, and only took 5 or 6 
hours to answer the question, was there a gpt table at the end of it, 
the answer of course was no.

Someone else did some math and said my count for the dd invocation I used 
should have gone another half a megabyte.

So I'm going to scroll back up the list, and make another image to see if 
that solves the problem.

-- 
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 

Re: libgparted bug.

[Thomas Schmitt]

Hi,

i wrote:
> > your count=122070 was too small. It should have been 128912. 

Gene Heskett wrote:
> the backup GPT table, if it exists, is actually at the end 
> of the disk, after another 50Gb of of 's. But how do I "fix" the 
> file?

Partition editors suitable for GPT are supposed to be able to create
a new backup GPT at the end of the storage medium. Of course this makes
few sense in the image file, because it does not have the final medium
size and also because yours is too short anyway.


> Blame that on gparted which did not update the ending GPT table when I 
> shrank part 7 from 59.6 GB to about 7

The backup GPT is always at the very end of the storage device. Not
necessarily directly after the last allocated partition.
(That's why GPT is less suitable for image files as would be MBR partition
table, which has reference to the size of the final storage medium.)


> gdisk /dev/sdd
> x
> e
> w
> seems to have fixed that, gparted is now as happy as a clam.

Formally your GPT is ok now. But to my computation, the last ~ 450 MB
of your partition 7 are not filled with bytes from the original card.
This range rather contains bytes which were on the new card already before
you copied the image file onto it. (Not really random, but quite surely not
matching the data which were valid on the original card.)

You could test this with the image file, by mounting partition 7 and
checking whether all its data files are fully readable:

  mkdir /mnt/partition7
  mount -o loop,offset=134217728 rock-img-shrunk.img /mnt/partition7
  tar cf /dev/null /mnt/partition7
  umount /mnt/partition7
  rmdir /mnt/partition7

(134217728 = partition start 262144 * 512 bytes per block)

If the directory tree of the filesystem in partition 7 refers to files
in a missing end piece of the partition, then you should see an i/o error
from tar while it copies all file content into /dev/null.

This will not yield i/o errors on /dev/sdd, because there you have
readable bytes at the end of the partition. They are just not those
which should sit there, to my theory.


But i seem to be out of sync with your endeavor:

How did you now manage to get rock-img-shrunk.img onto the new /dev/sdd ?
To my account, this was not yet achieved when you sent the mail with
  Date: Fri, 9 Feb 2018 12:22:54 -0500
which reported an MBR partition table with partition 1 starting at
block 32768 and containing "HPFS/NTFS/exFAT".


Have a nice day :)

Thomas

Re: libgparted bug.

[deloptes]

David Wright wrote:

> Well, as I explained, I don't use a DE so I wouldn't have a clue.
> There presumably are people here who use TDE. I see it mentioned
> a lot.

I use the 14.1 - DEV version, but also in previous one I have never
experienced automounting.
Could be that Gene installed automount package and it is not working as
expected?

I don't have that big file to test khexedit - I test with 1GB+, but it
displayed properly.

regards

Re: libgparted bug.

[Gene Heskett]

On Friday 09 February 2018 14:37:16 Thomas Schmitt wrote:

> Hi,
>
> your count=122070 was too small. It should have been 128912. See
> below.
>
> Gene Heskett wrote:
> > gene@coyote:~/rock64.imgs$ /sbin/gdisk -l rock-img-shrunk.img
> > [...]
> > Caution: invalid backup GPT header, but valid main header;
> > regenerating backup header from main header.
>
> You cut off ~ 56 GB of the original device data. At the very end of
> the original there is the GPT backup copy. So it was not copied.
>
> > Warning! One or more CRCs don't match. You should repair the disk!
>
> This is not a good sign. GPT has checksums in the header block. One
> for the header itself and one for the partition entries array.
> If any does not match, then some partition editing did not what it
> was supposed to do.
> Well, old sins ...
>
> > Total free space is 108670973 sectors (51.8 GiB)
>
> gdisk seems still to believe in the size which it found in the copied
> GPT header block. Hopefully this misbelief would end if the image was
> copied successfully to a new storage medium.
> Nevertheless, gdisk or an other partition editor will then have to
> adjust this size field in the GPT (and the checksums) to the real
> storage device size.
>
> > Number  Start (sector)End (sector)  Size   Code  Name
> >1  648063   3.9 MiB 8300  loader1
> >280648191   64.0 KiB8300  reserved1
> >38192   16383   4.0 MiB 8300  reserved2
> >4   16384   24575   4.0 MiB 8300  loader2
> >5   24576   32767   4.0 MiB 8300  atf
> >6   32768  262143   112.0 MiB   0700  boot
> >7  26214416500735   7.7 GiB 8300  root
>
> The first six partitions should be like on the original card.
> I am not so sure about number 7.
> Does it have the same size on the original card ?
>
> If it is like on the original:
> For a good copy up to the end of partition 7 you would have had to
> copy  16500735*512/65336 = 128912 blocks.
>
> So now your copy lacks the last 6842 * 65336 = 447,028,912 bytes of
> partition 7.
> With a copy of 128912 * 64 KiB the image file should be good and you'd
> only have to solve the riddle why the new card did not take the bytes
> you copied to it (or why it put them at the wrong place).

Blame that on gparted which did not update the ending GPT table when I 
shrank part 7 from 59.6 GB to about 7 so it would fit on a smaller sd 
card. but:
gdisk /dev/sdd
x
e
w

seems to have fixed that, gparted is now as happy as a clam.

> Have a nice day :)
>
> Thomas



-- 
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 

Re: libgparted bug.

[Gene Heskett]

On Friday 09 February 2018 14:28:15 Brian wrote:

> On Fri 09 Feb 2018 at 10:52:08 -0800, Don Armstrong wrote:
> > On Fri, 09 Feb 2018, Gene Heskett wrote:
> > > I killed udev for /dev/sdd, gparted works now. But I really need a
> > > quicker way than editing a udev rule. I wonder if I could make
> > > udev aware that gparted was running.
> >
> > udev doesn't automount by default;[1] it's likely just exposing the
> > fact that a device has been inserted with specific parameters to
> > whatever (some DE?) is doing the automounting.
>
> Gene Heskett is probably using an outdated, unsupported version
> of Debian. etch, potato. squeeze, that sort of thing. So there is
> little point in looking for a fundamental cause of the observation.
>
Wheezy, up to date a/o yesterday. /dev/ssd is not in my /etc/fstab. Yes. 
its old but not unsupported yet.

> On something more modern, udev will automount if the device is
> listed in /etc/fstab and is accessed. So not by default - but it
> can be arranged.
>
> > 1: At least, it doesn't here, and I haven't specifically changed
> > this configuration.
>
> LABEL=ARCHIVE-9 /media/ARCHIVE-9 vfat
> ro,gid=1000,fmask=0117,dmask=0007,noatime,noauto,user,x-systemd.automo
>unt,x-systemd.idle-timeout=5,x-systemd.device-timeout=1 0 0
>
> mounts the device and unmounts it five seconds after it is ceased
> to be used.
>
> A really nice feature of systemd. systemd.mount(5).

Sounds usefull. But I'm not there yet because of linuxcnc. I do have one 
machine running jessie, on a pi, and that works well for any i/o that 
doesn't have to go thru its internal usb2 hub. But keyboard and mouse 
events are unarmed in that gateway, and only get thru around 95% of the 
time. The fun part is the constant reboot until you hit a boot where it 
works. But it may take 5 or 6 reboots to get to that condition. When it 
works,
pi@picnc:~/linuxcnc/configs/sheldon-lathe $ uptime
 17:38:24 up 33 days, 21:55,  3 users,  load average: 0.23, 0.20, 0.17
uptimes are quite decent as above.

What I've seen of stretch has required a big piss-elm club to get it to 
march to my drummer, but when thats been done, it marches very well 
indeed. buildbot.Linuxcnc.org hasn't added an arm64 build to their 
offerings, but this rock64 built it from src in under 45 minutes. And a 
v4.14.15-rt13 kernel from vger built in:
real98m19.596s
user90m16.652s
sys 6m6.884s

And I'm probably building stuff it will never use yet.
The pi might be able to do that, but the times would like watching an oil 
based paint dry, likely days instead of minutes.

That kernel above is why I need the copies, as no one has yet wrote a 
kernel make install that works on a u-boot system. So that part will be 
dragging both the spinning rust where that kernel is living, in here, 
and figuring out how to erase whats there for ayufan's kernel, and put 
my v4.14.15-rt13 bits and pieces in its place. But probably not yet 
tonight as its dinner time and I need to go see what my dear woman wants 
to eat. I am now her caretaker. She fell and broke a hip a year ago, but 
is so far down with copd that there will not be a recovery even after it 
was replaced. Dragging an oxygen hose, the 10 feet to a potty chair 
takes a half hour to recover from. A Good Christian woman, she's 
tolerated me for 29 years now.

This is the "till death do us part", part.

-- 
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 

Re: libgparted bug.

[Gene Heskett]

On Friday 09 February 2018 14:11:27 Gene Heskett wrote:

> On Friday 09 February 2018 13:56:35 David Wright wrote:
> > On Fri 09 Feb 2018 at 12:34:05 (-0500), Gene Heskett wrote:
> > > On Friday 09 February 2018 11:50:46 David Wright wrote:
> > > > On Fri 09 Feb 2018 at 04:20:51 (-0500), Gene Heskett wrote:
> > > > > On Friday 09 February 2018 04:11:42 Thomas Schmitt wrote:
> > > > > > Hi,
> > > > > >
> > > > > > Gene Heskett wrote:
> > > > > > > That is not the problem, something is automounting the
> > > > > > > partition as soon as gparted unmounts the SOB, so by the
> > > > > > > time you start the resize, its mounted again and gparted
> > > > > > > is locked out.
> > > > > >
> > > > > > If explicit unmounting does not help, and if manual
> > > > > > execution of the gparted helper programs shows the same
> > > > > > problems, then you will have to do it without resizing. I.e.
> > > > > > the oldfashioned way of making a new partition with a new
> > > > > > filesystem into which you copy the files of the old
> > > > > > filesystem.
> > > > > >
> > > > > >
> > > > > > Have a nice day :)
> > > > > >
> > > > > > Thomas
> > > > >
> > > > > I killed udev for /dev/sdd, gparted works now. But I really
> > > > > need a quicker way than editing a udev rule. I wonder if I
> > > > > could make udev aware that gparted was running.  That would be
> > > > > ideal. So would meaningfull gparted error reporting without
> > > > > having to wade thru a kilobyte of (spit) html. I'm going back
> > > > > to bed...
> > > >
> > > > Would I be write in thinking that killing sdd just there
> > > > prevents the
> >
> >↑ I'll write "correct" next time. You'd think I, of
> > all people, could spell that word.
> >
> > > > appearance of /dev/disk/by-{this,that and the other} appearing
> > > > also?
> > >
> > > It must be doing an end run by that means. Can that be fixed too?
> >
> > Circumvent what by what? Are those files there or not? I don't know
> > what you mean by "fixing" until you say whether they're there and
> > whether they're desired.
> >
> > > > Do you run with a DE? What would happen if you tried all this in
> > > > a VC before starting X? My experience of wheezy, jessie (which
> > > > you're running?) and stretch is that nothing has ever
> > > > automounted itself unless I boot from a live stick. But I only
> > > > run fvwm.
> > >
> > > This machine is running TDE as its x-gui, r14.0.5 it says.
> >
> > Well, isn't that why things get automounted, then? ISTR people doing
> > similar battles when their disc burners tried to automount blank
> > discs. You had to turn it off somewhere.
> >
> > Cheers,
> > David.
>
> somewhere. That was the implied question.

As for looking at that file, hexdump finally got to the end of it, and 
reports:
1961ff5b0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 
00  ||
*
1dcd6

Which tells me the backup GPT table, if it exists, is actually at the end 
of the disk, after another 50Gb of of 's. But how do I "fix" the 
file?

Ran my script again, hexdump thinks its ok, gdisk says:
I might fix it with the x->e function so I did. Quit, reran it, looks ok, 
quit and reran gparted, which is also happy. Time to go to the garage 
and play in the fast lane. 

Now, if it won't boot the original card, which I haven't fixed with gdisk 
x,e,w but will boot the other 2 two, I'll be a happy camper

Later, and thank you for all the advice.



-- 
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 

Re: libgparted bug.

[David Wright]

On Fri 09 Feb 2018 at 14:11:27 (-0500), Gene Heskett wrote:
> On Friday 09 February 2018 13:56:35 David Wright wrote:
> 
> > On Fri 09 Feb 2018 at 12:34:05 (-0500), Gene Heskett wrote:
> > > On Friday 09 February 2018 11:50:46 David Wright wrote:
> > > > On Fri 09 Feb 2018 at 04:20:51 (-0500), Gene Heskett wrote:
> > > > > On Friday 09 February 2018 04:11:42 Thomas Schmitt wrote:
> > > > > > Hi,
> > > > > >
> > > > > > Gene Heskett wrote:
> > > > > > > That is not the problem, something is automounting the
> > > > > > > partition as soon as gparted unmounts the SOB, so by the
> > > > > > > time you start the resize, its mounted again and gparted is
> > > > > > > locked out.
> > > > > >
> > > > > > If explicit unmounting does not help, and if manual execution
> > > > > > of the gparted helper programs shows the same problems, then
> > > > > > you will have to do it without resizing. I.e. the oldfashioned
> > > > > > way of making a new partition with a new filesystem into which
> > > > > > you copy the files of the old filesystem.
> > > > > >
> > > > > >
> > > > > > Have a nice day :)
> > > > > >
> > > > > > Thomas
> > > > >
> > > > > I killed udev for /dev/sdd, gparted works now. But I really need
> > > > > a quicker way than editing a udev rule. I wonder if I could make
> > > > > udev aware that gparted was running.  That would be ideal. So
> > > > > would meaningfull gparted error reporting without having to wade
> > > > > thru a kilobyte of (spit) html. I'm going back to bed...
> > > >
> > > > Would I be write in thinking that killing sdd just there prevents
> > > > the
> >
> >↑ I'll write "correct" next time. You'd think I, of all
> >  people, could spell that word.
> >
> > > > appearance of /dev/disk/by-{this,that and the other} appearing
> > > > also?
> > >
> > > It must be doing an end run by that means. Can that be fixed too?
> >
> > Circumvent what by what? Are those files there or not? I don't know
> > what you mean by "fixing" until you say whether they're there and
> > whether they're desired.
> >
> > > > Do you run with a DE? What would happen if you tried all this in a
> > > > VC before starting X? My experience of wheezy, jessie (which
> > > > you're running?) and stretch is that nothing has ever automounted
> > > > itself unless I boot from a live stick. But I only run fvwm.
> > >
> > > This machine is running TDE as its x-gui, r14.0.5 it says.
> >
> > Well, isn't that why things get automounted, then? ISTR people doing
> > similar battles when their disc burners tried to automount blank
> > discs. You had to turn it off somewhere.
> >
> > Cheers,
> > David.
> 
> somewhere. That was the implied question.

Well, as I explained, I don't use a DE so I wouldn't have a clue.
There presumably are people here who use TDE. I see it mentioned
a lot.

No, I was more interested in your nobbling of sdd in rules.d and
whether that had the consequence of preventing the creation of
the appropriate symlinks under /dev/disk/. It seemed somewhat
brutal; I thought there might be side effects.

Cheers,
David.

Re: libgparted bug.

[Thomas Schmitt]

Hi,

your count=122070 was too small. It should have been 128912. See below.


Gene Heskett wrote:
> gene@coyote:~/rock64.imgs$ /sbin/gdisk -l rock-img-shrunk.img
> [...]
> Caution: invalid backup GPT header, but valid main header; regenerating
> backup header from main header.

You cut off ~ 56 GB of the original device data. At the very end of the
original there is the GPT backup copy. So it was not copied.

> Warning! One or more CRCs don't match. You should repair the disk!

This is not a good sign. GPT has checksums in the header block. One
for the header itself and one for the partition entries array.
If any does not match, then some partition editing did not what it
was supposed to do.
Well, old sins ...

> Total free space is 108670973 sectors (51.8 GiB)

gdisk seems still to believe in the size which it found in the copied
GPT header block. Hopefully this misbelief would end if the image was
copied successfully to a new storage medium.
Nevertheless, gdisk or an other partition editor will then have to
adjust this size field in the GPT (and the checksums) to the real
storage device size.

> Number  Start (sector)End (sector)  Size   Code  Name
>1  648063   3.9 MiB 8300  loader1
>280648191   64.0 KiB8300  reserved1
>38192   16383   4.0 MiB 8300  reserved2
>4   16384   24575   4.0 MiB 8300  loader2
>5   24576   32767   4.0 MiB 8300  atf
>6   32768  262143   112.0 MiB   0700  boot
>7  26214416500735   7.7 GiB 8300  root

The first six partitions should be like on the original card.
I am not so sure about number 7.
Does it have the same size on the original card ?

If it is like on the original:
For a good copy up to the end of partition 7 you would have had to
copy  16500735*512/65336 = 128912 blocks.

So now your copy lacks the last 6842 * 65336 = 447,028,912 bytes of
partition 7.
With a copy of 128912 * 64 KiB the image file should be good and you'd
only have to solve the riddle why the new card did not take the bytes
you copied to it (or why it put them at the wrong place).


Have a nice day :)

Thomas

Re: libgparted bug.

[Brian]

On Fri 09 Feb 2018 at 10:52:08 -0800, Don Armstrong wrote:

> On Fri, 09 Feb 2018, Gene Heskett wrote:
> > I killed udev for /dev/sdd, gparted works now. But I really need a
> > quicker way than editing a udev rule. I wonder if I could make udev
> > aware that gparted was running.
> 
> udev doesn't automount by default;[1] it's likely just exposing the fact
> that a device has been inserted with specific parameters to whatever
> (some DE?) is doing the automounting.

Gene Heskett is probably using an outdated, unsupported version
of Debian. etch, potato. squeeze, that sort of thing. So there is
little point in looking for a fundamental cause of the observation.

On something more modern, udev will automount if the device is
listed in /etc/fstab and is accessed. So not by default - but it
can be arranged.

> 1: At least, it doesn't here, and I haven't specifically changed this
> configuration.

LABEL=ARCHIVE-9 /media/ARCHIVE-9 vfat 
ro,gid=1000,fmask=0117,dmask=0007,noatime,noauto,user,x-systemd.automount,x-systemd.idle-timeout=5,x-systemd.device-timeout=1
 0 0

mounts the device and unmounts it five seconds after it is ceased
to be used.

A really nice feature of systemd. systemd.mount(5).

-- 
Brian

Re: libgparted bug.

[Gene Heskett]

On Friday 09 February 2018 13:56:35 David Wright wrote:

> On Fri 09 Feb 2018 at 12:34:05 (-0500), Gene Heskett wrote:
> > On Friday 09 February 2018 11:50:46 David Wright wrote:
> > > On Fri 09 Feb 2018 at 04:20:51 (-0500), Gene Heskett wrote:
> > > > On Friday 09 February 2018 04:11:42 Thomas Schmitt wrote:
> > > > > Hi,
> > > > >
> > > > > Gene Heskett wrote:
> > > > > > That is not the problem, something is automounting the
> > > > > > partition as soon as gparted unmounts the SOB, so by the
> > > > > > time you start the resize, its mounted again and gparted is
> > > > > > locked out.
> > > > >
> > > > > If explicit unmounting does not help, and if manual execution
> > > > > of the gparted helper programs shows the same problems, then
> > > > > you will have to do it without resizing. I.e. the oldfashioned
> > > > > way of making a new partition with a new filesystem into which
> > > > > you copy the files of the old filesystem.
> > > > >
> > > > >
> > > > > Have a nice day :)
> > > > >
> > > > > Thomas
> > > >
> > > > I killed udev for /dev/sdd, gparted works now. But I really need
> > > > a quicker way than editing a udev rule. I wonder if I could make
> > > > udev aware that gparted was running.  That would be ideal. So
> > > > would meaningfull gparted error reporting without having to wade
> > > > thru a kilobyte of (spit) html. I'm going back to bed...
> > >
> > > Would I be write in thinking that killing sdd just there prevents
> > > the
>
>↑ I'll write "correct" next time. You'd think I, of all
>  people, could spell that word.
>
> > > appearance of /dev/disk/by-{this,that and the other} appearing
> > > also?
> >
> > It must be doing an end run by that means. Can that be fixed too?
>
> Circumvent what by what? Are those files there or not? I don't know
> what you mean by "fixing" until you say whether they're there and
> whether they're desired.
>
> > > Do you run with a DE? What would happen if you tried all this in a
> > > VC before starting X? My experience of wheezy, jessie (which
> > > you're running?) and stretch is that nothing has ever automounted
> > > itself unless I boot from a live stick. But I only run fvwm.
> >
> > This machine is running TDE as its x-gui, r14.0.5 it says.
>
> Well, isn't that why things get automounted, then? ISTR people doing
> similar battles when their disc burners tried to automount blank
> discs. You had to turn it off somewhere.
>
> Cheers,
> David.

somewhere. That was the implied question.

-- 
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 

Re: libgparted bug.

[Gene Heskett]

On Friday 09 February 2018 13:13:42 Thomas Schmitt wrote:

> Hi,
>
> Gene Heskett wrote:
> > When did fdisk learn about GPT part tables?
>
> Dunno. It recognizes GPT by type "ee" of the "Protective MBR" entry in
>
> the partition table of the MBR:
> >  Device Boot   Start End  Blocks   Id 
> > System rock-img-shrunk.img 1  1   12517171162585855+
> >  ee  GPT
>
> For further investigations use gdisk:
>
>   /sbin/gdisk -l rock-img-shrunk.img
>
> which should show the partitions you know.
gene@coyote:~/rock64.imgs$ /sbin/gdisk -l rock-img-shrunk.img
GPT fdisk (gdisk) version 0.8.5

Warning! Disk size is smaller than the main header indicates! Loading
secondary header from the last sector of the disk! You should use 'v' to
verify disk integrity, and perhaps options on the experts' menu to repair
the disk.
Caution: invalid backup GPT header, but valid main header; regenerating
backup header from main header.

Warning! Error 25 reading partition table for CRC check!
Warning! One or more CRCs don't match. You should repair the disk!

Partition table scan:
  MBR: protective
  BSD: not present
  APM: not present
  GPT: damaged


Caution: Found protective or hybrid MBR and corrupt GPT. Using GPT, but 
disk
verification and recovery are STRONGLY recommended.

Disk rock-img-shrunk.img: 15624960 sectors, 7.5 GiB
Logical sector size: 512 bytes
Disk identifier (GUID): 1C7D4C86-35A6-4E6A-B3E3-2A6BEB44FDD0
Partition table holds up to 128 entries
First usable sector is 34, last usable sector is 125171678
Partitions will be aligned on 64-sector boundaries
Total free space is 108670973 sectors (51.8 GiB)

Number  Start (sector)End (sector)  Size   Code  Name
   1  648063   3.9 MiB 8300  loader1
   280648191   64.0 KiB8300  reserved1
   38192   16383   4.0 MiB 8300  reserved2
   4   16384   24575   4.0 MiB 8300  loader2
   5   24576   32767   4.0 MiB 8300  atf
   6   32768  262143   112.0 MiB   0700  boot
   7  26214416500735   7.7 GiB 8300  root

Humm, atf? Decode plz. This is (presumably) a u-boot machine, no grub 
stuff to be found.

Thanks.
>
> > gene@coyote:~/rock64.imgs$  /sbin/fdisk -l /dev/sdd
> >   Device Boot   Start End  Blocks   Id  System
> > /dev/sdd 1  32768   125042687625049607 
> > HPFS/NTFS/exFAT
>
> This is probably an unpartitioned "disk" with MS-Windows filesystem.
>
> In any case it is not a copy of rock-img-shrunk.img .
>
>
> Have a nice day :)
>
> Thomas



-- 
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 

Re: libgparted bug.

[David Wright]

On Fri 09 Feb 2018 at 12:34:05 (-0500), Gene Heskett wrote:
> On Friday 09 February 2018 11:50:46 David Wright wrote:
> 
> > On Fri 09 Feb 2018 at 04:20:51 (-0500), Gene Heskett wrote:
> > > On Friday 09 February 2018 04:11:42 Thomas Schmitt wrote:
> > > > Hi,
> > > >
> > > > Gene Heskett wrote:
> > > > > That is not the problem, something is automounting the partition
> > > > > as soon as gparted unmounts the SOB, so by the time you start
> > > > > the resize, its mounted again and gparted is locked out.
> > > >
> > > > If explicit unmounting does not help, and if manual execution of
> > > > the gparted helper programs shows the same problems, then you will
> > > > have to do it without resizing. I.e. the oldfashioned way of
> > > > making a new partition with a new filesystem into which you copy
> > > > the files of the old filesystem.
> > > >
> > > >
> > > > Have a nice day :)
> > > >
> > > > Thomas
> > >
> > > I killed udev for /dev/sdd, gparted works now. But I really need a
> > > quicker way than editing a udev rule. I wonder if I could make udev
> > > aware that gparted was running.  That would be ideal. So would
> > > meaningfull gparted error reporting without having to wade thru a
> > > kilobyte of (spit) html. I'm going back to bed...
> >
> > Would I be write in thinking that killing sdd just there prevents the
   ↑ I'll write "correct" next time. You'd think I, of all
 people, could spell that word.

> > appearance of /dev/disk/by-{this,that and the other} appearing also?
> >
> It must be doing an end run by that means. Can that be fixed too?

Circumvent what by what? Are those files there or not? I don't know
what you mean by "fixing" until you say whether they're there and
whether they're desired.

> > Do you run with a DE? What would happen if you tried all this in a VC
> > before starting X? My experience of wheezy, jessie (which you're
> > running?) and stretch is that nothing has ever automounted itself
> > unless I boot from a live stick. But I only run fvwm.
> >
> This machine is running TDE as its x-gui, r14.0.5 it says.

Well, isn't that why things get automounted, then? ISTR people doing
similar battles when their disc burners tried to automount blank discs.
You had to turn it off somewhere.

Cheers,
David.

Re: libgparted bug.

[Don Armstrong]

On Fri, 09 Feb 2018, Gene Heskett wrote:
> I killed udev for /dev/sdd, gparted works now. But I really need a
> quicker way than editing a udev rule. I wonder if I could make udev
> aware that gparted was running.

udev doesn't automount by default;[1] it's likely just exposing the fact
that a device has been inserted with specific parameters to whatever
(some DE?) is doing the automounting.


1: At least, it doesn't here, and I haven't specifically changed this
configuration.

-- 
Don Armstrong  https://www.donarmstrong.com

Who is thinking this?
I am.
 -- Greg Egan _Diaspora_ p38

Re: libgparted bug.

[Thomas Schmitt]

Hi,

correcting myself:

> > /dev/sdd 1  32768   125042687625049607  HPFS/NTFS/exFAT

> This is probably an unpartitioned "disk" with MS-Windows filesystem.

The "1" probably is the partition number. I mistook it for the boot flag.
So the stick is partitioned with one partition.


Have a nice day :)

Thomas

Re: libgparted bug.

[Thomas Schmitt]

Hi,

Gene Heskett wrote:
> When did fdisk learn about GPT part tables?

Dunno. It recognizes GPT by type "ee" of the "Protective MBR" entry in
the partition table of the MBR:

>  Device Boot   Start End  Blocks   Id  System
> rock-img-shrunk.img 1  1   12517171162585855+  ee  GPT

For further investigations use gdisk:

  /sbin/gdisk -l rock-img-shrunk.img

which should show the partitions you know.


> gene@coyote:~/rock64.imgs$  /sbin/fdisk -l /dev/sdd
>   Device Boot   Start End  Blocks   Id  System
> /dev/sdd 1  32768   125042687625049607  HPFS/NTFS/exFAT

This is probably an unpartitioned "disk" with MS-Windows filesystem.

In any case it is not a copy of rock-img-shrunk.img .


Have a nice day :)

Thomas

Re: libgparted bug.

[Gene Heskett]

On Friday 09 February 2018 11:50:46 David Wright wrote:

> On Fri 09 Feb 2018 at 04:20:51 (-0500), Gene Heskett wrote:
> > On Friday 09 February 2018 04:11:42 Thomas Schmitt wrote:
> > > Hi,
> > >
> > > Gene Heskett wrote:
> > > > That is not the problem, something is automounting the partition
> > > > as soon as gparted unmounts the SOB, so by the time you start
> > > > the resize, its mounted again and gparted is locked out.
> > >
> > > If explicit unmounting does not help, and if manual execution of
> > > the gparted helper programs shows the same problems, then you will
> > > have to do it without resizing. I.e. the oldfashioned way of
> > > making a new partition with a new filesystem into which you copy
> > > the files of the old filesystem.
> > >
> > >
> > > Have a nice day :)
> > >
> > > Thomas
> >
> > I killed udev for /dev/sdd, gparted works now. But I really need a
> > quicker way than editing a udev rule. I wonder if I could make udev
> > aware that gparted was running.  That would be ideal. So would
> > meaningfull gparted error reporting without having to wade thru a
> > kilobyte of (spit) html. I'm going back to bed...
>
> Would I be write in thinking that killing sdd just there prevents the
> appearance of /dev/disk/by-{this,that and the other} appearing also?
>
It must be doing an end run by that means. Can that be fixed too?

> Do you run with a DE? What would happen if you tried all this in a VC
> before starting X? My experience of wheezy, jessie (which you're
> running?) and stretch is that nothing has ever automounted itself
> unless I boot from a live stick. But I only run fvwm.
>
This machine is running TDE as its x-gui, r14.0.5 it says.

> Cheers,
> David.



-- 
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 

Re: libgparted bug.

[Gene Heskett]

On Friday 09 February 2018 11:01:38 Thomas Schmitt wrote:

> Hi,
>
> > # skip rules for inappropriate block devices
> > KERNEL=="fd*|mtd*|nbd*|gnbd*|btibm*|dm-*|md*|sdd",
> > GOTO="persistent_storage_end"
>
> That's a neighbor of where i once stopped to experiment.
> So now:
>
> KERNEL=="fd*|mtd*|nbd*|gnbd*|btibm*|dm-*|md*|zram*|mmcblk[0-9]*rpmb|sr
>4", GOTO="persistent_storage_end"
>
> But still immediate "No medium" and nearly immediate ejection of tray.
> (It seems that it ejects if the previously inserted tray was empty.)
>
> I switched off-and-on the USB box with the drive. No improvement.
> Grrr.
>
> > bs=65536, then count=122,070 covers 8Gb [...]
> > 779520 bytes (8.0 GB) copied, 399.487 s, 20.0 MB/s
>
> Sparsely and only ISO GBs.
> I'd rather assume the larger count=131072 = 8589934592 = 8 GiB.
>
> > dd if=/dev/sdd of=rock-img-shrunk.img bs=65536 count=122070
> > gparted can't see a thing except an empty card. WTF?
>
> Here you copied /dev/sdd to rock-img-shrunk.img.
>
> Quote from the other thread, "a hexeditor please":
> > Used dd to make a file of the first 8Gb, wrote that 8Gb to another
> > identical 64Gb card.
>
> By what command did you copy the file to the other card ?
>
dd if=rock-img-shrunk.img bs=65536 count=122070 of=/dev/sdd
Which is the reverse direction of the command generated that file...

> What do other partition editors report about rock-img-shrunk.img
> and the other card ?
> E.g.
>   /sbin/fdisk -l rock-img-shrunk.img
>   /sbin/fdisk -l /dev/sdd

When did fdisk learn about GPT part tables?

gene@coyote:~/rock64.imgs$   /sbin/fdisk -l rock-img-shrunk.img

WARNING: GPT (GUID Partition Table) detected on 'rock-img-shrunk.img'! 
The util fdisk doesn't support GPT. Use GNU Parted.

Disk rock-img-shrunk.img: 7999 MB, 779520 bytes
255 heads, 63 sectors/track, 972 cylinders, total 15624960 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x

  Device Boot  Start End  Blocks   Id  System
rock-img-shrunk.img 1  1   12517171162585855+  ee  GPT

And
gene@coyote:~/rock64.imgs$  /sbin/fdisk -l /dev/sdd

Disk /dev/sdd: 64.0 GB, 64021856256 bytes
255 heads, 63 sectors/track, 7783 cylinders, total 125042688 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x

   Device Boot  Start End  Blocks   Id  System
/dev/sdd 1  32768   125042687625049607  HPFS/NTFS/exFAT

huh

> (I assume they do not need hdparm -z which lets the kernel re-assess
> the partition table.)
>
> > Do we have a better hex editor?
>
> First parts of partition tables should be to see within the first 1024
> bytes.
>
>   dd if=/dev/sdd bs=1024 count=1 | od -t x1 | less
>
> The partition table of an MBR begins at byte 446, octal: 0676.
> It ends 64 bytes later before 0776, where you should read "55 aa".
>
> GPT header begins at byte 512, octal 01000, by "EFI PART":
>   0001000 45 46 49 20 50 41 52 54 ...
>
>
> Have a nice day :)
>
> Thomas



-- 
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 

Re: libgparted bug.

[David Wright]

On Fri 09 Feb 2018 at 04:20:51 (-0500), Gene Heskett wrote:
> On Friday 09 February 2018 04:11:42 Thomas Schmitt wrote:
> 
> > Hi,
> >
> > Gene Heskett wrote:
> > > That is not the problem, something is automounting the partition as
> > > soon as gparted unmounts the SOB, so by the time you start the
> > > resize, its mounted again and gparted is locked out.
> >
> > If explicit unmounting does not help, and if manual execution of the
> > gparted helper programs shows the same problems, then you will have
> > to do it without resizing. I.e. the oldfashioned way of making a new
> > partition with a new filesystem into which you copy the files of the
> > old filesystem.
> >
> >
> > Have a nice day :)
> >
> > Thomas
> 
> I killed udev for /dev/sdd, gparted works now. But I really need a 
> quicker way than editing a udev rule. I wonder if I could make udev 
> aware that gparted was running.  That would be ideal. So would 
> meaningfull gparted error reporting without having to wade thru a 
> kilobyte of (spit) html. I'm going back to bed...

Would I be write in thinking that killing sdd just there prevents the
appearance of /dev/disk/by-{this,that and the other} appearing also?

Do you run with a DE? What would happen if you tried all this in a VC
before starting X? My experience of wheezy, jessie (which you're
running?) and stretch is that nothing has ever automounted itself
unless I boot from a live stick. But I only run fvwm.

Cheers,
David.

Re: libgparted bug.

[Thomas Schmitt]

Hi,

> # skip rules for inappropriate block devices
> KERNEL=="fd*|mtd*|nbd*|gnbd*|btibm*|dm-*|md*|sdd", 
> GOTO="persistent_storage_end"

That's a neighbor of where i once stopped to experiment.
So now:

KERNEL=="fd*|mtd*|nbd*|gnbd*|btibm*|dm-*|md*|zram*|mmcblk[0-9]*rpmb|sr4", 
GOTO="persistent_storage_end"

But still immediate "No medium" and nearly immediate ejection of tray.
(It seems that it ejects if the previously inserted tray was empty.)

I switched off-and-on the USB box with the drive. No improvement. Grrr.


> bs=65536, then count=122,070 covers 8Gb [...]
> 779520 bytes (8.0 GB) copied, 399.487 s, 20.0 MB/s

Sparsely and only ISO GBs.
I'd rather assume the larger count=131072 = 8589934592 = 8 GiB.


> dd if=/dev/sdd of=rock-img-shrunk.img bs=65536 count=122070
> gparted can't see a thing except an empty card. WTF?

Here you copied /dev/sdd to rock-img-shrunk.img.

Quote from the other thread, "a hexeditor please":
> Used dd to make a file of the first 8Gb, wrote that 8Gb to another
> identical 64Gb card.

By what command did you copy the file to the other card ?

What do other partition editors report about rock-img-shrunk.img 
and the other card ?
E.g.
  /sbin/fdisk -l rock-img-shrunk.img
  /sbin/fdisk -l /dev/sdd

(I assume they do not need hdparm -z which lets the kernel re-assess the
 partition table.)


> Do we have a better hex editor?

First parts of partition tables should be to see within the first 1024 bytes.

  dd if=/dev/sdd bs=1024 count=1 | od -t x1 | less

The partition table of an MBR begins at byte 446, octal: 0676.
It ends 64 bytes later before 0776, where you should read "55 aa".

GPT header begins at byte 512, octal 01000, by "EFI PART":
  0001000 45 46 49 20 50 41 52 54 ...


Have a nice day :)

Thomas

Re: libgparted bug.

[Gene Heskett]

On Friday 09 February 2018 05:17:35 Thomas Schmitt wrote:

> Hi,
>
> > Got the sonofabitch, I added sdd to the ignore line
> > in /lib/udev/rules.d/60-persistent-storage.rules.
>
> What exactly did you do ?
> ("ignore line" does not give me insight when looking at the file.)
>
> > I wonder if I could make udev
> > aware that gparted was running.  That would be ideal.
>
> Ideal would be if the systemd/udev community would take into respect
> that they are not the only ones who want to access devices.
>
> If i execute
>   dd if=/dev/sr4 count=1 of=/dev/null
> while the DVD drive tray is out, then the tray gets pulled in,
> followed by the immediate error message "No medium found", and then
> the tray comes out immediately.
> On a second try, the tray stays in. But again dd reports "No medium
> found" and fails.
>
> I can see the theoretically sufficient waiting loop in function
> sr_do_ioctl() of drivers/scsi/sr_ioctl.c . It should really suffice,
> because i have a similar repetition loop in libburn, and i can see by
> libburn's SCSI log that the drive only emits the expected reply
> messages which should cause the sr_do_ioctl() loop to repeat the SCSI
> command in question.
>
> Everything in the kernel looks like it should work. Nevertheless, some
> entity must be accessing the drive without going through sr_do_ioctl()
> and obviously it has no clue of the peculiarities of a DVD drive.
>
> This looks much like the footprints of systemd and udev.
> I fiddled with 60-persistent-storage.rules too, but could not cause a
> change in behavior.
> Thus my request to see your succeful remedy for sdd.

# skip rules for inappropriate block devices
KERNEL=="fd*|mtd*|nbd*|gnbd*|btibm*|dm-*|md*|sdd", 
GOTO="persistent_storage_end"

The
|sdd
is the addition.

Now to calculate how much of sdd to have dd make a copy of. IOf I use a 
bs=65536, then count=122,070 covers 8Gb, and it says 7.74 now belongs 
toi part 7. The first 6 parts only occupy about 140 megs.
lets see if this gets me a working image once dd'd back to any card 16Gb 
or bigger.

dd if=/dev/sdd of=rock-img-shrunk.img bs=65536 count=122070
Based on my pisspoor short term memory, I wrote me a script to make 
endless copies :-) Now lets see if that works. Seems to be, led in 
reader is blinking.
122070+0 records in
122070+0 records out
779520 bytes (8.0 GB) copied, 399.487 s, 20.0 MB/s

But gparted can't see a thing except an empty card. WTF? Looking thru the 
disk file the above dd invocation generated. Slow slogging with 
khexedit. No scroll bar. Standing on down arrow is 16 bytes a line, some 
data even readable stuff in the first few pages, but its  at 
0004: offset yet. I give up on khexedit, there has to be a better 
tool for BIG files.

So I'll post this, see if the missus is ready for some coffee & see what 
else I can find to inspect this image file that at least has a 
pageup/pagedown function.
>
> Have a nice day :)
>
> Thomas



-- 
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 

Re: libgparted bug.

[Thomas Schmitt]

Hi,

> Got the sonofabitch, I added sdd to the ignore line 
> in /lib/udev/rules.d/60-persistent-storage.rules.

What exactly did you do ?
("ignore line" does not give me insight when looking at the file.)


> I wonder if I could make udev 
> aware that gparted was running.  That would be ideal.

Ideal would be if the systemd/udev community would take into respect that
they are not the only ones who want to access devices.

If i execute
  dd if=/dev/sr4 count=1 of=/dev/null
while the DVD drive tray is out, then the tray gets pulled in, followed by
the immediate error message "No medium found", and then the tray comes out
immediately.
On a second try, the tray stays in. But again dd reports "No medium found"
and fails.

I can see the theoretically sufficient waiting loop in function sr_do_ioctl()
of drivers/scsi/sr_ioctl.c . It should really suffice, because i have a
similar repetition loop in libburn, and i can see by libburn's SCSI log
that the drive only emits the expected reply messages which should cause
the sr_do_ioctl() loop to repeat the SCSI command in question.

Everything in the kernel looks like it should work. Nevertheless, some
entity must be accessing the drive without going through sr_do_ioctl()
and obviously it has no clue of the peculiarities of a DVD drive.

This looks much like the footprints of systemd and udev.
I fiddled with 60-persistent-storage.rules too, but could not cause a
change in behavior.
Thus my request to see your succeful remedy for sdd.


Have a nice day :)

Thomas

Re: libgparted bug.

[Gene Heskett]

On Friday 09 February 2018 04:11:42 Thomas Schmitt wrote:

> Hi,
>
> Gene Heskett wrote:
> > That is not the problem, something is automounting the partition as
> > soon as gparted unmounts the SOB, so by the time you start the
> > resize, its mounted again and gparted is locked out.
>
> If explicit unmounting does not help, and if manual execution of the
> gparted helper programs shows the same problems, then you will have
> to do it without resizing. I.e. the oldfashioned way of making a new
> partition with a new filesystem into which you copy the files of the
> old filesystem.
>
>
> Have a nice day :)
>
> Thomas

I killed udev for /dev/sdd, gparted works now. But I really need a 
quicker way than editing a udev rule. I wonder if I could make udev 
aware that gparted was running.  That would be ideal. So would 
meaningfull gparted error reporting without having to wade thru a 
kilobyte of (spit) html. I'm going back to bed...


-- 
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 

Re: libgparted bug.

[Gene Heskett]

On Friday 09 February 2018 03:52:05 Gene Heskett wrote:

> On Friday 09 February 2018 03:05:23 deloptes wrote:
> > Gene Heskett wrote:
> > > Trying to make a backup image of a 64GB bootable sdcard. Th os say
> > > its 59.b GB when it mounts the original, but pull copy to a file
> > > and its nearly a megabyte bigger than 64gigs.  So obviously the
> > > file is bigger than a brand new unformatted disk.
> >
> > Hi Gene, you should know each partition has header or meta data,
> > that is not visible after mount. I can't recall where, but there was
> > a document (perhaps on Debian) that explained how the meta data
> > looks like. So basically with each partition operation you add a
> > layer on top of the physical device. For example you create a luks
> > partition, it adds some meta data (perhaps 1-2MB), you add a LVM on
> > top it also adds some meta data, you add the partition, it also adds
> > some meta data.
> >
> > The other concern could be that the 64GB are actually GB by 1000
> > (sales GB) and not GiB.
> > For example my HDD and SSD report this
> >
> > sudo fdisk -l /dev/sda
> > Disk /dev/sda: 465.8 GiB, 500107862016 bytes, 976773168 sectors
> >
> > sudo fdisk -l /dev/sdb
> > Disk /dev/sdb: 465.8 GiB, 500107862016 bytes, 976773168 sectors
> >
> > I bought 500GB which seems to be equivalent of 465.8 GiB
>
> I've been playing in the night with gparted, which loads up the
> operating card out of the rockchip, which shows that a bit over 4GiB
> is used out of 59.6GiB for partition 7, the last partition in it, so I
> unmount it, select move/resize, and pull the right end of the gui's
> part 7 bar down to about 10GiB. which then shows 49GiB and change of
> unallocated space.
>
> All of these sd images are shrunken in a similar manner, and once
> installed on whatever size of sd card you have, and that will hold the
> decompressed image, 8 gb is more than enough, and the last partition
> will be autoexpanded on the next boot to allocate the rest of the
> card.
>
> So raspian, ayyufan, and all these guys obviously have a way to do
> this shrinkage down to only whats used.
>
> But running gparted as root, it refuses to resize the SOB so I can
> turn around and reinstall a working system on an 8, 16, 32, 64 or even
> a 128GiB card.
>
> But gparted, running as root, refuses to do it, and its log info makes
> zero sense.
>
> Because I want exactly the same file as you can down load. And this
> includes the stuff I've built and installed to get it to a fully
> working for my purposes install.
>
> But, and heres the but, I have got to be able to make copies of a
> working install, but with a realtime kernel I've built. That way, I
> always have a backup system on the last card that I don't have to
> start over from scratch to rebuild.
>
> Heres that log from telling it to resize part7.
>
> Sorry about the html, but thats how gparted saves it.
>
>  Transitional//EN'
> 'http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd'>  xmlns='http://www.w3.org/1999/xhtml' xml:lang='en-US' lang='en-US'>
> 
> 
> GParted Details
> 
> 
> GParted 0.12.1 --enable-libparted-dmraid
> Libparted 2.3
> 
> 
> 
> Shrink /dev/sdd7 from 59.56 GiB to 6.91
> GiB00:00:01( ERROR )
> 
> 
> 
> 
> 
> 
> 
> 
> calibrate /dev/sdd700:00:00(
> SUCCESS )
> 
> 
> 
> 
> 
> 
> 
> 
> path: /dev/sdd7start: 262,144end: 125,171,678 />size: 124,909,535 (59.56 GiB)
> 
> 
> 
> 
> 
> 
> 
> 
> 
> check file system on /dev/sdd7 for errors and (if possible) fix
> them00:00:00( ERROR )
> 
> 
> 
> 
> 
> 
> 
> 
> e2fsck -f -y -v /dev/sdd7
> 
> 
> 
> 
> 
> 
> 
> 
> /dev/sdd7 is mounted.
> 
> 
> 
> 
> 
> 
> e2fsck 1.42.5 (29-Jul-2012)e2fsck: Cannot continue,
> aborting.
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
>
> Now part7 is NOT mounted which would explain the e2fsck failure.
> Now, it does NOT tell me that e2fsck failed in the messages I see on
> screen.
>
> > Why don't you tar.gz or tar.bz2 your data instead of pulling
> > multiple 0-bytes into backup?
>
> That should be adequately explained above.
>
> > regards
>
>  Transitional//EN'
> 'http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd'>  xmlns='http://www.w3.org/1999/xhtml' xml:lang='en-US' lang='en-US'>
> 
> 
> GParted Details
> 
> 
> GParted 0.12.1 --enable-libparted-dmraid
> Libparted 2.3
> 
> 
> 
> Shrink /dev/sdd7 from 59.56 GiB to 8.34
> GiB00:00:01( ERROR )
> 
> 
> 
> 
> 
> 
> 
> 
> calibrate /dev/sdd700:00:00(
> SUCCESS )
> 
> 
> 
> 
> 
> 
> 
> 
> path: /dev/sdd7start: 262,144end: 125,171,678 />size: 124,909,535 (59.56 GiB)
> 
> 
> 
> 
> 
> 
> 
> 
> 
> check file system on /dev/sdd7 for errors and (if possible) fix
> them00:00:01( ERROR )
> 
> 
> 
> 
> 
> 
> 
> 
> e2fsck -f -y -v /dev/sdd7
> 
> 
> 
> 
> 
> 
> 
> 
> /dev/sdd7 is mounted.
> 
> 
> 
> 
> 
> 
> e2fsck 1.42.5 (29-Jul-2012)e2fsck: Cannot continue,
> aborting.
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
>
>
> So I go back and repeat it, see above and it 

Re: libgparted bug.

[Thomas Schmitt]

Hi,

Gene Heskett wrote:
> That is not the problem, something is automounting the partition as soon 
> as gparted unmounts the SOB, so by the time you start the resize, its 
> mounted again and gparted is locked out.

If explicit unmounting does not help, and if manual execution of the
gparted helper programs shows the same problems, then you will have
to do it without resizing. I.e. the oldfashioned way of making a new
partition with a new filesystem into which you copy the files of the
old filesystem.


Have a nice day :)

Thomas

Re: libgparted bug.

[Gene Heskett]

On Friday 09 February 2018 03:33:38 Thomas Schmitt wrote:

> Hi,
>
> Gene Heskett wrote:
> > Th os say its 59.b GB when it mounts the original
> > [...]
> > gene@coyote:~/rock64.imgs$ dd of=/dev/sdd bs=64k
> > if=working-rock64.img dd: writing `/dev/sdd': No space left on
> > device
> > 976897+0 records in
> > 976896+0 records out
>
> That's the usual confusion between ISO GB (= 1 billion bytes) and
> programmer's GiB (1024 * 1024 * 1024 bytes).
> dd's "k" are programmer's KiB (= 1024).
>
> 976896*64*1024 = 64021856256 = 64.02 ISO GB = 59.63 programmer's GiB.
>
> So it failed when it had already reached the 64 ISO GB limit.
> No chance to return the card to the seller for being undersized, i
> guess.
>
> > So nominally 600k of card disappeared.
>
> The old card is obviously slightly larger than the new one.
>
> > Obviously I need to restrict dd to about the first 10 gigs as there
> > is not any data beyond that anyway.  So wash, rinse and repeat. But
> > I need too, to shrink the file system, and the last partition on the
> > card to low enough I could use a 16GB sdcard as the test tool
>
> You need to do it in a qualified way.
> The partition table would be easy as soon as you identified what type
> it is: MBR partition table or GPT.
>
> > partition 7 is around 125k bigger than the disk
>
> The task of shrinking a filesystem depends much on its type.
> E.g.
> http://www.microhowto.info/howto/reduce_the_size_of_an_ext2_ext3_or_ex
>t4_filesystem.html (Disclaimer: I have never done this.)
>
> > Why hasn't such a utility been done?
>
> I guess because most people just buy a bigger medium.
>
That is not the problem, something is automounting the partition as soon 
as gparted unmounts the SOB, so by the time you start the resize, its 
mounted again and gparted is locked out.
>
> Normally i would advise to copy old partition 7 file by file into a
> freshly formatted filesystem in the slightly smaller partition 7 on
> the new card. But the bootability might get damaged that way.
>
> You would be lucky if the boot loader on the old card does not refer
> to partition 7. I'd flatly give it a try:
>
> - Copy the old card by dd up to the start of partition 7.
>   This will most probably copy the oversized partition entry of old
>   partition 7.
>
> - So use a partition editor to delete partition 7 on the new card.
>   Create an new partition 7 of a size that matches the card size.
>
> - Create a new filesystem in the new partition 7.
>
> - Mount both partitions 7 of old and new card.
>   Copy all files from old partition 7 to new one. E.g. by cp -a.
>
> If the new card then does not boot, you have to find out which boot
> loader is installed, what it uses on partition 7, and how to
> re-install it so that it works properly with new partition 7.
>
>
> Have a nice day :)
>
> Thomas



-- 
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 

Re: libgparted bug.

[Gene Heskett]

On Friday 09 February 2018 03:05:23 deloptes wrote:

> Gene Heskett wrote:
> > Trying to make a backup image of a 64GB bootable sdcard. Th os say
> > its 59.b GB when it mounts the original, but pull copy to a file and
> > its nearly a megabyte bigger than 64gigs.  So obviously the file is
> > bigger than a brand new unformatted disk.
>
> Hi Gene, you should know each partition has header or meta data, that
> is not visible after mount. I can't recall where, but there was a
> document (perhaps on Debian) that explained how the meta data looks
> like. So basically with each partition operation you add a layer on
> top of the physical device. For example you create a luks partition,
> it adds some meta data (perhaps 1-2MB), you add a LVM on top it also
> adds some meta data, you add the partition, it also adds some meta
> data.
>
> The other concern could be that the 64GB are actually GB by 1000
> (sales GB) and not GiB.
> For example my HDD and SSD report this
>
> sudo fdisk -l /dev/sda
> Disk /dev/sda: 465.8 GiB, 500107862016 bytes, 976773168 sectors
>
> sudo fdisk -l /dev/sdb
> Disk /dev/sdb: 465.8 GiB, 500107862016 bytes, 976773168 sectors
>
> I bought 500GB which seems to be equivalent of 465.8 GiB
>
>
I've been playing in the night with gparted, which loads up the operating 
card out of the rockchip, which shows that a bit over 4GiB is used out 
of 59.6GiB for partition 7, the last partition in it, so I unmount it, 
select move/resize, and pull the right end of the gui's part 7 bar down 
to about 10GiB. which then shows 49GiB and change of unallocated space.

All of these sd images are shrunken in a similar manner, and once 
installed on whatever size of sd card you have, and that will hold the 
decompressed image, 8 gb is more than enough, and the last partition 
will be autoexpanded on the next boot to allocate the rest of the card.

So raspian, ayyufan, and all these guys obviously have a way to do this 
shrinkage down to only whats used.

But running gparted as root, it refuses to resize the SOB so I can turn 
around and reinstall a working system on an 8, 16, 32, 64 or even a 
128GiB card.

But gparted, running as root, refuses to do it, and its log info makes 
zero sense.

Because I want exactly the same file as you can down load. And this 
includes the stuff I've built and installed to get it to a fully working 
for my purposes install.

But, and heres the but, I have got to be able to make copies of a working 
install, but with a realtime kernel I've built. That way, I always have 
a backup system on the last card that I don't have to start over from 
scratch to rebuild.

Heres that log from telling it to resize part7.

Sorry about the html, but thats how gparted saves it.

http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd'>



GParted Details


GParted 0.12.1 --enable-libparted-dmraid
Libparted 2.3



Shrink /dev/sdd7 from 59.56 GiB to 6.91 
GiB00:00:01( ERROR )








calibrate /dev/sdd700:00:00( 
SUCCESS )








path: /dev/sdd7start: 262,144end: 125,171,678size: 
124,909,535 (59.56 GiB)









check file system on /dev/sdd7 for errors and (if possible) fix 
them00:00:00( ERROR )








e2fsck -f -y -v /dev/sdd7








/dev/sdd7 is mounted.






e2fsck 1.42.5 (29-Jul-2012)e2fsck: Cannot continue, 
aborting.
















Now part7 is NOT mounted which would explain the e2fsck failure.
Now, it does NOT tell me that e2fsck failed in the messages I see on 
screen.

> Why don't you tar.gz or tar.bz2 your data instead of pulling multiple
> 0-bytes into backup?
>
That should be adequately explained above.

> regards

http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd'>



GParted Details


GParted 0.12.1 --enable-libparted-dmraid
Libparted 2.3



Shrink /dev/sdd7 from 59.56 GiB to 8.34 
GiB00:00:01( ERROR )








calibrate /dev/sdd700:00:00( 
SUCCESS )








path: /dev/sdd7start: 262,144end: 125,171,678size: 
124,909,535 (59.56 GiB)









check file system on /dev/sdd7 for errors and (if possible) fix 
them00:00:01( ERROR )








e2fsck -f -y -v /dev/sdd7








/dev/sdd7 is mounted.






e2fsck 1.42.5 (29-Jul-2012)e2fsck: Cannot continue, 
aborting.

















So I go back and repeat it, see above and it says the partition is not 
mounted on the gparted screen, but the error message says it is. So 
something is automounting it, what do I kill to stop that?


Thanks for any hints.

-- 
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 

Re: libgparted bug.

[Thomas Schmitt]

Hi,

Gene Heskett wrote:
> Th os say its 59.b GB when it mounts the original
> [...]
> gene@coyote:~/rock64.imgs$ dd of=/dev/sdd bs=64k if=working-rock64.img
> dd: writing `/dev/sdd': No space left on device
> 976897+0 records in
> 976896+0 records out

That's the usual confusion between ISO GB (= 1 billion bytes) and programmer's
GiB (1024 * 1024 * 1024 bytes).
dd's "k" are programmer's KiB (= 1024).

976896*64*1024 = 64021856256 = 64.02 ISO GB = 59.63 programmer's GiB.

So it failed when it had already reached the 64 ISO GB limit.
No chance to return the card to the seller for being undersized, i guess.

> So nominally 600k of card disappeared. 

The old card is obviously slightly larger than the new one.


> Obviously I need to restrict dd to about the first 10 gigs as there is 
> not any data beyond that anyway.  So wash, rinse and repeat.
> But I need too, to shrink the file system, and the last partition on the 
> card to low enough I could use a 16GB sdcard as the test tool

You need to do it in a qualified way.
The partition table would be easy as soon as you identified what type
it is: MBR partition table or GPT.

> partition 7 is around 125k bigger than the disk

The task of shrinking a filesystem depends much on its type.
E.g. 
http://www.microhowto.info/howto/reduce_the_size_of_an_ext2_ext3_or_ext4_filesystem.html
(Disclaimer: I have never done this.)

> Why hasn't such a utility been done?

I guess because most people just buy a bigger medium.


Normally i would advise to copy old partition 7 file by file into a freshly
formatted filesystem in the slightly smaller partition 7 on the new card.
But the bootability might get damaged that way.

You would be lucky if the boot loader on the old card does not refer to
partition 7. I'd flatly give it a try:

- Copy the old card by dd up to the start of partition 7.
  This will most probably copy the oversized partition entry of old
  partition 7.

- So use a partition editor to delete partition 7 on the new card.
  Create an new partition 7 of a size that matches the card size.

- Create a new filesystem in the new partition 7.

- Mount both partitions 7 of old and new card.
  Copy all files from old partition 7 to new one. E.g. by cp -a.

If the new card then does not boot, you have to find out which boot loader
is installed, what it uses on partition 7, and how to re-install it so
that it works properly with new partition 7.


Have a nice day :)

Thomas

Re: libgparted bug.

[deloptes]

Gene Heskett wrote:

> Trying to make a backup image of a 64GB bootable sdcard. Th os say its
> 59.b GB when it mounts the original, but pull copy to a file and its
> nearly a megabyte bigger than 64gigs.  So obviously the file is bigger
> than a brand new unformatted disk.
> 

Hi Gene, you should know each partition has header or meta data, that is not
visible after mount. I can't recall where, but there was a document
(perhaps on Debian) that explained how the meta data looks like. So
basically with each partition operation you add a layer on top of the
physical device. For example you create a luks partition, it adds some meta
data (perhaps 1-2MB), you add a LVM on top it also adds some meta data, you
add the partition, it also adds some meta data.

The other concern could be that the 64GB are actually GB by 1000 (sales GB)
and not GiB.
For example my HDD and SSD report this

sudo fdisk -l /dev/sda
Disk /dev/sda: 465.8 GiB, 500107862016 bytes, 976773168 sectors

sudo fdisk -l /dev/sdb
Disk /dev/sdb: 465.8 GiB, 500107862016 bytes, 976773168 sectors

I bought 500GB which seems to be equivalent of 465.8 GiB



Why don't you tar.gz or tar.bz2 your data instead of pulling multiple
0-bytes into backup?

regards