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 systemd-fsck@dev-mmcblk0p1.service has failed
-- Defined-By: systemd
-- Support: https://www.debian.org/support
-- 
-- A start job for unit systemd-fsck@dev-mmcblk0p1.service 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]: systemd-fsck@dev-mmcblk0p1.service: Job systemd-fsck@dev-mmcblk0p1.service/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
  • I'd try copying everything off the boot partition, reformatting it (vfat), putting everything back. – goldilocks Feb 21 at 18:05
  • @goldilocks Well, it was worth a shot. Thanks for the suggestion. – The Altruist Feb 21 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 at 22:38
  • @Ingo I did the apt full-upgrade. – The Altruist Feb 24 at 15:14
1

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.

| improve this answer | |
  • 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 at 22:35

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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