Labeling micro-SD cards ?

On a sunny day (Wed, 26 Oct 2022 09:09:53 +0200) it happened "R.Wieser" snipped-for-privacy@not.available wrote in <tjambn$sjc$ snipped-for-privacy@gioia.aioe.org>:

If you created /mnt/sdb2 or something like that, no need to remove it after unmounting (I have a whole range on this laptop for example...

ls -rtl /mnt drwxr-xr-x 2 root root 48 Jan 17 2012 sda6/ drwxr-xr-x 2 root root 48 Jan 17 2012 sda4/ drwxr-xr-x 2 root root 48 Jan 17 2012 iso/ drwxr-xr-x 2 root root 48 Jan 20 2012 sdc8/ drwxr-xr-x 2 root root 48 Jan 29 2012 sdd1/ drwxr-xr-x 5 root root 104 Feb 15 2012 sda7/ drwxr-xr-x 2 root root 48 Jun 12 2012 sdc/ drwxr-xr-x 2 root root 48 Jun 16 2012 sdc7/ drwxr-xr-x 2 root root 48 Jun 16 2012 sdc6/ drwxr-xr-x 2 root root 48 Jun 16 2012 sdc5/ drwxr-xr-x 2 root root 48 Jun 16 2012 sdc4/ drwxr-xr-x 2 root root 48 Jun 16 2012 sdc3/ drwxr-xr-x 2 root root 48 Jun 16 2012 sdc2/ drwxr-xr-x 2 root root 48 Jul 27 2012 pantel9/ drwxr-xr-x 2 root root 48 Jul 27 2012 pantel10/ drwxr-xr-x 2 root root 48 Jul 27 2012 pantel11/ drwxr-xr-x 2 root root 48 Jul 27 2012 pantel12/ drwxr-xr-x 5 root root 168 Mar 18 2013 sda8/ drwxr-xr-x 2 root root 48 Apr 12 2013 sda11/ drwxr-xr-x 2 root root 48 Feb 26 2014 loop/ drwxr-xr-x 2 root root 48 May 17 2016 sdd2/ drwxr-xr-x 26 root root 776 Jun 7 2016 sda3/ drwxr-xr-x 2 root root 48 Oct 9 2016 sdd8/ drwxr-xr-x 5 root root 1072 Dec 8 2018 sda9/ drwxr-xr-x 2 root root 48 Oct 16 2019 sdb1/ drwxr-xr-x 5 root root 216 Oct 18 2019 sda5/ drwxr-xr-x 2 root root 48 Nov 23 2019 sda10/ drwxr-xr-x 2 root root 48 Jun 19 2020 sdd4/ drwxr-xr-x 2 root root 48 Jun 19 2020 sdd5/ drwxr-xr-x 2 root root 48 Jun 19 2020 sdd6/ drwxr-xr-x 2 root root 48 Jun 19 2020 sdd7/ drwxr-xr-x 2 root root 48 Jun 19 2020 sdd3/ drwxr-xr-x 3 root root 72 Feb 7 2022 sda2/ drwxr-xr-x 2 root root 48 Mar 10 2022 sdc1/

ls -rtl shows last one used last, often saves looking through a list. I have specified that in bash and zsh (a better shell) as just 'l' in .bashrc alias l='ls -rtl' alias d='ls' alias lb='ls -rtl --color=none'

Just saves typing... Using zsh as shell even saves more typing.

The '/mnt/loop' is an other story, used to mount OS images. mount -o loop=/dev/loop0 bluray.iso /mnt/loop looks at a DVD

Or to get more into that mount -o offset=62914560 /dev/dvd /mnt/dvd ####mount -o loop,ro,offset=62914560 /dev/dvd /mnt/dvd Offset in bytes, for example 512 * sector size indicated as start for that partition in fdisk, or found with partx -a /mnt/dvd/raspberry_pi_plus_wolfram_language_plus_mathematica.img

There are so many tricks...

At least the command line speaks (sort of) English, much better than pushing around on a rat or mouse or whatever.

Using automount was dis-encouraged for security reasons last time I heard about it. People would find an USB stick in the parking lot of the company, plug it in, it auto-mounted and installed some virus that send all company data to some adversary.

I never use automount.

No ALWAYS unmount the file system. The "sync" flush is an extra step. As far as I know "umount" does what sync does before it unmounts the filesystem anyway.

Jan,

I also considered that, but would not like to have all those empty folders there.

... Though that would certainly help finding the mounted partition back (I was also thinking about that).

Have you ever tried to play an FPS game *without* pushing a dead opossum around ? :-p

(Not that I'm a gamer myself mind you).

It came as part of my RPi OS installation, and I don't mind at all.

There is a reason why my RPi is, apart from when needed for a particular experiment, allways offline. Though in my case I considered the threat to possibly come from the other direction.

Regards, Rudy Wieser

That is autorun.

Automount just makes the file system available.

As I said. to fix the root partition on an SD card you cant obviously boot from it, so you need to boot from something else, and then attach the offending card via a card reader.

Its less easy to do this in windows so its best dine on a pi if you dont have a linux desktop

All you need is a working SD card and an sd cared reader to plug into the USB port on the Pi. That will automagically register itself as probably three devices in the /dev pseudo 'filesystem' One will be the whole card itself, which is useful when formatting it, and the other two will be the partitions normally created on a Pi card. I dont know what they will be called tho.

Under a *86 linux they would be /dev/sd[a,b,c][blank, 0,1.2]

On the actual pi slot reader itself they are /dev/mmcblk01[p1,p2]

So the USB card reader might be either of those. /dev/sd* or /dev/mmcblk02* So the step is to boot from a clean card and plug te dodgy card in a reader into the PI USB port and then see what's in /dev

Dmsg might help

For [ 2.255688] mmcblk0: mmc0:aaaa SC16G 14.8 GiB [ 2.270238] mmcblk0: p1 p2 [ 2.298428] EXT4-fs (mmcblk0p2): INFO: recovery required on readonly filesystem [ 2.308659] EXT4-fs (mmcblk0p2): write access will be enabled during recovery [ 2.326898] mmc1: new high speed SDIO card at address 0001 [ 2.866154] EXT4-fs (mmcblk0p2): orphan cleanup on readonly fs [ 2.875202] EXT4-fs (mmcblk0p2): 1 orphan inode deleted [ 2.883136] EXT4-fs (mmcblk0p2): recovery complete [ 2.935135] EXT4-fs (mmcblk0p2): mounted filesystem with ordered data mode. Opts: (null) [ 2.948608] VFS: Mounted root (ext4 filesystem) readonly on device 179:2. [ 2.970171] devtmpfs: mounted

Card was slightly inconsistent, so it fixed it with e2fsck and then mounted it

No, that's part of the spec, mount will not mount a partition it considers corrupt. Most *nixes will perform an fsck during boot and before mounting to check and repair this.

Ive only ever had it render a disk completely unbootable, and that was when it was running these checks when the power went out, again....

No, it doesn't

These folders are created on the root partition itself as part of the installation. Basically the boot process from memory will run some code that it finds on a specific part of the boot device, install a kernel in memory, and that kernel will first and foremostly mount not the partition called 'root' but a compete root filesystem, on / That filesystem on a PI has the two 'folders' - root and boot. IIRC the boot sectors on the disk are then remounted on /boot. /root is I think (not sure here) merely root's 'home directory'

On my Pi its empty.

My pi reports that '/dev/root' is the name of the partition it mounts as '/' but it doesnt create that - its merely convention

This is the command file for what partitions are automatically mounted

$ more /etc/fstab proc /proc proc defaults 0 0 PARTUUID=e12508fd-01 /boot vfat defaults 0 2 PARTUUID=e12508fd-02 / ext4 defaults,noatime 0 1

The root partitions will be mapped to a *device* /dev/root but that does not actually exist.

$ df -h Filesystem Size Used Avail Use% Mounted on /dev/root 15G 2.0G 12G 14% / devtmpfs 213M 0 213M 0% /dev tmpfs 217M 0 217M 0% /dev/shm tmpfs 217M 20M 198M 9% /run tmpfs 5.0M 4.0K 5.0M 1% /run/lock tmpfs 217M 0 217M 0% /sys/fs/cgroup /dev/mmcblk0p1 44M 23M 21M 52% /boot

however the device mounted on boot DOES exists

A better way to understand what's mounted using fstab is to use the 'mount' command e,g, $ mount | grep /dev/mm /dev/mmcblk0p2 on / type ext4 (rw,noatime) /dev/mmcblk0p1 on /boot type vfat (rw,relatime,fmask=0022,dmask=0022,codepage=437,iocharset=ascii,shortname=mixed,errors=remount-ro)

Here you can see the raw partitons that are turned into block devices in /dev as mmcblk0p1 and mmcblk0p2 are mounted on / and /boot

$ ls -l /dev/mmcblk0p1 brw-rw---- 1 root disk 179, 1 Oct 5 11:17 /dev/mmcblk0p1

As do all the other partitions on the SD card.

ls -l /dev/mmcblk* brw-rw---- 1 root disk 179, 0 Oct 5 11:17 /dev/mmcblk0 brw-rw---- 1 root disk 179, 1 Oct 5 11:17 /dev/mmcblk0p1 brw-rw---- 1 root disk 179, 2 Oct 5 11:17 /dev/mmcblk0p2

So, these are the actual partitions I would need to rub e2fsck on but of course if its the root partition you need it to be able to run anything at all. Hence why you need to have an SD card reader attached to another working setup.

And that card reader will NOT appear as /dev/mmcblk0 but might appear as /dev/mmcblk1

I don't know. I've run off my sphere of competence As I say I am not sure exactly whats going on, but if yu have a corrupted card, stick it in a usb card reader in a working pi and do an ls -l /dev/mm* and see if you can spot any partitions that you can run e2fsck on

Do you have any idea how I can retrieve the

I am not 100% clear on what exactly is your situation, but at some level you need enough of a working system to run e2fsck on whatever partition you have that is wonky.

And yes, it may take hours on a Pi. On a big partition.

If you have (another?) working Pi you could equip it with a USB SDcard reader, and boot from a clean install, then run e2fsck from that on the dodgy card in the reader

I do not know what in fact that partition would be called.

Correct - and a flush does not guarantee that there will be no fresh dirty pages pile up while it's going on or between the flush and the pull while an unmount *first* makes the filesystem unavailable to the OS, then flushes the buffers and finally returns to the user.

"The Golden Shot" springs to mind - "right, right, left a bit, up a bit, FIRE!".

$ df -h

works well if you just want to see what storage devices are mounted, their sizes and free space.

On a sunny day (Wed, 26 Oct 2022 11:40:25 +0200) it happened "R.Wieser" snipped-for-privacy@not.available wrote in <tjav5n$110f$ snipped-for-privacy@gioia.aioe.org>:

Opossum :-) no I am no gamer, do not even know what FPS game is.. Writing code and designing electronics is more fun of a game for me I do have xmajong or something, and had a chess game on the laptop but after I did beat the local champion in chess last century and he got really upset I have not played chess anymore, he accused me of strange moves well what do you expect from a beginner..

One RP4 4G is offline and recording security cameras and playing background music, logging radiation and temperature and air presure from my weather station, does GPS for time and more.

The other PI4 8 GB runs Chromium and Firefox browsers and uses a Huawei 4G stick for net connection and is configured as a router. So this laptop running NewsFleX Usenet reader connects to the net via that one. Both Pi 4 have a 4 TB or there about Toshiba USB harddisks, RTL_SDR 1ppm sticks for radio spectrum analyzer, etc. IR camera Anyways,

I have some more older raspis that do all sort of things, for example

Sorry got carried away...

Absolutely it does.

I only use sync to stop a machine in a hurry with internal disks.

I.e.

#sync;sync; halt;

will generally pull a machine down hard and fast without compromising its root file system.

Its wise to try and use a more sophisticated shutdown first, but if that hangs, halt is your last resort before pushing the powers switch or worse, yanking out the power cord

Not on a pi. df -h reports "/dev/root mounted on /"

There is no /dev/root.

$mount .. ..is a far better option

TNP,

Duh. What I ment to say is that e2fsck action, suggested by dmesg and /supposedly/ fixing whatever was wrong with that partition (if anything, 'cause it worked before), rendered it untouchable (read: trashed it). I will likely have to reformat and reimage the card.

A bit of misunderstanding : I was talking about the uSD card in an USB adapter. When its inserted into the RPi it gets auto-mounted as "boot" and "root" subdirectories in the /media/pi directory. When ejecting the adapter those "boot" and "root" folders disappear again. So, where does the RPi get /those/ "boot" and "root" names from ?

All my actions where done on the uSD card in the USB adapter. And it was e2fsck which trashed that partition to begin with and than threw the towel. I don't think that running it a second time time will help.

Regards, Rudy Wieser

Jan,

FPS, short for "First Person Shooter" ? As opposed to the point-and-click "go there, do that" strategy games. Hm. Would also need a "pointer device" ...

Whut ? That sounds as if he was not a chess player at all, just someone who learned to recognise a set of moves and memorized how to respond to them.

I used Microchip, and later on some Atmel ones.

To be honest, I bought my first RPi with microcontroller stuff in mind. I was not amused to discover that the RPi runs a multi-tasking system, not allowing for precise timing on its I/O pins.

So, I kept most of my hobby on the Windows 'puter (Assembly programming), using one RPi to view YouTube stuff with while I'm eating (love it that all the ads get stripped), and the other one to do ... well, whatever run into which needs simple I/O controlling. I did buy a few I/O modules though, just to see what I could do with them.

Neither do I, nor do I appreciate that MS thinks they are allowed to access someones 'puter whenever they like it. So, I kept myself on XP. I /might/ even go use Win7, but currently I have no need to switch.

IOW, technology wise I'm quite the conservative : as long as it works, why replace it ?

Regards, Rudy Wieser

Ah, ok. That is probably part of the Pis own software doing that.

It may well do actually.

Back in the day with Linux, I sometimes ran fsck several times to gradually fix a crashed disk *enough* to get data off it.

But I am slightly concerned that it got into that state to start with. Its not 100%, but my experience of crashed disks is that if fsck and friends dont fix them, then an fdisk wont either, and you need to run a sector by sector check. And make sure that every sector is readable and writeable.

I suppose you could reinstall using the DD method and see if it works, my gut tells me it probably wont..

In the case of a reasonably cheap SD card, I might think solution by credit card is the better option and replace the card.

TNP,

"Probably" ? :-)

The question is if I can retrieve such a name myself - from an unmounted partition ofcourse.

My bad, I used "reimage" where I should have just used "reinstall". And as I'm quite lazy (I'm a (hobby) programmer) I wil probably put a NOOBS file on it and let it run its course.

