Date   

locked Re: HamPi on a 128GB SD-Card

N5XMT
 

Hi Marty,
The SD cards are TYPICALLY formatted as xFAT from the factory.  Some may slip thru without initial formatting etc.  Yes, it warns you that all data will be deleted, but that is because it overwrites everything on the disc/card etc.  it doesn't do a format or erase before it starts


locked Difference of Opinion on writing an image to disc

John Nicholas
 

This thread has turned into a Gotcha like 3 year olds.

Let us get back to discussing RaspberryPi problems.


locked Re: HamPi on a 128GB SD-Card

Jeff Palmer
 

Narrowing the scope?

Below, I'll paste the original in it's unedited format. You can
clearly see that I say that if it doesn't work, it's something *other*
than the disk image, or the writing process. An OS that refuses to
write an unmounted disk IS an unrelated issue. I digress. I was
trying to correct misinformation and confusion, and have been seen
nothing but personal attacks by 3 different people. Time to leave
well enough alone, and let those who "know more" continue answering
the same questions over and over, rather than educate and help people
learn.


Mark,

If you are using a disk image, then no.. the existing partitioning, or
filesystems don't matter. They literally get overwritten. If you've
seen cases where this doesn't seem to be the case, I assure you,
something else is going on. With a disk image, even the boot sectors
of a disk are overwritten.

I'm not trying to argue. But I am trying to clear up misinformation,
because it's become obvious in these threads that.. a little
misinformation leads to a LOT of confusion. So, I'd submit that if
you've "seen it matter" before, you investigate the root cause, as I
assure you, it's not the fault of a disk image "sometimes working,
sometimes not". a properly created disk image, which is also written
properly to a disk will *always* overwrite existing boot sectors,
partition maps, and existing filesystems. Any result *other* than
that, something else was at play. (human error, invalid disk image,
an error with the software writing the image, faulty disk, etc etc the
list goes on and on.)

On Tue, Jul 7, 2020 at 11:44 AM N5XMT <dacooley@gmail.com> wrote:

I provided facts. When you were presented with them, You danced around them and narrowed your scope to try and retain being righteous.




On Tue, Jul 7, 2020 at 8:40 AM Jeff Palmer via groups.io <jeff=palmerit.net@groups.io> wrote:

"stop being a cocky ass"

As usual, when you cannot argue facts, the weak argument becomes
personal. Cool.

On Tue, Jul 7, 2020 at 11:38 AM N5XMT <dacooley@gmail.com> wrote:

When you give an absolute in that "it just works" and ignore hardware issues, that is faulty reasoning. The process fails and you cannot get the process to complete properly
Stop being a cocky ass

On Tue, Jul 7, 2020 at 8:36 AM Jeff Palmer via groups.io <jeff=palmerit.net@groups.io> wrote:

"but the issue becomes, if the hardware has an issue,"

Thank you for confirming my point. It's not the disk image, or the
process by which the image is written. It's another (and unrelated)
cause.
Again, I stand by the facts I've presented.

On Tue, Jul 7, 2020 at 11:30 AM N5XMT <dacooley@gmail.com> wrote:

Jeff,
RELAX. Just because you have not run across something doesn't mean it never happens. That is also an anecdotal observation. Just because someone eats 20 greasy hamburgers a day and lives to be 120 doesn't mean everyone will. Computers work in absolutes, yes, but the issue becomes, if the hardware has an issue, the computer cannot always force it to perform as designed. I had that issue with Engineers 30+ years ago. They design a circuit, they have you assemble it, it doesn't properly work, both digital and analog. What their book learning doesn't take into account is tolerances of components. Tolerances stack up and now they are outside the "theoretical perfect world". They don't see that, they argue and obviously whoever assembled it is the issue. Memory is the same way. Bulk manufacturing isn't perfect, and the factory format may or may not have properly completed, and there may be an issue that keeps the system from properly accessing the device. Unfortunately, I have seen it MANY times. Windows is the least forgiving OS. You stick a memory card in, or attach a drive, and some issues will make the disk subsystem put the device offline due to some access error. At that point, even from a system utility, the drive cannot be written to or read from. MacOS is probably the 2nd pickiest, and Linux the least. Don't even get me started on DEC's VMS...


On Tue, Jul 7, 2020 at 7:44 AM Jeff Palmer via groups.io <jeff=palmerit.net@groups.io> wrote:

Mark,

I've done nothing but state facts. You've done nothing but personal
attacks ("One day I'll learn enough", "I guess you just haven't seen
enough", blah blah blah)
You've not stated a single fact, or provided any evidence to refute
the facts. You've only provided faulty anecdotal observations.

So, yea.. I guess your 30+ years don't matter, if you're denying
actual facts. Maybe take a moment and learn what a disk image
actually is, does, and doesn't do.

Meanwhile, I'll sit here and wait for your next personal attack, since
you literally will not find anything to refute the *actual* facts
about what a disk image is.

Also, agreed. My audience is elsewhere. My audience is the people
in this group who want to educate themselves. My audience is people
who want to hear facts. My audience is people who would rather things
work. As the saying goes in computer sciences. "Something that is
done wrong, may sometimes work. Something that is done correctly will
always work". Computers don't work on "random" unless specifically
instructed too. there is nothing "random" about the success of
writing a disk image. It's not subject to your OPINION, period.

I await your rebuttal against the facts. But I suspect it'll be more
personal attacks, since you won't be able to refute.



On Tue, Jul 7, 2020 at 10:26 AM Mark Griffith via groups.io
<mdgriffith2003=yahoo.com@groups.io> wrote:

Well, I suppose my 30+ years also means something too? Eh?

I guess you just haven't seen enough yet. My apologies.

Argue away. I'm not listening, so your audience is elsewhere.

Mark


On Tuesday, July 7, 2020, 9:23:46 AM CDT, Jeff Palmer via groups.io <jeff=palmerit.net@groups.io> wrote:


OK, Now I am trying to argue.

There are absolutes in this field. Disk images ARE absolute.
writing them to a disk IS absolute. It overwrites *everything* that
holds any old layout. That is simply a fact. Your observations,
while relevant, are not *accurate*. There is a significant
difference. correlation does NOT equal causation.

30 years as a unix admin, dealing with disk images.. I'm fairly
confident that I have "enough experience" to have learned what a disk
image is, does, and doesn't do.

One time, I bought new shoes. I immediately stubbed my toe while
wearing them. Correlation: new shoes = stubbed toes. Causation: I
wasn't actually paying attention, and kicked something by accident.
Facts are facts man. properly formatted and written disk images work
100% of the time. IF it doesn't, as I mentioned in the last email,
something else was the cause. Period.

On Tue, Jul 7, 2020 at 10:07 AM Mark Griffith via groups.io
<mdgriffith2003=yahoo.com@groups.io> wrote:

Whatever. You *are* trying to argue and tell me my observations are not relevant to your discussion.

It's unfortunate, that in what some people may call a discussion, it's obvious that one side doesn't want any other opinions to be expressed. That's not a discussion. There are no absolutes in this field. You probably have not yet had enough experience to learn that yet. Keep learning, it will come.

Mark
KD0QYN


On Tuesday, July 7, 2020, 8:54:49 AM CDT, Jeff Palmer via groups.io <jeff=palmerit.net@groups.io> wrote:


Mark,

If you are using a disk image, then no.. the existing partitioning, or
filesystems don't matter. They literally get overwritten. If you've
seen cases where this doesn't seem to be the case, I assure you,
something else is going on. With a disk image, even the boot sectors
of a disk are overwritten.

I'm not trying to argue. But I am trying to clear up misinformation,
because it's become obvious in these threads that.. a little
misinformation leads to a LOT of confusion. So, I'd submit that if
you've "seen it matter" before, you investigate the root cause, as I
assure you, it's not the fault of a disk image "sometimes working,
sometimes not". a properly created disk image, which is also written
properly to a disk will *always* overwrite existing boot sectors,
partition maps, and existing filesystems. Any result *other* than
that, something else was at play. (human error, invalid disk image,
an error with the software writing the image, faulty disk, etc etc the
list goes on and on.)

On Tue, Jul 7, 2020 at 8:52 AM Mark Griffith via groups.io
<mdgriffith2003=yahoo.com@groups.io> wrote:

The existence of a partition or filesystem on an SD card *should not* make any difference when writing an image, but it sometimes does. That's why I say NOT to format the card before copying the image. In most cases, I would say it doesn't make a difference, but I have seen some where it has.

Also, I'm hoping all those that are using a giant SD card for the image know to use raspi-config to then expand the filesystem so all of the big SD card is used.

Mark
KD0QYN


On Tuesday, July 7, 2020, 7:32:23 AM CDT, Jeff Palmer via groups.io <jeff=palmerit.net@groups.io> wrote:


Interesting.

Since etcher is writing a raw disk image, the existing filesystems,
partitions, or layouts shouldn't matter (or affect writing the image)

For what it's worth, I have HamPi running on a 128gb sd card. I used
etcher, and never had an issue. I hope that helps.

On Tue, Jul 7, 2020 at 1:16 AM thegadget techie <gadgetechie@gmail.com> wrote:

I did pick up a couple of SanDisk xPros. Seemed the issue may have been the factory format - I zapped the 2nd on w/ xFat (not FAT32) and no hitch w/ Etcher. So maybe that's the issue. Also on MacPro (yeah yeah I'm 25+ yrs *nix guy). I dd'd the 1st SDCard (wiped block 0 & 100) and the PI imager did all the magic - so long story short - not really sure of the issue - but both 128Gb's running like a charm. Now onto USB boot on Pi4....

Thanks all for replies.

On Sun, Jul 5, 2020 at 5:50 AM John Nicholas <stnick@iwichita.com> wrote:

Ditto on San Disc. I found that out with discs from my Infrared Imager at work.

JN

On Jul 5, 2020, at 3:24 AM, Roger Reeves M0ROJ <m0roj@goldford.co.uk> wrote:

It’s all down to the quality of the SD card. A recommendation is the SanDisk Extreme Pro, whatever the size.

Roger M0ROJ



--
Jeff Palmer
Palmer IT Consulting, LLC.
https://PalmerIT.net




--
Jeff Palmer
Palmer IT Consulting, LLC.
https://PalmerIT.net




--
Jeff Palmer
Palmer IT Consulting, LLC.
https://PalmerIT.net




--
Jeff Palmer
Palmer IT Consulting, LLC.
https://PalmerIT.net




--
Jeff Palmer
Palmer IT Consulting, LLC.
https://PalmerIT.net




--
Jeff Palmer
Palmer IT Consulting, LLC.
https://PalmerIT.net


--
Jeff Palmer
Palmer IT Consulting, LLC.
https://PalmerIT.net


locked Re: HamPi on a 128GB SD-Card

Marty Hartwell
 

Hi Jeff and all

A question for my ongoing education. Not exactly about copying

an image onto a new micro SD card, but one on the Pi doing

a SD copy backup of the disk in use. Like copying the image

on the first card, doesn't the Pi OS prepare the SD for the copy

by what ever means, it says all information will be erased, as a

warning.

Another question, I recently bought a SanDisk 64GB 10 rated Ultra

disk and trying to use it right out of the package my Pi nor two other

PC's would see the disk, so I returned it. So when you buy a new disk

has it been formatted as say FAT32 or is it not formatted at all just

seen as a media ready for use somehow. I have never been curious

enough to check before.


Marty kd8bj

On 7/7/20 8:54 AM, Jeff Palmer via groups.io wrote:
Mark,

If you are using a disk image, then no.. the existing partitioning, or
filesystems don't matter. They literally get overwritten. If you've
seen cases where this doesn't seem to be the case, I assure you,
something else is going on. With a disk image, even the boot sectors
of a disk are overwritten.

I'm not trying to argue. But I am trying to clear up misinformation,
because it's become obvious in these threads that.. a little
misinformation leads to a LOT of confusion. So, I'd submit that if
you've "seen it matter" before, you investigate the root cause, as I
assure you, it's not the fault of a disk image "sometimes working,
sometimes not". a properly created disk image, which is also written
properly to a disk will *always* overwrite existing boot sectors,
partition maps, and existing filesystems. Any result *other* than
that, something else was at play. (human error, invalid disk image,
an error with the software writing the image, faulty disk, etc etc the
list goes on and on.)

On Tue, Jul 7, 2020 at 8:52 AM Mark Griffith via groups.io
<mdgriffith2003=yahoo.com@groups.io> wrote:
The existence of a partition or filesystem on an SD card *should not* make any difference when writing an image, but it sometimes does. That's why I say NOT to format the card before copying the image. In most cases, I would say it doesn't make a difference, but I have seen some where it has.

Also, I'm hoping all those that are using a giant SD card for the image know to use raspi-config to then expand the filesystem so all of the big SD card is used.

Mark
KD0QYN


On Tuesday, July 7, 2020, 7:32:23 AM CDT, Jeff Palmer via groups.io <jeff=palmerit.net@groups.io> wrote:


