LinuxQuestions.org
Register a domain and help support LQ
Go Back   LinuxQuestions.org > Forums > Linux Forums > Linux - Distributions > Slackware
User Name
Password
Slackware This Forum is for the discussion of Slackware Linux.

Notices



Reply
 
Search this Thread
Old 10-11-2013, 02:48 AM   #1
stf92
Senior Member
 
Registered: Apr 2007
Location: Buenos Aires.
Distribution: Slackware
Posts: 3,271

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


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?
 
Old 10-11-2013, 02:52 AM   #2
Didier Spaier
Senior Member
 
Registered: Nov 2008
Location: Paris, France
Distribution: Slackware{,64}-{14.1,current} on a Lenovo Thinkpad T61 6457-4XG
Posts: 4,657

Rep: Reputation: 1235Reputation: 1235Reputation: 1235Reputation: 1235Reputation: 1235Reputation: 1235Reputation: 1235Reputation: 1235Reputation: 1235
I don't think so, but what do you want to achieve with this modification?
 
Old 10-11-2013, 02:58 AM   #3
ponce
Senior Member
 
Registered: Aug 2004
Location: Pisa, Italy
Distribution: Slackware
Posts: 2,498

Rep: Reputation: 912Reputation: 912Reputation: 912Reputation: 912Reputation: 912Reputation: 912Reputation: 912Reputation: 912
Quote:
Originally Posted by stf92 View Post
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...
 
Old 10-11-2013, 02:59 AM   #4
stf92
Senior Member
 
Registered: Apr 2007
Location: Buenos Aires.
Distribution: Slackware
Posts: 3,271

Original Poster
Rep: Reputation: 49
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.
 
Old 10-11-2013, 04:10 AM   #5
stf92
Senior Member
 
Registered: Apr 2007
Location: Buenos Aires.
Distribution: Slackware
Posts: 3,271

Original Poster
Rep: Reputation: 49
Quote:
Originally Posted by ponce View Post
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.
 
Old 10-11-2013, 04:14 AM   #6
ponce
Senior Member
 
Registered: Aug 2004
Location: Pisa, Italy
Distribution: Slackware
Posts: 2,498

Rep: Reputation: 912Reputation: 912Reputation: 912Reputation: 912Reputation: 912Reputation: 912Reputation: 912Reputation: 912
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
 
1 members found this post helpful.
Old 10-11-2013, 04:26 AM   #7
stf92
Senior Member
 
Registered: Apr 2007
Location: Buenos Aires.
Distribution: Slackware
Posts: 3,271

Original Poster
Rep: Reputation: 49
Quote:
Originally Posted by ponce View Post
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.
 
Old 10-11-2013, 04:37 AM   #8
Didier Spaier
Senior Member
 
Registered: Nov 2008
Location: Paris, France
Distribution: Slackware{,64}-{14.1,current} on a Lenovo Thinkpad T61 6457-4XG
Posts: 4,657

Rep: Reputation: 1235Reputation: 1235Reputation: 1235Reputation: 1235Reputation: 1235Reputation: 1235Reputation: 1235Reputation: 1235Reputation: 1235
Quote:
Originally Posted by stf92 View Post
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

Last edited by Didier Spaier; 10-11-2013 at 04:39 AM.
 
Old 10-11-2013, 04:39 AM   #9
ponce
Senior Member
 
Registered: Aug 2004
Location: Pisa, Italy
Distribution: Slackware
Posts: 2,498

Rep: Reputation: 912Reputation: 912Reputation: 912Reputation: 912Reputation: 912Reputation: 912Reputation: 912Reputation: 912
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.
 
Old 10-11-2013, 05:54 AM   #10
stf92
Senior Member
 
Registered: Apr 2007
Location: Buenos Aires.
Distribution: Slackware
Posts: 3,271

Original Poster
Rep: Reputation: 49
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.
 
Old 10-11-2013, 06:05 AM   #11
Didier Spaier
Senior Member
 
Registered: Nov 2008
Location: Paris, France
Distribution: Slackware{,64}-{14.1,current} on a Lenovo Thinkpad T61 6457-4XG
Posts: 4,657

Rep: Reputation: 1235Reputation: 1235Reputation: 1235Reputation: 1235Reputation: 1235Reputation: 1235Reputation: 1235Reputation: 1235Reputation: 1235
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
 
1 members found this post helpful.
Old 10-11-2013, 06:21 AM   #12
stf92
Senior Member
 
Registered: Apr 2007
Location: Buenos Aires.
Distribution: Slackware
Posts: 3,271

Original Poster
Rep: Reputation: 49
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.
 
Old 10-13-2013, 07:38 AM   #13
kikinovak
Senior Member
 
Registered: Jun 2011
Location: Montpezat (South France)
Distribution: Slackware, Slackware64
Posts: 1,948

Rep: Reputation: 971Reputation: 971Reputation: 971Reputation: 971Reputation: 971Reputation: 971Reputation: 971Reputation: 971
Quote:
Originally Posted by stf92 View Post
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.
 
Old 10-13-2013, 08:50 AM   #14
stf92
Senior Member
 
Registered: Apr 2007
Location: Buenos Aires.
Distribution: Slackware
Posts: 3,271

Original Poster
Rep: Reputation: 49
Quote:
Originally Posted by kikinovak View Post
I notice you do like to shoot yourself in the foot. Repeatedly.
That seems to be a favorite expression of yours! Why the "repeatedly"?

Last edited by stf92; 10-13-2013 at 08:51 AM.
 
Old 10-13-2013, 12:42 PM   #15
Richard Cranium
Senior Member
 
Registered: Apr 2009
Location: Carrollton, Texas
Distribution: Slackware64 14.1
Posts: 1,575

Rep: Reputation: 466Reputation: 466Reputation: 466Reputation: 466Reputation: 466
Quote:
Originally Posted by stf92 View Post
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.
 
  


Reply


Thread Tools Search this Thread
Search this Thread:

Advanced Search

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Can't boot properly. Filesystem damaged. moonshadow Linux - Laptop and Netbook 2 04-23-2009 12:07 PM
Strategies for recovering JPEG files from a damaged filesystem yello Linux - General 2 12-17-2007 04:22 PM
Cannot mount ext3 filesystem on damaged hard drive Mathieu_G Linux - Hardware 3 04-01-2005 11:51 PM
Repair damaged /var filesystem davep911 Linux - Newbie 1 06-04-2004 09:09 AM
Slackware 9.1: ext3 Filesystem Damaged Chu Linux - General 2 03-02-2004 12:22 AM


All times are GMT -5. The time now is 08:22 PM.

Main Menu
Advertisement
My LQ
Write for LQ
LinuxQuestions.org is looking for people interested in writing Editorials, Articles, Reviews, and more. If you'd like to contribute content, let us know.
Main Menu
Syndicate
RSS1  Latest Threads
RSS1  LQ News
Twitter: @linuxquestions
identi.ca: @linuxquestions
Facebook: linuxquestions Google+: linuxquestions
Open Source Consulting | Domain Registration