You are not logged in.
The ISO has a "dos" partition table that presents it as having two partitions:
1) first partition of type 0 spanning blocks 0-759807
2) second parition of type ef (=EFI) spanning blocks 4040-5511
Just the "normal" multi-boot set up.
Use "fdisk -l $iso" to review that ..
perhaps VBOX fails to see the partition table? Or that its virtual UEFI implementation fails to see it?
VBOX doesn't see the EFI partition of the devuan iso?
1) Why doesn't it boot? What does happen on the attempt?
My web search lead to
https://www.cocosenor.com/articles/comp … aptop.html
where at least the first option seems quite safe to try.
EDIT: duly edited. Thanks @Camtaf.
Yes, the netinstall is supposed to work in UEFI mode, and there are many cases were it has done so.
One of the issues that may come up with the grub installation step is that for some reason the "efivars" have got filled up with some kind of dump files. This can be handled by the following slight manual hands-on just before selecting init system:
Shift to virtual terminal 2 by pressing Ctrl-Alt-F2, and push Enter.
Check if this might be the problem by command: ls /sys/firmware/efi/efivars/dump-*
If that results with lots of output, then continue with step 3;
if there is no such file, then this is not your problem, so skip step 3.
Remove the dump files with command: rm /sys/firmware/efi/efivars/dump-*
Return back to installer at virtual terminal 1 by pressing Ctrl-Alt-F1, and continue.
"Use the source, Luke" ![]()
Yes, one could say, without imparting disrespect on any particular developers, that sometimes "fondness of gilding" strays from "diligent QA standard"... luckily it's scripts and not binaries.
Did you already try with
ROOTFSTYPE=ext4in /etc/initramfs-tools/initramfs.conf ?
Thanks, and there's now a new setup for forum translations, via a git project https://git.devuan.org/devuan/forum-lang
To make a new or existing language:
Fork the project, typically as a personal project at the git store. (*)
For a new language: copy the whole English directory tree into a new sibling directory tree that is named by the target language in that language.
Go through the files and replace the phrase part for each mapping as well as text portions in the mail templates. This is the actual authoring work. (**)
Submit a "pull request" for inclusion into the devuan/forum-lang project. (***)
Rest.
(*) It is feasible to clone into a personal workspace elsewhere than the git store as long as that workspace later is available to service the eventual pull request. But it's significantly less effort for us to merge it if you rather use the fork button on the web interface and make it a personal project on Devuan's git store.
(**) It is of course important to leave everything other than the phrase part as is.
(***) Again, it's easiest for us if you use the pull request button on web interface for submitting the pull request.
Thanks.
Ok. My fault. I've let my team of developers drag their feet about getting forum translations installed and now there is a small pile waiting. I'm now reasonably hopeful though, that by having a big bowl of peanuts as bounty, they will succeed in making forum translation available for distributed maintenance in a near future.
Your @Jackoline account was invalidated on your own request. Welcome back.
@vgal, the filename attribute of the Packages file(s) contain the relative pathname to the packages, into the "pool" directory tree, which as you point out, has the subdirectories DEBIAN and DEVUAN, and below that, you find the further relative path into the publication servers' tree for the .deb file.
It does seem like apt-ftparchive does something else than reproduce the pool path from the associated Packages files, which I guess is in your step "# generate "Packages" file". Specifically, if you locate the associated Packages file snippet for the package concerned, either in the original-cd Packages file(s), or in your local /var/lib/apt/lists/*Packages, you will find the correct pool pathname for the package. Alternatively, you add a step to change the Packages files generated by apt-ftparchive by replacing all filename attributes with the correct pool/ relative pathnames as found in that pool.
The note above was for the desktop-live installer that you find at the path variation devuan_chimaera/desktop-live/ and then the file name pattern is devuan_chimaera_4.0.beta-2021-08-27_xxxxxx.iso.
The devuan_chimaera/installer-iso/ collection will find themselves updated into isos of the pattern devuan_chimaera_4.0.beta-20210830_xxxxxx.iso, with and for the desktop-base improvement, at some near future.
@Jakoline I checked it out, and the rfkill package is actually in the ISO pool although not installed without DE. So the easier path would be to mount the ISO on, say, /mnt and then run
# dpkg -i $(find /mnt/pool -name \*rfkill\* )(as root) to install it.
Thereafter you may follow the above good advice as to how to use it.
Assuming the installer brought up the network, one way forward for you would be to start another installation but stop before partitioning; i.e., DON'T partition and instead use ctrl-alt-f2 to gain a shell.
In that shell, you first mount the previously installed file system partition, then chroot into that, and then install rfkill.
After the successful installation of rfkill, you should exit the chroot, unmount the partition, and then reboot into the previously installed system, now with rfkill installed.
I think you should comment out that second eth0 configuration; if you need both ipv4 and ipv6 you'll need to combine them into a single configuration block, e.g. with "up" statements dealing with ipv6.
Do you have files in /etc/network/interfaces.d/ ? Where do the vlan adapters come from .. or what they are? Eg wan@eth0
EDIT: it looks like some kind of "openwrt" setup; could you post /etc/config/network if you have one?
Is there a cable on eth0?
please post your /etc/network/interfaces
You might want to try out the https://git.devuan.org/rrq/buster-to-devuan method although it's named badly for this purpose.
Yes, someone has to do the work to figure that out. Why not you?
.. that's not meant to be aggressive in any way, but rather it's a suggestion that you shouldn't feel obstructed by imagined limitations and instead see it as an opportunity to learn as well as to actively contribute to the collaborative effort that Devuan is.
This is just a meta level note, that the way to capture bugs and user experience comments is by lodging "bugs", typically by email to the "bugs system".
The expectation is then that the lodger first tries to isolate which package is involved or seemingly involved and then lodge a "bug" against that package. If the package is "pure debian" the email target is "submit" at "bugs.debian.org, and if it's a devuan forked package, the email target is "submit" at "bugs.devuan.org,".
In both cases, the email should be a pure text email with the first two lines styled as
Package: packagename
Version: versionand then the description with details added.
It's of course fine to also note them at this forum, especially when it comes to more opinion based issues. However rather few of the package maintainers are at this forum.
You might want to check out
https://dev1galaxy.org/viewtopic.php?pid=29482#p29482
Maybe that works for you.
mmm you omitted the -e... the last part of the line should read
-geometry 120x15-300+150 -e mail"at least that's what the man xterm page says. I don't really know what the significant difference is between nominating a shell at the end (without -e) and nominating a program via the -e option. The man page has some discussion about it, but the authors' idea of clarity is different from mine.
yes; add the -e mail option for xterm as its last argument within the double-quoted string. Then that will be run instead of a command shell.
To use double-quotes within a double-quoted string, they must be back-slashed... ie
coolmail -e "xterm -xrm 'XTerm.vt100.allowTitleOps: false' -T \"System mail notification\"" -geometry 120x15-300+150An alternative is to use single-quotes, as in the -xrm detail.
Note that recently the kernel's loop module has max_part=0 by default, which means that the partitions (eg /dev/loop0p1) will not be set up. Many strands of hair have been lost due to this.
To get the good behaviour, I've added a file /etc/modprobe.d/loop.conf with the following line:
options loop max_part=15before the loading of the loop module. Almost any number other than 15, within bounds, is also fine.
There's some additional notes about quilt for debian packages in man dpkg-source, line 440++. Esp:
Any change on a binary file is not representable in a diff and will thus lead to a failure unless the maintainer deliberately decided to include that modified binary file in the debian tarball (by listing it in debian/source/include-binaries). The build will also fail if it finds binary files in the debian sub-directory unless they have been whitelisted through debian/source/include-binaries.
Perhaps that means both that the relative pathname for png file (probably relative the directory containing the debian sub directory) must be mentioned in that included-binaries file, and then that the included-binaries file is maintained via quilt patching.
EDIT: or that the included-binaries file is just updated (without quilt-ing).