Interesting.

Since etcher is writing a raw disk image, the existing filesystems,
partitions, or layouts shouldn't matter (or affect writing the image)

For what it's worth, I have HamPi running on a 128gb sd card. I used
etcher, and never had an issue. I hope that helps.

On Tue, Jul 7, 2020 at 1:16 AM thegadget techie <gadgetechie@gmail.com> wrote:
I did pick up a couple of SanDisk xPros. Seemed the issue may have been the factory format - I zapped the 2nd on w/ xFat (not FAT32) and no hitch w/ Etcher. So maybe that's the issue. Also on MacPro (yeah yeah I'm 25+ yrs *nix guy). I dd'd the 1st SDCard (wiped block 0 & 100) and the PI imager did all the magic - so long story short - not really sure of the issue - but both 128Gb's running like a charm. Now onto USB boot on Pi4....

Thanks all for replies.

On Sun, Jul 5, 2020 at 5:50 AM John Nicholas <stnick@iwichita.com> wrote:
Ditto on San Disc. I found that out with discs from my Infrared Imager at work.

JN

On Jul 5, 2020, at 3:24 AM, Roger Reeves M0ROJ <m0roj@goldford.co.uk> wrote:

It’s all down to the quality of the SD card. A recommendation is the SanDisk Extreme Pro, whatever the size.

Roger M0ROJ


--
Jeff Palmer
Palmer IT Consulting, LLC.
https://PalmerIT.net



locked Re: HamPi on a 128GB SD-Card

N5XMT
 

I provided facts.  When you were presented with them, You danced around them and narrowed your scope to try and retain being righteous.




On Tue, Jul 7, 2020 at 8:40 AM Jeff Palmer via groups.io <jeff=palmerit.net@groups.io> wrote:
"stop being a cocky ass"

As usual, when you cannot argue facts,  the weak argument becomes
personal.  Cool.

On Tue, Jul 7, 2020 at 11:38 AM N5XMT <dacooley@...> wrote:
>
> When you give an absolute in that "it just works" and ignore hardware issues, that is faulty reasoning.  The process fails and you cannot get the process to complete properly
> Stop being a cocky ass
>
> On Tue, Jul 7, 2020 at 8:36 AM Jeff Palmer via groups.io <jeff=palmerit.net@groups.io> wrote:
>>
>> "but the issue becomes, if the hardware has an issue,"
>>
>> Thank you for confirming my point.  It's not the disk image, or the
>> process by which the image is written. It's another (and unrelated)
>> cause.
>> Again, I stand by the facts I've presented.
>>
>> On Tue, Jul 7, 2020 at 11:30 AM N5XMT <dacooley@...> wrote:
>> >
>> > Jeff,
>> > RELAX.  Just because you have not run across something doesn't mean it never happens.  That is also an anecdotal observation.  Just because someone eats 20 greasy hamburgers a day and lives to be 120 doesn't mean everyone will.  Computers work in absolutes, yes, but the issue becomes, if the hardware has an issue, the computer cannot always force it to perform as designed.  I had that issue with Engineers 30+ years ago.  They design a circuit, they have you assemble it, it doesn't properly work, both digital and analog.  What their book learning doesn't take into account is tolerances of components.  Tolerances stack up and now they are outside the "theoretical perfect world".  They don't see that, they argue and obviously whoever assembled it is the issue. Memory is the same way.  Bulk manufacturing isn't perfect, and the factory format may or may not have properly completed, and there may be an issue that keeps the system from properly accessing the device.  Unfortunately, I have seen it MANY times.  Windows is the least forgiving OS.  You stick a memory card in, or attach a drive, and some issues will make the disk subsystem put the device offline due to some access error.  At that point, even from a system utility, the drive cannot be written to or read from.  MacOS is probably the 2nd pickiest, and Linux the least.  Don't even get me started on DEC's VMS...
>> >
>> >
>> > On Tue, Jul 7, 2020 at 7:44 AM Jeff Palmer via groups.io <jeff=palmerit.net@groups.io> wrote:
>> >>
>> >> Mark,
>> >>
>> >> I've done nothing but state facts.  You've done nothing but personal
>> >> attacks ("One day I'll learn enough", "I guess you just haven't seen
>> >> enough", blah blah blah)
>> >> You've not stated a single fact, or provided any evidence to refute
>> >> the facts. You've only provided faulty anecdotal observations.
>> >>
>> >> So, yea.. I guess your 30+ years don't matter, if you're denying
>> >> actual facts.    Maybe take a moment and learn what a disk image
>> >> actually is, does, and doesn't do.
>> >>
>> >> Meanwhile, I'll sit here and wait for your next personal attack, since
>> >> you literally will not find anything to refute the *actual* facts
>> >> about what a disk image is.
>> >>
>> >> Also,  agreed.  My audience is elsewhere.  My audience is the people
>> >> in this group who want to educate themselves.  My audience is people
>> >> who want to hear facts. My audience is people who would rather things
>> >> work.   As the saying goes in computer sciences.  "Something that is
>> >> done wrong, may sometimes work.  Something that is done correctly will
>> >> always work".   Computers don't work on "random" unless specifically
>> >> instructed too.  there is nothing "random" about the success of
>> >> writing a disk image.  It's not subject to your OPINION, period.
>> >>
>> >>  I await your rebuttal against the facts.  But I suspect it'll be more
>> >> personal attacks, since you won't be able to refute.
>> >>
>> >>
>> >>
>> >> On Tue, Jul 7, 2020 at 10:26 AM Mark Griffith via groups.io
>> >> <mdgriffith2003=yahoo.com@groups.io> wrote:
>> >> >
>> >> > Well, I suppose my 30+ years also means something too?  Eh?
>> >> >
>> >> > I guess you just haven't seen enough yet.  My apologies.
>> >> >
>> >> > Argue away.  I'm not listening, so your audience is elsewhere.
>> >> >
>> >> > Mark
>> >> >
>> >> >
>> >> > On Tuesday, July 7, 2020, 9:23:46 AM CDT, Jeff Palmer via groups.io <jeff=palmerit.net@groups.io> wrote:
>> >> >
>> >> >
>> >> > OK,  Now I am trying to argue.
>> >> >
>> >> > There are absolutes in this field.  Disk images ARE absolute.
>> >> > writing them to a disk IS absolute.  It overwrites *everything* that
>> >> > holds any old layout.  That is simply a fact.  Your observations,
>> >> > while relevant, are not *accurate*.  There is a significant
>> >> > difference.  correlation does NOT equal causation.
>> >> >
>> >> > 30 years as a unix admin, dealing with disk images.. I'm fairly
>> >> > confident that I have "enough experience" to have learned what a disk
>> >> > image is, does, and doesn't do.
>> >> >
>> >> > One time, I bought new shoes.  I immediately stubbed my toe while
>> >> > wearing them.  Correlation:  new shoes = stubbed toes.  Causation:  I
>> >> > wasn't actually paying attention, and kicked something by accident.
>> >> > Facts are facts man. properly formatted and written disk images work
>> >> > 100% of the time.  IF it doesn't, as I mentioned in the last email,
>> >> > something else was the cause.  Period.
>> >> >
>> >> > On Tue, Jul 7, 2020 at 10:07 AM Mark Griffith via groups.io
>> >> > <mdgriffith2003=yahoo.com@groups.io> wrote:
>> >> > >
>> >> > > Whatever.  You *are* trying to argue and tell me my observations are not relevant to your discussion.
>> >> > >
>> >> > > It's unfortunate, that in what some people may call a discussion, it's obvious that one side doesn't want any other opinions to be expressed.  That's not a discussion.  There are no absolutes in this field.  You probably have not yet had enough experience to learn that yet.  Keep learning, it will come.
>> >> > >
>> >> > > Mark
>> >> > > KD0QYN
>> >> > >
>> >> > >
>> >> > > On Tuesday, July 7, 2020, 8:54:49 AM CDT, Jeff Palmer via groups.io <jeff=palmerit.net@groups.io> wrote:
>> >> > >
>> >> > >
>> >> > > Mark,
>> >> > >
>> >> > > If you are using a disk image, then no.. the existing partitioning, or
>> >> > > filesystems don't matter.  They literally get overwritten.  If you've
>> >> > > seen cases where this doesn't seem to be the case, I assure you,
>> >> > > something else is going on.  With a disk image, even the boot sectors
>> >> > > of a disk are overwritten.
>> >> > >
>> >> > > I'm not trying to argue.  But I am trying to clear up misinformation,
>> >> > > because it's become obvious in these threads that..  a little
>> >> > > misinformation leads to a LOT of confusion.  So,  I'd submit that if
>> >> > > you've "seen it matter" before,  you investigate the root cause, as I
>> >> > > assure you, it's not the fault of a disk image "sometimes working,
>> >> > > sometimes not".  a properly created disk image, which is also written
>> >> > > properly to a disk will *always* overwrite existing boot sectors,
>> >> > > partition maps, and existing filesystems.  Any result *other* than
>> >> > > that,  something else was at play.  (human error, invalid disk image,
>> >> > > an error with the software writing the image, faulty disk, etc etc the
>> >> > > list goes on and on.)
>> >> > >
>> >> > > On Tue, Jul 7, 2020 at 8:52 AM Mark Griffith via groups.io
>> >> > > <mdgriffith2003=yahoo.com@groups.io> wrote:
>> >> > > >
>> >> > > > The existence of a partition or filesystem on an SD card *should not* make any difference when writing an image, but it sometimes does.  That's why I say NOT to format the card before copying the image.  In most cases, I would say it doesn't make a difference, but I have seen some where it has.
>> >> > > >
>> >> > > > Also, I'm hoping all those that are using a giant SD card for the image know to use raspi-config to then expand the filesystem so all of the big SD card is used.
>> >> > > >
>> >> > > > Mark
>> >> > > > KD0QYN
>> >> > > >
>> >> > > >
>> >> > > > On Tuesday, July 7, 2020, 7:32:23 AM CDT, Jeff Palmer via groups.io <jeff=palmerit.net@groups.io> wrote:
>> >> > > >
>> >> > > >
>> >> > > > Interesting.
>> >> > > >
>> >> > > > Since etcher is writing a raw disk image, the existing filesystems,
>> >> > > > partitions, or layouts shouldn't matter (or affect writing the image)
>> >> > > >
>> >> > > > For what it's worth, I have HamPi running on a 128gb sd card.  I used
>> >> > > > etcher, and never had an issue.  I hope that helps.
>> >> > > >
>> >> > > > On Tue, Jul 7, 2020 at 1:16 AM thegadget techie <gadgetechie@...> wrote:
>> >> > > > >
>> >> > > > > I did pick up a couple of SanDisk xPros.  Seemed the issue may have been the factory format - I zapped the 2nd on w/ xFat (not FAT32) and no hitch w/ Etcher.  So maybe that's the issue. Also on MacPro (yeah yeah I'm 25+ yrs *nix guy).  I dd'd the 1st SDCard (wiped block 0 & 100) and the PI imager did all the magic - so long story short - not really sure of the issue - but both 128Gb's running like a charm.  Now onto USB boot on Pi4....
>> >> > > > >
>> >> > > > > Thanks all for replies.
>> >> > > > >
>> >> > > > > On Sun, Jul 5, 2020 at 5:50 AM John Nicholas <stnick@...> wrote:
>> >> > > > >>
>> >> > > > >> Ditto on San Disc.  I found that out with discs from my Infrared Imager at work.
>> >> > > > >>
>> >> > > > >> JN
>> >> > > > >>
>> >> > > > >> On Jul 5, 2020, at 3:24 AM, Roger Reeves M0ROJ <m0roj@...> wrote:
>> >> > > > >>
>> >> > > > >> It’s all down to the quality of the SD card. A recommendation is the SanDisk Extreme Pro, whatever the size.
>> >> > > > >>
>> >> > > > >> Roger M0ROJ
>> >> > > > >>
>> >> > > > >>
>> >> > > > >
>> >> > > >
>> >> > > >
>> >> > > >
>> >> > > > --
>> >> > > > Jeff Palmer
>> >> > > > Palmer IT Consulting, LLC.
>> >> > > > https://PalmerIT.net
>> >> > > >
>> >> > > >
>> >> > > >
>> >> > >
>> >> > >
>> >> > >
>> >> > > --
>> >> > > Jeff Palmer
>> >> > > Palmer IT Consulting, LLC.
>> >> > > https://PalmerIT.net
>> >> > >
>> >> > >
>> >> > >
>> >> >
>> >> >
>> >> >
>> >> > --
>> >> > Jeff Palmer
>> >> > Palmer IT Consulting, LLC.
>> >> > https://PalmerIT.net
>> >> >
>> >> >
>> >> >
>> >>
>> >>
>> >>
>> >> --
>> >> Jeff Palmer
>> >> Palmer IT Consulting, LLC.
>> >> https://PalmerIT.net
>> >>
>> >>
>> >>
>> >
>>
>>
>>
>> --
>> Jeff Palmer
>> Palmer IT Consulting, LLC.
>> https://PalmerIT.net
>>
>>
>>
>



--
Jeff Palmer
Palmer IT Consulting, LLC.
https://PalmerIT.net




locked Re: HamPi on a 128GB SD-Card

K9HZ
 

Wow. Arguing over imaging an SD card. New ultimate low. Grow up guys and move on.


Dr. William J. Schmidt - K9HZ J68HZ 8P6HK ZF2HZ PJ4/K9HZ VP5/K9HZ PJ2/K9HZ

Owner - Operator
Big Signal Ranch – K9ZC
Staunton, Illinois

Owner – Operator
Villa Grand Piton – J68HZ
Soufriere, St. Lucia W.I.
Rent it: www.VillaGrandPiton.com
Like us on Facebook!

Moderator – North American QRO Group at Groups.IO.

email: bill@wjschmidt.com

-----Original Message-----
From: RaspberryPi-4-HamRadio@groups.io [mailto:RaspberryPi-4-HamRadio@groups.io] On Behalf Of Jeff Palmer via groups.io
Sent: Tuesday, July 7, 2020 9:44 AM
To: RaspberryPi-4-HamRadio@groups.io
Subject: Re: [RaspberryPi-4-HamRadio] HamPi on a 128GB SD-Card

Mark,

I've done nothing but state facts. You've done nothing but personal attacks ("One day I'll learn enough", "I guess you just haven't seen enough", blah blah blah) You've not stated a single fact, or provided any evidence to refute the facts. You've only provided faulty anecdotal observations.

So, yea.. I guess your 30+ years don't matter, if you're denying
actual facts. Maybe take a moment and learn what a disk image
actually is, does, and doesn't do.

Meanwhile, I'll sit here and wait for your next personal attack, since you literally will not find anything to refute the *actual* facts about what a disk image is.

Also, agreed. My audience is elsewhere. My audience is the people in this group who want to educate themselves. My audience is people who want to hear facts. My audience is people who would rather things
work. As the saying goes in computer sciences. "Something that is
done wrong, may sometimes work. Something that is done correctly will
always work". Computers don't work on "random" unless specifically
instructed too. there is nothing "random" about the success of writing a disk image. It's not subject to your OPINION, period.

I await your rebuttal against the facts. But I suspect it'll be more personal attacks, since you won't be able to refute.



On Tue, Jul 7, 2020 at 10:26 AM Mark Griffith via groups.io <mdgriffith2003=yahoo.com@groups.io> wrote:

Well, I suppose my 30+ years also means something too? Eh?

I guess you just haven't seen enough yet. My apologies.

Argue away. I'm not listening, so your audience is elsewhere.

Mark


On Tuesday, July 7, 2020, 9:23:46 AM CDT, Jeff Palmer via groups.io <jeff=palmerit.net@groups.io> wrote:


OK, Now I am trying to argue.

There are absolutes in this field. Disk images ARE absolute.
writing them to a disk IS absolute. It overwrites *everything* that
holds any old layout. That is simply a fact. Your observations,
while relevant, are not *accurate*. There is a significant
difference. correlation does NOT equal causation.

30 years as a unix admin, dealing with disk images.. I'm fairly
confident that I have "enough experience" to have learned what a disk
image is, does, and doesn't do.

One time, I bought new shoes. I immediately stubbed my toe while
wearing them. Correlation: new shoes = stubbed toes. Causation: I
wasn't actually paying attention, and kicked something by accident.
Facts are facts man. properly formatted and written disk images work
100% of the time. IF it doesn't, as I mentioned in the last email,
something else was the cause. Period.

On Tue, Jul 7, 2020 at 10:07 AM Mark Griffith via groups.io
<mdgriffith2003=yahoo.com@groups.io> wrote:

Whatever. You *are* trying to argue and tell me my observations are not relevant to your discussion.

It's unfortunate, that in what some people may call a discussion, it's obvious that one side doesn't want any other opinions to be expressed. That's not a discussion. There are no absolutes in this field. You probably have not yet had enough experience to learn that yet. Keep learning, it will come.

Mark
KD0QYN


On Tuesday, July 7, 2020, 8:54:49 AM CDT, Jeff Palmer via groups.io <jeff=palmerit.net@groups.io> wrote:


Mark,

If you are using a disk image, then no.. the existing partitioning,
or filesystems don't matter. They literally get overwritten. If
you've seen cases where this doesn't seem to be the case, I assure
you, something else is going on. With a disk image, even the boot
sectors of a disk are overwritten.

I'm not trying to argue. But I am trying to clear up
misinformation, because it's become obvious in these threads that..
a little misinformation leads to a LOT of confusion. So, I'd
submit that if you've "seen it matter" before, you investigate the
root cause, as I assure you, it's not the fault of a disk image
"sometimes working, sometimes not". a properly created disk image,
which is also written properly to a disk will *always* overwrite
existing boot sectors, partition maps, and existing filesystems.
Any result *other* than that, something else was at play. (human
error, invalid disk image, an error with the software writing the
image, faulty disk, etc etc the list goes on and on.)

On Tue, Jul 7, 2020 at 8:52 AM Mark Griffith via groups.io
<mdgriffith2003=yahoo.com@groups.io> wrote:

The existence of a partition or filesystem on an SD card *should not* make any difference when writing an image, but it sometimes does. That's why I say NOT to format the card before copying the image. In most cases, I would say it doesn't make a difference, but I have seen some where it has.

Also, I'm hoping all those that are using a giant SD card for the image know to use raspi-config to then expand the filesystem so all of the big SD card is used.

Mark
KD0QYN


On Tuesday, July 7, 2020, 7:32:23 AM CDT, Jeff Palmer via groups.io <jeff=palmerit.net@groups.io> wrote:


Interesting.

Since etcher is writing a raw disk image, the existing
filesystems, partitions, or layouts shouldn't matter (or affect
writing the image)

For what it's worth, I have HamPi running on a 128gb sd card. I
used etcher, and never had an issue. I hope that helps.

On Tue, Jul 7, 2020 at 1:16 AM thegadget techie <gadgetechie@gmail.com> wrote:

I did pick up a couple of SanDisk xPros. Seemed the issue may have been the factory format - I zapped the 2nd on w/ xFat (not FAT32) and no hitch w/ Etcher. So maybe that's the issue. Also on MacPro (yeah yeah I'm 25+ yrs *nix guy). I dd'd the 1st SDCard (wiped block 0 & 100) and the PI imager did all the magic - so long story short - not really sure of the issue - but both 128Gb's running like a charm. Now onto USB boot on Pi4....

Thanks all for replies.

On Sun, Jul 5, 2020 at 5:50 AM John Nicholas <stnick@iwichita.com> wrote:

Ditto on San Disc. I found that out with discs from my Infrared Imager at work.

JN

On Jul 5, 2020, at 3:24 AM, Roger Reeves M0ROJ <m0roj@goldford.co.uk> wrote:

It’s all down to the quality of the SD card. A recommendation is the SanDisk Extreme Pro, whatever the size.

Roger M0ROJ



--
Jeff Palmer
Palmer IT Consulting, LLC.
https://PalmerIT.net




--
Jeff Palmer
Palmer IT Consulting, LLC.
https://PalmerIT.net




--
Jeff Palmer
Palmer IT Consulting, LLC.
https://PalmerIT.net




--
Jeff Palmer
Palmer IT Consulting, LLC.
https://PalmerIT.net




--
This email has been checked for viruses by AVG.
https://www.avg.com


locked Re: HamPi on a 128GB SD-Card

Jeff Palmer
 

"stop being a cocky ass"

As usual, when you cannot argue facts, the weak argument becomes
personal. Cool.

On Tue, Jul 7, 2020 at 11:38 AM N5XMT <dacooley@gmail.com> wrote:

When you give an absolute in that "it just works" and ignore hardware issues, that is faulty reasoning. The process fails and you cannot get the process to complete properly
Stop being a cocky ass

On Tue, Jul 7, 2020 at 8:36 AM Jeff Palmer via groups.io <jeff=palmerit.net@groups.io> wrote:

"but the issue becomes, if the hardware has an issue,"

Thank you for confirming my point. It's not the disk image, or the
process by which the image is written. It's another (and unrelated)
cause.
Again, I stand by the facts I've presented.

On Tue, Jul 7, 2020 at 11:30 AM N5XMT <dacooley@gmail.com> wrote:

Jeff,
RELAX. Just because you have not run across something doesn't mean it never happens. That is also an anecdotal observation. Just because someone eats 20 greasy hamburgers a day and lives to be 120 doesn't mean everyone will. Computers work in absolutes, yes, but the issue becomes, if the hardware has an issue, the computer cannot always force it to perform as designed. I had that issue with Engineers 30+ years ago. They design a circuit, they have you assemble it, it doesn't properly work, both digital and analog. What their book learning doesn't take into account is tolerances of components. Tolerances stack up and now they are outside the "theoretical perfect world". They don't see that, they argue and obviously whoever assembled it is the issue. Memory is the same way. Bulk manufacturing isn't perfect, and the factory format may or may not have properly completed, and there may be an issue that keeps the system from properly accessing the device. Unfortunately, I have seen it MANY times. Windows is the least forgiving OS. You stick a memory card in, or attach a drive, and some issues will make the disk subsystem put the device offline due to some access error. At that point, even from a system utility, the drive cannot be written to or read from. MacOS is probably the 2nd pickiest, and Linux the least. Don't even get me started on DEC's VMS...


On Tue, Jul 7, 2020 at 7:44 AM Jeff Palmer via groups.io <jeff=palmerit.net@groups.io> wrote:

Mark,

I've done nothing but state facts. You've done nothing but personal
attacks ("One day I'll learn enough", "I guess you just haven't seen
enough", blah blah blah)
You've not stated a single fact, or provided any evidence to refute
the facts. You've only provided faulty anecdotal observations.

So, yea.. I guess your 30+ years don't matter, if you're denying
actual facts. Maybe take a moment and learn what a disk image
actually is, does, and doesn't do.

Meanwhile, I'll sit here and wait for your next personal attack, since
you literally will not find anything to refute the *actual* facts
about what a disk image is.

Also, agreed. My audience is elsewhere. My audience is the people
in this group who want to educate themselves. My audience is people
who want to hear facts. My audience is people who would rather things
work. As the saying goes in computer sciences. "Something that is
done wrong, may sometimes work. Something that is done correctly will
always work". Computers don't work on "random" unless specifically
instructed too. there is nothing "random" about the success of
writing a disk image. It's not subject to your OPINION, period.

I await your rebuttal against the facts. But I suspect it'll be more
personal attacks, since you won't be able to refute.



On Tue, Jul 7, 2020 at 10:26 AM Mark Griffith via groups.io
<mdgriffith2003=yahoo.com@groups.io> wrote:

Well, I suppose my 30+ years also means something too? Eh?

I guess you just haven't seen enough yet. My apologies.

Argue away. I'm not listening, so your audience is elsewhere.

Mark


On Tuesday, July 7, 2020, 9:23:46 AM CDT, Jeff Palmer via groups.io <jeff=palmerit.net@groups.io> wrote:


OK, Now I am trying to argue.

There are absolutes in this field. Disk images ARE absolute.
writing them to a disk IS absolute. It overwrites *everything* that
holds any old layout. That is simply a fact. Your observations,
while relevant, are not *accurate*. There is a significant
difference. correlation does NOT equal causation.

30 years as a unix admin, dealing with disk images.. I'm fairly
confident that I have "enough experience" to have learned what a disk
image is, does, and doesn't do.

One time, I bought new shoes. I immediately stubbed my toe while
wearing them. Correlation: new shoes = stubbed toes. Causation: I
wasn't actually paying attention, and kicked something by accident.
Facts are facts man. properly formatted and written disk images work
100% of the time. IF it doesn't, as I mentioned in the last email,
something else was the cause. Period.

On Tue, Jul 7, 2020 at 10:07 AM Mark Griffith via groups.io
<mdgriffith2003=yahoo.com@groups.io> wrote:

Whatever. You *are* trying to argue and tell me my observations are not relevant to your discussion.

It's unfortunate, that in what some people may call a discussion, it's obvious that one side doesn't want any other opinions to be expressed. That's not a discussion. There are no absolutes in this field. You probably have not yet had enough experience to learn that yet. Keep learning, it will come.

Mark
KD0QYN


On Tuesday, July 7, 2020, 8:54:49 AM CDT, Jeff Palmer via groups.io <jeff=palmerit.net@groups.io> wrote:


Mark,

If you are using a disk image, then no.. the existing partitioning, or
filesystems don't matter. They literally get overwritten. If you've
seen cases where this doesn't seem to be the case, I assure you,
something else is going on. With a disk image, even the boot sectors
of a disk are overwritten.

I'm not trying to argue. But I am trying to clear up misinformation,
because it's become obvious in these threads that.. a little
misinformation leads to a LOT of confusion. So, I'd submit that if
you've "seen it matter" before, you investigate the root cause, as I
assure you, it's not the fault of a disk image "sometimes working,
sometimes not". a properly created disk image, which is also written
properly to a disk will *always* overwrite existing boot sectors,
partition maps, and existing filesystems. Any result *other* than
that, something else was at play. (human error, invalid disk image,
an error with the software writing the image, faulty disk, etc etc the
list goes on and on.)

On Tue, Jul 7, 2020 at 8:52 AM Mark Griffith via groups.io
<mdgriffith2003=yahoo.com@groups.io> wrote:

The existence of a partition or filesystem on an SD card *should not* make any difference when writing an image, but it sometimes does. That's why I say NOT to format the card before copying the image. In most cases, I would say it doesn't make a difference, but I have seen some where it has.

Also, I'm hoping all those that are using a giant SD card for the image know to use raspi-config to then expand the filesystem so all of the big SD card is used.

Mark
KD0QYN


On Tuesday, July 7, 2020, 7:32:23 AM CDT, Jeff Palmer via groups.io <jeff=palmerit.net@groups.io> wrote:


Interesting.

Since etcher is writing a raw disk image, the existing filesystems,
partitions, or layouts shouldn't matter (or affect writing the image)

For what it's worth, I have HamPi running on a 128gb sd card. I used
etcher, and never had an issue. I hope that helps.

On Tue, Jul 7, 2020 at 1:16 AM thegadget techie <gadgetechie@gmail.com> wrote:

I did pick up a couple of SanDisk xPros. Seemed the issue may have been the factory format - I zapped the 2nd on w/ xFat (not FAT32) and no hitch w/ Etcher. So maybe that's the issue. Also on MacPro (yeah yeah I'm 25+ yrs *nix guy). I dd'd the 1st SDCard (wiped block 0 & 100) and the PI imager did all the magic - so long story short - not really sure of the issue - but both 128Gb's running like a charm. Now onto USB boot on Pi4....

