[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: libgparted bug.



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  |................|
*
1dcd60000

Which tells me the backup GPT table, if it exists, is actually at the end 
of the disk, after another 50Gb of of 0000'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 <http://geneslinuxbox.net:6309/gene>


Reply to: