How to check if /init starts /etc/inittab - linux

I have an embedded ARM system with processor AT91SAM9G45.
System consists of two components:
Linux kernel (4.14.79)
Busybox 1.29.3 as initramfs image.
I connect to the device using putty and connecting to serial port.
When kernel starts, everything goes fine. Kernel unpacks initramfs image, all files are found and listed (I see it by debug messages). But when it starts /init, log messages are:
Freeing unused kernel memory: 384K
This architecture does not have kernel memory protection.
run_init_process BEFORE /init
run_init_process AFTER /init, result = 0
Kernel panic - not syncing: Attempted to kill init! exitcode=0x00000004
/init is symlink to /bin/busybox. I tried to replace /init with /sbin/init, /bin/busybox, /linuxrc, but results are the same.
/etc/inittab file:
# Begin /etc/inittab
id::initdefault:
si::sysinit:/etc/init.d/rc S
#l0::wait:/etc/rc.d/init.d/rc 0
#l1::wait:/etc/rc.d/init.d/rc 1
#l2::wait:/etc/rc.d/init.d/rc 2
#l3::wait:/etc/rc.d/init.d/rc 3
#l4::wait:/etc/rc.d/init.d/rc 4
#l5::wait:/etc/rc.d/init.d/rc 5
#l6::wait:/etc/rc.d/init.d/rc 6
ca::ctrlaltdel:/sbin/shutdown -t1 -a -r now
su::once:/sbin/sulogin
1::respawn:/sbin/getty ttyS1 115200
2::respawn:/sbin/getty ttyS2 115200
3::respawn:/sbin/getty ttyS3 115200
4::respawn:/sbin/getty ttyS4 115200
5::respawn:/sbin/getty ttyS5 115200
6::respawn:/sbin/getty ttyS6 115200
# End /etc/inittab
/etc/init.d/rcS file (this file is allowed to execute):
#!/bin/busybox sh
echo "Hello world!"
I don't know if even /init process starts parsing /etc/inittab or it falls before getting /etc/inittab by some reasons I cannot find out. Maybe there are
some mistakes in my /etc/inittab and /etc/init.d/rcS files. Maybe there are some errors with terminal (/etc/init.d/rcS cannot write to stdout cause it's blocked, suspended, being used by another process and so on).
How to definitely get sured, that /etc/inittab is started?

Welcome to StackOverflow.
I see there is space between rc and S
si::sysinit:/etc/init.d/rc S
change it to
si::sysinit:/etc/init.d/rcS
let me know if it works.

/init is symlink to /bin/busybox.
The typical /init file in an initramfs built by Buildroot that incorporates Busybox is a script of seven lines:
#!/bin/sh
# devtmpfs does not get automounted for initramfs
/bin/mount -t devtmpfs devtmpfs /dev
exec 0</dev/console
exec 1>/dev/console
exec 2>/dev/console
exec /sbin/init $*
Note the comment ("devtmpfs does not get automounted for initramfs") and the mount command for /dev.
It's /sbin/init (rather than /init) that is linked to /bin/busybox.
IOW without the proper setup of the /dev directory, userland has no I/O capabilty.
Only after devtmpfs has been mounted should the init program in Busybox be executed, which will then access /etc/inittab.
See Is there a way to get Linux to treat an initramfs as the final root filesystem?
and
Make CONFIG_DEVTMPFS_MOUNT apply to initramfs/initmpfs

Related

Why do I get console output from ACPID when devtmpfs is mounted and logged when not?

I have a weird issue which I diagnosed all the way back to simply being that if I mount devtmpfs then launch ACPID daemon, i get console output, if I don't mount devtmpfs, the ACPI daemon output goes to the log. I also get some rpcbind messages when reboot is issued, but I think it's the same thing (normally logs instead of output to screen).
apcid: starting up with netlink and the input layer
apcid: 1 rule loaded
apcid: waiting for events: event logging is off
Does anyone have any ideas why? I can still use udev to create and load all my devices either way (mounting devtmpfs or not). I tried setting up /etc/sysctl.conf to use kernel.printk = 3 4 1 3 (the default without it was 3 4 1 7), but that made no difference.
TIA
The answer is that I had to restart syslogd and klogd after mounting devtmpfs. Output to syslog that failed when to console due to apcid using LOG_CONS option. This was busybox, kill and trying to start again didn't work, start-stop-daemon worked.

How do I change the filesystem of my 64GB USB, from FAT32 to anything which allows me to put a 35GB file from my x86_64 Linux machine onto the USB?

'uname -a' on my machine gives:
Linux ct-lt-966 4.9.0-8-amd64 #1 SMP Debian 4.9.144-3.1 (2019-02-19) x86_64 GNU/Linux
Currently the filesystem of my USB is MS-DOS 'FAT32' which has a ~4.5 GB maximum size for individual files. I want to change this filesystem to something else, which does not have a limit. (I am trying to put a 35GB file onto a 64GB USB but I believe most USB filesystems do not limit the size of individual files).
I have not found it clear what choices of USB filesystem that I have. I tried to change the filesystem to 'NTFS', but I could not install or locate 'mkfs.ntfs' or even 'ntfsprogs'. (I also tried installing with 'pacman' and 'yum' but apparently 'pacman' requires an aarch architecture and I could not get access to 'yum-config-manager' in order to enable any repos).
So to conclude, with my minimal prowess I am just looking for any way to change the filesystem of my 64GB USB to anything which will accept a 35GB file from my machine.
Thanks
Edit 1: Just planning to use the USB on this Linux machine, not Windows.
If there's nothing on the stick you want, or it's safe to delete it then basically:
delete the current FAT32 partition from the stick
add a new partition, utilising the full size of the device
create an ext4 filesystem on the new partition
PLEASE BE CAREFUL WITH THIS PROCESS: selecting the wrong device can obliterate a disk you needed such as a $HOME or your root OS
All the following is from memory and untested: I don't have a USB stick available right now to test fully.
Start by plugging in the stick while tailing the syslog in a console and see where it gets mounted (hopefully it automounts which it should if it's a desktop based Linux you're running. Possibly not if it's a server)..
sudo tail -f /var/log/syslog
(it might be /var/log/messages depending on distro)
then plug the stick. syslog should show it being allocated a device and a mount point. A file manager window may open depending on your config if you are in a GUI. For example, you might see it being loaded on /dev/sdc1 and mounted at /media/<yourusername>/USBKEY or something.
Confirm by running lsblk and note the device for the key, i.e.
$ lsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
sda 8:0 0 167.7G 0 disk
├─sda1 8:1 0 69.9G 0 part /
└─sda2 8:2 0 97.9G 0 part /home
sdb 8:16 0 149.1G 0 disk
└─sdb1 8:17 0 149.1G 0 part /mnt/snapshots
sdc 8:32 0 931.5G 0 disk
└─sdc1 8:33 0 931.5G 0 part /storage
sdd 8:48 0 465.8G 0 disk
└─sdd1 8:49 0 465.8G 0 part /mnt/backup
sr0 11:0 1 1024M 0 rom
Unmount the stick (if it mounted) but leave it plugged in. Assuming again your device is at /dev/sdc1...
umount /dev/sdc1
Now run cfdisk in a terminal if you have it (friendlier) or fdisk if not, passing it the device related to your USB stick, without the partition number.
man cfdisk
sudo cfdisk /dev/sdc
This should show the current FAT32 partition. Delete it, then create a new partition of type 'Linux', following the defaults for start and end blocks which will be suggested in such a way as to fill the available space.
When done, select the option to Write the changes. Again, DOUBLE AND TRIPLE CHECK you have the right device or you will blow away your main disk probably.
Once the changes are written, you can create the ext4 file system;
sudo mkfs.ext4 /dev/sdc1
And after it completes, you should be able to re-plug your stick and find that it remounts, this time with a file system that can take your large files.
This isn't the only way to achieve this, but it's probably the least fiddly. For the sake of repetition, don't make a mistake with the device identifiers. If you're unsure, ask.

Kernel Panic - Not Syncing. Segfault at Init

I recently tried to install php5-gd package on my debian vmware server and it failed at libc6 - i386.
Afterwards every command other than CD caused a Segmentation fault and the server would no long boot, showing the following error
[ 4.808086] init[1]: segfault at 0 ip (null) sp bff4645c error 14 in init[8048000+8000]
[ 4.808372] Kernel panic - not syncing: Attempted to kill init!
[ 4.808442] Pid: 1, comm: init Not tainted 3.2.0-4-686-pae #1 Debian 3.2.65-1
[ 4.808512] Call Trace:
(Trace continued in this image
)
I am at a complete loss on what to do at this moment. Any help or direction would be appreciated
Edit: I've since uploaded debian-live-8.3.0-i386-standard to the vmware store and booted the broken vm with the live cd.
Now I am in the live cd terminal but not sure what to do next. I did a lsblk and noted that the broken vm's boot partition is sda > sda2 and that's all I have done so far. Do I need to mount this somewhere now?
Edit2: I've now mounted the broken partition into the live cd, however when I tried to chroot, I get Segmentation Fault:
# mkdir -p /mnt/tcs1/boot
# mount /dev/tcs1/root /mnt/tcs1
# mount /dev/sda1 /mnt/tcs1/boot
# mount -t proc none /mnt/tcs1/proc
# mount -o bind /dev /mnt/tcs1/dev
# mount -o bind /run /mnt/tcs1/run
# mount -o bind /sys /mnt/tcs1/sys
# chroot /mnt/tcs1 /bin/bash
# Segmentation fault
Solved:
I relinked ld-linux.so.2 to /lib/i386-linux-gnu/ld-2.19.so from a rescue CD and managed to chroot in

Busybox SUID on NFS rootfs

I am building a Linux system from the bottom for a Beagle Bone board. I have compiled the vanilla kernel and built a basic root file system with busybox. The system is booted with U-boot, while the rootfs is located on a Linux PC and exported through NFS:
/path/to/rootfs 10.42.0.17(rw,wdelay,no_root_squash,no_subtree_check,sec=sys,rw,secure,no_root_squash,no_all_squash)
The U-boot bootargs are:
bootargs console=ttyO0,115200n8 root=/dev/nfs rw nfsroot=${serverip}:/path/to/rootfs,v3,tcp ip=dhcp
I've encountered a problem when trying to get su working for non-root users. In order to work around the problem people over internet are suggesting to set the suid bit for the busybox binary.
After doing so:
$ sudo chmod u+s busybox
and verifying:
$ ls -la
...
-rwsr-xr-x 1 myuser myuser 1882976 Jan 13 21:47 busybox
...
$ stat -c "%a %n" busybox
4755 busybox
Something went wrong. The kernel is booting and all of the usual messages are displayed, but it is getting stuck at the end, and no login line is displayed. Here are last few lines of the booting sequence:
[ 3.776185] IP-Config: Complete:
[ 3.779656] device=eth0, hwaddr=c8:a0:30:c5:80:e9, ipaddr=10.42.0.17, mask=255.255.255.0, gw=10.42.0.1
[ 3.789877] host=10.42.0.17, domain=, nis-domain=(none)
[ 3.795822] bootserver=10.42.0.1, rootserver=10.42.0.1, rootpath=
[ 3.802492] nameserver0=10.42.0.1
[ 3.871575] VFS: Mounted root (nfs filesystem) on device 0:15.
[ 3.879903] devtmpfs: mounted
[ 3.883713] Freeing unused kernel memory: 380K (c07ef000 - c084e000)
If removing the flag, the things are returning to normal:
....
[ 3.862291] Freeing unused kernel memory: 380K (c07ef000 - c084e000)
10.42.0.17 login:
If setting the flag from within the running shell on the Beagle Bone board itself, the shell is stopping responding right after the chmod is performed.
I suspect it is something to do with the way the NFS is exporting the rootfs, but it's only a guess, so qualified explanation and possible solution would be helpful.
After some research I will answer my question myself. The answer is very simple. In order the above to work, the busybox binary should be owned by root:root. The simplest solution is just to change the ownership.

Detecting a chroot jail from within

How can one detect being in a chroot jail without root privileges? Assume a standard BSD or Linux system. The best I came up with was to look at the inode value for "/" and to consider whether it is reasonably low, but I would like a more accurate method for detection.
[edit 20080916 142430 EST] Simply looking around the filesystem isn't sufficient, as it's not difficult to duplicate things like /boot and /dev to fool the jailed user.
[edit 20080916 142950 EST] For Linux systems, checking for unexpected values within /proc is reasonable, but what about systems that don't support /proc in the first place?
The inode for / will always be 2 if it's the root directory of an ext2/ext3/ext4 filesystem, but you may be chrooted inside a complete filesystem. If it's just chroot (and not some other virtualization), you could run mount and compare the mounted filesystems against what you see. Verify that every mount point has inode 2.
On Linux with root permissions, test if the root directory of the init process is your root directory. Although /proc/1/root is always a symbolic link to /, following it leads to the “master” root directory (assuming the init process is not chrooted, but that's hardly ever done). If /proc isn't mounted, you can bet you're in a chroot.
[ "$(stat -c %d:%i /)" != "$(stat -c %d:%i /proc/1/root/.)" ]
# With ash/bash/ksh/zsh
! [ -x /proc/1/root/. ] || [ /proc/1/root/. -ef / ]
This is more precise than looking at /proc/1/exe because that could be different outside a chroot if init has been upgraded since the last boot or if the chroot is on the main root filesystem and init is hard linked in it.
If you do not have root permissions, you can look at /proc/1/mountinfo and /proc/$$/mountinfo (briefly documented in filesystems/proc.txt in the Linux kernel documentation). This file is world-readable and contains a lot of information about each mount point in the process's view of the filesystem. The paths in that file are restricted by the chroot affecting the reader process, if any. If the process reading /proc/1/mountinfo is chrooted into a filesystem that's different from the global root (assuming pid 1's root is the global root), then no entry for / appears in /proc/1/mountinfo. If the process reading /proc/1/mountinfo is chrooted to a directory on the global root filesystem, then an entry for / appears in /proc/1/mountinfo, but with a different mount id. Incidentally, the root field ($4) indicates where the chroot is in its master filesystem. Again, this is specific to Linux.
[ "$(awk '$5=="/" {print $1}' </proc/1/mountinfo)" != "$(awk '$5=="/" {print $1}' </proc/$$/mountinfo)" ]
If you are not in a chroot and the root filesystem is ext2/ext3/ext4, the inode for / will always be 2. You may check that using
stat -c %i /
or
ls -id /
Interresting, but let's try to find path of chroot directory. Ask to stat on which device / is located:
stat -c %04D /
First byte is major of device and lest byte is minor. For example, 0802, means major 8, minor 1. If you check in /dev, you will see this device is /dev/sda2. If you are root you can directly create correspondong device in your chroot:
mknode /tmp/root_dev b 8 1
Now, let's find inode associated to our chroot. debugfs allows list contents of files using inode numbers. For exemple, ls -id / returned 923960:
sudo debugfs /tmp/root_dev -R 'ls <923960>'
923960 (12) . 915821 (32) .. 5636100 (12) var
5636319 (12) lib 5636322 (12) usr 5636345 (12) tmp
5636346 (12) sys 5636347 (12) sbin 5636348 (12) run
5636349 (12) root 5636350 (12) proc 5636351 (12) mnt
5636352 (12) home 5636353 (12) dev 5636354 (12) boot
5636355 (12) bin 5636356 (12) etc 5638152 (16) selinux
5769366 (12) srv 5769367 (12) opt 5769375 (3832) media
Interesting information is inode of .. entry: 915821. I can ask its content:
sudo debugfs /tmp/root_dev -R 'ls <915821>'
915821 (12) . 2 (12) .. 923960 (20) debian-jail
923961 (4052) other-jail
Directory called debian-jail has inode 923960. So last component of my chroot dir is debian-jail. Let's see parent directory (inode 2) now:
sudo debugfs /tmp/root_dev -R 'ls <2>'
2 (12) . 2 (12) .. 11 (20) lost+found 1046529 (12) home
130817 (12) etc 784897 (16) media 3603 (20) initrd.img
261633 (12) var 654081 (12) usr 392449 (12) sys 392450 (12) lib
784898 (12) root 915715 (12) sbin 1046530 (12) tmp
1046531 (12) bin 784899 (12) dev 392451 (12) mnt
915716 (12) run 12 (12) proc 1046532 (12) boot 13 (16) lib64
784945 (12) srv 915821 (12) opt 3604 (3796) vmlinuz
Directory called opt has inode 915821 and inode 2 is root of filesystem. So my chroot directory is /opt/debian-jail. Sure, /dev/sda1 may be mounted on another filesystem. You need to check that (use lsof or directly picking information /proc).
Preventing stuff like that is the whole point. If it's your code that's supposed to run in the chroot, have it set a flag on startup. If you're hacking, hack: check for several common things in known locations, count the files in /etc, something in /dev.
On BSD systems (check with uname -a), proc should always be present. Check if the dev/inode pair of /proc/1/exe (use stat on that path, it won't follow the symlink by text but by the underlying hook) matches /sbin/init.
Checking the root for inode #2 is also a good one.
On most other systems, a root user can find out much faster by attempting the fchdir root-breaking trick. If it goes anywhere you are in a chroot jail.
I guess it depends why you might be in a chroot, and whether any effort has gone into disguising it.
I'd check /proc, these files are automatically generated system information files. The kernel will populate these in the root filesystem, but it's possible that they don't exist in the chroot filesystem.
If the root filesystem's /proc has been bound to /proc in the chroot, then it is likely that there are some discrepancies between that information and the chroot environment. Check /proc/mounts for example.
Similrarly, check /sys.
I wanted the same information for a jail running on FreeBSD (as Ansible doesn't seem to detect this scenario).
On the FreeNAS distribution of FreeBSD 11, /proc is not mounted on the host, but it is within the jail. Whether this is also true on regular FreeBSD I don't know for sure, but procfs: Gone But Not Forgotten seems to suggest it is. Either way, you probably wouldn't want to try mounting it just to detect jail status and therefore I'm not certain it can be used as a reliable predictor of being within a jail.
I also ruled out using stat on / as certainly on FreeNAS all jails are given their own file system (i.e. a ZFS dataset) and therefore the / node on the host and in the jail both have inode 4. I expect this is common on FreeBSD 11 in general.
So the approach I settled on was using procstat on pid 0.
[root#host ~]# procstat 0
PID PPID PGID SID TSID THR LOGIN WCHAN EMUL COMM
0 0 0 0 0 1234 - swapin - kernel
[root#host ~]# echo $?
0
[root#host ~]# jexec guest tcsh
root#guest:/ # procstat 0
procstat: sysctl(kern.proc): No such process
procstat: procstat_getprocs()
root#guest:/ # echo $?
1
I am making an assumption here that pid 0 will always be the kernel on the host, and there won't be a pid 0 inside the jail.
If you entered the chroot with schroot, then you can check the value of $debian_chroot.

Resources