Thanks all for replies.

On Sun, Jul 5, 2020 at 5:50 AM John Nicholas <stnick@iwichita.com> wrote:

Ditto on San Disc. I found that out with discs from my Infrared Imager at work.

JN

On Jul 5, 2020, at 3:24 AM, Roger Reeves M0ROJ <m0roj@goldford.co.uk> wrote:

It’s all down to the quality of the SD card. A recommendation is the SanDisk Extreme Pro, whatever the size.

Roger M0ROJ



--
Jeff Palmer
Palmer IT Consulting, LLC.
https://PalmerIT.net




--
Jeff Palmer
Palmer IT Consulting, LLC.
https://PalmerIT.net




--
Jeff Palmer
Palmer IT Consulting, LLC.
https://PalmerIT.net




--
Jeff Palmer
Palmer IT Consulting, LLC.
https://PalmerIT.net




--
Jeff Palmer
Palmer IT Consulting, LLC.
https://PalmerIT.net


--
Jeff Palmer
Palmer IT Consulting, LLC.
https://PalmerIT.net


locked Re: HamPi on a 128GB SD-Card

Jeff Palmer
 

"To over write what ever is on the disc with the image; the disk
must be mounted on the hardware."

Again, an unrelated cause. This is not universally true. It's a
problem with the OS, and the requirement to mount disks. As an
example, linux with "dd" can write to the raw disk, regardless of if
it's mounted or not. IF this image on the disk is corrupt, AND your
OS needs it to not be, sure. Fix the underlying issue.

But, this is not a problem with the disk image not overwriting the
data on the disk. This is an issue with the OS being unable to, or
unwilling to allow that write to occur.

On Tue, Jul 7, 2020 at 11:36 AM John Nicholas <stnick@iwichita.com> wrote:

Jeff,

I do not believe anyone is disagreeing with that statement.

I do think you do not understand our problem. It is not a direct software problem; it is much more of a hardware problem.

To over write what ever is on the disc with the image; the disk must be mounted on the hardware.

I had two different computers, 1 MAC and 1 PC that refused to mount two different disks. The option presented was some form of erase and reformat. That process, allowed the disk image to be put on the disk overwriting the format that I had just completed. In the end the the process you described showed the format did not matter to the overwrite. The format did matter to the mounting process.

I think this entire thread should die a natural death.

73

de KEoZUW - John

On Jul 7, 2020, at 9:23 AM, Jeff Palmer via groups.io <jeff=palmerit.net@groups.io> wrote:

OK, Now I am trying to argue.

There are absolutes in this field. Disk images ARE absolute.
writing them to a disk IS absolute. It overwrites *everything* that
holds any old layout. That is simply a fact.


--
Jeff Palmer
Palmer IT Consulting, LLC.
https://PalmerIT.net


locked Re: HamPi on a 128GB SD-Card

N5XMT
 

When you give an absolute in that "it just works" and ignore hardware issues, that is faulty reasoning.  The process fails and you cannot get the process to complete properly
Stop being a cocky ass

On Tue, Jul 7, 2020 at 8:36 AM Jeff Palmer via groups.io <jeff=palmerit.net@groups.io> wrote:
"but the issue becomes, if the hardware has an issue,"

Thank you for confirming my point.  It's not the disk image, or the
process by which the image is written. It's another (and unrelated)
cause.
Again, I stand by the facts I've presented.

On Tue, Jul 7, 2020 at 11:30 AM N5XMT <dacooley@...> wrote:
>
> Jeff,
> RELAX.  Just because you have not run across something doesn't mean it never happens.  That is also an anecdotal observation.  Just because someone eats 20 greasy hamburgers a day and lives to be 120 doesn't mean everyone will.  Computers work in absolutes, yes, but the issue becomes, if the hardware has an issue, the computer cannot always force it to perform as designed.  I had that issue with Engineers 30+ years ago.  They design a circuit, they have you assemble it, it doesn't properly work, both digital and analog.  What their book learning doesn't take into account is tolerances of components.  Tolerances stack up and now they are outside the "theoretical perfect world".  They don't see that, they argue and obviously whoever assembled it is the issue. Memory is the same way.  Bulk manufacturing isn't perfect, and the factory format may or may not have properly completed, and there may be an issue that keeps the system from properly accessing the device.  Unfortunately, I have seen it MANY times.  Windows is the least forgiving OS.  You stick a memory card in, or attach a drive, and some issues will make the disk subsystem put the device offline due to some access error.  At that point, even from a system utility, the drive cannot be written to or read from.  MacOS is probably the 2nd pickiest, and Linux the least.  Don't even get me started on DEC's VMS...
>
>
> On Tue, Jul 7, 2020 at 7:44 AM Jeff Palmer via groups.io <jeff=palmerit.net@groups.io> wrote:
>>
>> Mark,
>>
>> I've done nothing but state facts.  You've done nothing but personal
>> attacks ("One day I'll learn enough", "I guess you just haven't seen
>> enough", blah blah blah)
>> You've not stated a single fact, or provided any evidence to refute
>> the facts. You've only provided faulty anecdotal observations.
>>
>> So, yea.. I guess your 30+ years don't matter, if you're denying
>> actual facts.    Maybe take a moment and learn what a disk image
>> actually is, does, and doesn't do.
>>
>> Meanwhile, I'll sit here and wait for your next personal attack, since
>> you literally will not find anything to refute the *actual* facts
>> about what a disk image is.
>>
>> Also,  agreed.  My audience is elsewhere.  My audience is the people
>> in this group who want to educate themselves.  My audience is people
>> who want to hear facts. My audience is people who would rather things
>> work.   As the saying goes in computer sciences.  "Something that is
>> done wrong, may sometimes work.  Something that is done correctly will
>> always work".   Computers don't work on "random" unless specifically
>> instructed too.  there is nothing "random" about the success of
>> writing a disk image.  It's not subject to your OPINION, period.
>>
>>  I await your rebuttal against the facts.  But I suspect it'll be more
>> personal attacks, since you won't be able to refute.
>>
>>
>>
>> On Tue, Jul 7, 2020 at 10:26 AM Mark Griffith via groups.io
>> <mdgriffith2003=yahoo.com@groups.io> wrote:
>> >
>> > Well, I suppose my 30+ years also means something too?  Eh?
>> >
>> > I guess you just haven't seen enough yet.  My apologies.
>> >
>> > Argue away.  I'm not listening, so your audience is elsewhere.
>> >
>> > Mark
>> >
>> >
>> > On Tuesday, July 7, 2020, 9:23:46 AM CDT, Jeff Palmer via groups.io <jeff=palmerit.net@groups.io> wrote:
>> >
>> >
>> > OK,  Now I am trying to argue.
>> >
>> > There are absolutes in this field.  Disk images ARE absolute.
>> > writing them to a disk IS absolute.  It overwrites *everything* that
>> > holds any old layout.  That is simply a fact.  Your observations,
>> > while relevant, are not *accurate*.  There is a significant
>> > difference.  correlation does NOT equal causation.
>> >
>> > 30 years as a unix admin, dealing with disk images.. I'm fairly
>> > confident that I have "enough experience" to have learned what a disk
>> > image is, does, and doesn't do.
>> >
>> > One time, I bought new shoes.  I immediately stubbed my toe while
>> > wearing them.  Correlation:  new shoes = stubbed toes.  Causation:  I
>> > wasn't actually paying attention, and kicked something by accident.
>> > Facts are facts man. properly formatted and written disk images work
>> > 100% of the time.  IF it doesn't, as I mentioned in the last email,
>> > something else was the cause.  Period.
>> >
>> > On Tue, Jul 7, 2020 at 10:07 AM Mark Griffith via groups.io
>> > <mdgriffith2003=yahoo.com@groups.io> wrote:
>> > >
>> > > Whatever.  You *are* trying to argue and tell me my observations are not relevant to your discussion.
>> > >
>> > > It's unfortunate, that in what some people may call a discussion, it's obvious that one side doesn't want any other opinions to be expressed.  That's not a discussion.  There are no absolutes in this field.  You probably have not yet had enough experience to learn that yet.  Keep learning, it will come.
>> > >
>> > > Mark
>> > > KD0QYN
>> > >
>> > >
>> > > On Tuesday, July 7, 2020, 8:54:49 AM CDT, Jeff Palmer via groups.io <jeff=palmerit.net@groups.io> wrote:
>> > >
>> > >
>> > > Mark,
>> > >
>> > > If you are using a disk image, then no.. the existing partitioning, or
>> > > filesystems don't matter.  They literally get overwritten.  If you've
>> > > seen cases where this doesn't seem to be the case, I assure you,
>> > > something else is going on.  With a disk image, even the boot sectors
>> > > of a disk are overwritten.
>> > >
>> > > I'm not trying to argue.  But I am trying to clear up misinformation,
>> > > because it's become obvious in these threads that..  a little
>> > > misinformation leads to a LOT of confusion.  So,  I'd submit that if
>> > > you've "seen it matter" before,  you investigate the root cause, as I
>> > > assure you, it's not the fault of a disk image "sometimes working,
>> > > sometimes not".  a properly created disk image, which is also written
>> > > properly to a disk will *always* overwrite existing boot sectors,
>> > > partition maps, and existing filesystems.  Any result *other* than
>> > > that,  something else was at play.  (human error, invalid disk image,
>> > > an error with the software writing the image, faulty disk, etc etc the
>> > > list goes on and on.)
>> > >
>> > > On Tue, Jul 7, 2020 at 8:52 AM Mark Griffith via groups.io
>> > > <mdgriffith2003=yahoo.com@groups.io> wrote:
>> > > >
>> > > > The existence of a partition or filesystem on an SD card *should not* make any difference when writing an image, but it sometimes does.  That's why I say NOT to format the card before copying the image.  In most cases, I would say it doesn't make a difference, but I have seen some where it has.
>> > > >
>> > > > Also, I'm hoping all those that are using a giant SD card for the image know to use raspi-config to then expand the filesystem so all of the big SD card is used.
>> > > >
>> > > > Mark
>> > > > KD0QYN
>> > > >
>> > > >
>> > > > On Tuesday, July 7, 2020, 7:32:23 AM CDT, Jeff Palmer via groups.io <jeff=palmerit.net@groups.io> wrote:
>> > > >
>> > > >
>> > > > Interesting.
>> > > >
>> > > > Since etcher is writing a raw disk image, the existing filesystems,
>> > > > partitions, or layouts shouldn't matter (or affect writing the image)
>> > > >
>> > > > For what it's worth, I have HamPi running on a 128gb sd card.  I used
>> > > > etcher, and never had an issue.  I hope that helps.
>> > > >
>> > > > On Tue, Jul 7, 2020 at 1:16 AM thegadget techie <gadgetechie@...> wrote:
>> > > > >
>> > > > > I did pick up a couple of SanDisk xPros.  Seemed the issue may have been the factory format - I zapped the 2nd on w/ xFat (not FAT32) and no hitch w/ Etcher.  So maybe that's the issue. Also on MacPro (yeah yeah I'm 25+ yrs *nix guy).  I dd'd the 1st SDCard (wiped block 0 & 100) and the PI imager did all the magic - so long story short - not really sure of the issue - but both 128Gb's running like a charm.  Now onto USB boot on Pi4....
>> > > > >
>> > > > > Thanks all for replies.
>> > > > >
>> > > > > On Sun, Jul 5, 2020 at 5:50 AM John Nicholas <stnick@...> wrote:
>> > > > >>
>> > > > >> Ditto on San Disc.  I found that out with discs from my Infrared Imager at work.
>> > > > >>
>> > > > >> JN
>> > > > >>
>> > > > >> On Jul 5, 2020, at 3:24 AM, Roger Reeves M0ROJ <m0roj@...> wrote:
>> > > > >>
>> > > > >> It’s all down to the quality of the SD card. A recommendation is the SanDisk Extreme Pro, whatever the size.
>> > > > >>
>> > > > >> Roger M0ROJ
>> > > > >>
>> > > > >>
>> > > > >
>> > > >
>> > > >
>> > > >
>> > > > --
>> > > > Jeff Palmer
>> > > > Palmer IT Consulting, LLC.
>> > > > https://PalmerIT.net
>> > > >
>> > > >
>> > > >
>> > >
>> > >
>> > >
>> > > --
>> > > Jeff Palmer
>> > > Palmer IT Consulting, LLC.
>> > > https://PalmerIT.net
>> > >
>> > >
>> > >
>> >
>> >
>> >
>> > --
>> > Jeff Palmer
>> > Palmer IT Consulting, LLC.
>> > https://PalmerIT.net
>> >
>> >
>> >
>>
>>
>>
>> --
>> Jeff Palmer
>> Palmer IT Consulting, LLC.
>> https://PalmerIT.net
>>
>>
>>
>



