GNUinOS - Libre

oui · 2022-12-30 21:04:46

Hello

I wish all people a merry new year 2023!

Gnuinos for i686: the new release of refracta snapshot causes that the USB stick can't be found to start linux starting the snapshot from USB.

can someone having a good working version upload a snapshot INCLUDING refracta tools?

fsmithred · 2022-12-30 22:29:06

oui wrote:

Hello
I wish all people a merry new year 2023!
Gnuinos for i686: the new release of refracta snapshot causes that the USB stick can't be found to start linux starting the snapshot from USB.
can someone having a good working version upload a snapshot INCLUDING refracta tools?

I don't understand what problem you are having or what you are asking for. If you want the previous version of refracasnapshot or any older version, they are here: https://sourceforge.net/projects/refracta/files/tools

What version of gnuinos/devuan are you using and how did you prepare the usb stick?

oui · 2022-12-30 23:10:28

hI
thank you very much for your fast answer!
I use gnuinos-5.0.0-daedalus_2022.11.05-xfce_i686.iso in full installation on harddisk, and did had in lot of steps following packages:

sudo apt install refractainstaller-base refractainstaller-gui refractasnapshot-base refractasnapshot-gui deborphan didiwiki viewnior mhwaveedit nted abiword gnumeric mgp sane-utils cups tesseract-ocr gimagereader gprolog lifelines

though I did not already use all, I suppose that all that works properly. all that was old from the last month, installed with ap-get in the full install.

as I did discover in the last day the new version from Devuan daedalus, I did try a apt-get update and constate that I have to update and did do it on the full installation.

with the updated installation, I did try my first refracta snapshot on it using the gui. it did happen very fast and produce an
snapshot-20221230_0120.iso.sha256 93 bytes
snapshot-20221230_0120.iso 1,1 GB
without any problem.
I did write it on a 2 GB memory card with fresh new partition table with an unique new partition FAT16 with boot flag using through "dd".
This starts pretty in an adequate card reader after reboot until the new system from the new iso search in the found partition but ends in a small console with the error message after relatively long searching informing that no new system to start was found in the founded stuff: the system did not find the system again on the stick where it did start.

I know no adequate command to enter in the small console to inform it where is /usb/sb1 and invite it to continue.

Does it give an adequate succession of commands?

fsmithred · 2022-12-30 23:49:24

The version of live-boot in daedalus/ceres is still broken. Use the deb packages for live-boot and live-boot-initramfs-tools in the same sourceforge directory I linked in my last post.

Make sure you dd the iso to the whole device, not to a partition. ( to /dev/sdb and not to /dev/sdb1 for example.)

zapper · 2023-02-03 04:46:50

fsmithred wrote:

The version of live-boot in daedalus/ceres is still broken. Use the deb packages for live-boot and live-boot-initramfs-tools in the same sourceforge directory I linked in my last post.
Make sure you dd the iso to the whole device, not to a partition. ( to /dev/sdb and not to /dev/sdb1 for example.)

So qemu-system-x86_64 isn't a way to do so?

Aka, with the command parameters from earlier in this thread only slightly different.

Btw, if it doesn't work properly installing via qemu on a vm, that's usually a sign of somrthing needs to be fixed.

fsmithred · 2023-02-03 12:39:44

zapper wrote:

fsmithred wrote:
The version of live-boot in daedalus/ceres is still broken. Use the deb packages for live-boot and live-boot-initramfs-tools in the same sourceforge directory I linked in my last post.
Make sure you dd the iso to the whole device, not to a partition. ( to /dev/sdb and not to /dev/sdb1 for example.)
So qemu-system-x86_64 isn't a way to do so?
Aka, with the command parameters from earlier in this thread only slightly different.
Btw, if it doesn't work properly installing via qemu on a vm, that's usually a sign of somrthing needs to be fixed.

