I'm looking for a way to have a tmpfs-like file system that can be unlimited in size, but will use a specified amount of RAM after which the "oversize" data will be stored on another disk-backed filesystem I'm running on a SSD-only system, with low available space (usually < 3 GB), so I don't want to reserve any space for SWAP or similar (that's my main requirement) Do you know of any solution that would fit my use-case ?

I switched from rtx 2080ti to rtx5080, I have dual boot system, windows works fine, ubuntu black screen, in recovery mode I see that it's stuck in "loading ramdisk". I couldn't even boot liveusb ubuntu, when I select try ubuntu, fans start spinning very loud and there's black screen. So I switched back to rtx2080ti, ubuntu works on that card and I tried few fixes that I found: - installing new 575-open nvidia drivers, I purged previous drivers - /etc/default/grub: I changed line 'GRUB_CMDLINE_LINUX_DEFAULT="quiet splash"' to 'GRUB_CMDLINE_LINUX_DEFAULT="dis_ucode_ldr"' - I upgraded ubuntu 22 to 24.04.2 LTS version - Bios update I switched back to rtx 5080 and it still doesn't work, same issue, any ideas?

I'm aware of tmpfs and what I really need is a disk partition resides on RAM where I could format it with BTRFS. How can I create a raw device on RAM and format it with any regular filesystem? Or is only chance creating a raw file on tmpfs, formatting it with a filesystem and mounting through a loop device ([source](https://unix.stackexchange.com/a/433720/65781)) .

mkdir /ramdisks
mount -t tmpfs tmpfs /ramdisks
dd if=/dev/zero of=/ramdisks/disk0 bs=1M count=100
losetup /dev/loop0 /ramdisks/disk0
mke2fs /dev/loop0
...
losetup -d /dev/loop0
rm /ramdisks/disk0

# Use Case I'm using BTRFS for a number of reasons. My current attempt is to use Overlayfs as rootfs (just like [Slax does with Aufs](https://www.slax.org/internals.php)) and I want the underlying directory structure be BTRFS. Slax uses the following trick: While the system is booting, 1. instead of actual switch_root operation that the normal installations usually do, Slax creates a transient folder and 2. mounts it as tmpfs (puts it on the RAM), 3. switch_root to it as if it were the actual filesystem. 4. Then it does some Kung-Fu: Mounts its "modules" (the squashfs files) to somewhere (say /modules) 5. Mounts all folders under /modules/ to /union along with a writable changes folder 6. pivot_root to the /union folder. What I want is mimicking that, which doesn't require what I asked so far, except: I want to place the changes folder on the RAM with the support of BTRFS goods: 1. Support snapshotting, 2. Support btrfs send | btrfs receive 3. Possibly BTRFS RAID-1

I wrote a script that generates a PDF and an HTML file on RAM-disk: - The PDF file can be opened as expected. - The HTML file can be opened with an editor, but not with a browser. This is the error message I get from the browser (Chrome, Firefox) on Ubuntu Linux 24.04: Access to the file was denied The file at file:///dev/shm/test.html is not readable. It may have been removed, moved or file permissions may be preventing access. ERR_ACCESS_DENIED These are the file details: /dev/shm> ll -rw-rw-r-- 1 11K 2024-08-30 11:06 test.html If I copy the file to the hard disk, it can be opened as expected: /dev/shm> cp ./test.html ~ ------- If I build Chromium from source as explained here , will I be able to open files stored on RAM-disk like /dev/shm?

I am trying to create a custom ramdisk, but it keeps failing right before launching init. Here is the script: https://gist.github.com/amanuel2/f3e8bb9399f3b3bd36a90cd925ecf63d Logs: Edit 2: Logs: https://pastebin.com/FUxUtiSE Script: https://gist.github.com/amanuel2/f3e8bb9399f3b3bd36a90cd925ecf63d

For *How to go about moving my webserver data onto a (tmpfs) RAM disk? (experiment)*, I formulated some ideas, notes, and stuff around. Need to hear if my whole idea is sound and solid, and **that such experiment is doable**. 1. Automate the creation of a sufficiently large (tmpfs) RAM disk at boot time. 2. With the same script, copy the www data , adjust ownership, just about everything. 3. Logs would stay on my NVMe SSD of type PCIe 3.0 x4:

