You are not logged in.
Did you already try with
ROOTFSTYPE=ext4
in /etc/initramfs-tools/initramfs.conf ?
Wow, that fixed it! I'd been using ROOTFS=ext4 as per the man page but that was having no effect. Thank you! You know things not in the man pages! Your solution was not in the man page of update-initramfs, nor was it in the man page of initramfs.conf .
I'd rather Getting Seamonkey Installed be its own thread, but I will say this much: I downloaded the binary and it had a nonsense error where it said a library that did exist did not exist.
Thank you for the reply.. One vote for Thunderbird, then.
It seems the clever init ram fs making program has decided that, despite the fstab, that my ext4 slash ('/") partition for Devuan is better mounted as ext2.
How much damage is being done by every write to this ext4 partition? Should I be running a repair operation from a live CD every day?
Before Devuan, I was using seamonkey for email. There is no seamonkey in Devuan repos, so what is everyone using as their email program?
Thank you.
Very nice QNX-alike theme durham, I used FluxBox for about a year haven't seen before this stylish.
Thank you.
Perhaps i haven't looked over BlackBox to find it, or it is a new one?
It's just the regular blackbox in the repo.
You made me curious. Ran cal in xterm. No highlight. Ran with -t, got the error message just as you did. Very odd.
edit: also running chimaera
Besides Devuan, I currently have Liinux from Scratch, Slackware and Void installed on this computer.
So I've been reading up on devuan/debian init ram disk (init ram fs) making.
OK, in the /etc/initramfs-tools/conf.d directory, made a file called force_ext4 and put one line in it: "FSTYPE=ext4".
Ran "update-initramfs -u" to regenerate the init ram fs.
Upon lilo and then reboot, discovered that nothing. I then tried the more forceful "update-initramfs -c -k <kernel version>," but that had no effect: still mounting "/" as ext2
I've no idea what's going on.
I think fstab should say '/dev/mapper/azura-dawn' instead of '/dev/azura/dawn'.
I've never had to do that before on the other distros. The other volumes are mounted the same way (things like /dev/azura/homie for /home) and that gets mounted correctly.
Oh crap, I'll bet it's the damn init ram disk when it first mounts "/". I really don't want to have to crack that open to fix it.
Did the installer do that? Did you do automatic or manual partitioning?
Manual. Had to, it's a multi-boot machine all on one LVM. Installers tend to get confused and/or want to wipe the entire disk.
I recently noticed something odd about my Devuan install:
~ $ mount | grep atime | grep dawn
/dev/mapper/azura-dawn on / type ext2 (rw,noatime,stripe=64)
~ $ grep dawn /etc/fstab
/dev/azura/dawn / ext4 noatime 1 1
~ $
Unless I'm overlooking something, it seems as if I'm telling Devuan to mount the dawn LVM volume on "/" as ext4 and something has taken it upon itself to ignore the fstab and mount the drive as ext2, thus throwing out journaling and disabling discards.
Can anyone please explain? Thank you.
edit: It's 64-bit Chimaera