1

Switched to F2FS for the root partition. Upgraded from stretch to buster by doing an apt full-upgrade. Now the system goes to the emergency console because the filesystem check dependency fails. It still boots after I hit ENTER. But, for the use case, that's not an acceptable solution. I'm mounting the boot partition from /dev/mmcblk0p1, so it's not a PARTUUID issue.

Here's the journal:

Feb 14 05:13:29 RaspPi systemd[1]: dev-mmcblk0p1.device: Job dev-mmcblk0p1.device/start timed out.
Feb 14 05:13:29 RaspPi systemd[1]: Timed out waiting for device /dev/mmcblk0p1.
-- Subject: A start job for unit dev-mmcblk0p1.device has failed
-- Defined-By: systemd
-- Support: https://www.debian.org/support
-- 
-- A start job for unit dev-mmcblk0p1.device has finished with a failure.
-- 
-- The job identifier is 22 and the job result is timeout.
Feb 14 05:13:29 RaspPi systemd[1]: Dependency failed for File System Check on /dev/mmcblk0p1.
-- Subject: A start job for unit [email protected] has failed
-- Defined-By: systemd
-- Support: https://www.debian.org/support
-- 
-- A start job for unit [email protected] has finished with a failure.
-- 
-- The job identifier is 20 and the job result is dependency.
Feb 14 05:13:29 RaspPi systemd[1]: Dependency failed for /boot.
-- Subject: A start job for unit boot.mount has failed
-- Defined-By: systemd
-- Support: https://www.debian.org/support
-- 
-- A start job for unit boot.mount has finished with a failure.
-- 
-- The job identifier is 19 and the job result is dependency.
Feb 14 05:13:29 RaspPi systemd[1]: Dependency failed for Local File Systems.
-- Subject: A start job for unit local-fs.target has failed
-- Defined-By: systemd
-- Support: https://www.debian.org/support
-- 
-- A start job for unit local-fs.target has finished with a failure.
-- 
-- The job identifier is 16 and the job result is dependency.
Feb 14 05:13:29 RaspPi systemd[1]: local-fs.target: Job local-fs.target/start failed with result 'dependency'.
Feb 14 05:13:29 RaspPi systemd[1]: local-fs.target: Triggering OnFailure= dependencies.
Feb 14 05:13:29 RaspPi systemd[1]: boot.mount: Job boot.mount/start failed with result 'dependency'.
Feb 14 05:13:29 RaspPi systemd[1]: [email protected]: Job [email protected]/start failed with result 'dependency'.
Feb 14 05:13:29 RaspPi systemd[1]: dev-mmcblk0p1.device: Job dev-mmcblk0p1.device/start failed with result 'timeout'.

sudo sfdisk -l /dev/mmcblk0

Disk /dev/mmcblk0: 7.5 GiB, 8090812416 bytes, 15802368 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0xcd18c759

Device         Boot Start      End  Sectors  Size Id Type
/dev/mmcblk0p1       8192    96042    87851 42.9M  c W95 FAT32 (LBA)
/dev/mmcblk0p2      98304 15802367 15704064  7.5G 83 Linux

sudo fsck.vfat -av /dev/mmcblk0p1

fsck.fat 4.1 (2017-01-24)
Checking we can access the last sector of the filesystem
0x41: Dirty bit is set. Fs was not properly unmounted and some data may be corrupt.
 Automatically removing dirty bit.
Boot sector contents:
System ID "mkfs.fat"
Media byte 0xf8 (hard disk)
       512 bytes per logical sector
       512 bytes per cluster
        32 reserved sectors
First FAT starts at byte 16384 (sector 32)
         2 FATs, 32 bit entries
    346112 bytes per FAT (= 676 sectors)
Root directory start at cluster 2 (arbitrary size)
Data area starts at byte 708608 (sector 1384)
     86467 data clusters (44271104 bytes)
32 sectors/track, 64 heads
         0 hidden sectors
     87851 sectors total
Reclaiming unconnected clusters.
Checking free cluster summary.
Performing changes.
/dev/mmcblk0p1: 220 files, 46381/86467 clusters

What I've tried so far:

  • sudo fsck.vfat -av /dev/mmcblk0p1 (but the dirty bit keeps coming back after every reboot)
  • Mounting by PARTUUID in /etc/fstab (no change)
  • Deleting and recreating the partition and copying back the files (Thanks, @goldilocks)
  • Reinstalled raspberrypi-kernel and raspberrypi-bootloader
4
  • I'd try copying everything off the boot partition, reformatting it (vfat), putting everything back.
    – goldilocks
    Feb 21, 2020 at 18:05
  • @goldilocks Well, it was worth a shot. Thanks for the suggestion. Feb 21, 2020 at 18:55
  • "Upgraded from stretch to buster" - did you install Raspbian Buster from the image or did you do an sudo apt full-upgrade on Stretch using the buster repository?
    – Ingo
    Feb 21, 2020 at 22:38
  • @Ingo I did the apt full-upgrade. Feb 24, 2020 at 15:14

1 Answer 1

2

You have done an apt full-upgrade from Raspbian Stretch to Raspbian Buster. This can be done with Debian but for Raspbian it isn't official supported by the Raspberry Pi Foundation. It may be possible with some knowledge but they recommend to always start a new version from a fresh flashed image. If you encounter to problems after an apt full-upgrade they are based on undefined conditions which are not reproducible. I'm afraid you will not find much help about this situation and you are alone. Better start with a fresh flashed image.

1
  • That's good advice I think. I upgraded from jessie to stretch "the hard way" some time ago, but it seemed that little issues remained for some time afterwards.
    – Seamus
    Feb 24, 2020 at 22:35

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.