Checking a new boot microSD card

Do you have a question? Post it now! No Registration Necessary

Translate This Thread From English to

Threaded View
I tried to write a Buster image to a new microSD card (Samsung Evo Plus)
using a usb-microSD adapter supplied with the card. It seemed to work,
but slowly, following the directions at
https://www.raspberrypi.org/documentation/installation/installing-images/linux.md

using my existing Pi3B+ running Stretch.  

However, the resulting image seems a bit out of whack.
bob@raspberrypi:~/Downloads $ sudo fsck /dev/sdb2
[sudo] password for bob:  
fsck from util-linux 2.29.2
e2fsck 1.43.4 (31-Jan-2017)
ext2fs_open2: Bad magic number in super-block
fsck.ext2: Superblock invalid, trying backup blocks...
fsck.ext2: Bad magic number in super-block while trying to open /dev/sdb2

The superblock could not be read or does not describe a valid ext2/ext3/ext4
filesystem.  If the device is valid and it really contains an ext2/ext3/ext4
filesystem (and not swap or ufs or something else), then the superblock
is corrupt, and you might try running e2fsck with an alternate superblock:
    e2fsck -b 8193 <device>
 or
    e2fsck -b 32768 <device>
I tried the second suggestion and my Pi replied:
bob@raspberrypi:~/Downloads $ sudo e2fsck -b 32768 /dev/sdb2
e2fsck 1.43.4 (31-Jan-2017)
e2fsck: Bad magic number in super-block while trying to open /dev/sdb2

The superblock could not be read or does not describe a valid ext2/ext3/ext4
filesystem.  If the device is valid and it really contains an ext2/ext3/ext4
filesystem (and not swap or ufs or something else), then the superblock
is corrupt, and you might try running e2fsck with an alternate superblock:
    e2fsck -b 8193 <device>
 or
    e2fsck -b 32768 <device>

Before simply starting over, might there be some way to salvage the
insttallation? Or, at least figure out what I did wrong?

Thanks for reading,

bob prohaska
  


Re: Checking a new boot microSD card
bob prohaska wrote:
Quoted text here. Click to load it

Those directions seem to favor dl/ing and installing the graphical  
Etcher, alternatively using dd.

--  
Mike Easter

Re: Checking a new boot microSD card
Quoted text here. Click to load it

Apologies for the unclarity; I used the section titled
"Copying a zipped image to the SD card"

using the command line

unzip -p 2020-02-13-raspbian-buster.zip | sudo dd of=/dev/sdX bs=4M conv=fsync

(adjusted for local condtions, of course).  

The command worked, but took a surprisingly long time, I think it was
over an hour. It finished with no errors, though it did report a one
block discrepancy between in and out.  

There's an sd card  copier in the Accessories menu, is that Etcher?

Thanks for reading,

bob prohaska
  

Re: Checking a new boot microSD card
declaimed the following:


Quoted text here. Click to load it
    <blink><blink> They released another version recently? Might explain
why my last "apt update" said something about a repository change.

Quoted text here. Click to load it

    Might work faster if one first unpacks the archive, then block copy it
to the card. Otherwise it may be so I/O bound that you are getting one
chunk from the archive into the pipe (can the pipe hold enough for 4MB?),
/then/ the pipe gets emptied, and the delay for the next chunk has the
card/OS flushing I/O channels (and maybe triggering card wear leveling and
allocation unit swapping).

Quoted text here. Click to load it
    Most likely NOT!

https://www.balena.io/etcher/
https://github.com/balena-io/etcher#debian-and-ubuntu-based-package-repository-gnulinux-x86x64
(doesn't appear to be built for ARM boards)


--  
    Wulfraed                 Dennis Lee Bieber         AF6VN
     snipped-for-privacy@ix.netcom.com    http://wlfraed.microdiversity.freeddns.org/

Re: Checking a new boot microSD card
Quoted text here. Click to load it

Looks like it was either the 4M block size or the "free" usb-microSD
adapter. Tried it a second time after unzipping the image using
dd and a 1M block size. The write finished in minutes and fsck finds
error-free filesystems.

Thanks for reading, and apologies for the noises!

bob prohaska


Re: Checking a new boot microSD card
bob prohaska wrote:
Quoted text here. Click to load it

I wrote it/ the .img/ w/ the Win Etcher via a USB2 adapter.  It spent 15  
min doing the write and verification process for the 7G .img.

That is, I dl/ed the torrent which fetched the .zip which sha256 hashed  
ok which I unzipped to the 7G img which I wrote w/  Win etcher.  I  
considered using Win Rufus in dd mode, but I wanted to see some more  
etcher operation.  I've used Rufus quite a lot and I would consider it  
my 'favorite' usb .iso writer except that it can't do persistence or  
multiboot writing, so it is just for non-persistent one-off/s.

For persistence using Ub (and some Deb) distros, I like mkusb from its  
.ppa repo best.  For multiboot I usually use the Win Yumi, which can  
also do persistence, but it sometimes doesn't work w/ distro/s which  
aren't in its stable/line-up.

--  
Mike Easter

Re: Checking a new boot microSD card
Dennis Lee Bieber wrote:
Quoted text here. Click to load it

It looks like there is an etcher for ARM in development

https://packagecloud.io/swift-arm/etcher

.deb pkg for raspbian buster

I think I like this install page for the .img better than the earlier  
cited

https://elinux.org/RPi_Easy_SD_Card_Setup RPi Easy SD Card Setup

It is 'less ambiguous' about -1- the arch for etcher -2- unzipping first  
-3- the 2 linux graphicals mentioned aren't for RPi; use dd

There are several threads including in rpi forum seeking a graphical for  
rpi with a lot of wrong/misleading answers.

--  
Mike Easter

Site Timeline