--
Jeff Palmer
Palmer IT Consulting, LLC.
https://PalmerIT.net




locked Re: HamPi on a 128GB SD-Card

Jeff Palmer
 

"but the issue becomes, if the hardware has an issue,"

Thank you for confirming my point. It's not the disk image, or the
process by which the image is written. It's another (and unrelated)
cause.
Again, I stand by the facts I've presented.

On Tue, Jul 7, 2020 at 11:30 AM N5XMT <dacooley@gmail.com> wrote:

Jeff,
RELAX. Just because you have not run across something doesn't mean it never happens. That is also an anecdotal observation. Just because someone eats 20 greasy hamburgers a day and lives to be 120 doesn't mean everyone will. Computers work in absolutes, yes, but the issue becomes, if the hardware has an issue, the computer cannot always force it to perform as designed. I had that issue with Engineers 30+ years ago. They design a circuit, they have you assemble it, it doesn't properly work, both digital and analog. What their book learning doesn't take into account is tolerances of components. Tolerances stack up and now they are outside the "theoretical perfect world". They don't see that, they argue and obviously whoever assembled it is the issue. Memory is the same way. Bulk manufacturing isn't perfect, and the factory format may or may not have properly completed, and there may be an issue that keeps the system from properly accessing the device. Unfortunately, I have seen it MANY times. Windows is the least forgiving OS. You stick a memory card in, or attach a drive, and some issues will make the disk subsystem put the device offline due to some access error. At that point, even from a system utility, the drive cannot be written to or read from. MacOS is probably the 2nd pickiest, and Linux the least. Don't even get me started on DEC's VMS...


On Tue, Jul 7, 2020 at 7:44 AM Jeff Palmer via groups.io <jeff=palmerit.net@groups.io> wrote:

Mark,

I've done nothing but state facts. You've done nothing but personal
attacks ("One day I'll learn enough", "I guess you just haven't seen
enough", blah blah blah)
You've not stated a single fact, or provided any evidence to refute
the facts. You've only provided faulty anecdotal observations.

So, yea.. I guess your 30+ years don't matter, if you're denying
actual facts. Maybe take a moment and learn what a disk image
actually is, does, and doesn't do.

Meanwhile, I'll sit here and wait for your next personal attack, since
you literally will not find anything to refute the *actual* facts
about what a disk image is.

Also, agreed. My audience is elsewhere. My audience is the people
in this group who want to educate themselves. My audience is people
who want to hear facts. My audience is people who would rather things
work. As the saying goes in computer sciences. "Something that is
done wrong, may sometimes work. Something that is done correctly will
always work". Computers don't work on "random" unless specifically
instructed too. there is nothing "random" about the success of
writing a disk image. It's not subject to your OPINION, period.

I await your rebuttal against the facts. But I suspect it'll be more
personal attacks, since you won't be able to refute.



On Tue, Jul 7, 2020 at 10:26 AM Mark Griffith via groups.io
<mdgriffith2003=yahoo.com@groups.io> wrote:

Well, I suppose my 30+ years also means something too? Eh?

I guess you just haven't seen enough yet. My apologies.

Argue away. I'm not listening, so your audience is elsewhere.

Mark


On Tuesday, July 7, 2020, 9:23:46 AM CDT, Jeff Palmer via groups.io <jeff=palmerit.net@groups.io> wrote:


OK, Now I am trying to argue.

There are absolutes in this field. Disk images ARE absolute.
writing them to a disk IS absolute. It overwrites *everything* that
holds any old layout. That is simply a fact. Your observations,
while relevant, are not *accurate*. There is a significant
difference. correlation does NOT equal causation.

30 years as a unix admin, dealing with disk images.. I'm fairly
confident that I have "enough experience" to have learned what a disk
image is, does, and doesn't do.

One time, I bought new shoes. I immediately stubbed my toe while
wearing them. Correlation: new shoes = stubbed toes. Causation: I
wasn't actually paying attention, and kicked something by accident.
Facts are facts man. properly formatted and written disk images work
100% of the time. IF it doesn't, as I mentioned in the last email,
something else was the cause. Period.

On Tue, Jul 7, 2020 at 10:07 AM Mark Griffith via groups.io
<mdgriffith2003=yahoo.com@groups.io> wrote:

Whatever. You *are* trying to argue and tell me my observations are not relevant to your discussion.

It's unfortunate, that in what some people may call a discussion, it's obvious that one side doesn't want any other opinions to be expressed. That's not a discussion. There are no absolutes in this field. You probably have not yet had enough experience to learn that yet. Keep learning, it will come.

Mark
KD0QYN


On Tuesday, July 7, 2020, 8:54:49 AM CDT, Jeff Palmer via groups.io <jeff=palmerit.net@groups.io> wrote:


Mark,

If you are using a disk image, then no.. the existing partitioning, or
filesystems don't matter. They literally get overwritten. If you've
seen cases where this doesn't seem to be the case, I assure you,
something else is going on. With a disk image, even the boot sectors
of a disk are overwritten.

I'm not trying to argue. But I am trying to clear up misinformation,
because it's become obvious in these threads that.. a little
misinformation leads to a LOT of confusion. So, I'd submit that if
you've "seen it matter" before, you investigate the root cause, as I
assure you, it's not the fault of a disk image "sometimes working,
sometimes not". a properly created disk image, which is also written
properly to a disk will *always* overwrite existing boot sectors,
partition maps, and existing filesystems. Any result *other* than
that, something else was at play. (human error, invalid disk image,
an error with the software writing the image, faulty disk, etc etc the
list goes on and on.)

On Tue, Jul 7, 2020 at 8:52 AM Mark Griffith via groups.io
<mdgriffith2003=yahoo.com@groups.io> wrote:

The existence of a partition or filesystem on an SD card *should not* make any difference when writing an image, but it sometimes does. That's why I say NOT to format the card before copying the image. In most cases, I would say it doesn't make a difference, but I have seen some where it has.

Also, I'm hoping all those that are using a giant SD card for the image know to use raspi-config to then expand the filesystem so all of the big SD card is used.

Mark
KD0QYN


On Tuesday, July 7, 2020, 7:32:23 AM CDT, Jeff Palmer via groups.io <jeff=palmerit.net@groups.io> wrote:


Interesting.

Since etcher is writing a raw disk image, the existing filesystems,
partitions, or layouts shouldn't matter (or affect writing the image)

For what it's worth, I have HamPi running on a 128gb sd card. I used
etcher, and never had an issue. I hope that helps.

On Tue, Jul 7, 2020 at 1:16 AM thegadget techie <gadgetechie@gmail.com> wrote:

I did pick up a couple of SanDisk xPros. Seemed the issue may have been the factory format - I zapped the 2nd on w/ xFat (not FAT32) and no hitch w/ Etcher. So maybe that's the issue. Also on MacPro (yeah yeah I'm 25+ yrs *nix guy). I dd'd the 1st SDCard (wiped block 0 & 100) and the PI imager did all the magic - so long story short - not really sure of the issue - but both 128Gb's running like a charm. Now onto USB boot on Pi4....

Thanks all for replies.

On Sun, Jul 5, 2020 at 5:50 AM John Nicholas <stnick@iwichita.com> wrote:

Ditto on San Disc. I found that out with discs from my Infrared Imager at work.

JN

On Jul 5, 2020, at 3:24 AM, Roger Reeves M0ROJ <m0roj@goldford.co.uk> wrote:

It’s all down to the quality of the SD card. A recommendation is the SanDisk Extreme Pro, whatever the size.

Roger M0ROJ



--
Jeff Palmer
Palmer IT Consulting, LLC.
https://PalmerIT.net




--
Jeff Palmer
Palmer IT Consulting, LLC.
https://PalmerIT.net




--
Jeff Palmer
Palmer IT Consulting, LLC.
https://PalmerIT.net




--
Jeff Palmer
Palmer IT Consulting, LLC.
https://PalmerIT.net


--
Jeff Palmer
Palmer IT Consulting, LLC.
https://PalmerIT.net


locked Re: HamPi on a 128GB SD-Card

John Nicholas
 

Jeff,

I do not believe anyone is disagreeing with that statement.

I do think you do not understand our problem.  It is not a direct software problem; it is much more of a hardware problem.

To over write what ever is on the disc with the image;  the disk  must be mounted on the hardware.

I had two different computers,  1 MAC and 1 PC that refused to mount two different disks.  The option presented was some form of erase and reformat.  That process, allowed the disk image to be put on the disk overwriting the format that I had just completed.  In the end the the process you described showed the format did not matter to the overwrite.  The format did matter to the mounting process.

I think this entire thread should die a natural death.  

73

de KEoZUW  -  John

On Jul 7, 2020, at 9:23 AM, Jeff Palmer via groups.io <jeff@...> wrote:

OK,  Now I am trying to argue.

There are absolutes in this field.   Disk images ARE absolute.
writing them to a disk IS absolute.  It overwrites *everything* that
holds any old layout.  That is simply a fact. 


locked Re: HamPi on a 128GB SD-Card

N5XMT
 

Jeff,
RELAX.  Just because you have not run across something doesn't mean it never happens.  That is also an anecdotal observation.  Just because someone eats 20 greasy hamburgers a day and lives to be 120 doesn't mean everyone will.  Computers work in absolutes, yes, but the issue becomes, if the hardware has an issue, the computer cannot always force it to perform as designed.  I had that issue with Engineers 30+ years ago.  They design a circuit, they have you assemble it, it doesn't properly work, both digital and analog.  What their book learning doesn't take into account is tolerances of components.  Tolerances stack up and now they are outside the "theoretical perfect world".  They don't see that, they argue and obviously whoever assembled it is the issue. Memory is the same way.  Bulk manufacturing isn't perfect, and the factory format may or may not have properly completed, and there may be an issue that keeps the system from properly accessing the device.  Unfortunately, I have seen it MANY times.  Windows is the least forgiving OS.  You stick a memory card in, or attach a drive, and some issues will make the disk subsystem put the device offline due to some access error.  At that point, even from a system utility, the drive cannot be written to or read from.  MacOS is probably the 2nd pickiest, and Linux the least.  Don't even get me started on DEC's VMS...


On Tue, Jul 7, 2020 at 7:44 AM Jeff Palmer via groups.io <jeff=palmerit.net@groups.io> wrote:
Mark,

