Inadvertent modification of /etc/rc.d/rc.S could have damaged the filesystem on disk.

stf92 · 10-11-2013, 01:48 AM

Hi: I inadvertently modified /etc/rc.d/rc.S leaving it in this state (I only show the affected part of the file):

Code:

# If /run exists, mount a tmpfs on it (unless the
# initrd has already done so):
###########if [ -d /run ]; then
###########  if ! grep -wq "tmpfs /run tmpfs" /proc/mounts ; then
###########    /sbin/mount -v -n -t tmpfs tmpfs /run -o mode=0755
###########  fi
###########fi

In the original file those lines were not commented. Still with the system under this state (that state reached after booting with rc.S modified as shown) I get

Code:

root@server:/etc/rc.d# cat /proc/mounts
rootfs / rootfs rw 0 0
proc /proc proc rw,relatime 0 0
sysfs /sys sysfs rw,relatime 0 0
tmpfs /run tmpfs rw,relatime,mode=755 0 0 [THE BOLD TYPE IS MINE]
devtmpfs /dev devtmpfs rw,relatime,size=1870088k,nr_inodes=467522,mode=755 0 0
/dev/sda2 / ext2 rw,relatime,errors=continue,user_xattr,acl 0 0
devpts /dev/pts devpts rw,relatime,gid=5,mode=620,ptmxmode=000 0 0
[MORE LINES HERE]

So, the tmpfs was mounted anyways. However, could the filesystem on the hard disk have been damaged, or some other system misbehavior could be happening, as a result of mentioned modification?

Didier Spaier · 10-11-2013, 01:52 AM

I don't think so, but what do you want to achieve with this modification?

ponce · 10-11-2013, 01:58 AM

Quote:

Originally Posted by stf92

Hi: I inadvertently modified /etc/rc.d/rc.S leaving it in this state (I only show the affected part of the file):

Code:

# If /run exists, mount a tmpfs on it (unless the
# initrd has already done so):

maybe (as hinted above) you're using an initrd.

Quote:

So, the tmpfs was mounted anyways. However, could the filesystem on the hard disk have been damaged, or some other system misbehavior could be happening, as a result of mentioned modification?

I think there won't be any damage involved but maybe stuff using the /run filesystem hierarchy, like udisk for example, may not work correctly...

stf92 · 10-11-2013, 01:59 AM

That was only part of a much larger modification I did in order to get rid of udev and hotplugging in a 14.0 install, and the rc.S part quoted was inadvertently left standing when I reverted to normal. But, please, about turning udev off I am presently writing a very detailed post. I would not like to have the matter scattered among two different threads.

stf92 · 10-11-2013, 03:10 AM

Quote:

Originally Posted by ponce

maybe (as hinted above) you're using an initrd.

I think there won't be any damage involved but maybe stuff using the /run filesystem hierarchy, like udisk for example, may not work correctly...

OK. As there have been two power blackouts here and I disregarded looking into the changes made by e2fsck (mine is an ext2 filesystem), for me any damage suffered by the hard disk filesystem is a thing of the past now. Perhaps some years from now I'll be perceiving some calamities made in it and wondering what could have happened. Never mind.

What I now want to know is a different thing: am I using a RAM disk (initrd) at boot time? How do I know? I was once forced to think about initrd, but I have now quite forgotten. I have a README.initrd file and the initrd manual page, but still can't figure out whether I use it or not. This question presupposes initrd is used only at boot time and later discarded.

ponce · 10-11-2013, 03:14 AM

Quote:

What I now want to know is a different thing: am I using a RAM disk (initrd) at boot time? How do I know?

look in the configuration of your bootloader: if you're using lilo, for example, and you're using an intird, you should have an entry like this near the end of /etc/lilo.conf

Code:

image = /boot/vmlinuz
  initrd = /boot/initrd.gz
  root = /dev/vda1
  label = Linux
  read-only

stf92 · 10-11-2013, 03:26 AM

Quote:

Originally Posted by ponce

look in the configuration of your bootloader: if you're using lilo, for example, and you're using an intird, you should have an entry like this near the end of /etc/lilo.conf

Code:

image = /boot/vmlinuz
  initrd = /boot/initrd.gz
  root = /dev/vda1
  label = Linux
  read-only

From /etc/lilo.conf:

Code:

image=/boot/vmlinuz # Linked to the generic kernel. So initrd necesary.
initrd=/boot/initrd.gz # See /boot/README.initrd
root=/dev/sda2
label=lin14
read-only

I put those lines there myself. And I had quite forgotten! This is slackware 14.0 x86_64 (64 bits). I wonder now if the presence of the generic kernel really demands the use of an init ram disk.

Didier Spaier · 10-11-2013, 03:37 AM

Quote:

Originally Posted by stf92

I wonder now if the presence of the generic kernel really demands the use of an init ram disk.

Short answer: yes.
Long answer: check in the config file for the generic kernel if the file system you use for / is built in. If not, you need an initrd including the relevant module or a custom kernel including the driver built in

ponce · 10-11-2013, 03:39 AM

you can run mkinitrd_command_generator.sh and check its output: on my kvm virtual machine

Code:

# /usr/share/mkinitrd/mkinitrd_command_generator.sh
#
# mkinitrd_command_generator.sh revision 1.45
#
# This script will now make a recommendation about the command to use
# in case you require an initrd image to boot a kernel that does not
# have support for your storage or root filesystem built in
# (such as the Slackware 'generic' kernels').
# A suitable 'mkinitrd' command will be:

mkinitrd -c -k 3.10.14 -f ext4 -r /dev/vda1 -m virtio:virtio_ring:virtio_blk:virtio_pci:virtio_balloon:virtio_net:mbcache:jbd2:ext4 -u -o /boot/initrd.gz

