InnovationQ will be updated on Sunday, Jan. 21, from 9am - 11am ET. You may experience brief service interruptions during that time.
Browse Prior Art Database

Using the 'append root=LABEL=current' for a "Dynamic FS mount" at boot time

IP.com Disclosure Number: IPCOM000033307D
Original Publication Date: 2004-Dec-06
Included in the Prior Art Database: 2004-Dec-06
Document File: 2 page(s) / 42K

Publishing Venue



A solution is proposed to the problem within the Linux environment of setting the correct FS that is to be mounted as default upon bootup. The proposed solution is to utilize the volume_label as the means to dynamically decide on the correct FS at bootup.

This text was extracted from a PDF file.
This is the abbreviated version, containing approximately 51% of the total text.

Page 1 of 2

Using the 'append root=LABEL=current' for a "Dynamic FS mount" at boot time

This advance relates to the environment in which Linux* is the (mostly embedded) operating system (OS). In today's market it is necessary to provide high availability of the disk-controller, and as such it has to support a concurrent code load (CCL) feature. Having a CCL implies that the CONTROLLER stays functional even while it is being updated/fixed. In order to provide such a functionality, two FS are set-up. One is used as "current" and is the active one, while the "other" is used as a repository of an older version, which can be used as a fall-back, and it is also the one on which the update (or rather a new install) is carried out. Once the system is updated and ready for use, the OS has to be rebooted and have the "other" FS come up as "current", while the previous "current" changes places and becomes the new "other". This "changing of the guards" process has to take place during the bootup phase.

    The common practice in the Linux world is to "burn" a new initrd (INITtial Ram Disk) and explicitly set the correct FS as the one to be mounted as default. Such a solution is not acceptable in the embedded world, however, because the burn process is quite a lengthy one and any failure (especially power-failure) during the process might result in an inoperable disk-controller. The other alternative is to modify the mkinitrd script such that it will add the required functionality to enable such a feature. The changes include adding a number of statically linked commands to the (already stressed-out) initrd space and require being dependent on a third FS in which the correct FS is listed. The latter proposition is not desirable because it involves adding code to an otherwise quite small and stable/reliable component. Debugging at the initrd stage is not an easy task. Also, the possibility that the THIRD FS might be bad/inaccessible/corrupted requires adding even more code.

    The solution proposed is to utilize the volume_label as the means to dynamically decide on the correct FS at bootup time. No additional code is required, and combining it with the THIRD FS will also enable provision of a none-Single Point of Failure (SPOF) solution.

    The idea is to set the root F...