I've done nothing but state facts.  You've done nothing but personal
attacks ("One day I'll learn enough", "I guess you just haven't seen
enough", blah blah blah)
You've not stated a single fact, or provided any evidence to refute
the facts. You've only provided faulty anecdotal observations.

So, yea.. I guess your 30+ years don't matter, if you're denying
actual facts.    Maybe take a moment and learn what a disk image
actually is, does, and doesn't do.

Meanwhile, I'll sit here and wait for your next personal attack, since
you literally will not find anything to refute the *actual* facts
about what a disk image is.

Also,  agreed.  My audience is elsewhere.  My audience is the people
in this group who want to educate themselves.  My audience is people
who want to hear facts. My audience is people who would rather things
work.   As the saying goes in computer sciences.  "Something that is
done wrong, may sometimes work.  Something that is done correctly will
always work".   Computers don't work on "random" unless specifically
instructed too.  there is nothing "random" about the success of
writing a disk image.  It's not subject to your OPINION, period.

 I await your rebuttal against the facts.  But I suspect it'll be more
personal attacks, since you won't be able to refute.



On Tue, Jul 7, 2020 at 10:26 AM Mark Griffith via groups.io
<mdgriffith2003=yahoo.com@groups.io> wrote:
>
> Well, I suppose my 30+ years also means something too?  Eh?
>
> I guess you just haven't seen enough yet.  My apologies.
>
> Argue away.  I'm not listening, so your audience is elsewhere.
>
> Mark
>
>
> On Tuesday, July 7, 2020, 9:23:46 AM CDT, Jeff Palmer via groups.io <jeff=palmerit.net@groups.io> wrote:
>
>
> OK,  Now I am trying to argue.
>
> There are absolutes in this field.  Disk images ARE absolute.
> writing them to a disk IS absolute.  It overwrites *everything* that
> holds any old layout.  That is simply a fact.  Your observations,
> while relevant, are not *accurate*.  There is a significant
> difference.  correlation does NOT equal causation.
>
> 30 years as a unix admin, dealing with disk images.. I'm fairly
> confident that I have "enough experience" to have learned what a disk
> image is, does, and doesn't do.
>
> One time, I bought new shoes.  I immediately stubbed my toe while
> wearing them.  Correlation:  new shoes = stubbed toes.  Causation:  I
> wasn't actually paying attention, and kicked something by accident.
> Facts are facts man. properly formatted and written disk images work
> 100% of the time.  IF it doesn't, as I mentioned in the last email,
> something else was the cause.  Period.
>
> On Tue, Jul 7, 2020 at 10:07 AM Mark Griffith via groups.io
> <mdgriffith2003=yahoo.com@groups.io> wrote:
> >
> > Whatever.  You *are* trying to argue and tell me my observations are not relevant to your discussion.
> >
> > It's unfortunate, that in what some people may call a discussion, it's obvious that one side doesn't want any other opinions to be expressed.  That's not a discussion.  There are no absolutes in this field.  You probably have not yet had enough experience to learn that yet.  Keep learning, it will come.
> >
> > Mark
> > KD0QYN
> >
> >
> > On Tuesday, July 7, 2020, 8:54:49 AM CDT, Jeff Palmer via groups.io <jeff=palmerit.net@groups.io> wrote:
> >
> >
> > Mark,
> >
> > If you are using a disk image, then no.. the existing partitioning, or
> > filesystems don't matter.  They literally get overwritten.  If you've
> > seen cases where this doesn't seem to be the case, I assure you,
> > something else is going on.  With a disk image, even the boot sectors
> > of a disk are overwritten.
> >
> > I'm not trying to argue.  But I am trying to clear up misinformation,
> > because it's become obvious in these threads that..  a little
> > misinformation leads to a LOT of confusion.  So,  I'd submit that if
> > you've "seen it matter" before,  you investigate the root cause, as I
> > assure you, it's not the fault of a disk image "sometimes working,
> > sometimes not".  a properly created disk image, which is also written
> > properly to a disk will *always* overwrite existing boot sectors,
> > partition maps, and existing filesystems.  Any result *other* than
> > that,  something else was at play.  (human error, invalid disk image,
> > an error with the software writing the image, faulty disk, etc etc the
> > list goes on and on.)
> >
> > On Tue, Jul 7, 2020 at 8:52 AM Mark Griffith via groups.io
> > <mdgriffith2003=yahoo.com@groups.io> wrote:
> > >
> > > The existence of a partition or filesystem on an SD card *should not* make any difference when writing an image, but it sometimes does.  That's why I say NOT to format the card before copying the image.  In most cases, I would say it doesn't make a difference, but I have seen some where it has.
> > >
> > > Also, I'm hoping all those that are using a giant SD card for the image know to use raspi-config to then expand the filesystem so all of the big SD card is used.
> > >
> > > Mark
> > > KD0QYN
> > >
> > >
> > > On Tuesday, July 7, 2020, 7:32:23 AM CDT, Jeff Palmer via groups.io <jeff=palmerit.net@groups.io> wrote:
> > >
> > >
> > > Interesting.
> > >
> > > Since etcher is writing a raw disk image, the existing filesystems,
> > > partitions, or layouts shouldn't matter (or affect writing the image)
> > >
> > > For what it's worth, I have HamPi running on a 128gb sd card.  I used
> > > etcher, and never had an issue.  I hope that helps.
> > >
> > > On Tue, Jul 7, 2020 at 1:16 AM thegadget techie <gadgetechie@...> wrote:
> > > >
> > > > I did pick up a couple of SanDisk xPros.  Seemed the issue may have been the factory format - I zapped the 2nd on w/ xFat (not FAT32) and no hitch w/ Etcher.  So maybe that's the issue. Also on MacPro (yeah yeah I'm 25+ yrs *nix guy).  I dd'd the 1st SDCard (wiped block 0 & 100) and the PI imager did all the magic - so long story short - not really sure of the issue - but both 128Gb's running like a charm.  Now onto USB boot on Pi4....
> > > >
> > > > Thanks all for replies.
> > > >
> > > > On Sun, Jul 5, 2020 at 5:50 AM John Nicholas <stnick@...> wrote:
> > > >>
> > > >> Ditto on San Disc.  I found that out with discs from my Infrared Imager at work.
> > > >>
> > > >> JN
> > > >>
> > > >> On Jul 5, 2020, at 3:24 AM, Roger Reeves M0ROJ <m0roj@...> wrote:
> > > >>
> > > >> It’s all down to the quality of the SD card. A recommendation is the SanDisk Extreme Pro, whatever the size.
> > > >>
> > > >> Roger M0ROJ
> > > >>
> > > >>
> > > >
> > >
> > >
> > >
> > > --
> > > Jeff Palmer
> > > Palmer IT Consulting, LLC.
> > > https://PalmerIT.net
> > >
> > >
> > >
> >
> >
> >
> > --
> > Jeff Palmer
> > Palmer IT Consulting, LLC.
> > https://PalmerIT.net
> >
> >
> >
>
>
>
> --
> Jeff Palmer
> Palmer IT Consulting, LLC.
> https://PalmerIT.net
>
>
>



--
Jeff Palmer
Palmer IT Consulting, LLC.
https://PalmerIT.net




locked Re: HamPi on a 128GB SD-Card

N5XMT
 

I have also been in IT for 30 years.  and I have seen cases where a disk image could NOT be written due to some unforseen corruption on a factory fresh disk/memory card etc.  The OS does look at the device and if it cannot properly address it when brought online, it blocks access to the device by other programs, including under linux, dd.  in every case except a few where the corruption was permanent/physical, a quick fdisk/format of the device cleared the issue and allowed the imaging to proceed


On Tue, Jul 7, 2020 at 7:23 AM Jeff Palmer via groups.io <jeff=palmerit.net@groups.io> wrote:
OK,  Now I am trying to argue.

There are absolutes in this field.   Disk images ARE absolute.
writing them to a disk IS absolute.  It overwrites *everything* that
holds any old layout.  That is simply a fact.  Your observations,
while relevant, are not *accurate*.  There is a significant
difference.  correlation does NOT equal causation.

30 years as a unix admin, dealing with disk images.. I'm fairly
confident that I have "enough experience" to have learned what a disk
image is, does, and doesn't do.

One time, I bought new shoes.   I immediately stubbed my toe while
wearing them.  Correlation:  new shoes = stubbed toes.   Causation:  I
wasn't actually paying attention, and kicked something by accident.
Facts are facts man. properly formatted and written disk images work
100% of the time.  IF it doesn't, as I mentioned in the last email,
something else was the cause.  Period.

On Tue, Jul 7, 2020 at 10:07 AM Mark Griffith via groups.io
<mdgriffith2003=yahoo.com@groups.io> wrote:
>
> Whatever.  You *are* trying to argue and tell me my observations are not relevant to your discussion.
>
> It's unfortunate, that in what some people may call a discussion, it's obvious that one side doesn't want any other opinions to be expressed.  That's not a discussion.  There are no absolutes in this field.  You probably have not yet had enough experience to learn that yet.  Keep learning, it will come.
>
> Mark
> KD0QYN
>
>
> On Tuesday, July 7, 2020, 8:54:49 AM CDT, Jeff Palmer via groups.io <jeff=palmerit.net@groups.io> wrote:
>
>
> Mark,
>
> If you are using a disk image, then no.. the existing partitioning, or
> filesystems don't matter.  They literally get overwritten.  If you've
> seen cases where this doesn't seem to be the case, I assure you,
> something else is going on.  With a disk image, even the boot sectors
> of a disk are overwritten.
>
> I'm not trying to argue.  But I am trying to clear up misinformation,
> because it's become obvious in these threads that..  a little
> misinformation leads to a LOT of confusion.  So,  I'd submit that if
> you've "seen it matter" before,  you investigate the root cause, as I
> assure you, it's not the fault of a disk image "sometimes working,
> sometimes not".  a properly created disk image, which is also written
> properly to a disk will *always* overwrite existing boot sectors,
> partition maps, and existing filesystems.  Any result *other* than
> that,  something else was at play.  (human error, invalid disk image,
> an error with the software writing the image, faulty disk, etc etc the
> list goes on and on.)
>
> On Tue, Jul 7, 2020 at 8:52 AM Mark Griffith via groups.io
> <mdgriffith2003=yahoo.com@groups.io> wrote:
> >
> > The existence of a partition or filesystem on an SD card *should not* make any difference when writing an image, but it sometimes does.  That's why I say NOT to format the card before copying the image.  In most cases, I would say it doesn't make a difference, but I have seen some where it has.
> >
> > Also, I'm hoping all those that are using a giant SD card for the image know to use raspi-config to then expand the filesystem so all of the big SD card is used.
> >
> > Mark
> > KD0QYN
> >
> >
> > On Tuesday, July 7, 2020, 7:32:23 AM CDT, Jeff Palmer via groups.io <jeff=palmerit.net@groups.io> wrote:
> >
> >
> > Interesting.
> >
> > Since etcher is writing a raw disk image, the existing filesystems,
> > partitions, or layouts shouldn't matter (or affect writing the image)
> >
> > For what it's worth, I have HamPi running on a 128gb sd card.  I used
> > etcher, and never had an issue.  I hope that helps.
> >
> > On Tue, Jul 7, 2020 at 1:16 AM thegadget techie <gadgetechie@...> wrote:
> > >
> > > I did pick up a couple of SanDisk xPros.  Seemed the issue may have been the factory format - I zapped the 2nd on w/ xFat (not FAT32) and no hitch w/ Etcher.  So maybe that's the issue. Also on MacPro (yeah yeah I'm 25+ yrs *nix guy).  I dd'd the 1st SDCard (wiped block 0 & 100) and the PI imager did all the magic - so long story short - not really sure of the issue - but both 128Gb's running like a charm.  Now onto USB boot on Pi4....
> > >
> > > Thanks all for replies.
> > >
> > > On Sun, Jul 5, 2020 at 5:50 AM John Nicholas <stnick@...> wrote:
> > >>
> > >> Ditto on San Disc.  I found that out with discs from my Infrared Imager at work.
> > >>
> > >> JN
> > >>
> > >> On Jul 5, 2020, at 3:24 AM, Roger Reeves M0ROJ <m0roj@...> wrote:
> > >>
> > >> It’s all down to the quality of the SD card. A recommendation is the SanDisk Extreme Pro, whatever the size.
> > >>
> > >> Roger M0ROJ
> > >>
> > >>
> > >
> >
> >
> >
> > --
> > Jeff Palmer
> > Palmer IT Consulting, LLC.
> > https://PalmerIT.net
> >
> >
> >
>
>
>
> --
> Jeff Palmer
> Palmer IT Consulting, LLC.
> https://PalmerIT.net
>
>
>



--
Jeff Palmer
Palmer IT Consulting, LLC.
https://PalmerIT.net




locked Re: HamPi on a 128GB SD-Card

Jeff Palmer
 

Mark,