so the virtio_* modules and the ext4 one in my case are needed to have a successful boot.

stf92 · 10-11-2013, 04:54 AM

Regarding mkinitrd_command_generator.sh, I got:

Code:

root@server:/boot# /usr/share/mkinitrd/mkinitrd_command_generator.sh
#
# mkinitrd_command_generator.sh revision 1.45
#
# This script will now make a recommendation about the command to use
# in case you require an initrd image to boot a kernel that does not
# have support for your storage or root filesystem built in
# (such as the Slackware 'generic' kernels').
# A suitable 'mkinitrd' command will be:

mkinitrd -c -k 3.2.29 -f ext2 -r /dev/sda2 -m usbhid:ehci-hcd:mbcache:ext2 -u -o /boot/initrd.gz
root@server:/boot#

But does this output answer the question "Does 3.2.29, the kernel I'm using, have support for ext2"?

Regarding /boot/config-generic-3.2.29, I am reading the following part of it:

Code:

#
# File systems
#
CONFIG_EXT2_FS=m
CONFIG_EXT2_FS_XATTR=y
CONFIG_EXT2_FS_POSIX_ACL=y
CONFIG_EXT2_FS_SECURITY=y
# CONFIG_EXT2_FS_XIP is not set
CONFIG_EXT3_FS=m
CONFIG_EXT3_DEFAULTS_TO_ORDERED=y
CONFIG_EXT3_FS_XATTR=y
CONFIG_EXT3_FS_POSIX_ACL=y
CONFIG_EXT3_FS_SECURITY=y
CONFIG_EXT4_FS=m
CONFIG_EXT4_FS_XATTR=y
CONFIG_EXT4_FS_POSIX_ACL=y
CONFIG_EXT4_FS_SECURITY=y
# CONFIG_EXT4_DEBUG is not set

from which I confess I'm unable to figure out if ext2, the filesystem I'm using for /, is built in or not. Perhaps I not looking at the right place in the file. Perhaps I should know first what is the thing into which ext2 can be built into or not. IMO the correct question is: does kernel 3.2.29 support ext2? That is, it would be a matter of the SUPPORT being built into the kernel.

Anyways, if using an init RAM disk can simplify or speed up the boot process, I would leave it asis, and postpone any investigation until I have a more clear understanding of the booting process than I have at present.

Didier Spaier · 10-11-2013, 05:05 AM

this line:
CONFIG_EXT2_FS=m
means that the kernel is configured with the support of ext2 as a module.

If it were configured to have it built in it would show:
CONFIG_EXT2_FS=y

so you need the initrd.

To know more type:
man mkinitrd

stf92 · 10-11-2013, 05:21 AM

I consider this thread to be a very instructive and helpful one for myself. In some way I managed myself to do the right questions and got the right answers back. I'm remain very much obliged to both of you, Didier and ponce. Au revoir.

kikinovak · 10-13-2013, 06:38 AM

Quote:

Originally Posted by stf92

That was only part of a much larger modification I did in order to get rid of udev and hotplugging in a 14.0 install

I notice you do like to shoot yourself in the foot. Repeatedly.

stf92 · 10-13-2013, 07:50 AM

Quote:

Originally Posted by kikinovak

I notice you do like to shoot yourself in the foot. Repeatedly.

That seems to be a favorite expression of yours! Why the "repeatedly"?

Richard Cranium · 10-13-2013, 11:42 AM

Quote:

Originally Posted by stf92

That was only part of a much larger modification I did in order to get rid of udev and hotplugging in a 14.0 install [...]

I don't know how pure you want to be about removing udev from the initialization process, but there is code in the initrd that uses udev:

Code:

# If udevd is available, use it to generate block devices
# else use mdev to read sysfs and generate the needed devices 
if [ -x /sbin/udevd -a -x /sbin/udevadm ]; then
  /sbin/udevd --daemon --resolve-names=never
  /sbin/udevadm trigger --subsystem-match=block --action=add
  /sbin/udevadm settle --timeout=10
else
  [ "$DEVTMPFS" != "1" ] && mdev -s
fi

Assuming that you haven't purged your /boot directory, you can find that in the file /boot/initrd-tree/init

I noticed that /sbin/udevadm is called in several other places in the init script, so I am not certain how well booting without udev has been tested. You will probably be able to suggest some patches to Pat when you are done.

You should simply run

Code:

chmod a-x /boot/initrd-tree/sbin/udevd

then run

Code:

/usr/share/mkinitrd/mkinitrd_command_generator.sh

to get the command line that you'll modify to create your new initrd.

On the machine where I am typing this, running /usr/share/mkinitrd/mkinitrd_command_generator.sh gives me

Code:

root@hp635:~# /usr/share/mkinitrd/mkinitrd_command_generator.sh
#
# mkinitrd_command_generator.sh revision 1.45
#
# This script will now make a recommendation about the command to use
# in case you require an initrd image to boot a kernel that does not
# have support for your storage or root filesystem built in
# (such as the Slackware 'generic' kernels').
# A suitable 'mkinitrd' command will be:

mkinitrd -c -k 3.2.45 -f xfs -r /dev/internal_vg/rootlv -m rts_pstor:usbhid:ehci-hcd:ohci-hcd:exportfs:xfs -L -u -o /boot/initrd.gz
root@hp635:~#

and so I would run that mkinitrd command with the "-c" removed as well as a different output file to create a new initrd with udevd not executable. I'd then edit lilo,conf to add a new stanza to use the new initrd file. I would leave the old one so I could re-boot into my system in case my modifications don't work.