# nvme list
    Node                  SN                   Model                                    Namespace Usage                      Format           FW Rev  
    --------------------- -------------------- ---------------------------------------- --------- -------------------------- ---------------- --------
    /dev/nvme0n1                Samsung SSD 970 EVO Plus 2TB             1         360.10  GB /   2.00  TB    512   B +  0 B   2B2QEXM7

4. The laptop has 32 GB RAM (DDR4 2400 MHz, dual-channel), and I feel it gets unused. 5. The laptop has a functional battery for a few minutes, but still. 6. The laptop is plugged into an older UPS, I might need to change the battery (note for me). 7. My uplink is (almost) 100 Mbits/s. https://www.speedtest.net/result/16116969035 8. I rarely reboot this laptop, it is 7th-gen Intel-based, and has AES-NI instruction set. 9. I do about weekly a snapshot with Timeshift-GTK app. Monthly then full clones of both SSDs. 10. The OS is Linux Mint 21.3 Cinnamon 64-bit based on Ubuntu 22.04. Current kernel is of version 6.5.0-27. *** That is about my notes of this experiment, an interesting one, if you ask me. I believe the only harder part for me would be writing that shell script for automating it. At the same time interesting it could be. Don't know where to start and what not to forget on. Thanks for all and any tips.

I'm looking to create a setup where an OS image is (automatically) downloaded over the network and then booted into. The obvious way would be to write it to disk, reconfigure grub (or whatever) and reboot, but I'm looking for a way to do this **without any disk writes** at all. The disk would only be used to read the fixed initial image, responsible for downloading the real image and everything after that would run purely from a RAMdisk. After a real reboot (like a shutdown command or disconnected power), I would expect the device to boot back into the initial disk image, which would again start from scratch by downloading the real image, etc. I've heard of netboot for diskless setups, but it seems not appropriate for my use case as I need a full Linux userland running for downloading the image (I want to have the option to download over WiFi, use gpg to verify signatures, etc. which is not feasible from bootloader). I've also looked into kexec, but I'm not sure how it could be used to load a full bootable image.

