Date   

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


Re: HamPi power drain on idle

Jim WB9QPM
 

Set nice value lower


Re: HamPi power drain on idle

Paul KC7PMU
 

Can one manage what constitutes idle time with the boinc manager. https://boinc.berkeley.edu/wiki/Preferences

Paul
kc7pmu


locked Re: HamPi on a 128GB SD-Card

the gadget techie
 

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



locked Re: HamPi on a 128GB SD-Card

the gadget techie
 

i picked up a couple SanDisk xPros - seemed to work by "unformatting" from the factor


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



Re: Decoding radiosondes to chase them and reprogramm them for Ham radio purpose

Neon22
 
Edited

This looks really interesting. Great video, very illuminating. I wonder if any of the Aussie ones land in NZ.
How about raising an issue on https://github.com/dslotter/HamPi/issues
and maybe adding the info you've discovered about how to get the packages working.
So you or someone else can add it to the distro ?
The more data you can add about what packages, startup scripts, whatever would be helpful.

Would it be:
https://github.com/oe5hpm/dxlAPRS but not sure how to use it once its installed ?? which programs go in the menu UI ?
https://github.com/projecthorus/radiosonde_auto_rx 
https://github.com/projecthorus/chasemapper   for online chasing ? 
https://github.com/projecthorus/oziplotter   for offline chasing ?
more ?


locked Re: HamPi on a 128GB SD-Card

John Nicholas
 

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



locked Re: HamPi on a 128GB SD-Card

Roger Reeves M0ROJ
 

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

Roger M0ROJ


Decoding radiosondes to chase them and reprogramm them for Ham radio purpose

Alex OE3JTB
 

Hi for a little while I have a new passion
decoding and chasing radiosondes, eg. little explaination in this video 
https://www.youtube.com/watch?v=fb9gNomWrAY
I am running a Raspberry PI 3 + with OE5DXL chain https://github.com/oe5hpm/dxlAPRS here you can see it https://radiosondy.info/maps/web_map.php?receiver=OE3JTB-11&altitude=40000&days=600&receiver_coverage=1
Also other fine decoders are available.
If you do not now which types of radiosondes are on the air, you can use VK5QI AUTO RX https://github.com/projecthorus/radiosonde_auto_rx/wiki  which has very fine decoders and a scanner.
If you are receiving serveral frequencies you can make the next step and use the image from radiosondy 
https://radiosondy.info/index.php? 
You can chase them and some types you can reprogram for Ham radio purpose https://www.rtl-sdr.com/reprogramming-vaisala-rs-41-radiosondes-to-transmit-aprs-rtty-cw-in-the-ham-or-ism-bands/ 
A very nice hobby I think
73 Alex


Re: HamPi power drain on idle

nfg
 

Personally as soon as I read the license I trashed hampi, I'm all for paying it forward but linux is about having the choice and full control of your system; not being locked down by it. I'd be fine with a link to a donation page on the desktop or something like that but forcing me to "donate" is unacceptable. I was thinking about paying it forward by helping to clean up the build scripts and bloat from the image but not anymore. What we really need is to have people working on an apt repository for ham tools for the pi. That I would gladly help with and donate too. 


locked Re: HamPi on a 128GB SD-Card

N5XMT
 

Ran it on a 128G SanDisk class 10, then went to a 500G samsung EVO860 SSD Without any issues with either.  Used Etcher for both

On Jul 4, 2020, at 13:29, gadgetechie@... wrote:
Anyone install onto a 128GB sd-card?

Tried using Etcher and seemed to not properly write boot record.
Ended up using 'Raspberry Pi Imager" and custom image. 
Seems good so far but random latency issues (same h/w).

Anyone else venture down this avenue?
Cheers
g


Re: HamPi power drain on idle

John Nicholas
 

Given the nature of the license as a paying it forward to a cause - I doubt anyone would try.

I am sure you would be able to pay it forward in another manner and everyone would be happy.

John

On Jul 4, 2020, at 3:11 PM, gadgetechie@gmail.com wrote:

I'd be curious to see how license could enforce "execution"
once deployed. IMHO.


locked Re: HamPi on a 128GB SD-Card

John Nicholas
 

I used a 64 Gig card.

ZEoZUW

On Jul 4, 2020, at 3:16 PM, gadgetechie@gmail.com wrote:

Anyone install onto a 128GB sd-card?

Tried using Etcher and seemed to not properly write boot record.
Ended up using 'Raspberry Pi Imager" and custom image.
Seems good so far but random latency issues (same h/w).

Anyone else venture down this avenue?
Cheers
g

2261 - 2280 of 14047