I've done nothing but state facts. You've done nothing but personal
attacks ("One day I'll learn enough", "I guess you just haven't seen
enough", blah blah blah)
You've not stated a single fact, or provided any evidence to refute
the facts. You've only provided faulty anecdotal observations.

So, yea.. I guess your 30+ years don't matter, if you're denying
actual facts. Maybe take a moment and learn what a disk image
actually is, does, and doesn't do.

Meanwhile, I'll sit here and wait for your next personal attack, since
you literally will not find anything to refute the *actual* facts
about what a disk image is.

Also, agreed. My audience is elsewhere. My audience is the people
in this group who want to educate themselves. My audience is people
who want to hear facts. My audience is people who would rather things
work. As the saying goes in computer sciences. "Something that is
done wrong, may sometimes work. Something that is done correctly will
always work". Computers don't work on "random" unless specifically
instructed too. there is nothing "random" about the success of
writing a disk image. It's not subject to your OPINION, period.

I await your rebuttal against the facts. But I suspect it'll be more
personal attacks, since you won't be able to refute.



On Tue, Jul 7, 2020 at 10:26 AM Mark Griffith via groups.io
<mdgriffith2003=yahoo.com@groups.io> wrote:

Well, I suppose my 30+ years also means something too? Eh?

I guess you just haven't seen enough yet. My apologies.

Argue away. I'm not listening, so your audience is elsewhere.

Mark


On Tuesday, July 7, 2020, 9:23:46 AM CDT, Jeff Palmer via groups.io <jeff=palmerit.net@groups.io> wrote:


OK, Now I am trying to argue.

There are absolutes in this field. Disk images ARE absolute.
writing them to a disk IS absolute. It overwrites *everything* that
holds any old layout. That is simply a fact. Your observations,
while relevant, are not *accurate*. There is a significant
difference. correlation does NOT equal causation.

30 years as a unix admin, dealing with disk images.. I'm fairly
confident that I have "enough experience" to have learned what a disk
image is, does, and doesn't do.

One time, I bought new shoes. I immediately stubbed my toe while
wearing them. Correlation: new shoes = stubbed toes. Causation: I
wasn't actually paying attention, and kicked something by accident.
Facts are facts man. properly formatted and written disk images work
100% of the time. IF it doesn't, as I mentioned in the last email,
something else was the cause. Period.

On Tue, Jul 7, 2020 at 10:07 AM Mark Griffith via groups.io
<mdgriffith2003=yahoo.com@groups.io> wrote:

Whatever. You *are* trying to argue and tell me my observations are not relevant to your discussion.

It's unfortunate, that in what some people may call a discussion, it's obvious that one side doesn't want any other opinions to be expressed. That's not a discussion. There are no absolutes in this field. You probably have not yet had enough experience to learn that yet. Keep learning, it will come.

Mark
KD0QYN


On Tuesday, July 7, 2020, 8:54:49 AM CDT, Jeff Palmer via groups.io <jeff=palmerit.net@groups.io> wrote:


Mark,

If you are using a disk image, then no.. the existing partitioning, or
filesystems don't matter. They literally get overwritten. If you've
seen cases where this doesn't seem to be the case, I assure you,
something else is going on. With a disk image, even the boot sectors
of a disk are overwritten.

I'm not trying to argue. But I am trying to clear up misinformation,
because it's become obvious in these threads that.. a little
misinformation leads to a LOT of confusion. So, I'd submit that if
you've "seen it matter" before, you investigate the root cause, as I
assure you, it's not the fault of a disk image "sometimes working,
sometimes not". a properly created disk image, which is also written
properly to a disk will *always* overwrite existing boot sectors,
partition maps, and existing filesystems. Any result *other* than
that, something else was at play. (human error, invalid disk image,
an error with the software writing the image, faulty disk, etc etc the
list goes on and on.)

On Tue, Jul 7, 2020 at 8:52 AM Mark Griffith via groups.io
<mdgriffith2003=yahoo.com@groups.io> wrote:

The existence of a partition or filesystem on an SD card *should not* make any difference when writing an image, but it sometimes does. That's why I say NOT to format the card before copying the image. In most cases, I would say it doesn't make a difference, but I have seen some where it has.

Also, I'm hoping all those that are using a giant SD card for the image know to use raspi-config to then expand the filesystem so all of the big SD card is used.

Mark
KD0QYN


On Tuesday, July 7, 2020, 7:32:23 AM CDT, Jeff Palmer via groups.io <jeff=palmerit.net@groups.io> wrote:


Interesting.

Since etcher is writing a raw disk image, the existing filesystems,
partitions, or layouts shouldn't matter (or affect writing the image)

For what it's worth, I have HamPi running on a 128gb sd card. I used
etcher, and never had an issue. I hope that helps.

On Tue, Jul 7, 2020 at 1:16 AM thegadget techie <gadgetechie@gmail.com> wrote:

I did pick up a couple of SanDisk xPros. Seemed the issue may have been the factory format - I zapped the 2nd on w/ xFat (not FAT32) and no hitch w/ Etcher. So maybe that's the issue. Also on MacPro (yeah yeah I'm 25+ yrs *nix guy). I dd'd the 1st SDCard (wiped block 0 & 100) and the PI imager did all the magic - so long story short - not really sure of the issue - but both 128Gb's running like a charm. Now onto USB boot on Pi4....

Thanks all for replies.

On Sun, Jul 5, 2020 at 5:50 AM John Nicholas <stnick@iwichita.com> wrote:

Ditto on San Disc. I found that out with discs from my Infrared Imager at work.

JN

On Jul 5, 2020, at 3:24 AM, Roger Reeves M0ROJ <m0roj@goldford.co.uk> wrote:

It’s all down to the quality of the SD card. A recommendation is the SanDisk Extreme Pro, whatever the size.

Roger M0ROJ



--
Jeff Palmer
Palmer IT Consulting, LLC.
https://PalmerIT.net




--
Jeff Palmer
Palmer IT Consulting, LLC.
https://PalmerIT.net




--
Jeff Palmer
Palmer IT Consulting, LLC.
https://PalmerIT.net




--
Jeff Palmer
Palmer IT Consulting, LLC.
https://PalmerIT.net


locked Re: HamPi on a 128GB SD-Card

Mark Griffith
 

Well, I suppose my 30+ years also means something too?  Eh?

I guess you just haven't seen enough yet.  My apologies.

Argue away.  I'm not listening, so your audience is elsewhere.

Mark


On Tuesday, July 7, 2020, 9:23:46 AM CDT, Jeff Palmer via groups.io <jeff@...> wrote:


OK,  Now I am trying to argue.

There are absolutes in this field.  Disk images ARE absolute.
writing them to a disk IS absolute.  It overwrites *everything* that
holds any old layout.  That is simply a fact.  Your observations,
while relevant, are not *accurate*.  There is a significant
difference.  correlation does NOT equal causation.

30 years as a unix admin, dealing with disk images.. I'm fairly
confident that I have "enough experience" to have learned what a disk
image is, does, and doesn't do.

One time, I bought new shoes.  I immediately stubbed my toe while
wearing them.  Correlation:  new shoes = stubbed toes.  Causation:  I
wasn't actually paying attention, and kicked something by accident.
Facts are facts man. properly formatted and written disk images work
100% of the time.  IF it doesn't, as I mentioned in the last email,
something else was the cause.  Period.

On Tue, Jul 7, 2020 at 10:07 AM Mark Griffith via groups.io
<mdgriffith2003=yahoo.com@groups.io> wrote:
>
> Whatever.  You *are* trying to argue and tell me my observations are not relevant to your discussion.
>
> It's unfortunate, that in what some people may call a discussion, it's obvious that one side doesn't want any other opinions to be expressed.  That's not a discussion.  There are no absolutes in this field.  You probably have not yet had enough experience to learn that yet.  Keep learning, it will come.
>
> Mark
> KD0QYN
>
>
> On Tuesday, July 7, 2020, 8:54:49 AM CDT, Jeff Palmer via groups.io <jeff=palmerit.net@groups.io> wrote:
>
>
> Mark,
>
> If you are using a disk image, then no.. the existing partitioning, or
> filesystems don't matter.  They literally get overwritten.  If you've
> seen cases where this doesn't seem to be the case, I assure you,
> something else is going on.  With a disk image, even the boot sectors
> of a disk are overwritten.
>
> I'm not trying to argue.  But I am trying to clear up misinformation,
> because it's become obvious in these threads that..  a little
> misinformation leads to a LOT of confusion.  So,  I'd submit that if
> you've "seen it matter" before,  you investigate the root cause, as I
> assure you, it's not the fault of a disk image "sometimes working,
> sometimes not".  a properly created disk image, which is also written
> properly to a disk will *always* overwrite existing boot sectors,
> partition maps, and existing filesystems.  Any result *other* than
> that,  something else was at play.  (human error, invalid disk image,
> an error with the software writing the image, faulty disk, etc etc the
> list goes on and on.)
>
> On Tue, Jul 7, 2020 at 8:52 AM Mark Griffith via groups.io
> <mdgriffith2003=yahoo.com@groups.io> wrote:
> >
> > The existence of a partition or filesystem on an SD card *should not* make any difference when writing an image, but it sometimes does.  That's why I say NOT to format the card before copying the image.  In most cases, I would say it doesn't make a difference, but I have seen some where it has.
> >
> > Also, I'm hoping all those that are using a giant SD card for the image know to use raspi-config to then expand the filesystem so all of the big SD card is used.
> >
> > Mark
> > KD0QYN
> >
> >
> > On Tuesday, July 7, 2020, 7:32:23 AM CDT, Jeff Palmer via groups.io <jeff=palmerit.net@groups.io> wrote:
> >
> >
> > Interesting.
> >
> > Since etcher is writing a raw disk image, the existing filesystems,
> > partitions, or layouts shouldn't matter (or affect writing the image)
> >
> > For what it's worth, I have HamPi running on a 128gb sd card.  I used
> > etcher, and never had an issue.  I hope that helps.
> >
> > On Tue, Jul 7, 2020 at 1:16 AM thegadget techie <gadgetechie@...> wrote:
> > >
> > > I did pick up a couple of SanDisk xPros.  Seemed the issue may have been the factory format - I zapped the 2nd on w/ xFat (not FAT32) and no hitch w/ Etcher.  So maybe that's the issue. Also on MacPro (yeah yeah I'm 25+ yrs *nix guy).  I dd'd the 1st SDCard (wiped block 0 & 100) and the PI imager did all the magic - so long story short - not really sure of the issue - but both 128Gb's running like a charm.  Now onto USB boot on Pi4....
> > >
> > > Thanks all for replies.
> > >
> > > On Sun, Jul 5, 2020 at 5:50 AM John Nicholas <stnick@...> wrote:
> > >>
> > >> Ditto on San Disc.  I found that out with discs from my Infrared Imager at work.
> > >>
> > >> JN
> > >>
> > >> On Jul 5, 2020, at 3:24 AM, Roger Reeves M0ROJ <m0roj@...> wrote:
> > >>
> > >> It’s all down to the quality of the SD card. A recommendation is the SanDisk Extreme Pro, whatever the size.
> > >>
> > >> Roger M0ROJ
> > >>
> > >>
> > >
> >
> >
> >
> > --
> > Jeff Palmer
> > Palmer IT Consulting, LLC.
> > https://PalmerIT.net
> >
> >
> >
>
>
>
> --
> Jeff Palmer
> Palmer IT Consulting, LLC.
> https://PalmerIT.net
>
>
>



--
Jeff Palmer
Palmer IT Consulting, LLC.
https://PalmerIT.net



locked Re: HamPi on a 128GB SD-Card

Jeff Palmer
 

OK, Now I am trying to argue.

There are absolutes in this field. Disk images ARE absolute.
writing them to a disk IS absolute. It overwrites *everything* that
holds any old layout. That is simply a fact. Your observations,
while relevant, are not *accurate*. There is a significant
difference. correlation does NOT equal causation.

30 years as a unix admin, dealing with disk images.. I'm fairly
confident that I have "enough experience" to have learned what a disk
image is, does, and doesn't do.

One time, I bought new shoes. I immediately stubbed my toe while
wearing them. Correlation: new shoes = stubbed toes. Causation: I
wasn't actually paying attention, and kicked something by accident.
Facts are facts man. properly formatted and written disk images work
100% of the time. IF it doesn't, as I mentioned in the last email,
something else was the cause. Period.

On Tue, Jul 7, 2020 at 10:07 AM Mark Griffith via groups.io
<mdgriffith2003=yahoo.com@groups.io> wrote:

Whatever. You *are* trying to argue and tell me my observations are not relevant to your discussion.

It's unfortunate, that in what some people may call a discussion, it's obvious that one side doesn't want any other opinions to be expressed. That's not a discussion. There are no absolutes in this field. You probably have not yet had enough experience to learn that yet. Keep learning, it will come.

Mark
KD0QYN


On Tuesday, July 7, 2020, 8:54:49 AM CDT, Jeff Palmer via groups.io <jeff=palmerit.net@groups.io> wrote:


Mark,

If you are using a disk image, then no.. the existing partitioning, or
filesystems don't matter. They literally get overwritten. If you've
seen cases where this doesn't seem to be the case, I assure you,
something else is going on. With a disk image, even the boot sectors
of a disk are overwritten.

I'm not trying to argue. But I am trying to clear up misinformation,
because it's become obvious in these threads that.. a little
misinformation leads to a LOT of confusion. So, I'd submit that if
you've "seen it matter" before, you investigate the root cause, as I
assure you, it's not the fault of a disk image "sometimes working,
sometimes not". a properly created disk image, which is also written
properly to a disk will *always* overwrite existing boot sectors,
partition maps, and existing filesystems. Any result *other* than
that, something else was at play. (human error, invalid disk image,
an error with the software writing the image, faulty disk, etc etc the
list goes on and on.)

