Noswap doen't work anymore

[benjibasson]

Hi
Since the february's update, the cheatcode noswap doesn't work anymore

expected result: no swap partition in use

Code: Select all

root@porteus:/home/guest# swapon 
NAME                    TYPE      SIZE USED PRIO
/dev/zram0              partition 3.3G   0B  100

what happen?

Code: Select all

root@porteus:/home/guest# swapon 
NAME                    TYPE      SIZE USED PRIO
/dev/sda6               partition 9.7G   0B   -2
/dev/zram0              partition 3.3G   0B  100

how to fix this? my /dev/sda6 is used to my Arch linux hibernation, and if other linux erase suspend data from /dev/sda6 it make extra mess in this distrib ( whole file system corruption)

Cheers

[Ed_P]

I'm not seeing what you're seeing benji.

Code: Select all

guest@porteus:~$ su
Password: 
root@porteus:/home/guest# swap
bash: swap: command not found
root@porteus:/home/guest# noswap
bash: noswap: command not found
root@porteus:/home/guest# swapon
root@porteus:/home/guest# swapon
root@porteus:/home/guest# swapon -s
root@porteus:/home/guest# 

I don't use the noswap cheatcode and I have no partitions formatted as swap. Why do you have swap partitions if you don't want them used?

Code: Select all

guest@porteus:~$ lsblk -f --output NAME,FSTYPE,LABEL,SIZE,TYPE
NAME        FSTYPE   LABEL         SIZE TYPE
loop0       iso9660  Porteus       358M loop
 :
nvme0n1                          931.5G disk
├─nvme0n1p1 vfat     ESP           150M part
├─nvme0n1p2                        128M part
├─nvme0n1p3 ntfs     OS            219G part
├─nvme0n1p4 ntfs                   1.2G part
├─nvme0n1p5 ntfs     Image        16.6G part
├─nvme0n1p6 ntfs     DELLSUPPORT   1.4G part
├─nvme0n1p7 ntfs     Data          250G part
└─nvme0n1p8 ntfs     Backups     443.1G part
guest@porteus:~$ 
 

[ncmprhnsbl]

Since the february's update, the cheatcode noswap doesn't work anymore

can't seem to reproduce this.. ie. noswap works as expected here..
i did introduce a new cheatcode: "swapfile=" into /etc/rc.d/rc.S, but that shouldn't have any effect on the noswap cheatcode (in fact, it requires it if there is a swap partition present) because it should do nothing at all if it isn't being used..
are you using any other cheatcodes or something else in the booting process?

[benjibasson]

Hi,

@Ed_P
the swap partition is reserved for my arch Linux and its hibernation.
I prefer to use the swapfile on porteus via RC.LOCAL and change=

@ncmprhnsbl
I am using this boot option and it mont and swapon /dev/sda6 swap partitions

Code: Select all

menuentry "porteus  on sda3 xfce safe mode"{
set root=(hd0,3)
linux /porteus64bit_v50/boot/syslinux/vmlinuz from=/dev/sda3/porteus64bit_v50 load=999 resume=/dev/sda3 resume_offset=4268032 login=guest copy2ram ramsize=14% zram=43% noswap noauto
initrd /porteus64bit_v50/boot/syslinux/initrd.xz
}

even with

Code: Select all

menuentry "porteus  on sda3 xfce always fresh"{
set root=(hd0,3)
linux /porteus64bit_v50/boot/syslinux/vmlinuz from=/dev/sda3/porteus64bit_v50 login=guest copy2ram base_only noswap
initrd /porteus64bit_v50/boot/syslinux/initrd.xz
}

it swapon

Code: Select all

/dev/sda6               partition 9.7G   0B   -2

didn't occure with 20221210's update
always occure with 20230216/

[ncmprhnsbl]

ok, to rule out(or in) the change in /etc/rc.d/rc.S, since you're using changes, comment(#) or remove lines 62 to 83 in /etc/rc.d/rc.S (as root user)
although i don't see the changes= cheatcode in your examples..
otherwise, make a module with that adjusted file in it and place in your modules folder..
another thing to try is maybe using the swapfile=</path/to/swapfile> cheatcode instead of the rc.local way, to seee if that makes a difference (without the above change)
apart from this, i can't see how any of the package updates might be affecting this..

[benjibasson]

Hi
I have edited rc.s but the troubleshoot still hapen

Here is extract of dmessg

Code: Select all