If live-boot is broken (can't find the mount command) then it doesn't matter if you install to VM or hardware.

However... the fixed version of live-boot is now in sid/ceres and will soon be in daedalus.

$ apt policy live-boot
...
  Version table:
     1:20230131 10
         10 http://deb.devuan.org/merged ceres/main amd64 Packages
         10 http://debian.csail.mit.edu/debian sid/main amd64 Packages

zapper · 2023-02-03 22:07:48

fsmithred wrote:

zapper wrote:
fsmithred wrote:
The version of live-boot in daedalus/ceres is still broken. Use the deb packages for live-boot and live-boot-initramfs-tools in the same sourceforge directory I linked in my last post.
Make sure you dd the iso to the whole device, not to a partition. ( to /dev/sdb and not to /dev/sdb1 for example.)
So qemu-system-x86_64 isn't a way to do so?
Aka, with the command parameters from earlier in this thread only slightly different.
Btw, if it doesn't work properly installing via qemu on a vm, that's usually a sign of somrthing needs to be fixed.
If live-boot is broken (can't find the mount command) then it doesn't matter if you install to VM or hardware.
However... the fixed version of live-boot is now in sid/ceres and will soon be in daedalus.
$ apt policy live-boot
...
  Version table:
     1:20230131 10
         10 http://deb.devuan.org/merged ceres/main amd64 Packages
         10 http://debian.csail.mit.edu/debian sid/main amd64 Packages
 

I mean, yeah... that is a given.

but my point being, is just that, if it can be done with vm, it should work outside of vm.

There is only one catch:

You won't know if internet works properly with a VM.

So... yeah.
I usually do this more or less:

qemu-img create -f qcow2 an.qcow2 60G
qemu-system-x86_64 -m 3072 -cdrom an.iso -boot d an.qcow2 --enable-kvm
qemu-system-x86-64 --enable-kvm an.qcow2 -cpu kvm64,+nx -m 4096 -device AC97

Btw, if you already have the OS installed and use the cd rom option and it looks like it will boot the usual os, it is still possible to press escape or have it start the other way, etc... if needed.

prospero · 2023-03-27 00:14:36

Hello, Gnuinos world. I just realized that there is a freshly baked ISO available. Was testing Chimaera Xfce 64-bit, great experience: 380MiB RAM with a complete DE.

I ran into the missing /dev/mapper/gnuinos--vg-root error when I tried to install with LVM, so I did without LVM and everything went fine. Also, is there a trick to get the installer to format to XFS? It would not, so I used EXT 4 instead. That was with the previous 2023-03-11 image, though.

Last edited by prospero (2023-03-27 00:24:31)

aitor · 2023-03-27 22:11:10

prospero wrote:

Hello, Gnuinos world. I just realized that there is a freshly baked ISO available. Was testing Chimaera Xfce 64-bit, great experience: 380MiB RAM with a complete DE.

Hi, prospero... First of all, thanks for your comments in the Trisquel forum.

I ran into the missing /dev/mapper/gnuinos--vg-root error when I tried to install with LVM, so I did without LVM and everything went fine. Also, is there a trick to get the installer to format to XFS? It would not, so I used EXT 4 instead. That was with the previous 2023-03-11 image, though.

Let me check both cases. I did some lvm partitioning time ago in order to test hopman, but I guess that it was under devuan with eudev as device manager. Give me some time and I shall let you know the results of my enquiries, thanks

prospero · 2023-03-28 04:48:37

aitor wrote:

Let me check both cases. I did some lvm partitioning time ago in order to test hopman, but I guess that it was under devuan with eudev as device manager. Give me some time and I shall let you know the results of my enquiries, thanks

Thank you for your much appreciated work on Gnuinos.

I just found a clue about XFS in another section of the forum: "if you have enough RAM to install packages in a live session, you can install xfsprogs and then format partitions with xfs." https://dev1galaxy.org/viewtopic.php?pid=36004#p36004

After deeper inquiry about XFS, I realize that Ext4 is in fact better suited for my use: it is somewhat faster than XFS, and it allows resizing. My question arose from the fact that there is an XFS option in the partitioner tool of the installer, although of course it will not format if selected.

prospero · 2023-04-03 23:56:03

I just noticed there is a new Chimaera live iso from two days ago. The last install with the previous iso eventually went to frozen mode, so I decided to try my luck with the Daedalus Xfce 64-bit iso instead, which has been working just fine for now. Probably because of the time elapsed Because Daedalus is the current testing version, "$ sudo apt update" is complaining about a missing release files. All upgrades went fine, of course.

Last edited by prospero (2023-04-05 01:38:15)

alexkemp · 2023-04-04 10:48:16

prospero wrote:

a new Chimaera live iso from two days ago

Possibly due to a recent kernel upgrade to 6.1.12-1 (available from backports):

$ uname -a
Linux ng3 6.1.0-0.deb11.5-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.1.12-1~bpo11+1 (2023-03-05) x86_64 GNU/Linux
$ la /boot/initrd* /boot/vmlinuz*
-rw-r--r-- 1 root root 68062772 Mar 28 22:35 /boot/initrd.img-6.0.0-0.deb11.6-amd64
-rw-r--r-- 1 root root 68913767 Mar 31 17:35 /boot/initrd.img-6.1.0-0.deb11.5-amd64
-rw-r--r-- 1 root root  7730784 Dec 19 14:14 /boot/vmlinuz-6.0.0-0.deb11.6-amd64
-rw-r--r-- 1 root root  7866720 Mar  5 18:27 /boot/vmlinuz-6.1.0-0.deb11.5-amd64

My actual update was March 31 (I update daily):

$ la -clt /boot/initrd* /boot/vmlinuz*
-rw-r--r-- 1 root root 68913767 Mar 31 17:35 /boot/initrd.img-6.1.0-0.deb11.5-amd64
-rw-r--r-- 1 root root  7866720 Mar 31 17:35 /boot/vmlinuz-6.1.0-0.deb11.5-amd64
-rw-r--r-- 1 root root 68062772 Mar 28 22:35 /boot/initrd.img-6.0.0-0.deb11.6-amd64
-rw-r--r-- 1 root root  7730784 Jan  4 10:14 /boot/vmlinuz-6.0.0-0.deb11.6-amd64

prospero · 2023-04-05 01:36:57

Gnuinos is using the Linux-libre kernel, the current version in Daedalus is 5.19.0.2.

Newer versions of the Linux-libre kernel are available up to 6.2, but they have to be installed manually.

aitor · 2023-04-05 21:54:46

prospero wrote:

I just noticed there is a new Chimaera live iso from two days ago.

Yes, last weekend I improved usbmount, an alternative to udevil without suid permissions, used by hopman. On the other hand, there were some glitches related to the eventfs integration in libudev-compat (vdev), but I think that I succeded fixing them today because I tested different udev monitors running at the same time while provoking a lot of udev events for several minutes straight, and none of them crashed. Hence, today I decided to update the isos once again.

prospero wrote:

The last install with the previous iso eventually went to frozen mode, so I decided to try my luck with the Daedalus Xfce 64-bit iso instead, which has been working just fine for now. Probably because of the time elapsed Because Daedalus is the current testing version, "$ sudo apt update" is complaining about a missing release files. All upgrades went fine, of course.

Perhaps you'll find gnuinos daedalus more stable because it ships with eudev, for the time being at least, as opposed to chimaera. However, if you aren't familiar with vdev or you prefer the earlier device manager in chimaera, you can always change to it (or vice versa) via apt if you wish:

# apt-get install eudev

Packages like vdev, libudev-compat, libudev-compat-helpers, libudev-compat-dev, udevadm-compat... wil be removed from the system, of course.

Last edited by aitor (2023-04-05 21:57:55)

prospero · 2023-04-06 01:56:27

aitor wrote:

Hence, today I decided to update the isos once again.

Thank you. Surely I will give another try at Chimaera at some point. I only remember that the Xfce session became unresponsive, possibly after an update: I could still move the pointer around, but clicking on menus or icons would not trigger any visible reaction. The keyboard also seemed unresponsive, so I could not even log in another tty. So yes, probably related to vdev vs. eudev, I suppose.

Anyway, Daedalus is proving quite resilient for now, so I am going to keep tweaking it and see how much I can bend it to my needs and to my liking.

EDIT: I installed Chimaera again from the last ISO, and all went well. I made the exact same "tweaking" I had been doing on Daedalus, so at times I forget which version is running. By the way, Daedalus was repeatedly trying to ping through wlan at startup, to no avail since that non-free wifi card is not compatible. Chimaera is not exhibiting that behavior, even when wifi is enabled in the BIOS setup. The only usability thing I have been unable to do on that Chimaera system is to activate two-finger scrolling and right-click emulation on the touch pad. I am quite sure they were functional on Daedalus.

Last edited by prospero (2023-04-09 21:38:23)

zapper · 2023-04-07 04:13:12

Btw, is daedalus up to snuff yet, its based on a testing version after all, or is it just too daed!

prospero · 2023-04-12 03:58:15

@mammon: could you help aitor and send him some coworkers instead of trolling this thread?
@aitor: thanks for the new Gnuinos Chimaera ISO images that keep coming.

I have given up on touchpad scrolling for the time being, could not find where those settings are hiding and mostly using the keyboard anyway. It looks like the touchpad is defaulting to mouse, it appears as <default pointer> in the Xfce "Mouse and Touchpad" GUI, and there is no "Touchpad" tab showing. Other than that, it is quite a great experience, fast and stable. Great job in blob-free init freedom.

UPDATE: I had just managed to get some clues about synaptics vs. libinput vs. evdev, when I noticed this in the synaptics manual: "if your device is recognized as "PS/2 Mouse" or similar, the kernel driver does not support your device and this driver will only provide limited functionality". I did not want to believe earlier hints about the kernel, but they were probably correct. This is also consistent with my recollection of two-finger scrolling available in Daedalus.

UPDATE II: that was a red herring, I installed the last available kernel to no avail. I will now try the last chimaera ISO.

Last edited by prospero (2023-04-25 05:58:29)

zapper · 2023-04-14 16:43:03

@prospero I always disable touchpad on all my thinkpads if a trackpoint is available

Even if its via script

prospero · 2023-04-16 05:50:38

zapper wrote:

I always disable touchpad on all my thinkpads if a trackpoint is available

Are you referring to Gnuinos or to Hyperbola? As much as I will celebrate the day HyperbolaBSD is released, this thread is about Gnuinos.

aitor · 2023-05-01 17:59:57

Thanks to the recent eventfs integration in libudev-compat and vdev, Xorg can now make use of the libudev support available in the kernel (CONFIG_DEVTMPFS) that has been disabled in the ServerFlags Section of Xorg via:

Section "ServerFlags"
	Option "AutoAddDevices" "off"
	Option "AllowEmptyInput" "on"
EndSection

in all the previous versions of gnuinos to not use libudev, in a way that no input devices were being added from the udev backend. Otherwise, mice and keyboards didn't respond during the X sessions.

It happened that the uevent files pushed to /dev/metadata/udev/events as explained here:

https://www.gnuinos.org/libudev-compat/

were consumed by all the libudev clients, but Xorg. However, after the eventfs integration things have changed (for some reason only under 64 bits), and now the behavior of the pointer is much better in both virtual machines and touchscreens. I've also been able to enable/disable tap to click on the touchpad either via xinput and synclient (synaptics), and my Wacom Pen Tablet is recognized by Gimp. However, the libudev compatibility still doesn't work in 32 bits and I need to use the config snippet mentioned above to get the mouse and keyboard working thanks to obsolete drivers. Although the uevents are being consumed, input devices don't work if I enable udev in the server flags.

I've updated all the isos of gnuinos chimaera today.

Last edited by aitor (2023-05-07 17:20:24)

prospero · 2023-05-02 11:26:43

This is great news! I had indeed been looking at those lines in the zz-server.conf file, without any idea what to do about them.

Now everything just works, and I can indeed select tap-to-click in the Xfce touchpad configuration tab. I am planning to install again from the latest Chimaera ISO, but I was wondering whether there is a way to include these modifications through a system upgrade.

aitor · 2023-05-02 20:55:37

prospero wrote:

I am planning to install again from the latest Chimaera ISO, but I was wondering whether there is a way to include these modifications through a system upgrade.

System upgrades from vdev worked for me, but in this case it's very likely that the upgrade process will require a reboot in between to get the mouse and keyboard working again, after which you'll need to type `dpkg --configure -a` and then finish the process with another `apt-get dist-upgrade`.

To avoid this workaround I recommend to change to eudev before the system upgrade, that is:

# apt-get install eudev

Reboot, and upgrade the system:

# apt-get dist-upgrade

And then restore vdev if you wish once the upgrade process has been carried out:

# apt-get install vdev

Hope this helps.

Last edited by aitor (2023-05-02 20:57:50)

prospero · 2023-05-04 11:53:18

Good to know, thanks.

I am currently 100% happy with Gnuinos 4.0 Chimaera 64-bits Xfce, so I would like to thank you again for your effort.

The only extra system package I install is gvfs-backends, so I can sftp into other local machines right from Thunar's address bar.

aitor · 2023-05-07 17:51:40

aitor wrote:

after the eventfs integration things have changed (for some reason only under 64 bits)

Solved!

It's working in x86 as well

The origin of the issue was in the lines 85-92 of inode.c when the flags verify_discipline and EVENTFS_VERIFY_INODE are enabled:

if( verify_discipline & EVENTFS_VERIFY_INODE ) {
      
      if( pstat_is_deleted( proc_stat ) || inode_sb.st_ino != sb.st_ino ) {
         
         eventfs_debug("%d: Inode mismatch: %ld != %ld\n", pstat_get_pid( inode->ps ), inode_sb.st_ino, sb.st_ino );
         return 0;
      }
}

The function:

static int eventfs_dir_inode_is_created_by_proc( struct eventfs_dir_inode* inode, struct pstat* proc_stat, int verify_discipline );

tries to determine whether or not the given directory /dev/metadata/udev/events/serial/libudev-$CLIENT_PID-$monitor_slot has been created by the given process (i.e. the libudev client). Otherwise, the aforementioned directory will be tagged as garbage, and thus, removed by the garbage collector in the eventfs filesystem.

However, even if the directory has been created by the given process, inode numbers may change and the above comparison cannot be considered as an absolute rule. Moreover, inode numbers always changed for me under 32 bit (It seems that Jude Nelson did all of his labs in x86_64). Therefore, I by-passed these lines in the code of inode.c, comparing only other attributes like the size, the path, the starttime, and so on.

I've updated the isos again.

Last edited by aitor (2023-05-07 17:57:30)

Ion · 2023-05-11 20:26:05

Hi,
I tried to install GNUinOS chimaera 2023.05.08 i386 netinstall on an x86_64 old computer (I hope the i386 doesn't mean 32 bits or else that explains where the problem comes from).
I decided to use Chimaera because I want to do a web server and I prefer to have PHP 7 for a certain time before the big jump into PHP 8… and the netinstall choice seems logical for a web server (that doesn't need a desktop environment).
The first strange thing that happened was this message:

No Kernel modules found
No kernel modules were found. This probably is due to a mismatch between the kernel used by this version of the installer and the kernel version available in the archive.
You should make sure that your installation image is up-to-date, or - if that's the case - try a different mirror, preferably deb.devuan.org

I continued anyway, but I think it explains what happened further.
Moreover, there where no root nor first user's creation (but I noticed that later).
Also, it was impossible to have a mount point if not choosing one of the few file system that for ext stopped in ext2.
After the crypt partitions' creation, ext4 was proposed but then no mount point was accessible, to render it accessible, the file system had to be changed.
Then, at the end of the installation, I had this message:

Aucun programme de démarrage installé
Aucun programme de démarrage n'a été installé, soit parce que vous avez volontairement choisi de ne pas le faire, soit parce qu'aucun ne gère actuellement l'architecture que vous utilisez.
Vous devrez démarrer manuellement avec le noyau /vmlinuz qui se trouve sur la partition /dev/mapper/sda3_crypt et root=/dev/mapper/sda3_crypt quit passé en argument à ce noyau.

That I translate in English that way:

No starting software is installed
No starting software is installed, either because you voluntary chose not to do it, or because none are presently managing the architecture that you use.
You'll have to start manually the kernel /vmlinuz that is in the /dev/mapper/sda3_crypt partition and root=/dev/mapper/sda3_crypt quit passed in argument to this kernel [sic].

And when I restarted the computer, of course:

GRUB loading..
Welcome to GRUB!
error: no such cryptodisk found.
error: disk 'cryptouuid/(…)' not found.
Entering rescue mode...
grub rescue> _

Using GRUB's rescue is out of what I'm able to do, but I guess the problem couldn't be solved anyway.

Last edited by Ion (2023-05-12 01:51:25)

The officially official Devuan Forum!

#51 2022-12-30 21:04:46

Re: GNUinOS - Libre

#52 2022-12-30 22:29:06

Re: GNUinOS - Libre

#53 2022-12-30 23:10:28

Re: GNUinOS - Libre

#54 2022-12-30 23:49:24

Re: GNUinOS - Libre

#55 2023-02-03 04:46:50

Re: GNUinOS - Libre

#56 2023-02-03 12:39:44

Re: GNUinOS - Libre

#57 2023-02-03 22:07:48

Re: GNUinOS - Libre

#58 2023-03-27 00:14:36

Re: GNUinOS - Libre

#59 2023-03-27 22:11:10

Re: GNUinOS - Libre

#60 2023-03-28 04:48:37

Re: GNUinOS - Libre

#61 2023-04-03 23:56:03

Re: GNUinOS - Libre

#62 2023-04-04 10:48:16

Re: GNUinOS - Libre

#63 2023-04-05 01:36:57

Re: GNUinOS - Libre

#64 2023-04-05 21:54:46

Re: GNUinOS - Libre

#65 2023-04-06 01:56:27

Re: GNUinOS - Libre

#66 2023-04-07 04:13:12

Re: GNUinOS - Libre

#67 2023-04-12 03:58:15

Re: GNUinOS - Libre

#68 2023-04-14 16:43:03

Re: GNUinOS - Libre

#69 2023-04-16 05:50:38

Re: GNUinOS - Libre

#70 2023-05-01 17:59:57

Re: GNUinOS - Libre

#71 2023-05-02 11:26:43

Re: GNUinOS - Libre

#72 2023-05-02 20:55:37

Re: GNUinOS - Libre

#73 2023-05-04 11:53:18

Re: GNUinOS - Libre

#74 2023-05-07 17:51:40

Re: GNUinOS - Libre

#75 2023-05-11 20:26:05

Re: GNUinOS - Libre

Board footer