I have an embedded system that boots off compact flash and runs with the initrd.img ramdisk mounted as root. When booting, it mounts the initrd image ok in read only mode but then when inittab runs, it seems to skip over the first mount command which is

null::sysinit:/bin/mount -o remount,rw /

I have /etc/fstab setup with the correct options as far as I know:

/dev/root    /    ext2    rw,noauto,noatime    1    1

The system then manages to get me a command prompt and I can then login as root and type the mount command which works without a problem.

Furthermore, this same setup has worked on a seemingly identical piece of target hardware. The difference is that I am creating the boot image from my laptop instead of the usual server that we use. My laptop is running a newer version of grub which I use to make a bootloader for the image. Perhaps I also have a newer version of genext2fs which is used to make the image used as the ramdisk. The server is running FC10 but my laptop is using ubuntu so there must be some differences that I'm overlooking which is affecting mount or inittab. Could it be something to do with /dev/null?

Why isn't the system remounting the ramdisk image and how can I fix it?


I managed to solve my problem using two steps:

The first was to get rid of the null at the start of the line in inittab which just allows errors to be seen on the console. This revealed that the error was to do with /proc/mounts. I changed inittab so that the ::sysinit:/bin/mount -t proc /proc came above the remount,rw / stuff and it's now ok.

The mystery remains why the other system boots anyway with supposedly identical binaries of the kernel and busybox - I'm still thinking that genext2fs must set something up differently in my version such that the mount -o remount,rw command is happy to go ahead without /proc/mounts

  • Classically the mount command will read & write /etc/mtab, but on Linux, the classic /etc/mtab is often replaced with a symbolic link: originally to /proc/mounts, but on modern systems with namespace support, now /proc/self/mounts. If the remount command includes the option -n, it tells mount to ignore the /etc/mtab file, and if your distribution uses a symlink to /proc/[self/]mounts in its place, to make it insensitive to the presence/absence of the /proc filesystem.
    – telcoM
    Jul 7 at 22:24

Are you sure your distribution reads /etc/inittab?

For example, Ubuntu now uses upstart, which uses a different set of configuration files.

Another thought: put another entry in there that runs mount and redirects the output to a file. That will prove if inittab is being read, and if the filesystems are in the expected state at the time you're trying to run the remount.

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.