[    0.000000] Linux version 5.18.8-porteus (root@porteus.example.net) (gcc (GCC) 11.2.0, GNU ld version 2.37-slack15) #1 SMP PREEMPT_DYNAMIC Sat Jul 2 10:05:31 MSK 2022
[    0.000000] Command line: BOOT_IMAGE=/porteus64bit_v50/boot/syslinux/vmlinuz from=/dev/sda3/porteus64bit_v50 load=999 resume=/dev/sda3 resume_offset=4268032 login=guest copy2ram ramsize=14% zram=43% [b]noswap[/b] noauto
[    0.024391] PM: hibernation: Registered nosave memory: [mem 0xff000000-0xffffffff]
[    0.024394] [mem 0xdf200000-0xf7ffffff] available for PCI devices
[    0.024397] clocksource: refined-jiffies: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 1910969940391419 ns
[    0.039762] setup_percpu: NR_CPUS:32 nr_cpumask_bits:32 nr_cpu_ids:4 nr_node_ids:1
[    0.039934] percpu: Embedded 44 pages/cpu s143016 r8192 d29016 u524288
[    0.039940] pcpu-alloc: s143016 r8192 d29016 u524288 alloc=1*2097152
[    0.039942] pcpu-alloc: [0] 0 1 2 3
[    0.039959] Fallback order for Node 0: 0
[    0.039961] Built 1 zonelists, mobility grouping on.  Total pages: 2044185
[    0.039963] Policy zone: Normal
[    0.039965] Kernel command line: quiet BOOT_IMAGE=/porteus64bit_v50/boot/syslinux/vmlinuz from=/dev/sda3/porteus64bit_v50 load=999 resume=/dev/sda3 resume_offset=4268032 login=guest copy2ram ramsize=14% zram=43% noswap noauto
[    0.040107] Unknown kernel command line parameters "copy2ram [b]noswap[/b] noauto BOOT_IMAGE=/porteus64bit_v50/boot/syslinux/vmlinuz from=/dev/sda3/porteus64bit_v50 load=999 login=guest ramsize=14% zram=43%", will be passed to user space.
[    0.040551] Dentry cache hash table entries: 1048576 (order: 11, 8388608 bytes, linear)
[   25.249532] intel_rapl_common: RAPL package-0 domain package locked by BIOS
[   25.249540] intel_rapl_common: RAPL package-0 domain dram locked by BIOS
[   25.329019] ieee80211 phy0: Selected rate control algorithm 'iwl-mvm-rs'
[   25.692672] Adding 10208252k swap on /dev/sda6.  Priority:-2 extents:1 across:10208252k
[   25.774530] zram: Added device: zram0
[   25.830911] zram0: detected capacity change from 0 to 6947424
[   25.865485] Adding 3473708k swap on /dev/zram0.  Priority:100 extents:1 across:3473708k SS
[   26.758814] Generic FE-GE Realtek PHY r8169-0-301:00: attached PHY driver (mii_bus:phy_addr=r8169-0-301:00, irq=MAC)
[   26.843298] EXT4-fs (sda3): mounted filesystem with ordered data mode. Quota mode: disabled.
[   26.894371] Adding 10239996k swap on /mnt/sda3/swapfile.swap.  Priority:-3 extents:148 across:163168256k
[   26.941330] r8169 0000:03:00.1 eth0: Link is Down
[   28.424327] wlan0: authenticate with 06:2c:fa:a1:28:a9
[   28.424341] wlan0: 80 MHz not supported, disabling VHT

Should I remove both noswap and rc.local content to add swapfile=</path/to/swapfile> cheatcode?

The change is on 999-change.xzm on optional ( purpose switch off sda drive. And take less memory on ramsize with compressed change)

[scaleinvariant]

This problem hit me today!

I had to clone a server's OS SSD over the network in an emergency situation. I booted from my trusty Porteus 5.01 USB drives on both the source and target machines, making sure not to mount anything on the source machine by adding the "noswap noauto" cheatcodes. (The target SSD had no partitions defined.) After the cloning process was finished, I computed sha256sums of the entire SSDs on both sides to check that the target/imaged machine was indeed a bit-for-bit identical copy. To my horror, the hashes did not match! I was panicking thinking I had bad RAM or a bad SSD, making data copy unreliable. When I tracked down where the differences between the source and target were, they were all on the swap partition! Then I checked, and sure enough, /proc/swaps and swapon -s showed that swap had been enabled on the source machine, despite my explicit "noswap" cheatcode forbidding this.

I tracked down the problem to line 264 of the file /etc/rc.d/rc.services in the 001-core.xzm Porteus module. This line does a "swapon -a" with no grepping of the /proc/cmdline for "noswap". (Compare with how the following zram stanza on line 267 of the script does grep /proc/cmdline).

I made a custom change module with line 264 commented out, and verified upon reboot that the swap was no longer automatically enabled, so that line is the culprit.

I was using an older version of Porteus, but I checked the code on the latest 2024-08-01 Porteus update (at https://mirrors.dotsrc.org/porteus/x86_ ... 1-core.xzm) and it still has the problematic "swapon -a" on line 264.

Hope this helps someone.

[Otto]

Sofar I know you can not mix both zram and swap-file/partition.
In your case you have "/mnt/sda3/swapfile.swap" and "zram0: detected capacity" and also "Adding 10208252k swap on /dev/sda6" (please see your attached dmessg-report).
Please correct me if I am wrong.

[ncmprhnsbl]

I tracked down the problem to line 264 of the file /etc/rc.d/rc.services

thanks! for no good reason, i hadn't noticed this ..(rc.services doesn't seem like a good place for this)
in any case, it should have conditionals prefacing it to account for noswap at least. to be fixed in future update.

[ncmprhnsbl]

followup: still can't reproduce this here ie. noswap works as expected here, so i'm not sure what's going on to cause this..
afaics, it should work by a function in initrd causing fstab to be generated without any swap entries, therefore swapon -a should have no effect.
clearly there are some scenarios, where this somehow fails, so i'll go ahead with prefacing it with a conditional.

Sofar I know you can not mix both zram and swap-file/partition.

looking around, i see some suggestion that it is possible, provided the priority is set correctly...