But that means I have to reformat to FAT32 first, and I will than do a full format to at least /try/ to catch any bad blocks.

I really should take the time to figure out how a standard install works though. I've already got the 2020-02-13-raspbian-buster.img file downloaded, but do not have any idea what to expect after I DD that to an uSD card. And that makes me hesitant. :-\

Regards, Rudy Wieser

blkid and lsblk will give info about unmounted but connected partitions as well as mounted partitions.

On a raspberry pi (u)SD card after writing the RPi image there are 2 partitions, one FAT32 labelled 'boot' and one ext4 labelled 'root'. The boot prtition can be read on any Windows machine. Both partitons can be read on any Linux/Unix machine.

You can use balenaEtcher or Unetbootin (or similar) to write the image to an SD card. There is no need for hesitance. (However dd will (should) work too.) Get a newer image!

Sorry, ext4 partition is labelled 'rootfs'

Chris,

Thanks. lsblk seems to be the one which can, when asked nicely, output the partition label.

In my case using a NOOBS install there are four partitions (ignoring the Extended partition which can't be mounted). Two FAT (off of which Windows ofcourse only wants to show one, 'cause removable media) and two Linux partitions (which are the ones that get auto-mounted). Accessing one of the FAT partitions from within the RPi takes more work.

Hmmm... Am I missing a swap partition ?

Ackk.... Such an assurance without anything to back it up causes the opposite to happen in me. :-|

Thanks for the link. I guess I was unlucky in, last week, finding that

Some trimming of it (hacking ! :-) ) showed me a list of earlier versions. Alas, even though each of those downloads is accompnied by an "info" file there is nothing in there explaining why it exists (how its different from the previous version).

Regards, Rudy Wieser

That must be to cater for more than you need. My straight RASPIOS is only two