Installing with and without apt-get

[quarkjuggler]

I got a working RPi, but I'm trying to put together a second one for a friend for Christmas. It's going on about 3 weeks now. I finally got the .img file (although it doesn't include recommended software. --Looks like Firefox doesn't download anything over 2.0 GB.) Now I'm trying to get it onto the SD. As recommended by stackexchange, I tried

Code: Select all

sudo dd  bs=1M if=2019-09-26-raspbian-buster.img of=/dev/sdc1

but the new RPI zeroW wouldn't boot. Having something on the drive now, probably wrong, I decided to go with balena etcher. With several tries, I was able to download it into a zip file, which I unzipped to give "balenaEtcher-1.5.70-ia32.AppImage". There I'm stuck.

Should I have chosen X64 instead of X86? I think my RPi is only 32 bits wide, which I don't know for certain either. Any suggestions???

I also couldn't find instructions for installing bitTorrent. I did manage to "sudo apt-get install bittorrent", but now what do I do?? It didn't ask any questions, so how can I configure it?

[drgeoff]

]
I decided to go with balena etcher. With several tries, I was able to download it into a zip file, which I unzipped to give "balenaEtcher-1.5.70-ia32.AppImage". There I'm stuck.

Should I have chosen X64 instead of X86? I think my RPi is only 32 bits wide, which I don't know for certain either.

I don't understand what you are asking. x64 and x86 software does not run on a RPi. So whether a RPi is 32 bits or not is irrelevant. If your PC is running a 64 bit version of Windows then either the 32 or 64 bit version of Etcher is OK. If the PC is running a 32 bit Windows then only the 32 bit Etcher will work.

If you want to use a RPi running Raspbian to make another card, you don't need Etcher. Either use the dd command to write an image (https://www.raspberrypi.org/documentati ... s/linux.md) or use the card copier utility in Raspbian.

[quarkjuggler]

Thank you for your answer. The page that you pointed me to seems to have all the answers I need. I was working with the unzip command, piping directly to the device without using the dd command, which didn't make sense to me.

I am still confused about the fact that there were two new devices rather than one. There was /dev/sdc and /dev/sdc1. I think I did the dd command to sdc1, which I now suspect is one partition within the device, so did this break it? (I don't know why it skipped over the name "sdb", but it did.)

I rather suspected that "X86" referred to the 80386, but didn't know for sure, and X64 was probably for the 80486??

I realize that my post was out of focus, but as I think about it, it is perfectly focused: I just want to get the operating system onto an SD. But Chromium would fail and then not give an option to retry. Firefox also failed, but allowed retry, but after six hours, I discovered that it wouldn't go above 2.0 GB. I had to babysit, and manually retry about every two minutes. Then firefox couldn't even display the home screen for balena Etcher, so I went back to Chromium.

Maybe I'll give up on the pi and give my friend a nice necktie....

[wildfire]

I rather suspected that "X86" referred to the 80386, but didn't know for sure, and X64 was probably for the 80486??

Close but no cigar X86 generally refers to 32 bit Intel* compatible processors with a 32 bit OS, X64 refers to 64bit Intel* compatible processors with a 64bit OS.

The 486 (whether SX or DX) was not a 64 bit processor, 64bit Intel* compatible CPU's can run X86 software on a 32/64 bit OS (think of the switch between win 3.x (16 bit) to win 95 (32 bit)).

In any case ARM (the CPU in your Pi) is not Intel* compatible.

*Other brands are available

[rpdom]

I am still confused about the fact that there were two new devices rather than one. There was /dev/sdc and /dev/sdc1. I think I did the dd command to sdc1, which I now suspect is one partition within the device, so did this break it?

The /dev/sdX device nodes are the whole "disk" including all partitions and the partition table. /dev/sdXn nodes are the partitions on that "disk".

As the image file contains two partitions and the partition table you would write it to the /dev/sdX device and the /dev/sdX1 and /dev/sdX2 devices will appear once the new partition table is read (remove and reinsert after writing has completed the card for this to happen).

[quarkjuggler]

It's a real joy to be among people who know so much! I hope I can come to deserve it in time. Meanwhile, EUREKA! I wrote the image to sdc instead of sdc1 and everything worked!

I don't know why I had so much trouble downloading the buster onto my pi 3. but if I decide to download big files again, I think I shall use curl. If I keep the transfer speed down and cut down the block size, maybe it'll make the wait time on the transmission more accessible. I think with my raspbian jessie was taking too long for de-encrypting, and the transmitter was regularly timing out.

I was elated but disappointed when I got my friend's pi zero W running with raspbian buster. It seems to run much more slowly than my pi 3 with jessie. Both should have clock speed of 400MHz, so why the difference? (My test was with www.solitr.com, which runs without communication with web.)

Thanks, folks, for the info.

[HawaiianPi]

I was elated but disappointed when I got my friend's pi zero W running with raspbian buster. It seems to run much more slowly than my pi 3 with jessie. Both should have clock speed of 400MHz, so why the difference?

Neither has a clock speed of 400MHz. The Pi Zero SoC is clocked at 1GHz, while the Pi 3B SoC is 1.2GHz, and there's a bit more to it.

The Pi Zero has a single core, 32-bit ARM11 CPU, while the Pi 3B has a quad-core, 64-bit ARM Cortex A53, which is a much newer and faster design. Even if you down-clocked a Pi3 to 1GHz and ran only one core, it would still clobber the Pi Zero.

The Pi 3B is around 8X faster than a Pi Zero in CPU heavy tasks. Of course it's also much more expensive.