initramfs mountpoint space Insufficient - linux

I try to boot from ethernet my own Linux FS :
create an initramfs with a simple and very minimal fedora structure : ok
boot with DHCP with a 2.6 kernel : ok
kernel load the initramfs : ok
a custom init.sh script is call : ok
So after the boot I have a Linux OS with an initramfs as filesystem.
With the initramfs, I have compiled some minimal applications.
The aim of this minimal boot is to make things without to have to mount
a hard disk or another filesystem.
My problem is that some applications, like mail, complain that disk
space is insuficient, and of course, df / result :
df /
Filesystem 1K-blocks Used Available Use% Mounted on
- 0 0 0 - /
So, how to make the initramfs have a mountpoint with a real capacity
(capacity = RAM capacity ?)
Thanks for any help
Yves

Related

why my hash functions doesnt work or freez in the /sys/kernel/tracing/per_cpu/cpu45 folder?

Im having issue with my script that calulates intergity on this version of ubunutu :
cyber#ubuntu:/$ hostnamectl
Static hostname: ubuntu
Icon name: computer-vm
Chassis: vm
Machine ID: 48d13c046d74421781e6c6f771f6ac31
Boot ID: 847b838897ac47eb932f6427361232d1
Virtualization: vmware
Operating System: Ubuntu 20.04.4 LTS
Kernel: Linux 5.13.0-51-generic
Architecture: x86-64
Im wondering if /sys/kernel/tracing/per_cpu/cpu45 is not by any chance an alive file ?
because calculating the hash of the files inside takes ifinite time.
If you want to check filesystem integrity, skip the whole /sys folder - it is an interface to the kernel.
Also it would be better if you also skip /proc (also kernel interface) and /dev (special or device files) folders. F.e - you can read from /dev/zero or /dev/urandom forever. Network mounts can give you a lot of bright moments too.
Also your script can freeze on reading pipes - it there is enough permissions it can read from a pipe forever.
If I was building such a script, I'll start from the mounts, checked their filesystems and scanned only needed ones. For example if a mount is tmpfs - it's contents is located in RAM and will be wiped after reboot.
And you totally should check it out -
https://en.wikipedia.org/wiki/Filesystem_Hierarchy_Standard

Command to know what was mounted in a folder

I have a folder on my server that mounts volumes of a FreeNAS via the iSCSI protocol. I need to mount these same folders on another server but I can't figure out how they were mounted because the naming in FreeNAS and the folders are different.
 
Are there any commands I can use to see how they were assembled? Using the df command I have the following return:
/dev/sde 1008G 605G 352G 64% /mnt/folder1
/dev/sda 1008G 150G 808G 16% /mnt/folder2
/dev/sdf 4,0T 4,0T 0 100% /mnt/folder3
But this is not useful since I can't figure out which volumes these mounts are referencing.
I'm Using Debian GNU/Linux 8.9 (jessie) and FreeNAS 9.10.2.
As we discussed in the comments to the original question, /dev/sdX is simulated devices with iSCSI protocol. To manage those you would normally use iscsiadm command.

Linux kernel can't mount /dev file system

I'm building a custom linux image, using a non-manipulated Linux kernel 2.6.32.65.
the kernel boots just fine until it reaches this:
EXT2-fs warning: mounting unchecked fs, running e2fsck is recommended
VFS: Mounted root (ext2 filesystem) on device 3:1.
Freeing unused kernel memory: 304k freed
init: Unable to mount /dev filesystem: No such device
init: ureadahead main process (983) terminated with status 5
init: console-setup main process (1052) terminated with status 1
I tried the solutions mentioned here although the error is not exactly the same, but no luck. I tried multiple "reference" .config files. I have been googling for a bit but I can't find anything with the same problem.
I'm running this custom image on gem5 simulator, with file system from ubuntu-core and a clean kernel. earlier in the output the kernel shows this:
hda: max request size: 128KiB
hda: 16514064 sectors (8455 MB), CHS=16383/16/63
hda: hda1
So the kernel is able to see partitions just fine. I don't think this is caused by something in the file system. maybe initrd? or the kernel itself? how can I fix it?
1.) The problem is not in devfs, it seems issue is console setup. 2.) This is init issue not a linux kernel issue. 3.) Try to pass /bin/sh instead of init to kernel cmd line
I have the same problem with custom built embedded Linux.
Check you have enabled devfs in kernel .config
# core filesystems
CONFIG_PROC_FS=y
CONFIG_SYSFS=y
## devfs
CONFIG_DEVTMPFS=y
CONFIG_DEVTMPFS_MOUNT=y

Solutions to resize root partition on live mounted system

I'm writing a Chef recipe to automate setting up software RAID 1 on an existing system with. The basic procedure is:
Clear partition table on new disk (/dev/sdb)
Add new partitions, and set then to raid using parted (sdb1 for /boot and sdb2 with LVM for /)
Create a degraded RAID with /dev/sdb using mdadm --create ... missing
pvcreate /dev/md1 && vgextend VolGroup /dev/md1
pvmove /dev/sda2 /dev/md1
vgreduce VolGroup /dev/sda2 && pvremove /dev/sda2
...
...
I'm stuck on no. 5. With 2 disks of the same size I always get an error:
Insufficient free space: 10114 extents needed, but only 10106 available
Unable to allocate mirror extents for pvmove0.
Failed to convert pvmove LV to mirrored
I think it's because when I do the mdadm --create, it adds extra information to the disk so it has slightly less physical extents.
To remedy the issue, one would normally reboot the system off a live distro and:
e2fsck -f /dev/VolGroup/lv_root
lvreduce -L -0.5G --resizefs ...
pvresize --setphysicalvolumesize ...G /dev/sda2
etc etc
reboot
and continue with step no. 5 above.
I can't do that with Chef as it can't handle the rebooting onto a live distro and continuing where it left off. I understand that this obviously wouldn't be idempotent.
So my requirements are to be able to lvreduce (somehow) on the live system without using a live distro cd.
Anyone out there have any ideas on how this can be accomplished?
Maybe?:
Mount a remote filesystem as root and remount current root elsewhere
Remount the root filesystem as read-only (but I don't know how that's possible as you can't unmount the live system in the first place).
Or another solution to somehow reboot into a live distro, script the resize and reboot back and continue the Chef run (Not sure if this is even popssible
Ideas?
I'm quite unsure chef is the right tool.
Not a definitive solution but what I would do for this case:
Create a live system with a chef and a cookbook
Boot on this
run chef as chef-solo with the recipe doing the work (which should work as the physical disk are unmounted at first)
The best way would be to write cookbooks to be able to redo the target boxes from scratch, once it's done you can reinstall entirely the target with the correct partitionning at system install time and let chef rebuild your application stack after that.

Linux boot process -- iniramfs & root (\)

I have some question related to linux boot process. Initramfs is the first stage rootfile system loaded.
Init process inside iniramfs is responsible to mount actual rootfile system from harddisk to / directory.
Now my question is where is / directory created by init (init process of initramfs) to mount actual root partition. Is it in ram or hardisk ?
Also once actual root partiton is mounted then what happens to initramfs ?
If initramfs is deleted from ram then what happens to / folder created by initramfs ?
Please suggest , can some explain how does this magic works.
//Allan
What /sbin/init (of initramfs) does is, loads the filesystems and necessary modules. Then it tries to load the targeted real "rootfs". Then it switches from initramfs to real rootfs and "/" is on the harddisk. "/" is created when you installed the systems, done harddrive formating. Note, it's about reading the filesystem's content thus it's a prerequisite to load the required module first. If you've a ext3 partition of "/", then ext3.ko will be loaded and so.
Answer to second question - after doing the required fs module loading, it switches from initramfs's init to real rootfs's init and the usual booting process starts of and initramfs is removed from memory. This switching is done through pivot_root().
Answer to third - initramfs doesn't create any directory, it just load existing initramfs.img image into ram.
So, in short, loading iniramfs or rootfs isn't about creating any directory, it's about loading existing filesystem images. Just after boot - it uses initramfs to load must needed filesystems module, as if it can read the real filesystem. Hope it'll help!
With initrd there are two options:
Using pivot_root to rotate the final filesystem into position, or
Emptying the root and mounting the final filesystem over it.
More info can be found here.

Resources