Re: [DNG] Custom OS initiator. In need of some hints...
On Mon, Jun 13, 2016 at 08:16:44AM +0200, Edward Bartolo wrote: > Hi, > > This is a question about implementing a minimal OS initiator. If > DNG's admins/mods deem this email is misplaced please delete it or > ignore it. > > Till now, I implemented a little OS initiator that calls "/bin/bash" > and then enters an infinite while loop that does nothing. The loop's > purpose is to prevent PID 1 from exiting. > > I would like to have my OS initiator: > a) initiate a terminal before launching it. /sbin/init launches six > such terminals tty1..tty6 > b) prevent this terminal from closing > c) do some basic child process management > If I can provide my 2 cents to the discusion, before writing a new init you should have studied and understood very well one of the existing ones, and what should happen behind the scenes from the moment your kernel is decompressed to the appearance of a login terminal. I would recommend to start with sysvinit or the standard rc-based init of *BSD. By studying I mean looking into the code of the process that is called "init" and into the code of all the processes directly started by init (e.g., /etc/init.d/rc, in the case of sysvinit, getty/agetty, etc...), and being sure to have understood what is in there. If you don't master the procedure behind system initialisation, to the point of being able to replay in your mind all the steps that init does while having a more or less precise idea of how those steps can be implemented in your language of choice, then you will waste a lot of time. Personally, I think I couldn't start writing a new complete init system anytime soon, despite I might have a very rough idea of what is going on there, the main reason being that I have never really *understood* how console management is performed under Linux (a concrete contribution to this ignorance is the fact that we have had 5 or 6 different ways of managing console setups in the last 20 years, most of them used concurrently on the same installation, but this is not a good excuse anyway...). My2Cents KatolaZ -- [ ~.,_ Enzo Nicosia aka KatolaZ - GLUGCT -- Freaknet Medialab ] [ "+. katolaz [at] freaknet.org --- katolaz [at] yahoo.it ] [ @) http://kalos.mine.nu --- Devuan GNU + Linux User ] [ @@) http://maths.qmul.ac.uk/~vnicosia -- GPG: 0B5F062F ] [ (@@@) Twitter: @KatolaZ - skype: katolaz -- github: KatolaZ ] ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Custom OS initiator. In need of some hints...
On 13/06/16 15:29, KatolaZ wrote: If I can provide my 2 cents to the discusion, before writing a new init you should have studied and understood very well one of the existing ones, and what should happen behind the scenes from the moment your kernel is decompressed to the appearance of a login terminal. I would recommend to start with sysvinit or the standard rc-based init of *BSD. By studying I mean looking into the code of the process that is called "init" and into the code of all the processes directly started by init (e.g., /etc/init.d/rc, in the case of sysvinit, getty/agetty, etc...), and being sure to have understood what is in there. Concur. If you wanted a simple and easy to follow example, grab the busybox init source. It does everything you need and is small enough that you can digest it relatively easily. Most other init systems tend to rapidly devolve into a nest of vipers and are therefore harder to follow. Regards, Brad ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Custom OS initiator. In need of some hints...
On Mon, Jun 13, 2016 at 08:16:44AM +0200, Edward Bartolo wrote: > Hi, > > This is a question about implementing a minimal OS initiator. If > DNG's admins/mods deem this email is misplaced please delete it or > ignore it. If you really want to create yet another init, I can recommend this simple, step by step explanation of Linux' init responsibilities: https://felipec.wordpress.com/2013/11/04/init/ -- Tomasz Torcz ,,(...) today's high-end is tomorrow's embedded processor.'' xmpp: zdzich...@chrome.pl -- Mitchell Blank on LKML ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
[DNG] Devuan on Android
Hi all, I want to report that I've installed Devuan on a "rooted" Android device using DebKit. All I did was: 1. Change the package mirror to: auto.mirror.devuan.org/merged 2. After the debootstrap process is complete and under the chroot install the devuan-keyring package. I tried to use some other apps like LilDebian, DebianKit, and LinuxDeploy, but for some reason they didn't work for installing Debian. So I didn't try Devuan. It's nice to have Devuan on my portable computing device. Thank you, Simon ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] LXC template for Devuan
hi, On Mon, 13 Jun 2016, Simon Walter wrote: > I've made an account on git.devuan.org (user: smwltr) How do you want to do > this? Shall I fork your repo and apply a patch and then send you a pull > request? we can create a group (named lxc?) and make you admins for it, or simply a single project as there may be no need for more packages. i'm cc: hellekin to stimulate a quicker response on what should be the naming scheme, since so far it has been curated with great attention to be meaningful. to me it makes sense to have something like 'virtualization-' as a prefix for repositories like lxc, but I'm also not sure what else would fall in there. ciao ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Custom OS initiator. In need of some hints...
On 13/06/16 16:19, Tomasz Torcz wrote: On Mon, Jun 13, 2016 at 08:16:44AM +0200, Edward Bartolo wrote: Hi, This is a question about implementing a minimal OS initiator. If DNG's admins/mods deem this email is misplaced please delete it or ignore it. If you really want to create yet another init, I can recommend this simple, step by step explanation of Linux' init responsibilities: https://felipec.wordpress.com/2013/11/04/init/ That was a great read and a lot simpler than getting into the busybox source :) I've not particularly bought into the whole systemd politics, I just don't like it on a technical level. Having said that the two links on the first line of that article made for horrifying reading. If that is the position taken by the systemd author, there is no wonder it's such a three legged goat. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
[DNG] The utility of pristine-tar
Hi all, You can verify the purity of the tarball of the kernel of gnuinos in a very easy way: Download the sources from the .deb repository of gnuinos: wget http://gnuinos.org/linux-libre/pool/main/l/linux/linux_4.3.5.orig.tar.bz2 Check the md5sum: $ md5sum linux_4.3.5.orig.tar.bz2 13d35915c7a99e1e7973c932cff075e0 linux_4.3.5.orig.tar.bz2 Now download the sources from the ::[FSFLA]:: GNU Linux-libre project (FSF-Latin América): wget http://linux-libre.fsfla.org/pub/linux-libre/releases/4.3.5-gnu/linux-libre-4.3.5-gnu.tar.bz2 and check the md5sum again: $ md5sum linux-libre-4.3.5-gnu.tar.bz2 13d35915c7a99e1e7973c932cff075e0 linux-libre-4.3.5-gnu.tar.bz2 As you can see, they are the same tarball. Here you are the utility of *pristine-tar* (fuentes puras, fonti puri...) Gnu, new, ñu, ñu :-) Cheers, Aitor. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Custom OS initiator. In need of some hints...
Le 13/06/2016 08:16, Edward Bartolo a écrit : Hi, This is a question about implementing a minimal OS initiator. If DNG's admins/mods deem this email is misplaced please delete it or ignore it. Till now, I implemented a little OS initiator that calls "/bin/bash" and then enters an infinite while loop that does nothing. The loop's purpose is to prevent PID 1 from exiting. I would like to have my OS initiator: a) initiate a terminal before launching it. /sbin/init launches six such terminals tty1..tty6 b) prevent this terminal from closing c) do some basic child process management Here's something you could try: mount -t proc proc /proc mount -t sysfs sys /sys mount -t devtmpfs dev /dev # or mount /dev as tmpfs and start hotplugger (udev/eudev/vdev/mdev) mount -t tmpfs run /run mknod -m 0600 /dev/console c 5 1 mknod -m 0660 /dev/tty1c 4 1 while ( true ) do printf 'Entering interactive shell\n' setsid /bin/sh -c 'exec bash /dev/tty1 2>&1' done; Have fun. Didier ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Devuan on Android
On Mon, Jun 13, 2016 at 05:23:17PM +0900, Simon Walter wrote: > Hi all, > > I want to report that I've installed Devuan on a "rooted" Android device > using DebKit. > > All I did was: > 1. Change the package mirror to: auto.mirror.devuan.org/merged > 2. After the debootstrap process is complete and under the chroot install > the devuan-keyring package. > > I tried to use some other apps like LilDebian, DebianKit, and LinuxDeploy, > but for some reason they didn't work for installing Debian. So I didn't try > Devuan. > > It's nice to have Devuan on my portable computing device. > Great! It would be even better if you could put a minimal howto somewhere (e.g., a wiki in git.devuan.org) so that other users can share your happiness :) HND KatolaZ -- [ ~.,_ Enzo Nicosia aka KatolaZ - GLUGCT -- Freaknet Medialab ] [ "+. katolaz [at] freaknet.org --- katolaz [at] yahoo.it ] [ @) http://kalos.mine.nu --- Devuan GNU + Linux User ] [ @@) http://maths.qmul.ac.uk/~vnicosia -- GPG: 0B5F062F ] [ (@@@) Twitter: @KatolaZ - skype: katolaz -- github: KatolaZ ] ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Devuan LXC Template: lxc-devuan
On Wed, Jun 01, 2016 at 12:55:42AM -0400, Greg Olsen wrote: > I very much appreciate the work that's being done by everyone here with > Devuan, and I thought it would be good to give back in some way. > > This is a little something for those who use, or want to use, Devuan LXC > containers. > > Recently I needed a quick reliable way to build Devuan LXC containers. I > couldn't find a template for Devuan in the upstream LXC repo, so I wrote one > myself (lxc-devuan). > > It works well for my purposes, so I decided to publish it as a project on > GitLab with the hope it might be useful to others. Appears to work for me. If you think the template is done, please submit it upstream: https://linuxcontainers.org/lxc/contribute/ -- An imaginary friend squared is a real enemy. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Custom OS initiator. In need of some hints...
Hi, Many thanks for your replies especially for: https://felipec.wordpress.com/2013/11/04/init/ Edward On 13/06/2016, Didier Kryn wrote: > Le 13/06/2016 08:16, Edward Bartolo a écrit : >> Hi, >> >> This is a question about implementing a minimal OS initiator. If >> DNG's admins/mods deem this email is misplaced please delete it or >> ignore it. >> >> Till now, I implemented a little OS initiator that calls "/bin/bash" >> and then enters an infinite while loop that does nothing. The loop's >> purpose is to prevent PID 1 from exiting. >> >> I would like to have my OS initiator: >> a) initiate a terminal before launching it. /sbin/init launches six >> such terminals tty1..tty6 >> b) prevent this terminal from closing >> c) do some basic child process management > > Here's something you could try: > > mount -t proc proc /proc > mount -t sysfs sys /sys > mount -t devtmpfs dev /dev # or mount /dev as tmpfs and start > hotplugger (udev/eudev/vdev/mdev) > mount -t tmpfs run /run > mknod -m 0600 /dev/console c 5 1 > mknod -m 0660 /dev/tty1c 4 1 > while ( true ) > do > printf 'Entering interactive shell\n' > setsid /bin/sh -c 'exec bash /dev/tty1 2>&1' > done; > > Have fun. > Didier > > ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
[DNG] task-lxde-desktop 3.33+devuan0.3
Sorry if i am coming back to task-lxde-desktop: Finally - and i really do not understand how, but anyway - i succeeded installin devuan ascii on qemu. I did not install any desktop, but started from the base installation and installed manually xorg, jwm, menu and lxdm. Now, looking for lxsession-logout tool (which i did not find btw!?!?) i checked task-lxde-desktop and i see it pulls in lots of dependencies which imho are *NOT* needed: - yelp - yelp-xsl - gnome-user-guide - gnome-desktop3-data - gnome-disk-utility - gnome-icon-theme - gnome-system-tools is what i note at a first glance (gnome-orca is there too, but i'm not aware of an alternative). Very likely, there are others too ... Cheers. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
[DNG] missing linefeed in libffi6:amd64
Trying to install the gtk2 engines i' am getting the following error msg: - There is missing a final linefeed in the filelisting file of the package E: Sub-process /usr/bin/dpgk returned an error code (2) - ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] secure boot
On Sun, Jun 12, 2016 at 05:49:11PM +0200, Didier Kryn wrote: > Le 12/06/2016 17:08, Simon Hobson a écrit : > >Hendrik Boom wrote: > > > >>How *do* we deal with secure boot? I am terrified of buying a new > >>machine because I'm afraid I won't get to install anything on it > >>wxcept for an OS from one of the big companies that have > >>sweetheart deals with Microsoft. > >Well (under UK law at least, other EU countries should have something > >equivalent, dunno about other places ...) you mention when buying it that > >you intend to install (say) Devuan Linux. If it can't run it, and the vendor > >didn't warn you at time of purchase, then you can insist that they : repair > >it, replace it, or refund it. > >That's basic consumer protection legislation, required by EU directive and > >implemented by national laws in each EU country. > > > The dealer will just be instructed to not sell it to people who > claim they will do anything else than using the pre-installed > Windows. They don't care our tiny market segment. Even asking whether it will run Linux isn't enough now that there are a few megacorp Linux purveyors that are signed up to the new restrictions. -- hendrik ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] LXC template for Devuan
KatolaZ writes:
> On Fri, Jun 10, 2016 at 09:39:49AM -0400, Greg Olsen wrote:
>> On 2016-06-10 08:59, Simon Walter wrote:
>>[snip]
>> > > I will give the templates a go now.
>>
>> >I had some issues:
>> >perl: warning: Setting locale failed.
>> >perl: warning: Please check that your locale settings:
>> >LANGUAGE = "en_US:en",
>> >LC_ALL = (unset),
>> >LANG = "en_US.UTF-8"
>> >are supported and installed on your system.
>> >perl: warning: Falling back to the standard locale ("C").
>> >
>> >Over ten times repeated, but more importantly:
>>
>> Simon, thanks for testing.
>>
>> I think the locale just isn't setup yet at that early point.
>> Perhaps a Perl expert can opine?
>>
>
> I have had those messages on a server for the best part of the last 9
> years, just to checl whether those stupid warning actually meant to be
> serious. It's just perl which complains because you have not set the
> locale properly.
The message means that using a certain locale has been requested by
setting the LANGUAGE and LANG environment variables to its name but that
it can't really be used because the compiled locale definitions for the
requested locale aren't available. The two obvious ways to deal with
that would be
- change the requested locale to one that's actually supported
(/etc/locale.gen contains the so-far created one) or to C to
use the POSIX locale
- generate the locales
The source files used for these reside in /usr/share/i18n and the file
containg the compiled equivalents is /usr/lib/locale/locale-archive. An
LXC-container could use a read-only bind mount to get access to the
locale-archive file of the host.
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] task-lxde-desktop 3.33+devuan0.3
On Mon, 13 Jun 2016 14:47:13 +0200, Emninger wrote: [...] > Now, looking for lxsession-logout tool (which i did not > find btw!?!?) It is provided by the lxsession package. > i checked task-lxde-desktop and i see it pulls in lots of > dependencies which imho are *NOT* needed: > > - yelp > - yelp-xsl > - gnome-user-guide > - gnome-desktop3-data > - gnome-disk-utility > - gnome-icon-theme > - gnome-system-tools 1. Those are not "hard" dependencies, they're "Recommends", most of them even pulled in recursively by other recommended packages (yelp, for example). 2. None of them is referenced by task-lxde-desktop directly, but by the very lxde package itself (and its dependencies)! 3. You can avoid installing (most of) it by using the apt-get option --no-install-recommends — or even configure apt to always leave those out by putting APT::Install-Recommends "0"; in a file in /etc/apt/apt.conf.d . 4. The *real* pain in the rear WRT lxde are some of the actual "Depends" in the lxde package, e.g. galculator. But I'm repeating myself, so I'll stop here. ;-) Bottom line: If you want a lean desktop environment, do not use *any* of the metapackages. Instead, install only the components you actually intend to use (and their actual "Depends", of course). In the process, leave out any "Recommends". If, at a later time, you find some of those recommended packages might actually be useful to you, you simply install them separately. HTH, Regards Urban ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] ..another new(?) step towards Debian systemd: linux-image-4.6.0-1[-rt]-amd-signed, with MSTF keys...
On Sun, 12 Jun 2016 18:00:13 +0200 Edward Bartolo wrote: > Hi, > > In line with: << > That way only the big distros will be able to provide a bootable OS > and the poor DIY guy will be definitely disgusted. This EFI thingy > will in no way improve the security. It is a pure fallacy. > > We can survive as long as the BIOS allows non-EFI boot. I hope > they will be forced by law to keep this option. > >> > > I have been 'told' that any kernel can still be booted under UEFI > Secure Boot. This was told to me on forurms.debian.net. The respondent > insisted any kernel can be booted even custom compiled ones. > > Refer to forums.debian.net thread: > http://forums.debian.net/viewtopic.php?p=609579&sid=c65ab3dc5f980e0c1f79b7b7a5116511#p609579 > > Edward Hi Edward, How can I put this politely? Let's try this... Most of those remaining in the Debian user world are pure idiots. They'll pull any old pseudofact out of thin air, and state it as an absolute truth. Notice that his web reference's date is October 2012. Last time I googled this subject (probably 9 months ago), DIY secure boot overrides, whether involving this Linux Foundation hack or not, were much more complex than installing Gentoo. They had more steps than an Arch chroot install. They were a mess. I've seen no distro-independent way to defeat secure-boot that was simple enough for a power user: A guy who can install his own software via ./configure;make;make install, configure his applications, change window managers, etc, but is not a professional admin. SteveT SteveT Steve Litt June 2016 featured book: Troubleshooting: Why Bother? http://www.troubleshooters.com/twb ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] ..another new(?) step towards Debian systemd: linux-image-4.6.0-1[-rt]-amd-signed, with MSTF keys...
Hi, SteveT wrote: << Most of those remaining in the Debian user world are pure idiots. They'll pull any old pseudofact out of thin air, and state it as an absolute truth. Notice that his web reference's date is October 2012. Last time I googled this subject (probably 9 months ago), DIY secure boot overrides, whether involving this Linux Foundation hack or not, were much more complex than installing Gentoo. They had more steps than an Arch chroot install. They were a mess. I've seen no distro-independent way to defeat secure-boot that was simple enough for a power user: A guy who can install his own software via ./configure;make;make install, configure his applications, change window managers, etc, but is not a professional admin. >> But I still am convinced with a signed kernel one can still use it to boot any installed OS. My reasoning goes like this: once the signed kernel boots, it would be in control of the machine. A running kernel can be used to run any executable provided the latter is coded for the same machine architecture. So, the boot procedure would first consist of UEFI loading the signed kernel, the kernel then loads a bootloader like GRUB*. What do you think? It may look an ugly workaround like most workarounds, but there is no logic why it should fail. Edward On 13/06/2016, Steve Litt wrote: > On Sun, 12 Jun 2016 18:00:13 +0200 > Edward Bartolo wrote: > >> Hi, >> >> In line with: << >> That way only the big distros will be able to provide a bootable OS >> and the poor DIY guy will be definitely disgusted. This EFI thingy >> will in no way improve the security. It is a pure fallacy. >> >> We can survive as long as the BIOS allows non-EFI boot. I hope >> they will be forced by law to keep this option. >> >> >> >> I have been 'told' that any kernel can still be booted under UEFI >> Secure Boot. This was told to me on forurms.debian.net. The respondent >> insisted any kernel can be booted even custom compiled ones. >> >> Refer to forums.debian.net thread: >> http://forums.debian.net/viewtopic.php?p=609579&sid=c65ab3dc5f980e0c1f79b7b7a5116511#p609579 >> >> Edward > > Hi Edward, > > How can I put this politely? Let's try this... > > Most of those remaining in the Debian user world are pure idiots. > They'll pull any old pseudofact out of thin air, and state it as an > absolute truth. > > Notice that his web reference's date is October 2012. Last time I > googled this subject (probably 9 months ago), DIY secure boot > overrides, whether involving this Linux Foundation hack or not, were > much more complex than installing Gentoo. They had more steps than an > Arch chroot install. They were a mess. > > I've seen no distro-independent way to defeat secure-boot that was > simple enough for a power user: A guy who can install his own software > via ./configure;make;make install, configure his applications, change > window managers, etc, but is not a professional admin. > > SteveT > > > SteveT > > Steve Litt > June 2016 featured book: Troubleshooting: Why Bother? > http://www.troubleshooters.com/twb > ___ > Dng mailing list > Dng@lists.dyne.org > https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng > ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] ..another new(?) step towards Debian systemd: linux-image-4.6.0-1[-rt]-amd-signed, with MSTF keys...
Hi SteveT, GRUB2 has a small kernel, on can always replace that with a full blown signed kernel and this would not introduce another step in the boot procedure. Edward On 13/06/2016, Edward Bartolo wrote: > Hi, > > SteveT wrote: > << > Most of those remaining in the Debian user world are pure idiots. > They'll pull any old pseudofact out of thin air, and state it as an > absolute truth. > > Notice that his web reference's date is October 2012. Last time I > googled this subject (probably 9 months ago), DIY secure boot > overrides, whether involving this Linux Foundation hack or not, were > much more complex than installing Gentoo. They had more steps than an > Arch chroot install. They were a mess. > > I've seen no distro-independent way to defeat secure-boot that was > simple enough for a power user: A guy who can install his own software > via ./configure;make;make install, configure his applications, change > window managers, etc, but is not a professional admin. >>> > > But I still am convinced with a signed kernel one can still use it to > boot any installed OS. My reasoning goes like this: once the signed > kernel boots, it would be in control of the machine. A running kernel > can be used to run any executable provided the latter is coded for the > same machine architecture. So, the boot procedure would first consist > of UEFI loading the signed kernel, the kernel then loads a bootloader > like GRUB*. > > What do you think? It may look an ugly workaround like most > workarounds, but there is no logic why it should fail. > > Edward > > On 13/06/2016, Steve Litt wrote: >> On Sun, 12 Jun 2016 18:00:13 +0200 >> Edward Bartolo wrote: >> >>> Hi, >>> >>> In line with: << >>> That way only the big distros will be able to provide a bootable OS >>> and the poor DIY guy will be definitely disgusted. This EFI thingy >>> will in no way improve the security. It is a pure fallacy. >>> >>> We can survive as long as the BIOS allows non-EFI boot. I hope >>> they will be forced by law to keep this option. >>> >> >>> >>> I have been 'told' that any kernel can still be booted under UEFI >>> Secure Boot. This was told to me on forurms.debian.net. The respondent >>> insisted any kernel can be booted even custom compiled ones. >>> >>> Refer to forums.debian.net thread: >>> http://forums.debian.net/viewtopic.php?p=609579&sid=c65ab3dc5f980e0c1f79b7b7a5116511#p609579 >>> >>> Edward >> >> Hi Edward, >> >> How can I put this politely? Let's try this... >> >> Most of those remaining in the Debian user world are pure idiots. >> They'll pull any old pseudofact out of thin air, and state it as an >> absolute truth. >> >> Notice that his web reference's date is October 2012. Last time I >> googled this subject (probably 9 months ago), DIY secure boot >> overrides, whether involving this Linux Foundation hack or not, were >> much more complex than installing Gentoo. They had more steps than an >> Arch chroot install. They were a mess. >> >> I've seen no distro-independent way to defeat secure-boot that was >> simple enough for a power user: A guy who can install his own software >> via ./configure;make;make install, configure his applications, change >> window managers, etc, but is not a professional admin. >> >> SteveT >> >> >> SteveT >> >> Steve Litt >> June 2016 featured book: Troubleshooting: Why Bother? >> http://www.troubleshooters.com/twb >> ___ >> Dng mailing list >> Dng@lists.dyne.org >> https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng >> > ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
[DNG] Shim
Hi folks... Where can I find a *good* and *deep enough* explanation of what a "shim" is (in the context of systemd and EFI), but also *easy enough* to explain it to some colleagues at work? Thanks Noel er Envite binRBqUCRGrNw.bin Description: Clave PGP pública ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Custom OS initiator. In need of some hints...
On Mon, 13 Jun 2016 08:16:44 +0200 Edward Bartolo wrote: > Hi, > > This is a question about implementing a minimal OS initiator. If > DNG's admins/mods deem this email is misplaced please delete it or > ignore it. > > Till now, I implemented a little OS initiator that calls "/bin/bash" > and then enters an infinite while loop that does nothing. The loop's > purpose is to prevent PID 1 from exiting. > > I would like to have my OS initiator: > a) initiate a terminal before launching it. /sbin/init launches six > such terminals tty1..tty6 > b) prevent this terminal from closing > c) do some basic child process management > Edward, it sounds to me like you're building your own PID1 as a shellscript. If this is true, I salute you! Learning the ins and outs of PID1 and its relation to the rest of the init system is a process, and that process starts with the 16 lines (not counting blank lines) of C code at the bottom of the following post: http://ewontfix.com/14/ Your first task is to implement that in either sh or csh, and personally, I think it's very possible. You can look up the details of the C calls: They mostly relate to dealing with signals. Here are a few high level guides to this code: * See if (fork()) for (;;) wait(&status); ? That code is the infinite loop that keeps PID1 running forever, in a loop checking for new signals. * if (fork()) for (;;) wait(&status); splits the process into two processes: PID1 and a child. PID1 spins forever checking signals, while the child process drops through and eventually execs /etc/rc, or whatever you want to call the shellscript that handles bringing up processes. Your six tty1 thru tty6 get brought up by /etc/rc, NOT by PID1. * In my opinion, the best way to handle /etc/rc is to have it first do a few preliminary one-time early bringups, such as udev/vdev/eudev and maybe the network. Then /etc/rc can hand over control to either runit or s6, to supervise forever type processes such as tty1 thru tty6. * In my opinion, runit and s6 are so good that there's no use you or anyone else trying to write a replacement for them. Stick to rewriting PID1, in bash, and when you get it finished, please publicize it widely so others can follow in your footsteps. * You're not done when you've written /etc/rc and had it invoke runit or s6. You still need to write a shutdown shellscript. This script would do any special ordered shutdown such as downing apps before databases, databases before the network, etc. The final several lines of most home-brew shutdown scripts look something like the following, to guaranty you won't need an fsck or a journal recover after each reboot: killall5 -15; sleep 2 # Ask nicely killall5 -9; sleep 2 # They didn't comply, so murder them sync # Get everything written to disk swapoff -a# Cleanly shut down swap umount -a # Unmount everything mount -o remount,ro /dev/sda1 # System now readonly # Safe to halt /sbin/halt# Or /sbin/reboot * The shutdown script must be run manually to shut down, and doesn't respond to Ctrl+Alt+Del. Later, when you make your PID1 shellscript more like Suckless Init, it can respond to Ctrl+Alt+Del and to reboot signals. * Rich Felker's 16 line PID1 doesn't react to signals, it just dumps them on the floor. Later, when you've mastered Felker's algorithm, you can look at Suckless Init, an 83 line C program that does pretty much what Felker's program does, except it also handles appropriate signals and reaps zombies. But get Felker's working in /bin/sh first. If I were in your shoes (and actually I have been), for experimentation's sake I'd compile Rich Felker's init, possibly changing the location of the rc file, and call the compiled result /f By using the short name /f, it becomes very easy upon Grub to change the init to /f, and init to Felker. Next, I would have /etc/rc do nothing but run /bin/bash, or for Poetterized directory systems /usr/bin/sh. All this does is brings up a shell, in tty1, for you to look around. It's a proof of concept. With this bash shell on tty1 as a periscope, start trying mount -a and other stuff, find out what goes wrong, and make a shellscript to properly mount and instantiate things. Obviously, with this being experimental, you should have no encryption nor LVM nor RAID, and to the best of your ability, have a one partition filesystem plus a swap partition. Next I'd make my shutdown script, and make sure when shut down by the shutdown script, the next reboot invokes neither fsck nor journal recovery. Then I'd integrate either runit or s6, calling it from /etc/rc or the shellscript invoked by /etc/rc to get everything mounted. Then I'd fool around with the system for awhile, making sure it's useable to a degree. Then I'd code a shellscript plug replacement for the Felker PID1, plug it in, and see if it
Re: [DNG] ..another new(?) step towards Debian systemd: linux-image-4.6.0-1[-rt]-amd-signed, with MSTF keys...
Edward Bartolo wrote: > But I still am convinced with a signed kernel one can still use it to > boot any installed OS. My reasoning goes like this: once the signed > kernel boots, it would be in control of the machine. A running kernel > can be used to run any executable provided the latter is coded for the > same machine architecture. So, the boot procedure would first consist > of UEFI loading the signed kernel, the kernel then loads a bootloader > like GRUB*. > > What do you think? Yes, it can be done. No it's not something your average user could do on his own. What you point out is the weakness of signing code - if that code isn't itself "secure" then it defeats the point of signing anything. So long term, not this year, probably not next year, but sometime ... expect some pressure to extend the signing. The first step will be signing of kernel binaries in distros, then some extra code in Grub to only load signed kernels - and only versions of Grub built that way will get signed. So now we've reached the point of only being able to use a Grub that will only load signed kernels. And only 'clean' kernel binaries will get signed - so no "non-approved" drivers. And if that bit of wedge gets hammered in without too much pushback ... The next step will be to add kernel code to only run signed binaries - but it'll be OK for the likes of RH because you'll have no reason to run anything other than the binaries they supply for packages. Yes, you can build a Grub that will load any kernel - but the EFI won't load it as it won't be signed. And expect it to get harder to add your own sigs to EFI systems as well. And all in the name of "security". Rrriiight. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Shim
On Mon, 13 Jun 2016 19:37:44 +, Noel wrote in message <20160613193744.horde.6as5qe3gnqf8zk7lci_w...@rolamasao.org>: > Hi folks... > > Where can I find a *good* and *deep enough* explanation of what a > "shim" is (in the context of systemd and EFI), but also *easy > enough* to explain it to some colleagues at work? ..I only know the banana republic politics part of this. ..does your colleagues know how banana republic politics works? ..do you know how banana republic politics works? Do you know it well enough to explain it to your colleagues? ..are you ok with them viewing you as a crack head conspiracy theorist until they know, or get get first hand experience the hard way themselves? ..good luck, you'll need it! -- ..med vennlig hilsen = with Kind Regards from Arnt Karlsen ...with a number of polar bear hunters in his ancestry... Scenarios always come in sets of three: best case, worst case, and just in case. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Shim
On Mon, 13 Jun 2016 19:37:44 +, Noel Torres wrote: > Hi folks... > > Where can I find a *good* and *deep enough* explanation of what a > "shim" is https://en.wikipedia.org/wiki/Shim_%28computing%29 In short: A shim is an adaptation or compatibility layer that enables software to use functionalities of other components not actually present on the system (or present, but in an older version, or the like). It does so by providing the desired functionality itself, or mapping it to other third party libraries, or simply by faking it. A typical example would be a "thin" wrapper library that maps one API (-version) onto another API (-version). (In technical engineering context, a shim is generally some kind of lining plate or metal spacer (e.g. a simple washer) used to mechanically adapt pieces of machinery or equipment.) > (in the context of systemd and EFI), The systemd-shim package in debian allows software to use systemd functionality without the need of actually having systemd installed and running as PID1 on the system. Not sure about the (U)EFI context. I assume it would be a signed bootloader that allows some kind of chain-loading other arbitrary (unsigned) OS kernels. > but also *easy enough* > to explain it to some colleagues at work? That would depend on where you work, and how well educated your coworkers are. ;-D HTH, Regards Urban ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] ..another new(?) step towards Debian systemd: linux-image-4.6.0-1[-rt]-amd-signed, with MSTF keys...
On Mon, Jun 13, 2016 at 09:14:00PM +0200, Edward Bartolo wrote: > But I still am convinced with a signed kernel one can still use it to > boot any installed OS. My reasoning goes like this: once the signed > kernel boots, it would be in control of the machine. A running kernel > can be used to run any executable provided the latter is coded for the > same machine architecture. So, the boot procedure would first consist > of UEFI loading the signed kernel, the kernel then loads a bootloader > like GRUB*. Not anymore. Any syscalls and devices that can be used to subvert the system by its owner, even as root, are disabled when Secure Boot is in use. So sorry, no kexec or loading a bootloader module unless the kernel being kexeced is itself signed. -- An imaginary friend squared is a real enemy. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Custom OS initiator. In need of some hints...
On Mon, 13 Jun 2016 15:47:49 -0400, Steve Litt wrote: [...] > Then I'd write a shellscript workalike for Suckless Init. In my > opinion, once you've done that, you should publicize it like the Autumn > leaves, because you've done a service to all of Linuxdom, and you've > especially done a service to Devuan, whose root story is that init > should be simple. [...] I'm probably missing something important here, so I have to ask: What would be the point in replacing an easily comprehensible, self-contained and statically linked piece of code[1] by some script, howsoever simple, that relies on an (in comparison) gigantic and potentially buggy blob like a shell[2]? To me that's not exactly KISS. Does your mileage vary that much, or am I simply missing the point? [1] E.g. Felker's init, or one of it's variations. [2] Dynamically linked bash would be the worst case scenario here, I believe. Mksh linked statically with musl-libc would be a much safer bet, but IMHO still far from ideal. Regards Urban ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] ..another new(?) step towards Debian systemd: linux-image-4.6.0-1[-rt]-amd-signed, with MSTF keys...
Am Montag, 13. Juni 2016 schrieb Adam Borowski: > On Mon, Jun 13, 2016 at 09:14:00PM +0200, Edward Bartolo wrote: > > But I still am convinced with a signed kernel one can still use it to > > boot any installed OS. My reasoning goes like this: once the signed > > kernel boots, it would be in control of the machine. A running kernel > > can be used to run any executable provided the latter is coded for the > > same machine architecture. So, the boot procedure would first consist > > of UEFI loading the signed kernel, the kernel then loads a bootloader > > like GRUB*. > > Not anymore. Any syscalls and devices that can be used to subvert the > system by its owner, even as root, are disabled when Secure Boot is in > use. So sorry, no kexec or loading a bootloader module unless the kernel > being kexeced is itself signed. > Broken computers for a broken world. -- Please do not email me anything that you are not comfortable also sharing with the NSA. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Custom OS initiator. In need of some hints...
Le 13/06/2016 22:49, Irrwahn a écrit : On Mon, 13 Jun 2016 15:47:49 -0400, Steve Litt wrote: [...] Then I'd write a shellscript workalike for Suckless Init. In my opinion, once you've done that, you should publicize it like the Autumn leaves, because you've done a service to all of Linuxdom, and you've especially done a service to Devuan, whose root story is that init should be simple. [...] I'm probably missing something important here, so I have to ask: What would be the point in replacing an easily comprehensible, self-contained and statically linked piece of code[1] by some script, howsoever simple, that relies on an (in comparison) gigantic and potentially buggy blob like a shell[2]? To me that's not exactly KISS. Does your mileage vary that much, or am I simply missing the point? [1] E.g. Felker's init, or one of it's variations. [2] Dynamically linked bash would be the worst case scenario here, I believe. Mksh linked statically with musl-libc would be a much safer bet, but IMHO still far from ideal. Regards Urban Sure. But a shell-script init is a nice toy to explore the early OS, specially if it can run an interactive shell. It would become a big tangle if the intent was to wait() the zombies or "supervise" more than one other process :-) As long as this script does not make overly complex things (for a script) like supervision and trapping signals, it remains pretty small. When comparing to the executable produced by a compiled program, I'm not sure the small difference matters. You don't have to count the size of the interpreter and the dynamic library, since they are part of the system anyway. If your system is so tiny that it only runs Busybox, then you still have an interpreter. Didier ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Custom OS initiator. In need of some hints...
On Mon, 13 Jun 2016 23:49:45 +0200, Didier Kryn wrote: > Le 13/06/2016 22:49, Irrwahn a écrit : [...] >> I'm probably missing something important here, so I have >> to ask: What would be the point in replacing an easily >> comprehensible, self-contained and statically linked piece >> of code[1] by some script, howsoever simple, that relies >> on an (in comparison) gigantic and potentially buggy blob >> like a shell[2]? [...] > Sure. But a shell-script init is a nice toy to explore the early > OS, specially if it can run an interactive shell. It would become a big > tangle if the intent was to wait() the zombies or "supervise" more than > one other process :-) I acknowledge the toy character. And I intentionally didn't mention the obvious problems of child process handling from within a shell script, but you are of course right here. > As long as this script does not make overly complex things (for a > script) like supervision and trapping signals, it remains pretty small. > When comparing to the executable produced by a compiled program, I'm not > sure the small difference matters. You don't have to count the size of > the interpreter and the dynamic library, since they are part of the > system anyway. If your system is so tiny that it only runs Busybox, then > you still have an interpreter. I was not so much concerned about the actual size in bytes, but more with the unnecessary complexity and potential lack of robustness, which I would not expect to see in the PID1 process. For one thing, dynamic linking IMO is already a big boo-boo in PID1, for it makes it far to easy to hose the whole system. Personally, I'd really love to have at least the PID1 executable, [a]getty and one emergency shell statically linked. But maybe lately I'm just becoming overly paranoid and extreme in my views on such matters. Sidenote: Even busybox, which in its static incarnation is what drives an Debian initrd IIRC and therefore in principle fulfills my requirement above, is IMVHO not the be-all and end-all in early userspace handling. Too bad Rob Landley's Toybox is not yet quite complete enough to be ready for primetime WRT system initialization, at least in my book. Anyways, thanks for your input, Didier! :) Regards Urban ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
[DNG] maintainers resource for Devuan
This is a bit of itch scratching on my part but hopefully can become useful to people wondering how to help out with devuan packaging. Just the basics here and an unofficial list of packages that haven't had systemd removed yet, can't catch all of these as I can only tell what is on github and don't know the details of each package there. https://git.devuan.org/dev1fanboy/Upgrade-Install-Devuan/wikis/maintainer-resource Feel free to mention anything that should be included. Cheers, chillfan -- Take back your privacy. Switch to www.StartMail.com ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] package request
It would be nice to have palemoon, they are pretty open to choice and are specifically against adding any DRM support in their browser. Also, it works with XUL and doesn't have the bloat that Iceweasel does that is annoying people in later releases. I have heard Debian will follow the ESR releases (even in stable) so avoiding any of that whilst having a non chrom(e|ium) browser will be harder if that's true. Only issue with pale moon is the branding: https://www.palemoon.org/branding.shtml Not sure if that's compatible with the main repo, maybe it needs rebranding first? Cheers, chillfan On Friday, June 10, 2016 2:16 PM, emnin...@riseup.net wrote: > Would it be possible to package palemoon for devuan? > > Since a while, i am unhappy with firefox/iceweasel and trying here and > there i found that, from a users point of view, palemoon would be a > very valid and viable substitute. > > As far as i am able to check, most, if not all privacy related settings > in "about:config" were well set (towards more privacy protection); the > same goes for - imho - essential extensions like https-everywhere or > NoScript. In the all day use the browser feelss faster and more > responsive than firefox. > > Since there is also a mobile version, i think palemoon could be really > used as the main browser. > > [PS. There are several ways to migrate from firefox to palemoon without > loosing anything but unfortunately the sync service does *NOT* work > across the 2 browsers] > ___ > Dng mailing list > Dng@lists.dyne.org > https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng -- Take back your privacy. Switch to www.StartMail.com ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] LXC template for Devuan
Hi Folks, I just pushed an update to lxc-devuan. This adds support for LXC versions <= 1.0.8. LXC version 1.1.0 came with the updated config that caused the previous problem. Greg ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] LXC template for Devuan
On 2016-06-13 01:28, Simon Walter wrote: [snip] > > This might be a bit surprising but I actually wrote lxc-devuan with > > *non-Devuan* OS's in mind. To not discourage people from running Devuan, > > it automatically downloads and uses the Devuan keyring. Without that > > capability it won't get past square one on a non-Devuan OS, and the user > > is likely to mumble some not so nice things about Devuan. Something to > > be avoided if at all possible. > > It seems to be fine with the 'auto' sub domain maybe because the keys > are registered for that domain name. Are you saying that those keys are > pre-installed on the image? If that's the case, I think we should make > two versions, that are based on the same source - an include or > something. One to be used on Devuan, one to be used by other distros > that want to run Devuan containers. The issue isn't the domain and there's no pre-installed image. It's a chicken and egg problem to bootstrap the keyring to validate the signed packages. Assume install on a foreign OS. The foreign OS probably won't have a Devuan keyring. When running debootstrap, among the packages it will download is the keyring package. When it goes to validate the download (which includes the keyring package), it doesn't have a key to validate, so it fails with "Release signed by unknown key". [snip] > I've made an account on git.devuan.org (user: smwltr) How do you want to > do this? Shall I fork your repo and apply a patch and then send you a > pull request? After a look maybe the solution will present itself. I > guess the .conf files too. Hi Simon, For now we can work it that way. I just pushed an update that adds support for LXC <= 1.0.8. The README is updated to use ./config-1.0.8 for LXC <= 1.0.8 The existing ./config directory is for LXC >= 1.1.0 It'll be great if you'll test again. So if you've already forked, please fetch and rebase. Thanks Greg ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] LXC template for Devuan
On 2016-06-13 08:23, Jaromil wrote: > we can create a group (named lxc?) and make you admins for it, or > simply a single project as there may be no need for more packages. > > i'm cc: hellekin to stimulate a quicker response on what should be the > naming scheme, since so far it has been curated with great attention > to be meaningful. to me it makes sense to have something like > 'virtualization-' as a prefix for repositories like lxc, but I'm also > not sure what else would fall in there. A generic name seems better. But I'm OK with whatever you think is appropriate. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] LXC template for Devuan
On 06/14/2016 09:26 AM, Greg Olsen wrote: On 2016-06-13 01:28, Simon Walter wrote: [snip] > > This might be a bit surprising but I actually wrote lxc-devuan with > > *non-Devuan* OS's in mind. To not discourage people from running Devuan, > > it automatically downloads and uses the Devuan keyring. Without that > > capability it won't get past square one on a non-Devuan OS, and the user > > is likely to mumble some not so nice things about Devuan. Something to > > be avoided if at all possible. > > It seems to be fine with the 'auto' sub domain maybe because the keys > are registered for that domain name. Are you saying that those keys are > pre-installed on the image? If that's the case, I think we should make > two versions, that are based on the same source - an include or > something. One to be used on Devuan, one to be used by other distros > that want to run Devuan containers. The issue isn't the domain and there's no pre-installed image. It's a chicken and egg problem to bootstrap the keyring to validate the signed packages. Well, maybe I didn't say it correctly. Is there already a devuan-keyring package on the iso-image? If so, that would explain why it works fine when the "host" is a Devuan installation. My personal opinion is that keys should not be automatically downloaded and installed. But I am a bit paranoid. Assume install on a foreign OS. The foreign OS probably won't have a Devuan keyring. When running debootstrap, among the packages it will download is the keyring package. When it goes to validate the download (which includes the keyring package), it doesn't have a key to validate, so it fails with "Release signed by unknown key". Yes. So, perhaps we have one script maintained for the Devuan OS and another for non-Devaun OSes, and they have most things in common. [snip] > I've made an account on git.devuan.org (user: smwltr) How do you want to > do this? Shall I fork your repo and apply a patch and then send you a > pull request? After a look maybe the solution will present itself. I > guess the .conf files too. Hi Simon, For now we can work it that way. I just pushed an update that adds support for LXC <= 1.0.8. The README is updated to use ./config-1.0.8 for LXC <= 1.0.8 The existing ./config directory is for LXC >= 1.1.0 It'll be great if you'll test again. So if you've already forked, please fetch and rebase. Nice. Sure thing. I will be testing it out soon. Kind regards, Simon ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] LXC template for Devuan
On 2016-06-13 13:42, Rainer Weikusat wrote:
> The message means that using a certain locale has been requested by
> setting the LANGUAGE and LANG environment variables to its name but that
> it can't really be used because the compiled locale definitions for the
> requested locale aren't available. The two obvious ways to deal with
> that would be
>
>
>
> The source files used for these reside in /usr/share/i18n and the file
> containg the compiled equivalents is /usr/lib/locale/locale-archive. An
> LXC-container could use a read-only bind mount to get access to the
> locale-archive file of the host.
Rainer,
Thank very much for the info.
In this case is was a timing issue of when lxc-devuan configures the
locale. It needed to be configured before the /usr/sbin/update-rc.d
commands. It was happening after that.
I've since fixed by moving into a separate function and calling earlier:
configure_locale ()
{
if [ -z "$LANG" ]; then
cat >> $rootfs/etc/locale.gen << EOF
en_US.UTF-8 UTF-8
EOF
chroot $rootfs locale-gen
chroot $rootfs update-locale LANG=en_US.UTF-8
else
encoding=$(echo $LANG | cut -d. -f2)
chroot $rootfs sed -e "s/^# \(${LANG} ${encoding}\)/\1/" \
-i /etc/locale.gen 2> /dev/null
if ! grep -q ^${LANG}\ ${encoding} /etc/locale.gen ; then
cat >> $rootfs/etc/locale.gen << EOF
$LANG $encoding
EOF
fi
chroot $rootfs locale-gen
chroot $rootfs update-locale LANG=$LANG
fi
}
Greg
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Custom OS initiator. In need of some hints...
On Mon, 13 Jun 2016 10:19:43 +0200 Tomasz Torcz wrote: > On Mon, Jun 13, 2016 at 08:16:44AM +0200, Edward Bartolo wrote: > > Hi, > > > > This is a question about implementing a minimal OS initiator. If > > DNG's admins/mods deem this email is misplaced please delete it or > > ignore it. > > If you really want to create yet another init, I can recommend this > simple, step by step explanation of Linux' init responsibilities: > > https://felipec.wordpress.com/2013/11/04/init/ Edward, be aware that the preceding link represents a substantially different philosophy about init than Rich Felker's PID1 and Suckless Init PID1. The preceding link is *not* a minimal PID1. I could argue either philosophy (but in truth I like Felker's model). The thing I'd say to you is that if you're writing your first init, I'd have it *only* spawn /etc/rc and spin (and in real life listen for signals and act on them). Writing a PID1, writing the /etc/rc and the shutdown script, and connecting it to s6 or runit is quite enough work for a first stab. I'd keep PID1 ultra-simple on the first stab. Later you can make something more like the referenced link. SteveT Steve Litt June 2016 featured book: Troubleshooting: Why Bother? http://www.troubleshooters.com/twb ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] LXC template for Devuan
On 2016-06-14 00:39, Simon Walter wrote: > Well, maybe I didn't say it correctly. Is there already a devuan-keyring > package on the iso-image? It's a debootstrap install. There's no iso-image involved. > My personal opinion is that keys should not be automatically downloaded > and installed. But I am a bit paranoid. I understand your reservations. However it does **not** trust the keyring on the user system. It simply downloads it, issues a message it was downloaded, and then passes the keyring file to the debootstrap command for it to use validating packages. So it's completely safe. Greg ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Custom OS initiator. In need of some hints...
On Mon, 13 Jun 2016 11:02:12 +0200 Didier Kryn wrote: > Le 13/06/2016 08:16, Edward Bartolo a écrit : > > Hi, > > > > This is a question about implementing a minimal OS initiator. If > > DNG's admins/mods deem this email is misplaced please delete it or > > ignore it. > > > > Till now, I implemented a little OS initiator that calls "/bin/bash" > > and then enters an infinite while loop that does nothing. The loop's > > purpose is to prevent PID 1 from exiting. > > > > I would like to have my OS initiator: > > a) initiate a terminal before launching it. /sbin/init launches six > > such terminals tty1..tty6 > > b) prevent this terminal from closing > > c) do some basic child process management > > Here's something you could try: > > mount -t proc proc /proc > mount -t sysfs sys /sys > mount -t devtmpfs dev /dev # or mount /dev as tmpfs and start > hotplugger (udev/eudev/vdev/mdev) > mount -t tmpfs run /run > mknod -m 0600 /dev/console c 5 1 > mknod -m 0660 /dev/tty1c 4 1 > while ( true ) > do > printf 'Entering interactive shell\n' > setsid /bin/sh -c 'exec bash /dev/tty1 2>&1' > done; > > Have fun. > Didier And later, when Edward makes a real PID1, everything before the line about /dev/console comprises the first few statements of the /etc/rc shellscript. SteveT Steve Litt June 2016 featured book: Troubleshooting: Why Bother? http://www.troubleshooters.com/twb ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] ..another new(?) step towards Debian systemd: linux-image-4.6.0-1[-rt]-amd-signed, with MSTF keys...
On Mon, 13 Jun 2016 21:14:00 +0200 Edward Bartolo wrote: > But I still am convinced with a signed kernel one can still use it to > boot any installed OS. My reasoning goes like this: once the signed > kernel boots, it would be in control of the machine. A running kernel > can be used to run any executable provided the latter is coded for the > same machine architecture. So, the boot procedure would first consist > of UEFI loading the signed kernel, the kernel then loads a bootloader > like GRUB*. > > What do you think? It may look an ugly workaround like most > workarounds, but there is no logic why it should fail. Try it. If it turns out to be that easy, all of Linuxdom will give you a tickertape parade. By the way, I'm pretty sure the Grub would need to be signed too. SteveT Steve Litt June 2016 featured book: Troubleshooting: Why Bother? http://www.troubleshooters.com/twb ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Custom OS initiator. In need of some hints...
On Mon, 13 Jun 2016 22:49:27 +0200 Irrwahn wrote: > On Mon, 13 Jun 2016 15:47:49 -0400, Steve Litt wrote: > [...] > > Then I'd write a shellscript workalike for Suckless Init. In my > > opinion, once you've done that, you should publicize it like the > > Autumn leaves, because you've done a service to all of Linuxdom, > > and you've especially done a service to Devuan, whose root story is > > that init should be simple. > [...] > > I'm probably missing something important here, so I have > to ask: What would be the point in replacing an easily > comprehensible, self-contained and statically linked piece > of code[1] by some script, howsoever simple, that relies > on an (in comparison) gigantic and potentially buggy blob > like a shell[2]? > > To me that's not exactly KISS. Does your mileage vary that > much, or am I simply missing the point? Hi Urban, I failed to make my point. Let me try again... The one and only point in replacing an easily comprehensible, self-contained and statically linked piece of code by some script is for the purposes of demonstration and propaganda. Nobody in their right mind would permanently use a shellscript to PID1 a machine used to do actual work. Felker's PID1, and even more so Suckless Init, are system level C that aren't as comprehensible as /bin/sh or /bin/csh would be. Especially if Edward would comment liberally. Right now, Felker's PID1 is the acknowledged "Hello World" PID1. But as I remember you have to add an #include to get it to work with mainstream Linuxes, you have to get it to compile, and it's just not as understandable to non-C programmers. Hackers who might not know C are more able to put their own commands into the shellscript and see the result. And then there's the propaganda value. Over and over and over again, Lennart and the Redhats have told us how complex, do not touch, no user serviceable parts inside init systems are. And now we find that Edward Bartolo has used a couple shellscripts and some commands from runit to init a computer. It's priceless. Edward Bartolo > Lennart Poettering The preceding angle bracket means "greater than" Here's an article I wrote with a similar flavor: http://troubleshooters.com/linux/init/manjaro_experiments.htm#is_that_all_there_is So Urban, once again, the reasons for a shellscript PID1 are: * Learning * Demonstration and teaching * Propaganda For real systems doing real work, use a compiled PID1. SteveT Steve Litt June 2016 featured book: Troubleshooting: Why Bother? http://www.troubleshooters.com/twb ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] package request
On Tue, 14 Jun 2016 00:34:23 +0100 "dev1fanboy" wrote: > It would be nice to have palemoon, they are pretty open to choice and > are specifically against adding any DRM support in their browser. > Also, it works with XUL and doesn't have the bloat that Iceweasel > does that is annoying people in later releases. I have heard Debian > will follow the ESR releases (even in stable) so avoiding any of that > whilst having a non chrom(e|ium) browser will be harder if that's > true. > > Only issue with pale moon is the branding: > https://www.palemoon.org/branding.shtml > > Not sure if that's compatible with the main repo, maybe it needs > rebranding first? > > Cheers, > > chillfan Yeah, just call it Bright Star, and swap the pale moon graphic with a beaming star. Then write the author, let him know what you did, and let him know that if he'd like the publicity benefit of having a major distro package Palemoon as Palemoon, he can write Devuan an official letter giving us permanent non-exclusive right to use the name and graphic, and we'll be glad to accommodate him with the publicity. By the way, thanks to emninger's post, I've been using Palemoon as my main browser for almost a week, and it's head and shoulders better than ALL the rest. It's less bloaty than the other XUL browsers, and it's more stable than the webkit based browsers. SteveT Steve Litt June 2016 featured book: Troubleshooting: Why Bother? http://www.troubleshooters.com/twb ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Devuan LXC Template: lxc-devuan
On 2016-06-13 09:42, Adam Borowski wrote: > > Appears to work for me. > > If you think the template is done, please submit it upstream: > https://linuxcontainers.org/lxc/contribute/ > Hi Adam, Thanks very much for the feedback. I'm glad it worked for you! I just pushed an update with config to support for LXC <= 1.0.8. It also fixes a couple things in the template. Future container installs should look a cleaner with the new template. However there's no need to recreate existing containers. If you do happen to test with the new config/template, I'd sure appreciate hearing how it went. Yes, after some more testing I plan to submit upstream. Thanks. Greg ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] package request
Yeah it's a pretty great browser, rename/rebrand and it won't matter. Best to stay away from the whole "the brand is ours" thing. All one needs really is a graphic that looks like a moon or other various space "rock" and it'll be fine. Cheers, chillfan On Tuesday, June 14, 2016 2:57 AM, Steve Litt wrote: > On Tue, 14 Jun 2016 00:34:23 +0100 > "dev1fanboy" wrote: > >> It would be nice to have palemoon, they are pretty open to choice and >> are specifically against adding any DRM support in their browser. >> Also, it works with XUL and doesn't have the bloat that Iceweasel >> does that is annoying people in later releases. I have heard Debian >> will follow the ESR releases (even in stable) so avoiding any of that >> whilst having a non chrom(e|ium) browser will be harder if that's >> true. >> >> Only issue with pale moon is the branding: >> https://www.palemoon.org/branding.shtml >> >> Not sure if that's compatible with the main repo, maybe it needs >> rebranding first? >> >> Cheers, >> >> chillfan > > Yeah, just call it Bright Star, and swap the pale moon graphic with a > beaming star. Then write the author, let him know what you did, and let > him know that if he'd like the publicity benefit of having a major > distro package Palemoon as Palemoon, he can write Devuan an official > letter giving us permanent non-exclusive right to use the name and > graphic, and we'll be glad to accommodate him with the publicity. > > By the way, thanks to emninger's post, I've been using Palemoon as my > main browser for almost a week, and it's head and shoulders better than > ALL the rest. It's less bloaty than the other XUL browsers, and it's > more stable than the webkit based browsers. > > SteveT > > Steve Litt > June 2016 featured book: Troubleshooting: Why Bother? > http://www.troubleshooters.com/twb > ___ > Dng mailing list > Dng@lists.dyne.org > https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng -- Take back your privacy. Switch to www.StartMail.com ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] package request
Also I heard they do include some non restricted graphic in their sources as the default when building, the graphic they use in the binary builds is the one they use those terms for I believe. Cheers, chillfan On Tuesday, June 14, 2016 4:32 AM, dev1fanboy wrote: > Yeah it's a pretty great browser, rename/rebrand and it won't matter. Best > to stay away from the whole "the brand is ours" thing. All one needs > really is a graphic that looks like a moon or other various space "rock" > and it'll be fine. > > Cheers, > > chillfan > > On Tuesday, June 14, 2016 2:57 AM, Steve Litt > wrote: >> On Tue, 14 Jun 2016 00:34:23 +0100 >> "dev1fanboy" wrote: >> >>> It would be nice to have palemoon, they are pretty open to choice and >>> are specifically against adding any DRM support in their browser. >>> Also, it works with XUL and doesn't have the bloat that Iceweasel >>> does that is annoying people in later releases. I have heard Debian >>> will follow the ESR releases (even in stable) so avoiding any of that >>> whilst having a non chrom(e|ium) browser will be harder if that's >>> true. >>> >>> Only issue with pale moon is the branding: >>> https://www.palemoon.org/branding.shtml >>> >>> Not sure if that's compatible with the main repo, maybe it needs >>> rebranding first? >>> >>> Cheers, >>> >>> chillfan >> >> Yeah, just call it Bright Star, and swap the pale moon graphic with a >> beaming star. Then write the author, let him know what you did, and let >> him know that if he'd like the publicity benefit of having a major >> distro package Palemoon as Palemoon, he can write Devuan an official >> letter giving us permanent non-exclusive right to use the name and >> graphic, and we'll be glad to accommodate him with the publicity. >> >> By the way, thanks to emninger's post, I've been using Palemoon as my >> main browser for almost a week, and it's head and shoulders better than >> ALL the rest. It's less bloaty than the other XUL browsers, and it's >> more stable than the webkit based browsers. >> >> SteveT >> >> Steve Litt >> June 2016 featured book: Troubleshooting: Why Bother? >> http://www.troubleshooters.com/twb >> ___ >> Dng mailing list >> Dng@lists.dyne.org >> https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng > -- > Take back your privacy. Switch to www.StartMail.com > ___ > Dng mailing list > Dng@lists.dyne.org > https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng -- Take back your privacy. Switch to www.StartMail.com ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] package request
> On June 13, 2016 at 9:57 PM Steve Litt wrote: > > Only issue with pale moon is the branding: > > https://www.palemoon.org/branding.shtml > > > > Not sure if that's compatible with the main repo, maybe it needs > > rebranding first? > Yeah, just call it Bright Star, and swap the pale moon graphic with a > beaming star. Then write the author, let him know what you did, and let > him know that if he'd like the publicity benefit of having a major > distro package Palemoon as Palemoon, he can write Devuan an official > letter giving us permanent non-exclusive right to use the name and > graphic, and we'll be glad to accommodate him with the publicity. +10 I have an issue though with the non-exclusive right: it means anyone downstream from us has to drop the package or renegotiate. This is why there is Iceweasel instead of Firefox. Ask PM's maintainer what he really wants. It's work, but a systematic rebranding of Palemoon with another theme (not Bright Star :-) might be another idea. PM has already done it for Firefox, so it should be easy to figure out what to do. My vote: Europa. One of the coolest moons in the solar system. apt-cache search europa returns nothing. > By the way, thanks to emninger's post, I've been using Palemoon as my > main browser for almost a week, and it's head and shoulders better than > ALL the rest. It's less bloaty than the other XUL browsers, and it's > more stable than the webkit based browsers. My thanks also, I have been using it too. Peter Olson ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Custom OS initiator. In need of some hints...
On Mon, Jun 13, 2016 at 09:37:11PM -0400, Steve Litt wrote: [cut] > > Right now, Felker's PID1 is the acknowledged "Hello World" PID1. But as > I remember you have to add an #include to get it to work with > mainstream Linuxes, you have to get it to compile, and it's just not as > understandable to non-C programmers. > > Hackers who might not know C are more able to put their own commands > into the shellscript and see the result. > With all the due respect, anyone can put a few lines in a shell script or in a C code to create two devices and call rc. But we should be honest and tell Bartolo, and anybody else willing to go down this path, that this is not exactly "making a custom init", though, since what is normally intended as "init" needs to be a tad more complicated than that, if the intention is to make it useful outside a sandbox. My2Cents KatolaZ -- [ ~.,_ Enzo Nicosia aka KatolaZ - GLUGCT -- Freaknet Medialab ] [ "+. katolaz [at] freaknet.org --- katolaz [at] yahoo.it ] [ @) http://kalos.mine.nu --- Devuan GNU + Linux User ] [ @@) http://maths.qmul.ac.uk/~vnicosia -- GPG: 0B5F062F ] [ (@@@) Twitter: @KatolaZ - skype: katolaz -- github: KatolaZ ] ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
[DNG] SaltStack
Just wanted to pass the word, I installed SaltStack master on Devuan outside the repos (2014-01was kinda old) from the SaltStack installer and had no problems. Didn't even have to decompose systemd settings & setup an init.d script like I had to do with Plex. Wonder why SaltStack is so old in the deb repos but systemd is so up to date? SWS ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Custom OS initiator. In need of some hints...
On Mon, 13 Jun 2016 21:37:11 -0400, Steve Litt wrote: > On Mon, 13 Jun 2016 22:49:27 +0200 > Irrwahn wrote: [...] >> I'm probably missing something important here, so I have >> to ask: What would be the point in replacing an easily >> comprehensible, self-contained and statically linked piece >> of code[1] by some script, howsoever simple, that relies >> on an (in comparison) gigantic and potentially buggy blob >> like a shell[2]? >> >> To me that's not exactly KISS. Does your mileage vary that >> much, or am I simply missing the point? > > > Hi Urban, > > I failed to make my point. Let me try again... > > The one and only point in replacing an easily comprehensible, > self-contained and statically linked piece of code by some script is > for the purposes of demonstration and propaganda. Nobody in > their right mind would permanently use a shellscript to PID1 a machine > used to do actual work. That's what I hoped for, but you never know these days — we're living in strange times. There have reportedly been cases of people even trying to use systemd as the PID1 on machines used to do actual work. [...] > Right now, Felker's PID1 is the acknowledged "Hello World" PID1. But as > I remember you have to add an #include to get it to work with > mainstream Linuxes, Yup, #include , trivial. > you have to get it to compile, and it's just not as > understandable to non-C programmers. > > Hackers who might not know C are more able to put their own commands > into the shellscript and see the result. There's a point to be made about the value of actually learning C and understand how the real thing works. There are far to few good C programmers around these days, and their number is dwindling. But that's another topic altogether. Note: I had to restrain myself from expanding even more on your catchy notes about the propagandistic value; the result probably wouldn't have been appropriate for this (or any other) list, I ponder. [...] > So Urban, once again, the reasons for a shellscript PID1 are: > > * Learning > * Demonstration and teaching > * Propaganda Thanks Steve, got it. I just failed to see that that was the only intent in your original comments. > For real systems doing real work, use a compiled PID1. Nah, real programmers write $cat | xxd -r - /sbin/init HAND, Regards Urban ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] package request
On Tue, 14 Jun 2016 00:37:59 -0400 (EDT), Peter Olson wrote: [About possible branding issues for a hypothetical future Pale Moon package in De(vu|bi)an.] > This is why there is Iceweasel instead of Firefox. Not anymore. It's plain "firefox" from Ascii (=Stretch) on. [...] > My vote: Europa. One of the coolest moons in the solar system. apt-cache > search europa returns nothing. I suggest Ganymede. It's the largest moon in the solar system, and the mythology behind the name is also quite nice. Regards Urban ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] package request
> On June 14, 2016 at 1:43 AM Irrwahn wrote: > > On Tue, 14 Jun 2016 00:37:59 -0400 (EDT), Peter Olson wrote: > > [About possible branding issues for a hypothetical > future Pale Moon package in De(vu|bi)an.] > > > This is why there is Iceweasel instead of Firefox. > > Not anymore. It's plain "firefox" from Ascii (=Stretch) on. Well, I'm on Devuan Jessie. In Ascii, what are you really running? In Devuan Jessie, if I type firefox at the command prompt, it starts Iceweasel. Peter Olson ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] package request
On Tue, 14 Jun 2016 02:04:08 -0400 (EDT), Peter Olson wrote: > On June 14, 2016 at 1:43 AM Irrwahn wrote: >> On Tue, 14 Jun 2016 00:37:59 -0400 (EDT), Peter Olson wrote: >>> >>> This is why there is Iceweasel instead of Firefox. >> >> Not anymore. It's plain "firefox" from Ascii (=Stretch) on. > > Well, I'm on Devuan Jessie. > > In Ascii, what are you really running? Palemoon. SCNR; jokes aside: > In Devuan Jessie, if I type firefox at the command prompt, it starts > Iceweasel. From Debian Stretch (= Devuan Ascii) on there is no more Iceweasel, but just Firefox and Firefox-ESR. Quote from https://wiki.debian.org/Iceweasel: | As documented at the article The end of the Iceweasel Age[1], | Firefox is now in Debian again with the official name and | branding. | | At Mozilla's request (see 815006), Debian now contains Mozilla | “Firefox ESR” (Extended Support Release) as the firefox-esr | package. Normal Debian support policies, including patches for | bug fixes, apply to the package. | | [...] | | In Debian Stretch and later, the package iceweasel is a | transitional package which installs the firefox-esr package. | As of 9th of June, 2016 the package Firefox-ESR replaces | Iceweasel, and is in Wheezy and Jessie security repositories. [1] https://lwn.net/Articles/676799/ Purportedly discussion is underway to rename Icedove Thunderbird. Regards Urban ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Custom OS initiator. In need of some hints...
Hi,
I downloaded and compiled Felker's minimal init but found it didn't
work. Examining the code it seems that the website had been
vandalised. According to my logic the endless loops should be at the
end rather than at the middle of the code. Furthermore, the code seems
to first block signals then it enables them back afterwards
contradicting the text.
I am quoting the website:
http://ewontfix.com/14/
The C code for Felker's minimal init is:
-
#define _XOPEN_SOURCE 700
#include
#include
int main()
{
sigset_t set;
int status;
if (getpid() != 1) return 1;
sigfillset(&set);
sigprocmask(SIG_BLOCK, &set, 0);
if (fork()) for (;;) wait(&status);
sigprocmask(SIG_UNBLOCK, &set, 0);
setsid();
setpgid(0, 0);
return execve("/etc/rc", (char *[]){ "rc", 0 }, (char *[]){ 0 });
}
-
Edward
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
