Arch Linux

jamtat

Member

Registered: 2008-03-13

Posts: 229

[SOLVED] Running from SD card: weird /boot partition mount behavior

This post will refer to an i686 installation of Arch that resides on an older, legacy/BIOS, netbook I've repurposed as an AP (see https://bbs.archlinux.org/viewtopic.php?id=210470 for more information on that project). I know that the i686 architecture is due to be dropped officially as of next month. I thought it still might be worthwhile posting about the issue here because the symptoms I'm seeing may be indicative of some underlying problem that could affect other architectures as well. The more likely scenario is that I have something misconfigured or am under some fundamental misconception about matters involved. But at this point I can't draw a meaningful distinction between those possibilities. Thus the current posting.

I set up this netbook some time ago and had to defer indefinitely my initial intention of installing and running Arch from the SD card reader built into this netbook: the main reason for that was because I had used the wrong partitioning scheme and file systems for the SD card (should have made 2 partitions, a small /boot partition formatted ext2 and and much larger root partition formatted f2fs). I did run the system from the SD card for a bit using a single ext4 partition but, when I started seeing some disk corruption, decided to move the installation over to the netbook's internal hard drive. Even at that point I continued booting from the SD card, which had syslinux and relevant associated files on it, but the OS was runnning from the internal HD once the boot process was complete. It ran reliably like that, though seeing only intermittent use, for well over a year.

Just recently I decided to have another go at getting the SD card installation fully working again. I recreated the partition table on the SD card so that there is a 400 MB primary partition at the beginning and a 14.5 GB primary partition following that, formatted the partitions ext2 and f2fs respectively, then reinstalled syslinux to the SD card and copied over relevant files; syslinux files and kernel/initramfs to the small partition, all other OS files to the larger partition. The newly-copied system boots and runs ok, though there is a bit of a hiccup I'd like to ask about here. The problem concerns mounting of the first partition, the one containing the boot files, at /boot during system start-up.

I crafted an appropriate /etc/fstab and have tried a few minor modifications, but the issue persists. The issue is that, during system start-up, I see the message "A start job is running for dev-by-disk . . . .device" (ellipsis marks uuid for the small ext2 partition mentioned) followed by a timer. That timer, as most of us will know, runs for 1.5 minutes. After that amount of time ticks off without the start job completing, the system drops into emergency mode.

The interesting thing here is that, if I give the root password for maintenance and do nothing except run the mount command periodically, the problem partition does wind up getting mounted after 3 minutes' time (inclusive of the 1.5 minute timeout). Likewise if I do not enter the root password to get the maintenance shell but rather just wait about 3 minutes and hit ctrl-d to continue booting, once I log into the system and run the mount command, I can also see that the partition has been mounted in the appropriate place. I could therefore almost say that the system is working fine, were it not for the fact that user input is required during start-up (entry of ctrl-d after the timeout) in order for the system to fully initialize.

My fstab file looks like the following (I don't have access to the system at the moment so the below data is based on recollection):

 UUID=alpha-numeric-string1 /boot ext2 defaults 0 2 
UUID=alpha-numeric-string2 / f2fs rw,acl,active_logs=6,background_gc=on,user_xattr

Input, anyone, on what might be going on here and how to fix things so that user input will no longer be required during start-up? Would an fstab mount option like x-systemd.device-timeout=360s be an appropriate tactic? Or maybe implementing something like what's described at https://unix.stackexchange.com/question … eout-value ? Can the systemd service that searches for this partition be backgrounded or some such? TIA

PS The installation is a few months out of date, having last been updated at the end of Feb. of the current year (kernel 4.9.11-1). I plan to bring it fully up to date once I resolve the initialization issue(s).

PPS I experienced a number of obstacles getting the f2fs root file system recognized during system start-up. Having had some experience booting drives with f2fs root partitions, I first tried adding the various crc* modules to the initramfs: but that did not resolve the problem. It was only after I'd added the f2fs module to the initramfs that the system was finally able to boot the f2fs root partition. So it seems that, at least for the i686 architecture, the wiki article's indication that only f2fs-tools need to be added to the system, subsequent to which regenerating the initramfs is the only further step required (https://wiki.archlinux.org/index.php/F2 … _partition), is in error.

Last edited by jamtat (2017-10-27 19:57:26)

circleface

Member

Registered: 2012-05-26

Posts: 639

Re: [SOLVED] Running from SD card: weird /boot partition mount behavior

I don't know if it is required or not, but I always put the / filesystem first in fstab, then the /boot after it.

jamtat

Member

Registered: 2008-03-13

Posts: 229

Re: [SOLVED] Running from SD card: weird /boot partition mount behavior

I don't know if it is required or not, but I always put the / filesystem first in fstab, then the /boot after it.

Thanks for the input, circleface. I'd tried switching around those fstab entries previously without success, but I decided to give it another try just in case, among the various permutations I was testing, I might've been mis-remembering. Switching the order of the fstab entries definitely had no effect on the issue when I tried it this time: I still get the timer that issues in a timeout followed by entry into emergency mode.

jamtat

Member

Registered: 2008-03-13

Posts: 229

Re: [SOLVED] Running from SD card: weird /boot partition mount behavior

I've discovered a workaround which I hesitate to call a solution. So I'll explain it here and see whether any further input will be offered. Maybe later I'll mark the thread solved, once I'm convinced that this represents the only and most appropriate and/or effective resolution.

The workaround was to introduce the nofail option into my fstab file. So, instead of the entry

UUID=alpha-numeric-string1 /boot ext2 defaults 0 2

I now have

UUID=alpha-numeric-string1 /boot ext2 nofail,defaults 0 2

The effect is that the boot process does not get disrupted by the timeout, but continues in spite of it. Though the problem partition does not show up at its mount point once the boot process completes, roughly 3 minutes later it does show up there. So the mount process does succeed, albeit with an unusually lengthy delay.

I doubt this delay will present much of a problem since I can't envision a scenario under which I will need access to the /boot partition within 3 minutes of system start-up. Still, it's strange behavior and I am considering for now the solution I've implemented to be a kludge.

Anyone have other suggestions for resolving the weird mount delay I'm seeing? If so, I'm all ears (eyes?)

Last edited by jamtat (2017-10-26 21:44:35)

jamtat

Member

Registered: 2008-03-13

Posts: 229

Re: [SOLVED] Running from SD card: weird /boot partition mount behavior

This problem appears to have been kernel related. I was experiencing the issue when trying to use the 4.9.11-1 kernel and, if memory serves, it was occurring under some earlier kernels (can't recall for certain since I was doing a series of overdue upgrades and only later in the process did I start trying to mount the problem partition at /boot by using an entry in /etc/fstab). Once I got past the problem and continued upgrading, I noted that the mount delay/disruption stopped occurring when the 4.12 kernel was running. Now, under the 4.13 kernel the delay/disruption in mount the partition at /boot is also not happening. So I've removed the nofail option from fstab and the system is now booting fine. I'll presume the problem was fully resolved by a kernel upgrade and will makr this thread accordingly.