I'm trying to establish a baseline throughput overhead for a passthrough device mapper; i.e. a device mapper that does nothing. Roughly following benchmarking procedures [from Cloudflare](https://blog.cloudflare.com/speeding-up-linux-disk-encryption) , I'm measuring roughly **30% throughput decrease** from using a passthrough device mapper over ramdisk with fio, as opposed to straight I/Os to ramdisk, running on Azure VMs, GCP VMs, and raw metal machines, with both Ubuntu 20.04 LTS and 22.04 LTS. **Is this expected?** I'm getting roughly 1000+MB/s over ramdisk across devices and 600+MB/s for passthrough. Here's my setup for those of you who would like to replicate my results: 1. Create a Ubuntu 20.04 or 22.04 VM or get access to such a machine. Turn off secure boot so you can load kernel modules. 2. Create 4GB of ramdisk: sudo modprobe brd rd_nr=1 rd_size=4194304 3. Install fio: sudo apt install -y fio 4. Run fio over ramdisk: sudo fio --filename=/dev/ram0 --readwrite=readwrite --bs=4k --direct=1 --loops=20 --name=plain 5. Record the read/write throughput at the bottom of the output: aggrb=?MB/s. This is the baseline. Now for the passthrough device mapper, using the "delay" device mapper. This is what was done by [Cloudflare](https://www.usenix.org/sites/default/files/conference/protected-files/vault20_slides_korchagin.pdf) : 1. Set up the passthrough device mapper: echo '0 8388608 delay /dev/ram0 0 0' | sudo dmsetup create plain 2. Run fio over it: sudo fio --filename=/dev/mapper/plain --readwrite=readwrite --bs=4k --direct=1 --loops=20 --name=plain 3. Record the throughput similarly. Alternatively, if you suspect the "delay" device mapper with 0 delay is not performant, you can use my implementation of a passthrough device [here](https://github.com/davidchuyaya/rollbaccine/blob/main/src/passthrough/passthrough.c) . Download both files [here](https://github.com/davidchuyaya/rollbaccine/tree/main/src/passthrough) , then compile and load the kernel module: 1. Run make 2. Load the module: sudo insmod passthrough.ko 3. Load the device mapper: `echo "0 sudo blockdev --getsz /dev/ram0 passthrough /dev/ram0" | sudo dmsetup create passthrough` 4. Run fio over it: sudo fio --filename=/dev/mapper/passthrough --readwrite=readwrite --bs=4k --direct=1 --loops=20 --name=passthrough 5. Record the throughput similarly.

Is there away way to turn on IO accounting for /dev/ramX block devices in Linux? I already tried echo 1 > /sys/block/ram1/queue/iostat but it did not work. Notice that all devices have stats except the ram devices at the bottomSo performance measurement tools like dool cannot measure the IO speed:

# cat /proc/diskstats 
  11       0 sr0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
  11       1 sr1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
   8       0 sda 723676 35000 88332842 15213728 1023996 4665548 516093800 245971648 0 17497453 262613130 0 0 0 0 45125 1427753
   8      16 sdb 160138 25031 9086236 1901857 5894107 1629435 99783746 263249749 0 34043114 273161200 0 0 0 0 319611 8009594
   8      17 sdb1 126 30 8994 751 9 0 24 117 0 862 869 0 0 0 0 0 0
   8      18 sdb2 159872 25001 9072882 1900962 5894094 1629435 99783722 263249569 0 34042604 265150532 0 0 0 0 0 0
 253       0 dm-0 2910 0 55490 64862 6575840 0 52901448 295198662 0 20973198 295263524 0 0 0 0 0 0
 253       1 dm-1 112625 0 3832882 2024582 103580 0 1755640 12405574 0 1639466 14430156 0 0 0 0 0 0
 253       2 dm-2 757922 0 88327794 16122171 5450438 0 516093800 1273579273 0 16577985 1289701444 0 0 0 0 0 0
 253       3 dm-3 729 0 805332 9620 58317 0 13217898 6701775 0 868402 6711395 0 0 0 0 0 0
 253       4 dm-4 68487 0 4373706 650891 766343 0 31908736 44931626 0 13503972 45582517 0 0 0 0 0 0
   7       0 loop0 741 0 32160 69 159 0 912 4296 0 4336 8536 6 0 6 10 45 4160
   1       0 ram0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
   1       1 ram1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
   1       2 ram2 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
   1       3 ram3 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
   1       4 ram4 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
   1       5 ram5 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
   1       6 ram6 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
   1       7 ram7 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
   1       8 ram8 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
   1       9 ram9 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
   1      10 ram10 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
   1      11 ram11 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
   1      12 ram12 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
   1      13 ram13 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
   1      14 ram14 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
   1      15 ram15 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0

Due to a deficit of RAM on Debian, I need to move /tmp to SSD drive. But I still can't figure it out, how to do that so the programs that use it will still access it under /tmp path. So basically, what I want to achieve is move /tmp from ramdisk to for example /home/tmp. And be able to access it through /tmp

Is there a device node called /dev/selinux Android 13 init crashes with the following

[    1.417333]  (7)[1:init]selinux: SELinux: Loaded file_contexts
[    1.417341]  (7)[1:init]selinux: 
[    1.419537]  (7)[1:init]selinux: SELinux: Could not set context for /dev/selinux:  Permission denied
[    1.419545]  (7)[1:init]selinux: 
[    1.419623]  (7)[1:init]init: restorecon failed of /dev/selinux failed: Success
[    1.420364]  (7)[1:init]init: InitFatalReboot: signal 6

When I run command ls /dev/selinux with a stock ramdisk it is absent, when I compile Lineage 20 the ramdisk boots to the permission denied on /dev/selinux error

I am following the book "Mastering Embedded Linux Programming - Second Edition" trying to boot up the Linux kernel mounting a ramdisk. I have U-boot 2020.01 working and the Linux kernel image made. I have made a file system on my computer where I have added busybox and the libraries required by it manually as so files. Here is summarized copy of tree in my filesystem.

├── bin
│   ├── arch -> busybox
...
│   ├── busybox
│   ├── cat -> busybox
...
├── dev
├── etc
├── home
├── lib
│   ├── ld-2.30.so
│   ├── ld-linux-armhf.so.3 -> ld-2.30.so
│   ├── libc-2.30.so
│   ├── libc.so.6 -> libc-2.30.so
│   ├── libm-2.30.so
│   ├── libm.so.6 -> libm-2.30.so
│   ├── libresolv-2.30.so
│   └── libresolv.so.2 -> libresolv-2.30.so
├── linuxrc -> bin/busybox
├── proc
├── sbin
│   ├── acpid -> ../bin/busybox
...
├── sys
├── tmp
├── usr
│   ├── bin
│   │   ├── [ -> ../../bin/busybox
...
│   ├── lib
│   └── sbin
│       ├── addgroup -> ../../bin/busybox
...
└── var
    └── log

I have created my ramdisk image following the snippet:

cd ~/rootfs
find . | cpio -H newc -ov --owner root:root > ../initramfs.cpio
cd ..
gzip initramfs.cpio
mkimage -A arm -O linux -T ramdisk -d initramfs.cpio.gz uRamdisk

I have placed all the needed files in the SD card and in u-boot in the Beaglebone black tried to boot as:

fatload mmc 0:1 0x80200000 zImage
fatload mmc 0:1 0x80f00000 am335x-boneblack.dtb
fatload mmc 0:1 0x81000000 uRamdisk
setenv bootargs console=ttyO0,115200 rdinit=/bin/sh
bootz 0x80200000 0x81000000 0x80f00000

The problem is after the bootz it complains about my ramdisk image being wrong.

=> fatload mmc 0:1 0x80200000 zImage
7109016 bytes read in 464 ms (14.6 MiB/s)
=> fatload mmc 0:1 0x80f00000 am335x-boneblack.dtb
34220 bytes read in 5 ms (6.5 MiB/s)
=> fatload mmc 0:1 0x81000000 uRamdisk
2828897 bytes read in 185 ms (14.6 MiB/s)
=> setenv bootargs console=ttyO0,115200 rdinit=/bin/sh
=> bootz 0x80200000 0x81000000 0x80f00000
Wrong Ramdisk Image Format
Ramdisk image is corrupt or invalid

As I am starting with Linux on embedded devices I am completely out of ideas on how to solve the issue. I have found the reason is that the filesystem image has been created wrong. I have tried to use mkimage with -c none to no avail. I have tried using the mkimage inside my u-boot copy instead of the one that you can install in Ubuntu (with sudo apt-get install u-boot-tools). Before mkimage is called initramfs.cpio.gz looks as as follow: Am I missing some folders/files in my filesystem? Is it a problem my computer has ext4 but the boot partition uses fat32? Do I need to use a different mkimage toolset? What could be the problem?

This is how I create RAM disk manually on Linux Debian Jessie: mount -o size=1G -t tmpfs none /mnt/tmpfs My question is, how do I make this automatic at each computer startup?

I have allocated /dev/ram0: dd if=/dev/zero of=/dev/ram0 bs=1M count=1024 Now I have 1Gb sitting in memory. How do I free up the allocated space?

How do I accomplish setting up project quota for my live root folder being ext4 on Ubuntu 18.04? Documentation specific to project quota on the ext4 filesystem is basically non-existent and I tried this: 1. Installed Quota with apt install quota -y 2. Put prjquota into /etc/fstab for the root / and rebooted, filesystem got booted as read-only, no project quota (from here only with prjquota instead of the user and group quotas) 3. Also `find /lib/modules/uname -r -type f -name '*quota_v*.ko*' was run and both kernel modules /lib/modules/4.15.0-96-generic/kernel/fs/quota/quota_v2.ko and /lib/modules/4.15.0-96-generic/kernel/fs/quota/quota_v1.ko` were found (from this tutorial) 4. Put GRUB_CMDLINE_LINUX_DEFAULT="rootflags=prjquota" into /etc/default/grub, ran update-grub and rebooted, machine does not come up anymore. 5. Putting rootflags=quota into GRUB_CMDLINE_LINUX="... rootflags=quota" running update-grub and restarting did show quota and usrquota being enabled on root, but it does not work with prjquota or pquota or project being set as an rootflag I need this for the DIR storage backend of LXD to be able to limit container storage size. What else can I try?

There are quite a few Linux kernel parameters that can prevent the boot and shutdown logs from appearing on the screen. I was able to set the following kernel parameters to achieve a completely silent boot:

quiet systemd.show_status=0 loglevel=3 udev.log_level=3 vt.global_cursor_default=0

However, the shutdown screen still shows some messages despite the kernel parameters being set. These messages show up strictly at the initramfs stage of shutdown. For example, I sometimes get the following messages:

sd-umoun: Failed to unmount /oldroot: Device or resource busy
sd-umoun: Failed to unmount /oldroot/dev: Device or resource busy
shutdown: Could not detach DM /dev/dm-1: Device or resource busy
shutdown: Could not detach DM /dev/dm-0: Device or resource busy
shutdown: Failed to finalize file systems, DM devices, ignoring.

These are due to some configuration problems with the plymouth service and are mostly harmless. Despite the cause of the messages, I would like to know if it's possible to hide **all** logs produced at this stage of the shutdown process? Is there a way to tell the initrd system to not print any logs to the console during shutdown, even if they are errors? I tried to prepend rd. to some of the kernel parameters, but from what I understand these are redundant with the normal kernel parameters i.e. rd.loglevel=0 doesn't do anything extra in regards to the ramdisk image.

Having a bsd.rd extracted from an installation image and mounted as a vnode I can see there is 0.2MB free space available for additional files such as used during unattended installation. I want to copy a file 1MB in size but it obviously won't fit. Having that said, is there any way to increase the size of the ramdisk kernel without building it from source? My idea was to copy its content to newcontent.d, move my additional file into it, run makefs newcontent.fs newcontent.d on it, then rdsetroot bsd.rd.uc newcontent.fs and finally compress it and put back on an installation media. Sadly, while the size of original bsd.rd is 3.3MB the copy of it takes 180MB... I measure the size of directories using du -hs /path/to/directory.

I've reproduced this twice from a fresh install - the setup initially works fine, but when a kernel update is applied, the system hangs on reboot. Selecting the older kernel I have available from GRUB works fine. System details: - XPS 13 9380 - i5-8265U - BIOS version 1.15.0 - Microcode version reported as "0xea". Output of apt list --installed | grep microcode: intel-microcode/hirsute-updates,hirsute-security,now 3.20210608.0ubuntu0.21.04.1 amd64 [installed,automatic] - Secure Boot is, I believe, set to audit mode. - Ubuntu hirsute (as mentioned) - Installed on a LUKS partition from LiveUSB - Currently on 5.11.0-37-generic but I've reproduced with older 5.11 kernels as well. Definitely seems to be the *change* in kernel version rather than the version itself. 5.11.0-36-generic boots with no unusual GRUB options required. GRUB settings I've tried that **definitely do not work**: - dis_ucode_ldr and mitigations=off (together or separately); - nomodeset - removing quiet splash - recovery - debug (no change in output) - any form of echo after the line "initrd /initrd.img-5.11.0-37-generic" And all permutations thereof. lsinitramfs of both initrd.img and initrd.img.old (that I can boot off of) files doesn't pop up any obvious candidates. It seems to likely be either microcode or cryptsetup-related, but since debug gives nothing, and dmesg presumably reports a normal boot once I boot with 36, I'm slightly at a loss. Any thoughts? There seem to be related bugs but nothing that exactly reproduces.

I have a machine with 62GB of RAM, and a trunk that's only 7GB, so I thought I would create a RAM disk and compile there. I am not a Linux expert. I found instructions on the internet to create the RAM disk: mkfs -q /dev/ram1 8192 but I changed the 8192 to 16777216 in an attempt to allocate 16GB of ram disk. I got the following error: mkfs.ext2: Filesystem larger than apparent device size. Proceed anyway? (y,n) At which point I got spooked and bailed. sudo dmidecode --type 17 | grep Size shows 8x8192MB + 2048MB = 67584 MB but du on /dev gives 804K. Is that the problem? Can I overcome that /dev size?

I have 32 GB of memory in my PC. This is more than enough for a linux OS. Is there an easy to use version of Linux (Ubuntu preferably) that can be booted via optical or USB disk and be run completely within RAM? I know a live disc can be booted with a hard disk, but stuff still runs off the disc and this takes a while to load. I'd like everything loaded into RAM and then run from there, completely volatile. Any files I need to create would be saved to a USB disk. I'm aware of http://en.wikipedia.org/wiki/List_of_Linux_distributions_that_run_from_RAM but these all depend on a little bit of RAM. I'd prefer something like Ubuntu instead of these light versions.