On Tue, Jul 7, 2020 at 8:52 AM Mark Griffith via groups.io
<mdgriffith2003=yahoo.com@groups.io> wrote:

The existence of a partition or filesystem on an SD card *should not* make any difference when writing an image, but it sometimes does. That's why I say NOT to format the card before copying the image. In most cases, I would say it doesn't make a difference, but I have seen some where it has.

Also, I'm hoping all those that are using a giant SD card for the image know to use raspi-config to then expand the filesystem so all of the big SD card is used.

Mark
KD0QYN


On Tuesday, July 7, 2020, 7:32:23 AM CDT, Jeff Palmer via groups.io <jeff=palmerit.net@groups.io> wrote:


Interesting.

Since etcher is writing a raw disk image, the existing filesystems,
partitions, or layouts shouldn't matter (or affect writing the image)

For what it's worth, I have HamPi running on a 128gb sd card. I used
etcher, and never had an issue. I hope that helps.

On Tue, Jul 7, 2020 at 1:16 AM thegadget techie <gadgetechie@gmail.com> wrote:

I did pick up a couple of SanDisk xPros. Seemed the issue may have been the factory format - I zapped the 2nd on w/ xFat (not FAT32) and no hitch w/ Etcher. So maybe that's the issue. Also on MacPro (yeah yeah I'm 25+ yrs *nix guy). I dd'd the 1st SDCard (wiped block 0 & 100) and the PI imager did all the magic - so long story short - not really sure of the issue - but both 128Gb's running like a charm. Now onto USB boot on Pi4....

Thanks all for replies.

On Sun, Jul 5, 2020 at 5:50 AM John Nicholas <stnick@iwichita.com> wrote:

Ditto on San Disc. I found that out with discs from my Infrared Imager at work.

JN

On Jul 5, 2020, at 3:24 AM, Roger Reeves M0ROJ <m0roj@goldford.co.uk> wrote:

It’s all down to the quality of the SD card. A recommendation is the SanDisk Extreme Pro, whatever the size.

Roger M0ROJ



--
Jeff Palmer
Palmer IT Consulting, LLC.
https://PalmerIT.net




--
Jeff Palmer
Palmer IT Consulting, LLC.
https://PalmerIT.net




--
Jeff Palmer
Palmer IT Consulting, LLC.
https://PalmerIT.net


locked Re: HamPi on a 128GB SD-Card

Mark Griffith
 

Whatever.  You *are* trying to argue and tell me my observations are not relevant to your discussion.

It's unfortunate, that in what some people may call a discussion, it's obvious that one side doesn't want any other opinions to be expressed.  That's not a discussion.  There are no absolutes in this field.  You probably have not yet had enough experience to learn that yet.  Keep learning, it will come.

Mark
KD0QYN


On Tuesday, July 7, 2020, 8:54:49 AM CDT, Jeff Palmer via groups.io <jeff@...> wrote:


Mark,

If you are using a disk image, then no.. the existing partitioning, or
filesystems don't matter.  They literally get overwritten.  If you've
seen cases where this doesn't seem to be the case, I assure you,
something else is going on.  With a disk image, even the boot sectors
of a disk are overwritten.

I'm not trying to argue.  But I am trying to clear up misinformation,
because it's become obvious in these threads that..  a little
misinformation leads to a LOT of confusion.  So,  I'd submit that if
you've "seen it matter" before,  you investigate the root cause, as I
assure you, it's not the fault of a disk image "sometimes working,
sometimes not".  a properly created disk image, which is also written
properly to a disk will *always* overwrite existing boot sectors,
partition maps, and existing filesystems.  Any result *other* than
that,  something else was at play.  (human error, invalid disk image,
an error with the software writing the image, faulty disk, etc etc the
list goes on and on.)

On Tue, Jul 7, 2020 at 8:52 AM Mark Griffith via groups.io
<mdgriffith2003=yahoo.com@groups.io> wrote:
>
> The existence of a partition or filesystem on an SD card *should not* make any difference when writing an image, but it sometimes does.  That's why I say NOT to format the card before copying the image.  In most cases, I would say it doesn't make a difference, but I have seen some where it has.
>
> Also, I'm hoping all those that are using a giant SD card for the image know to use raspi-config to then expand the filesystem so all of the big SD card is used.
>
> Mark
> KD0QYN
>
>
> On Tuesday, July 7, 2020, 7:32:23 AM CDT, Jeff Palmer via groups.io <jeff=palmerit.net@groups.io> wrote:
>
>
> Interesting.
>
> Since etcher is writing a raw disk image, the existing filesystems,
> partitions, or layouts shouldn't matter (or affect writing the image)
>
> For what it's worth, I have HamPi running on a 128gb sd card.  I used
> etcher, and never had an issue.  I hope that helps.
>
> On Tue, Jul 7, 2020 at 1:16 AM thegadget techie <gadgetechie@...> wrote:
> >
> > I did pick up a couple of SanDisk xPros.  Seemed the issue may have been the factory format - I zapped the 2nd on w/ xFat (not FAT32) and no hitch w/ Etcher.  So maybe that's the issue. Also on MacPro (yeah yeah I'm 25+ yrs *nix guy).  I dd'd the 1st SDCard (wiped block 0 & 100) and the PI imager did all the magic - so long story short - not really sure of the issue - but both 128Gb's running like a charm.  Now onto USB boot on Pi4....
> >
> > Thanks all for replies.
> >
> > On Sun, Jul 5, 2020 at 5:50 AM John Nicholas <stnick@...> wrote:
> >>
> >> Ditto on San Disc.  I found that out with discs from my Infrared Imager at work.
> >>
> >> JN
> >>
> >> On Jul 5, 2020, at 3:24 AM, Roger Reeves M0ROJ <m0roj@...> wrote:
> >>
> >> It’s all down to the quality of the SD card. A recommendation is the SanDisk Extreme Pro, whatever the size.
> >>
> >> Roger M0ROJ
> >>
> >>
> >
>
>
>
> --
> Jeff Palmer
> Palmer IT Consulting, LLC.
> https://PalmerIT.net
>
>
>



--
Jeff Palmer
Palmer IT Consulting, LLC.
https://PalmerIT.net



locked Re: HamPi on a 128GB SD-Card

Jeff Palmer
 

Mark,

If you are using a disk image, then no.. the existing partitioning, or
filesystems don't matter. They literally get overwritten. If you've
seen cases where this doesn't seem to be the case, I assure you,
something else is going on. With a disk image, even the boot sectors
of a disk are overwritten.

I'm not trying to argue. But I am trying to clear up misinformation,
because it's become obvious in these threads that.. a little
misinformation leads to a LOT of confusion. So, I'd submit that if
you've "seen it matter" before, you investigate the root cause, as I
assure you, it's not the fault of a disk image "sometimes working,
sometimes not". a properly created disk image, which is also written
properly to a disk will *always* overwrite existing boot sectors,
partition maps, and existing filesystems. Any result *other* than
that, something else was at play. (human error, invalid disk image,
an error with the software writing the image, faulty disk, etc etc the
list goes on and on.)

On Tue, Jul 7, 2020 at 8:52 AM Mark Griffith via groups.io
<mdgriffith2003=yahoo.com@groups.io> wrote:

The existence of a partition or filesystem on an SD card *should not* make any difference when writing an image, but it sometimes does. That's why I say NOT to format the card before copying the image. In most cases, I would say it doesn't make a difference, but I have seen some where it has.

Also, I'm hoping all those that are using a giant SD card for the image know to use raspi-config to then expand the filesystem so all of the big SD card is used.

Mark
KD0QYN


On Tuesday, July 7, 2020, 7:32:23 AM CDT, Jeff Palmer via groups.io <jeff=palmerit.net@groups.io> wrote:


Interesting.

Since etcher is writing a raw disk image, the existing filesystems,
partitions, or layouts shouldn't matter (or affect writing the image)

For what it's worth, I have HamPi running on a 128gb sd card. I used
etcher, and never had an issue. I hope that helps.

On Tue, Jul 7, 2020 at 1:16 AM thegadget techie <gadgetechie@gmail.com> wrote:

I did pick up a couple of SanDisk xPros. Seemed the issue may have been the factory format - I zapped the 2nd on w/ xFat (not FAT32) and no hitch w/ Etcher. So maybe that's the issue. Also on MacPro (yeah yeah I'm 25+ yrs *nix guy). I dd'd the 1st SDCard (wiped block 0 & 100) and the PI imager did all the magic - so long story short - not really sure of the issue - but both 128Gb's running like a charm. Now onto USB boot on Pi4....

Thanks all for replies.

On Sun, Jul 5, 2020 at 5:50 AM John Nicholas <stnick@iwichita.com> wrote:

Ditto on San Disc. I found that out with discs from my Infrared Imager at work.

JN

On Jul 5, 2020, at 3:24 AM, Roger Reeves M0ROJ <m0roj@goldford.co.uk> wrote:

It’s all down to the quality of the SD card. A recommendation is the SanDisk Extreme Pro, whatever the size.

Roger M0ROJ



--
Jeff Palmer
Palmer IT Consulting, LLC.
https://PalmerIT.net




--
Jeff Palmer
Palmer IT Consulting, LLC.
https://PalmerIT.net


locked Re: HamPi on a 128GB SD-Card

Mark Griffith
 

The existence of a partition or filesystem on an SD card *should not* make any difference when writing an image, but it sometimes does.  That's why I say NOT to format the card before copying the image.  In most cases, I would say it doesn't make a difference, but I have seen some where it has.

Also, I'm hoping all those that are using a giant SD card for the image know to use raspi-config to then expand the filesystem so all of the big SD card is used.

Mark
KD0QYN


On Tuesday, July 7, 2020, 7:32:23 AM CDT, Jeff Palmer via groups.io <jeff@...> wrote:


Interesting.

Since etcher is writing a raw disk image, the existing filesystems,
partitions, or layouts shouldn't matter (or affect writing the image)

For what it's worth, I have HamPi running on a 128gb sd card.  I used
etcher, and never had an issue.  I hope that helps.

On Tue, Jul 7, 2020 at 1:16 AM thegadget techie <gadgetechie@...> wrote:
>
> I did pick up a couple of SanDisk xPros.  Seemed the issue may have been the factory format - I zapped the 2nd on w/ xFat (not FAT32) and no hitch w/ Etcher.  So maybe that's the issue. Also on MacPro (yeah yeah I'm 25+ yrs *nix guy).  I dd'd the 1st SDCard (wiped block 0 & 100) and the PI imager did all the magic - so long story short - not really sure of the issue - but both 128Gb's running like a charm.  Now onto USB boot on Pi4....
>
> Thanks all for replies.
>
> On Sun, Jul 5, 2020 at 5:50 AM John Nicholas <stnick@...> wrote:
>>
>> Ditto on San Disc.  I found that out with discs from my Infrared Imager at work.
>>
>> JN
>>
>> On Jul 5, 2020, at 3:24 AM, Roger Reeves M0ROJ <m0roj@...> wrote:
>>
>> It’s all down to the quality of the SD card. A recommendation is the SanDisk Extreme Pro, whatever the size.
>>
>> Roger M0ROJ
>>
>>
>



--
Jeff Palmer
Palmer IT Consulting, LLC.
https://PalmerIT.net



locked Re: HamPi on a 128GB SD-Card

Jeff Palmer
 

Interesting.

Since etcher is writing a raw disk image, the existing filesystems,
partitions, or layouts shouldn't matter (or affect writing the image)

For what it's worth, I have HamPi running on a 128gb sd card. I used
etcher, and never had an issue. I hope that helps.

On Tue, Jul 7, 2020 at 1:16 AM thegadget techie <gadgetechie@gmail.com> wrote:

I did pick up a couple of SanDisk xPros. Seemed the issue may have been the factory format - I zapped the 2nd on w/ xFat (not FAT32) and no hitch w/ Etcher. So maybe that's the issue. Also on MacPro (yeah yeah I'm 25+ yrs *nix guy). I dd'd the 1st SDCard (wiped block 0 & 100) and the PI imager did all the magic - so long story short - not really sure of the issue - but both 128Gb's running like a charm. Now onto USB boot on Pi4....

Thanks all for replies.

On Sun, Jul 5, 2020 at 5:50 AM John Nicholas <stnick@iwichita.com> wrote:

Ditto on San Disc. I found that out with discs from my Infrared Imager at work.

JN

On Jul 5, 2020, at 3:24 AM, Roger Reeves M0ROJ <m0roj@goldford.co.uk> wrote:

It’s all down to the quality of the SD card. A recommendation is the SanDisk Extreme Pro, whatever the size.

Roger M0ROJ

--
Jeff Palmer
Palmer IT Consulting, LLC.
https://PalmerIT.net

1961 - 1980 of 13759