Re: [DNG] Giving Devuan sans-initramfs capabilities

[aitor_czr]

On 01/06/2016 10:10 AM, Daniel Reurich  wrote:

choosing configuration is the hard part.


You are right :)

-- Aitor.
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Giving Devuan sans-initramfs capabilities

[karl]

Daniel Reurich:
> On 06/01/16 07:55, k...@aspodata.se wrote:
> > Rainer Weikusat:
> > ...
> >> The sensible way to handle this is really "the distribution ships a
> >> kernel which optionally supports everything" (via aggressive
> >> modularization) and people who think they want/ need more control over
> >> this part of the system can change that as they see fit (by compiling a
> >> custom kernel). Insofar someone feels his custom kernel is of more
> >> general use than just "run on this machine", the configuration could be
> >> shared via internet. It's even failrly easy to share the kernel itself:
> >> I posted a script I've been using since 1998 to build kernels for
> >> different machines on a dedicated one and for someone who likes "shot
> >> from behind trough the chest right into the eye" constructions, there's
> >> always kernel-package for creating custom-kernel Debian packages.
> > 
> > Building the kernel is easy, tools are provided (later kernels have a 
> > deb-pkg target), choosing configuration is the hard part.
> > 
> > Would it be sensible for devuan to set up a user contrib site where one 
> > can upload kerlnels and or configs, together with reasons why that 
> > config is choosen ?
> > 
> Sure, how about talk.devuan.org

kernel.devuan.org ?

Though it will depend of if and who will set it up.

Regards,
/Karl Hammar

---
Aspö Data
Lilla Aspö 148
S-742 94 Östhammar
Sweden
+46 173 140 57


___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Giving Devuan sans-initramfs capabilities

[karl]

Aitor:
> On 01/06/2016 10:10 AM, Daniel Reurich  wrote:
> > choosing configuration is the hard part.
> You are right :)

So then, it's there we should share our knowledge.

Regards,
/Karl Hammar

---
Aspö Data
Lilla Aspö 148
S-742 94 Östhammar
Sweden
+46 173 140 57


___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Giving Devuan sans-initramfs capabilities

[aitor_czr]

Hi Svante,

On 01/04/2016 11:00 PM, Svante Signell  wrote:

The more we need to have vdev debianised then! aitor_csr, can I help? What about
eudev?


Now i'm progressing in netman-gtk3. Shortly i will follow with vdev.

   Aitor.

@SteveT: I keep in mind to test your amounter :)

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Giving Devuan sans-initramfs capabilities

[Didier Kryn]

Le 05/01/2016 04:30, Simon Wise a écrit :

On 05/01/16 08:10, Svante Signell wrote:

On Mon, 2016-01-04 at 20:43 +, Rainer Weikusat wrote:

k...@aspodata.se writes:

chaosesquet...@cock.li:

I don't understand the desire to change it at all.


See UsrMerge discussion on debian-devel. They wan to move most stuff 
in / to
/usr and make it readonly. (The only sensible motivation I've found 
so far is

for NFS, but how many people use that?


It would seem to be a potentially useful tool in managing a fleet of 
locked-down desktops with the end users prevented from modifying their 
system.


It's frozen, like Knoppix. It's sometimes convenient, but it's not 
an evolving distro like Debian or RedHat. I imagine RedHat shipping a 
DVD to their clients for every security update or bug fix!


Didier

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Giving Devuan sans-initramfs capabilities

[karl]

Rainer Weikusat:
...
> The sensible way to handle this is really "the distribution ships a
> kernel which optionally supports everything" (via aggressive
> modularization) and people who think they want/ need more control over
> this part of the system can change that as they see fit (by compiling a
> custom kernel). Insofar someone feels his custom kernel is of more
> general use than just "run on this machine", the configuration could be
> shared via internet. It's even failrly easy to share the kernel itself:
> I posted a script I've been using since 1998 to build kernels for
> different machines on a dedicated one and for someone who likes "shot
> from behind trough the chest right into the eye" constructions, there's
> always kernel-package for creating custom-kernel Debian packages.

Building the kernel is easy, tools are provided (later kernels have a 
deb-pkg target), choosing configuration is the hard part.

Would it be sensible for devuan to set up a user contrib site where one 
can upload kerlnels and or configs, together with reasons why that 
config is choosen ?

Regards,
/Karl Hammar

---
Aspö Data
Lilla Aspö 148
S-742 94 Östhammar
Sweden
+46 173 140 57


___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Giving Devuan sans-initramfs capabilities

[Daniel Reurich]

On 06/01/16 07:55, k...@aspodata.se wrote:
> Rainer Weikusat:
> ...
>> The sensible way to handle this is really "the distribution ships a
>> kernel which optionally supports everything" (via aggressive
>> modularization) and people who think they want/ need more control over
>> this part of the system can change that as they see fit (by compiling a
>> custom kernel). Insofar someone feels his custom kernel is of more
>> general use than just "run on this machine", the configuration could be
>> shared via internet. It's even failrly easy to share the kernel itself:
>> I posted a script I've been using since 1998 to build kernels for
>> different machines on a dedicated one and for someone who likes "shot
>> from behind trough the chest right into the eye" constructions, there's
>> always kernel-package for creating custom-kernel Debian packages.
> 
> Building the kernel is easy, tools are provided (later kernels have a 
> deb-pkg target), choosing configuration is the hard part.
> 
> Would it be sensible for devuan to set up a user contrib site where one 
> can upload kerlnels and or configs, together with reasons why that 
> config is choosen ?
> 
Sure, how about talk.devuan.org



-- 
Daniel Reurich
Centurion Computer Technology (2005) Ltd.
021 797 722



signature.asc
Description: OpenPGP digital signature
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Giving Devuan sans-initramfs capabilities

[karl]

Katola2:
> On Mon, Jan 04, 2016 at 02:57:58AM -0500, Steve Litt wrote:
...
> there is really no magic skill involved. By using kernel-package the
> "skills" needed to do what you mention are just those needed to
> compile a standard kernel + invoking make-kpkg. There is also a
> relatively old howto here:
...

There is a new "howto":

 
https://www.debian.org/doc/manuals/debian-handbook/sect.kernel-compilation.en.html

basically, do (or some variation of):

 make menuconfig
 make deb-pkg

Regards,
/Karl Hammar

---
Aspö Data
Lilla Aspö 148
S-742 94 Östhammar
Sweden
+46 173 140 57


___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Giving Devuan sans-initramfs capabilities

[chaosesqueteam]

I don't understand the desire to change it at all.

We know where the kern modules are now, we've known for over a decade,
just leave it as it was.

If systemd wasn't, this wouldn't be talked about.
Which is why it shouldn't be discussed.

Don't let them pull you by the nose.
At all.

On 2016-01-04 16:43, Didier Kryn wrote:

Le 04/01/2016 17:32, Svante Signell a écrit :

On Mon, 2016-01-04 at 16:53 +0100, Didier Kryn wrote:

Le 04/01/2016 16:26, Hendrik Boom a écrit :

I meant
4) Let the installer build the kernel, depending on what the 
hardware

and
file systems being installed actually need.
  Maybe Gentoo does this, although I'm not sure, but the 
philosophy
is very different: they compile everything from source. And it 
doesn't

install as smoothly as Devuan.

  In Devuan it means something very unusual: the installer must 
first
install gcc, generate a config file and compile the kernel. It is not 
an
easy task to generate a working config for any hardware combination. 
The
resulting kernel package would be local and couldn't undergo 
upgrades.
Just an idea: Would it be possible to detect the hardware of each 
computer being
installed on and after that install the needed modules? Preferably the 
modules

should not be located on /usr, currently they are under /lib.


I don't understand the repulsion towards having the modules in
/usr/lib. What difference does it make? None, unless you want the
three following conditions: no initramfs, /usr being a mountpoint,
some drivers and filesystems compiled in the kernel, but missing just
the one for /usr. You've got to work pretty hard to fulfill these
conditions.

Didier


___
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] Giving Devuan sans-initramfs capabilities

[Rainer Weikusat]

k...@aspodata.se writes:
> chaosesquet...@cock.li:
>> I don't understand the desire to change it at all.
>
> And neither do I.
> Except someone talked about ssl libs.

Someone wrote about some PAM module which would require OpenSSL. No such
PAM module currently exists on my system and I don't quite understand
why 'PAM modules' would be needed for booting a system, anyway.

But udev wants to put its rules files below /usr by default and as far
as I know, changing this requires patching the code.
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Giving Devuan sans-initramfs capabilities

[Svante Signell]

On Mon, 2016-01-04 at 20:43 +, Rainer Weikusat wrote:
> k...@aspodata.se writes:
> > chaosesquet...@cock.li:
> > > I don't understand the desire to change it at all.

See UsrMerge discussion on debian-devel. They wan to move most stuff in / to
/usr and make it readonly. (The only sensible motivation I've found so far is 
for NFS, but how many people use that?

> > And neither do I.
> > Except someone talked about ssl libs.
> 
> But udev wants to put its rules files below /usr by default and as far
> as I know, changing this requires patching the code.

The more we need to have vdev debianised then! aitor_csr, can I help? What about
eudev?
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Giving Devuan sans-initramfs capabilities

[Florian Zieboll]

On Mon, 04 Jan 2016 17:32:26 +0100
Svante Signell  wrote:


> Just an idea: Would it be possible to detect the hardware of each
> computer being installed on and after that install the needed
> modules?


IIUC, exactly this hardware detection is already happening. Regarding the 
installation of the initramfs, the installer gives you the choice whether to 
include "all" or an adapted subset of modules. HTH / correct me if I'm wrong.

Regards,

Florian
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Giving Devuan sans-initramfs capabilities

[karl]

chaosesquet...@cock.li:
> I don't understand the desire to change it at all.

And neither do I.
Except someone talked about ssl libs.

> On 2016-01-04 16:43, Didier Kryn wrote:
...
> > I don't understand the repulsion towards having the modules in
> > /usr/lib. What difference does it make? None, unless you want the
> > three following conditions: no initramfs, /usr being a mountpoint,
> > some drivers and filesystems compiled in the kernel, but missing just
> > the one for /usr. You've got to work pretty hard to fulfill these
> > conditions.

If you have a desire to move /lib/modules why don't move it and 
everything you need to boot to /boot.

 From what I understand uefi requires some vfat (or ext2 for mbr) boot
partition first in disk. Then include ahci (which would handle the
majority of not to old sata disk controllers out there) and vfat in
the kernel. Mount /boot in your initrd and go from there. /boot can
always be mounted read-only unless when changing kernel and boot
things. Files in /boot don't need user id's nor unix permissions so
vfat is perfectly ok.

Regards,
/Karl Hammar

---
Aspö Data
Lilla Aspö 148
S-742 94 Östhammar
Sweden
+46 173 140 57


___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Giving Devuan sans-initramfs capabilities

[karl]

Rainer Weikusat:
> k...@aspodata.se writes:
> > chaosesquet...@cock.li:
> >> I don't understand the desire to change it at all.
> >
> > And neither do I.
> > Except someone talked about ssl libs.
> 
> Someone wrote about some PAM module which would require OpenSSL. No such
> PAM module currently exists on my system and I don't quite understand
> why 'PAM modules' would be needed for booting a system, anyway.
> 
> But udev wants to put its rules files below /usr by default and as far
> as I know, changing this requires patching the code.

Don't use udev so cannot check that. Perhaps time for devuan to switch 
to vdev, is it ready for prime time ?

Why don't udev place its rules close to the kernel modules directory, 
that would make more sense, or put them under /etc as is the 
conventional wisdom. But then, /etc-less systems are thought about:

http://0pointer.net/blog/projects/stateless.html

Regards,
/Karl Hammar

---
Aspö Data
Lilla Aspö 148
S-742 94 Östhammar
Sweden
+46 173 140 57


___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Giving Devuan sans-initramfs capabilities

[KatolaZ]

On Mon, Jan 04, 2016 at 02:57:58AM -0500, Steve Litt wrote:

[cut]

> 
> Thanks Joel,
> 
> With my particular skillset, I'd envision my involvement to be more of
> documentation somewhat like the Manjaro Experiments
> (http://www.troubleshooters.com/linux/init/manjaro_experiments.htm).
> With a description of how to set the thing up, others would try it, and
> if there's demand, somebody would do the magic necessary to bring it
> into the package manager.
> 

Steve, 

there is really no magic skill involved. By using kernel-package the
"skills" needed to do what you mention are just those needed to
compile a standard kernel + invoking make-kpkg. There is also a
relatively old howto here:

  http://newbiedoc.sourceforge.net/system/kernel-pkg.html

which might be still enough. 

My2Cents

KatolaZ

-- 
[ Enzo Nicosia aka KatolaZ --- GLUG Catania -- Freaknet Medialab ]
[ me [at] katolaz.homeunix.net -- http://katolaz.homeunix.net -- ]
[ GNU/Linux User:#325780/ICQ UIN: #258332181/GPG key ID 0B5F062F ]
[ Fingerprint: 8E59 D6AA 445E FDB4 A153 3D5A 5F20 B3AE 0B5F 062F ]
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Giving Devuan sans-initramfs capabilities

[Mitt Green]

Karl Hammar wrote:

>But then, /etc-less systems are thought about:
>[http://0pointer.net/blog/projects/stateles](http://0pointer.net/blog/projects/stateless.html)s.html

PulseAudio motto is "I'll break your audio",
Lennartd should be "I'll break your Unix".

What's next, I wonder. If they call it
"innovations", I'd rather stay in my cave.
We will end up with the kernel depending on systemd
one day.___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Giving Devuan sans-initramfs capabilities

[Arnt Karlsen]

On Mon,  4 Jan 2016 22:13:06 +0100 (CET), k...@aspodata.se wrote in
message <20160104211307.20a5d809d...@turkos.aspodata.se>:

> Rainer Weikusat:
> > k...@aspodata.se writes:
> > > chaosesquet...@cock.li:
> > >> I don't understand the desire to change it at all.
> > >
> > > And neither do I.
> > > Except someone talked about ssl libs.
> > 
> > Someone wrote about some PAM module which would require OpenSSL. No
> > such PAM module currently exists on my system and I don't quite
> > understand why 'PAM modules' would be needed for booting a system,
> > anyway.
> > 
> > But udev wants to put its rules files below /usr by default and as
> > far as I know, changing this requires patching the code.
> 
> Don't use udev so cannot check that. Perhaps time for devuan to
> switch to vdev, is it ready for prime time ?
> 
> Why don't udev place its rules close to the kernel modules directory, 
> that would make more sense, or put them under /etc as is the 
> conventional wisdom. But then, /etc-less systems are thought about:
> 
> http://0pointer.net/blog/projects/stateless.html

...which is also © Lennart Poettering. 
Let them systemd guys prove us wrong in the _long_ run. ;o) 

..in the short term, I'm pleasantly surprised to see more 
traffic here in devuan-* than in debian-user. ;oD

-- 
..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] Giving Devuan sans-initramfs capabilities

[Didier Kryn]

Le 04/01/2016 18:33, Svante Signell a écrit :

On Mon, 2016-01-04 at 17:43 +0100, Didier Kryn wrote:

Le 04/01/2016 17:32, Svante Signell a écrit :
Just an idea: Would it be possible to detect the hardware of each computer
being installed on and after that install the needed modules? Preferably the
modules should not be located on /usr, currently they are under /lib.
  
  I don't understand the repulsion towards having the modules in

/usr/lib. What difference does it make? None, unless you want the three
following conditions: no initramfs, /usr being a mountpoint, some
drivers and filesystems compiled in the kernel, but missing just the one
for /usr. You've got to work pretty hard to fulfill these conditions.

Well, the important part of my question was: "Would it be possible to detect the
hardware of each computer being installed on and after that install the needed
modules?"

Where the modules are located is very much under discussion here and on debian-
devel, see the "support for merged /usr in Debian" thread there. This is another
issue that could be discussed elsewhere here.

There are two places where a driver can be: either statically 
linked with the kernel, or in a loadable module. In the second case the 
kernel has some minimal interface to the driver that is to be 
dynamically loaded, and a mechanism to search and load the module from a 
file.


 There is one place for a file: within a file hierarchy. And a file 
hierarchy has the rootfs at its top, watever it is, a hard disk, a 
cdrom, a flash memory, or a ramdisk.


If there is an initramfs, then it is the rootfs, and the kernel 
launches init. Otherwise it must first mount the rootfs, which means 
that all the drivers needed to operate the disk and the partitions and 
perform the mount must be linked statically with the kernel

 (built-in).

It is possible to choose which drivers to have, either all 
possible, or just the ones necessary for the hardware, but they must be 
either statically linked with the kernel, or stored in files. In the 
absence of an initramfs, a minimal set of drivers must be statically 
linked with the kernel.


Didier

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Giving Devuan sans-initramfs capabilities

[Didier Kryn]

Le 04/01/2016 21:33, k...@aspodata.se a écrit :

If you have a desire to move /lib/modules why don't move it and
everything you need to boot to /boot.
I don't want to move anything. I just don't care. And I think it 
has nothing to do with Systemd, except it comes in the same time.


Didier

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Giving Devuan sans-initramfs capabilities

[Simon Wise]

On 05/01/16 08:10, Svante Signell wrote:

On Mon, 2016-01-04 at 20:43 +, Rainer Weikusat wrote:

k...@aspodata.se writes:

chaosesquet...@cock.li:

I don't understand the desire to change it at all.


See UsrMerge discussion on debian-devel. They wan to move most stuff in / to
/usr and make it readonly. (The only sensible motivation I've found so far is
for NFS, but how many people use that?


It would seem to be a potentially useful tool in managing a fleet of locked-down 
desktops with the end users prevented from modifying their system.


It would also be helpful if a vendor wanted to sell locked-down desktops without 
root access, the way Samsung does very profitably with their android systems ... 
using selinux to limit what the user can do ('owner' doesn't seem an accurate 
word for the person who acquires such a device, while that system remains in place).


Or perhaps set up a flock of virtual servers with shared read-only systems.

All of which are the kind of use-cases the people pushing the changes in debian 
hope to make $$$ from, and they are real and valid use-cases. But they are all 
the exact opposite of the original motivation for debian, GNU and everything 
most people here believe in. Instead those use-cases should be developed and 
maintained within the corporate budgets that hope to profit from them, within 
their own distributions ... Red Hat, Canonical etc.


It is very grim that Debian has allowed itself to be co-opted as a cheap 
resource for those companies, but really I do not believe that will be the 
outcome ... more likely it will just be knackered in a way which leaves less 
choice for the less sophisticated end user and persuades more open source 
developers to focus on making their work fully compliant with those corporate 
oriented distributions. Fantasies of becoming the android of the desktop, with 
app stores and advertising revenue flowing in their direction. Not likely, the 
direct consumer market is already taken, by Samsung, Apple, Google, Facebook etc 
... and they have much much bigger resources to deploy in keeping it.



Simon
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Giving Devuan sans-initramfs capabilities

[Didier Kryn]

Le 04/01/2016 16:26, Hendrik Boom a écrit :

I meant

>4) Let the installer build the kernel, depending on what the hardware and
>file systems being installed actually need.


Maybe Gentoo does this, although I'm not sure, but the philosophy 
is very different: they compile everything from source. And it doesn't 
install as smoothly as Devuan.


In Devuan it means something very unusual: the installer must first 
install gcc, generate a config file and compile the kernel. It is not an 
easy task to generate a working config for any hardware combination. The 
resulting kernel package would be local and couldn't undergo upgrades.


Didier


___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Giving Devuan sans-initramfs capabilities

[Hendrik Boom]

On Mon, Jan 04, 2016 at 10:10:34AM -0500, Hendrik Boom wrote:
> On Mon, Jan 04, 2016 at 02:01:32AM -0500, Steve Litt wrote:
> > 
> > But there's a third option, that could be offered as a non-default
> > choice:
> > 
> > 3) Compile ext4 and only the most common hard drive and SSD drivers
> >into a separate and optional kernel that doesn't call an
> >initramfs, but merely runs an rc file as an init. That rc file
> >does nothing but get all the drives mounted and then exec the
> >normal init (sysvinit). 
> > 
> > Repeating: This would be an option, not the default. It would be
> > optional, not required. It would work only with ext4 and the very most
> > common hardware drivers.
> > 
> > The cost of this would be more work for the Devuan developers.
> 
> With even more work for the Devuan developers
> 
> 4) Let the installer build the, depending on what the hardware and 

I meant
> 4) Let the installer build the kernel, depending on what the hardware and 


> file systems being installed actually need.
> 
> -- hendrik
> 
> > The
> > benefits would be:
> > 
> > 1) Simpler, more transparent startup for setups that qualify.
> > 
> > 2) Very good educationally, because adding initramfs to the mix really
> >complicates matters while trying to learn the rudiments of bootup.
> > 
> > 3) Publicity. AFAIK, Devuan would be the only major distro to offer
> >this option.
> ___
> 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] Giving Devuan sans-initramfs capabilities

[Rainer Weikusat]

Steve Litt  writes:

[...]

> 3) Compile ext4 and only the most common hard drive and SSD drivers
>into a separate and optional kernel that doesn't call an
>initramfs, but merely runs an rc file as an init. That rc file
>does nothing but get all the drives mounted and then exec the
>normal init (sysvinit).

Your understanding of that is still a little faint: 'Starting userspace'
really works by

1) Mount the root filesystem.
2) Start a process running /sbin/init.

> Repeating: This would be an option, not the default. It would be
> optional, not required. It would work only with ext4 and the very most
> common hardware drivers.

And what precisely is "a very most common hardware driver"? Do you want
to setup a commitee voting on that (regularly, as hardware changes over
time)? And what's "a very most common filesystem"? What about other,
optional kernel features, eg, I'm running kernels compiled without ASR
and with kernel preemption disabled (and I used 250Hz as tick frequency
before switching tickless).

The sensible way to handle this is really "the distribution ships a
kernel which optionally supports everything" (via aggressive
modularization) and people who think they want/ need more control over
this part of the system can change that as they see fit (by compiling a
custom kernel). Insofar someone feels his custom kernel is of more
general use than just "run on this machine", the configuration could be
shared via internet. It's even failrly easy to share the kernel itself:
I posted a script I've been using since 1998 to build kernels for
different machines on a dedicated one and for someone who likes "shot
from behind trough the chest right into the eye" constructions, there's
always kernel-package for creating custom-kernel Debian packages.
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Giving Devuan sans-initramfs capabilities

[Svante Signell]

On Mon, 2016-01-04 at 17:43 +0100, Didier Kryn wrote:
> Le 04/01/2016 17:32, Svante Signell a écrit :

> Just an idea: Would it be possible to detect the hardware of each computer
> being installed on and after that install the needed modules? Preferably the
> modules should not be located on /usr, currently they are under /lib.
> 
>  I don't understand the repulsion towards having the modules in 
> /usr/lib. What difference does it make? None, unless you want the three 
> following conditions: no initramfs, /usr being a mountpoint, some 
> drivers and filesystems compiled in the kernel, but missing just the one 
> for /usr. You've got to work pretty hard to fulfill these conditions.

Well, the important part of my question was: "Would it be possible to detect the
hardware of each computer being installed on and after that install the needed
modules?"

Where the modules are located is very much under discussion here and on debian-
devel, see the "support for merged /usr in Debian" thread there. This is another
issue that could be discussed elsewhere here.
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Giving Devuan sans-initramfs capabilities

[Rainer Weikusat]

Svante Signell  writes:
> On Mon, 2016-01-04 at 17:43 +0100, Didier Kryn wrote:
>> Le 04/01/2016 17:32, Svante Signell a écrit :
>
>> Just an idea: Would it be possible to detect the hardware of each computer
>> being installed on and after that install the needed modules? Preferably the
>> modules should not be located on /usr, currently they are under /lib.
>> 
>>  I don't understand the repulsion towards having the modules in 
>> /usr/lib. What difference does it make? None, unless you want the three 
>> following conditions: no initramfs, /usr being a mountpoint, some 
>> drivers and filesystems compiled in the kernel, but missing just the one 
>> for /usr. You've got to work pretty hard to fulfill these conditions.
>
> Well, the important part of my question was: "Would it be possible to detect 
> the
> hardware of each computer being installed on and after that install the needed
> modules?"

"Somewhat". The kernel will send uevents for everything it detects (or
invoke a modprobe/ hotplug program with this information). But 'the
hardware' is not static. Eg, I have an USB printer/scanner that's
usually turned off. I installed the OS on my current 'workstation' by
connecting the disk to the SATA bus of the old one, copying the system
over and the compiling a kernel I considered to be capable of booting
the new one. Alternatively, one could also just move a disk to a new
machine.
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Giving Devuan sans-initramfs capabilities

[KatolaZ]

On Mon, Jan 04, 2016 at 05:32:26PM +0100, Svante Signell wrote:

[cut]

> 
> Just an idea: Would it be possible to detect the hardware of each computer 
> being
> installed on and after that install the needed modules? Preferably the modules
> should not be located on /usr, currently they are under /lib.

Hi Svante, 

the kernel itself is able to auto-detect the (known) hardware on which
it is running, and load the corresponding modules since ever. In
principle, if a minimal (and massively modular) kernel is used during
installation (as currently happens for Debian/Devuan) a list of
modules to be installed can be obtained at install time by a bash
one-liner like

  lsmod | cut -d " "  -f 1 | sort

However, this will not solve the problem of upgrades. 

My2Cents

KatolaZ

-- 
[ Enzo Nicosia aka KatolaZ --- GLUG Catania -- Freaknet Medialab ]
[ me [at] katolaz.homeunix.net -- http://katolaz.homeunix.net -- ]
[ GNU/Linux User:#325780/ICQ UIN: #258332181/GPG key ID 0B5F062F ]
[ Fingerprint: 8E59 D6AA 445E FDB4 A153 3D5A 5F20 B3AE 0B5F 062F ]
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Giving Devuan sans-initramfs capabilities

[Didier Kryn]

Le 04/01/2016 17:32, Svante Signell a écrit :

On Mon, 2016-01-04 at 16:53 +0100, Didier Kryn wrote:

Le 04/01/2016 16:26, Hendrik Boom a écrit :

I meant

4) Let the installer build the kernel, depending on what the hardware
and
file systems being installed actually need.

  Maybe Gentoo does this, although I'm not sure, but the philosophy
is very different: they compile everything from source. And it doesn't
install as smoothly as Devuan.

  In Devuan it means something very unusual: the installer must first
install gcc, generate a config file and compile the kernel. It is not an
easy task to generate a working config for any hardware combination. The
resulting kernel package would be local and couldn't undergo upgrades.

Just an idea: Would it be possible to detect the hardware of each computer being
installed on and after that install the needed modules? Preferably the modules
should not be located on /usr, currently they are under /lib.

I don't understand the repulsion towards having the modules in 
/usr/lib. What difference does it make? None, unless you want the three 
following conditions: no initramfs, /usr being a mountpoint, some 
drivers and filesystems compiled in the kernel, but missing just the one 
for /usr. You've got to work pretty hard to fulfill these conditions.


Didier


___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Giving Devuan sans-initramfs capabilities

[Svante Signell]

On Mon, 2016-01-04 at 16:53 +0100, Didier Kryn wrote:
> Le 04/01/2016 16:26, Hendrik Boom a écrit :
> > I meant
> > > > 4) Let the installer build the kernel, depending on what the hardware
> > > > and
> > > > file systems being installed actually need.
> 
>  Maybe Gentoo does this, although I'm not sure, but the philosophy 
> is very different: they compile everything from source. And it doesn't 
> install as smoothly as Devuan.
> 
>  In Devuan it means something very unusual: the installer must first 
> install gcc, generate a config file and compile the kernel. It is not an 
> easy task to generate a working config for any hardware combination. The 
> resulting kernel package would be local and couldn't undergo upgrades.

Just an idea: Would it be possible to detect the hardware of each computer being
installed on and after that install the needed modules? Preferably the modules
should not be located on /usr, currently they are under /lib.
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Giving Devuan sans-initramfs capabilities

[Steve Litt]

On Sun, 3 Jan 2016 21:27:58 -1000
Joel Roth  wrote:


> Hi Steve,
> 
> I would like to see Devuan as a source for innovation in the
> community in future and  I think it's a great idea to offer a
> simpler kernel and boot process. It could be accomplished
> with a modest effort, and would simplify subsequent
> administration. 
> 
> I know it's been a discipline of Devuan's default deciders
> to avoid enhancements to Debian outside the minimum needed
> to achieve Devuan's initial goal of init freedom.
>  
> > If anyone wants to debate me about this, please read the preceding
> > sentence, so at least you're debating a position I really took.  
> 
> If you start to develop the pieces involved, it's probably
> just a matter of time before they can be brought into the
> distribution, again conditional on our achieving Devuan's
> preliminary goals.
> 
> cheers,

Thanks Joel,

With my particular skillset, I'd envision my involvement to be more of
documentation somewhat like the Manjaro Experiments
(http://www.troubleshooters.com/linux/init/manjaro_experiments.htm).
With a description of how to set the thing up, others would try it, and
if there's demand, somebody would do the magic necessary to bring it
into the package manager.

Thanks,

SteveT

Steve Litt 
January 2016 featured book: Twenty Eight Tales of Troubleshooting
http://www.troubleshooters.com/28


___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Giving Devuan sans-initramfs capabilities

[Steve Litt]

On Sun, 3 Jan 2016 09:09:28 +
KatolaZ  wrote:

> On Sat, Jan 02, 2016 at 01:11:07PM -0500, Steve Litt wrote:
> > On Sat, 2 Jan 2016 09:08:37 +
> > KatolaZ  wrote:
> > 
> >   
> > > If your root fs does not change every five minutes, you can have a
> > > custom kernel with ext4 and a few other drivers compiled in, and
> > > get rid of initramfs altogether. Then, the usage that has been
> > > done of initramfs in the last few years is just an overkill,
> > > IMHO.   
> > 
> > This was exactly my point. Why can't Devuan put the ext4 kernel
> > module and the few other drivers for ext4, on directories directly
> > off the root partition, plus the stub of an rc file to bring the
> > thing to the mounted state. This would make Devuan the only distro
> > giving the user an easy choice of initramfs or not.
> >   
> 
> Steve, 
> 
> just because not everybody wants to use ext4, not everybody has the
> same disc controller, not everybody has the same configuration of
> raid/lvm/whatever. 

Let me repeat myself. I think it would be an excellent idea for Debian
to offer, not to require, as an option, not as the default, an easy way
of booting sans-initramfs for very simple ext4 configs with no LVM or
Raid or LUKS on the root partition.

Not for everybody, not for every setup, just for this one fairly simple
and fairly common one.

> Again, the installer of a distro should be able to
> install on *any* supported hw/sw configuration. There are basically
> two ways to do so:
> 
> 1) build and ship a kernel with everything compiled-in, which might
> not be any more a viable option, since it would be impossible in some
> cases to load the full image into RAM at boot time;

Obviously the preceding is not going to be done.

> 
> 2) use an initrd/initramfs with all the potentially useful modules,
> and let the kernel figure out which of them have to be loaded during
> boot, which is what happens now.

The preceding is what I envision continues to be the default way of
booting, and I also hope that the initramfs is kept as simple as
humanly possible, with only the complexity needed to mount / and
maybe /usr.

But there's a third option, that could be offered as a non-default
choice:

3) Compile ext4 and only the most common hard drive and SSD drivers
   into a separate and optional kernel that doesn't call an
   initramfs, but merely runs an rc file as an init. That rc file
   does nothing but get all the drives mounted and then exec the
   normal init (sysvinit). 

Repeating: This would be an option, not the default. It would be
optional, not required. It would work only with ext4 and the very most
common hardware drivers.

The cost of this would be more work for the Devuan developers. The
benefits would be:

1) Simpler, more transparent startup for setups that qualify.

2) Very good educationally, because adding initramfs to the mix really
   complicates matters while trying to learn the rudiments of bootup.

3) Publicity. AFAIK, Devuan would be the only major distro to offer
   this option.

Let me repeat just one more time: I mention this as a non-default
option for the simplest of ext4 setups.

If anyone wants to debate me about this, please read the preceding
sentence, so at least you're debating a position I really took.

Thanks,

SteveT

Steve Litt 
January 2016 featured book: Twenty Eight Tales of Troubleshooting
http://www.troubleshooters.com/28


___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Giving Devuan sans-initramfs capabilities

[Joel Roth]

Steve Litt wrote:
> On Sun, 3 Jan 2016 09:09:28 +
> KatolaZ  wrote:
> 
> > On Sat, Jan 02, 2016 at 01:11:07PM -0500, Steve Litt wrote:
> > > On Sat, 2 Jan 2016 09:08:37 +
> > > KatolaZ  wrote:
> > > 
> > >   
> > > > If your root fs does not change every five minutes, you can have a
> > > > custom kernel with ext4 and a few other drivers compiled in, and
> > > > get rid of initramfs altogether. Then, the usage that has been
> > > > done of initramfs in the last few years is just an overkill,
> > > > IMHO.   
> > > 
> > > This was exactly my point. Why can't Devuan put the ext4 kernel
> > > module and the few other drivers for ext4, on directories directly
> > > off the root partition, plus the stub of an rc file to bring the
> > > thing to the mounted state. This would make Devuan the only distro
> > > giving the user an easy choice of initramfs or not.
> > >   
> > 
> > Steve, 
> > 
> > just because not everybody wants to use ext4, not everybody has the
> > same disc controller, not everybody has the same configuration of
> > raid/lvm/whatever. 
> 
> Let me repeat myself. I think it would be an excellent idea for Debian
> to offer, not to require, as an option, not as the default, an easy way
> of booting sans-initramfs for very simple ext4 configs with no LVM or
> Raid or LUKS on the root partition.
> 
> Not for everybody, not for every setup, just for this one fairly simple
> and fairly common one.
> 
> > Again, the installer of a distro should be able to
> > install on *any* supported hw/sw configuration. There are basically
> > two ways to do so:
> > 
> > 1) build and ship a kernel with everything compiled-in, which might
> > not be any more a viable option, since it would be impossible in some
> > cases to load the full image into RAM at boot time;
> 
> Obviously the preceding is not going to be done.
> 
> > 
> > 2) use an initrd/initramfs with all the potentially useful modules,
> > and let the kernel figure out which of them have to be loaded during
> > boot, which is what happens now.
> 
> The preceding is what I envision continues to be the default way of
> booting, and I also hope that the initramfs is kept as simple as
> humanly possible, with only the complexity needed to mount / and
> maybe /usr.
> 
> But there's a third option, that could be offered as a non-default
> choice:
> 
> 3) Compile ext4 and only the most common hard drive and SSD drivers
>into a separate and optional kernel that doesn't call an
>initramfs, but merely runs an rc file as an init. That rc file
>does nothing but get all the drives mounted and then exec the
>normal init (sysvinit). 
> 
> Repeating: This would be an option, not the default. It would be
> optional, not required. It would work only with ext4 and the very most
> common hardware drivers.
> 
> The cost of this would be more work for the Devuan developers. The
> benefits would be:
> 
> 1) Simpler, more transparent startup for setups that qualify.
> 
> 2) Very good educationally, because adding initramfs to the mix really
>complicates matters while trying to learn the rudiments of bootup.
> 
> 3) Publicity. AFAIK, Devuan would be the only major distro to offer
>this option.
> 
> Let me repeat just one more time: I mention this as a non-default
> option for the simplest of ext4 setups.

Hi Steve,

I would like to see Devuan as a source for innovation in the
community in future and  I think it's a great idea to offer a
simpler kernel and boot process. It could be accomplished
with a modest effort, and would simplify subsequent
administration. 

I know it's been a discipline of Devuan's default deciders
to avoid enhancements to Debian outside the minimum needed
to achieve Devuan's initial goal of init freedom.
 
> If anyone wants to debate me about this, please read the preceding
> sentence, so at least you're debating a position I really took.

If you start to develop the pieces involved, it's probably
just a matter of time before they can be brought into the
distribution, again conditional on our achieving Devuan's
preliminary goals.

cheers,

Joel

 
> Thanks,
> 
> SteveT
> 
> Steve Litt 
> January 2016 featured book: Twenty Eight Tales of Troubleshooting
> http://www.troubleshooters.com/28
> 
> 
> ___
> Dng mailing list
> Dng@lists.dyne.org
> https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

-- 
Joel Roth
  

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Giving Devuan sans-initramfs capabilities

[KatolaZ]

On Sat, Jan 02, 2016 at 01:11:07PM -0500, Steve Litt wrote:
> On Sat, 2 Jan 2016 09:08:37 +
> KatolaZ  wrote:
> 
> 
> > If your root fs does not change every five minutes, you can have a
> > custom kernel with ext4 and a few other drivers compiled in, and get
> > rid of initramfs altogether. Then, the usage that has been done of
> > initramfs in the last few years is just an overkill, IMHO. 
> 
> This was exactly my point. Why can't Devuan put the ext4 kernel module
> and the few other drivers for ext4, on directories directly off the
> root partition, plus the stub of an rc file to bring the thing to the
> mounted state. This would make Devuan the only distro giving the user
> an easy choice of initramfs or not.
> 

Steve, 

just because not everybody wants to use ext4, not everybody has the
same disc controller, not everybody has the same configuration of
raid/lvm/whatever. Again, the installer of a distro should be able to
install on *any* supported hw/sw configuration. There are basically
two ways to do so:

1) build and ship a kernel with everything compiled-in, which might
not be any more a viable option, since it would be impossible in some
cases to load the full image into RAM at boot time;

2) use an initrd/initramfs with all the potentially useful modules,
and let the kernel figure out which of them have to be loaded during
boot, which is what happens now.

Then, after install, you are free to compile your own custom kernel,
containing only the modules you need in your specific machine, and get
rid of initrd/initramfs. 

HND

KatolaZ

-- 
[ Enzo Nicosia aka KatolaZ --- GLUG Catania -- Freaknet Medialab ]
[ me [at] katolaz.homeunix.net -- http://katolaz.homeunix.net -- ]
[ GNU/Linux User:#325780/ICQ UIN: #258332181/GPG key ID 0B5F062F ]
[ Fingerprint: 8E59 D6AA 445E FDB4 A153 3D5A 5F20 B3AE 0B5F 062F ]
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Giving Devuan sans-initramfs capabilities

[KatolaZ]

On Sat, Jan 02, 2016 at 01:53:02PM -0500, Steve Litt wrote:

> 
> Where can I find documentation on how to do this? The last time I
> compiled a kernel was probably in the 20th century, so I imagine things
> have changed.
> 
> You mention that you recompile your kernel. What do you do every time
> apt-get upgrade brings you a new kernel? Do you re-recompile? If so, do
> you have some sort of file containing all your choices so it's easy?

There is no need to recompile anything. Just configure your bootloader
to use *your* kernel at boot. I currently have four of five kernels
installed, due to laziness in purging onld ones when dist-upgrading,
and I am using the one *I* have chosen to use.

> 
> How do you tell your kernel not to load an initramfs?
> 

Just remove the support for initramfs and do not provide an initramfs
option at boot. Fullstop. 

HND

KatolaZ

-- 
[ Enzo Nicosia aka KatolaZ --- GLUG Catania -- Freaknet Medialab ]
[ me [at] katolaz.homeunix.net -- http://katolaz.homeunix.net -- ]
[ GNU/Linux User:#325780/ICQ UIN: #258332181/GPG key ID 0B5F062F ]
[ Fingerprint: 8E59 D6AA 445E FDB4 A153 3D5A 5F20 B3AE 0B5F 062F ]
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Giving Devuan sans-initramfs capabilities

[marc]

> I was trying to explain that "a distribution"
> has to use initrd/ initramfs because of problems specific to
> distribution kernels but that individual users don't have to use this
> mechanism if they don't want to because they can just compile a kernel
> which will work with their hardware (which is usually rather static).

How about Devuan adopting an approach which supports both 
explicitly - given that:

1 - freedoorstop.org and the big distributions want to merge
everything into /usr

2 - most big distributions have opaque, non-standard and otherwise
horrible initrd/initramfs systems

For Devuan to resist point 1, it would imply having to build custom
.deb files for large parts of the upstream core system (stripping 
out systemd seems enough work already). So how about and alternative 
which solves problems 1+2 in one go:

S - Assemble a small initramfs system which resembles a proper root /
filesystem as much as possible (which doesn't contain /usr)
and runs a sensible init process. For starters it really could
just be busybox and a bit of init. Devuan doing its own initramfs
is probably unavoidable anyway - the upstream initramfs might
be too entangled with systemd and udev to be useful or stable.

Depending on user preference and constraints there are then three
options:

A - Users who run custom kernels get to copy/uncpio this filesystem
on to a real partition, and never need run the initrd ever
again.

B - Users on systems with enough RAM run the initrd, but never
do a pivot_root - they just keep the ramdisk around and mount
/usr and whatever filesystems they need.

C - Only really small RAM constrained systems do the pivot root
(and then maybe switch to a disk based copy of /, as per case
A).

This has the nifty property that mkinitrd is less scary - it is
just takes a snapshot of the currently running root filesystem and 
runs cpio on it. And it gives people the choice to run an initrd or 
not. And it makes the content of the initrd visible. And / has a backup 
in the initramfs image. And a disk crash means the system can still run. 

Two things have to be solved for this to work though: modprobe
will then need a search path (/lib/modules for the essential ones
needed for boot up, and /usr/lib/modules for the rest) and
persistence for /etc needs to be addressed - some link or bind
mount into /usr or it own partition, a revision controlled
filesystem, something ...

regards

marc
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Giving Devuan sans-initramfs capabilities

[KatolaZ]

On Sat, Jan 02, 2016 at 09:05:26AM -0500, Stephanie Daugherty wrote:
> Might be worth trying to get interest upstream for functionality to "merge"
> binary modules with an already compiled kernel as a single file.
> Presumably, it wouldn't be *that* difficult for the kernel to look for
> modules at the end of its image and load them early.
> 
> Not sure what the kernel maintainers would say to this idea, but it seems
> like it would be more robust than initrd/initramfs.
> 

But what's the point of having modules "at the end of [the kernel]
image"? You can just compile-in them.

My2Cents

KatolaZ

-- 
[ Enzo Nicosia aka KatolaZ --- GLUG Catania -- Freaknet Medialab ]
[ me [at] katolaz.homeunix.net -- http://katolaz.homeunix.net -- ]
[ GNU/Linux User:#325780/ICQ UIN: #258332181/GPG key ID 0B5F062F ]
[ Fingerprint: 8E59 D6AA 445E FDB4 A153 3D5A 5F20 B3AE 0B5F 062F ]
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Giving Devuan sans-initramfs capabilities

[KatolaZ]

On Sat, Jan 02, 2016 at 01:50:22PM -0500, Steve Litt wrote:

[cut]

> 
> :s/choice/easy choice/
> 
> Maybe 1 out of 50 Linux users can reliably compile their own kernels.
>  

Then, Steve, if I am one of those 49 Linux users who cannot reliably
compile a kernel, there is a very high probability that I don't want
to be bothered with questions about initrd/initramfs, since I won't
understand those questions anyway and will probably just choose the
default answer, whatever it is. 

I genuinely can't see the reason behind all this fuzz around
initrd/initramfs. Freedom does not come for free, and is not given
from above, by a benevolent oligarchy. If you want the freedom to get
rid of something, you should fisrt *understand* what that something is
used for, how you can replace/remove it, and what to do if something
goes wrong.

My2Cents

KatolaZ

-- 
[ Enzo Nicosia aka KatolaZ --- GLUG Catania -- Freaknet Medialab ]
[ me [at] katolaz.homeunix.net -- http://katolaz.homeunix.net -- ]
[ GNU/Linux User:#325780/ICQ UIN: #258332181/GPG key ID 0B5F062F ]
[ Fingerprint: 8E59 D6AA 445E FDB4 A153 3D5A 5F20 B3AE 0B5F 062F ]
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Giving Devuan sans-initramfs capabilities

[Stephanie Daugherty]

On Sun, Jan 3, 2016 at 3:59 AM, KatolaZ  wrote:

> But what's the point of having modules "at the end of [the kernel]
> image"? You can just compile-in them.
>


Simple, It's to be able to turn a packaged, distribution supplied kernel
into one that will successfully boot on obscure hardware - to be able to
inject the modules needed for drive controllers, filesystems, and other
boot-time dependencies into the image.  Which would be not only faster, but
also less error prone, and easier to do than a full kernel compile and all
the obscure, potentially breaking choices that go with it.

There's also the issue of overly risk-averse enterprise environments. Even
if they trust their sysadmins, they may not trust the compiler and the
hardware it runs on well enough to risk deployment into production. A
distribution-supplied kernel typically means that same binary is already
running on at least hundreds of thousands, if not millions of other
systems, meaning someone else is finding problems for you. There's no way
they're going to get that level of testing from a kernel built in house.
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Giving Devuan sans-initramfs capabilities

[Didier Kryn]

Le 02/01/2016 15:05, Stephanie Daugherty a écrit :
Might be worth trying to get interest upstream for functionality to 
"merge" binary modules with an already compiled kernel as a single 
file. Presumably, it wouldn't be *that* difficult for the kernel to 
look for modules at the end of its image and load them early.


That's exactly what initrd/initramfs is for. It also allows much 
more. In general, "providing more" is considered a good thing. The fact 
that there are abuses of the initramfs to do things we don't like, 
should not disconsider initramfs itself. I guess also that many things 
done in the initramfs could be undone later.


Didier

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Giving Devuan sans-initramfs capabilities

[Didier Kryn]

Le 02/01/2016 19:53, Steve Litt a écrit :

How do you tell your kernel not to load an initramfs?
There's an item in "make menuconfig" where you can tell where to 
find the initramfs.


There are two ways to build it: either provide a compressed archive 
or a list of files. I'm sure you can find many howtos on the web. I 
learned that ~10 years ago and built my own framework. Of course you 
need to put in some applications and the easiest is Busybox.


This means you must build Busybox, preferably as a statically 
linked single executable. Building it statically is almost impossible if 
it is linked against glibc. To use another libc, I think the easiest way 
is to use the Buildroot toolchain; just configure Buildroot to build 
nothing but Busybox.


Once you have Busybox, you only need to write shell scripts and 
discover the mysteries of starting up a Linux system. There's some fun...


___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Giving Devuan sans-initramfs capabilities

[Didier Kryn]

Le 02/01/2016 18:30, aitor_czr a écrit :
Devuan-installer can replace the kernel in the target (the installed 
system) during the installation adding/removing all the 
wanted/unwanted modules.
Are you meaning "recompile the kernel with the needed drivers 
built-in" ? Otherwise I don't understand what you mean.


Didier

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Giving Devuan sans-initramfs capabilities

[Simon Hobson]

Stephanie Daugherty  wrote:

>> But what's the point of having modules "at the end of [the kernel] image"? 
>> You can just compile-in them.
> 
> Simple, It's to be able to turn a packaged, distribution supplied kernel into 
> one that will successfully boot on obscure hardware - to be able to inject 
> the modules needed for drive controllers, filesystems, and other boot-time 
> dependencies into the image.  Which would be not only faster, but also less 
> error prone, and easier to do than a full kernel compile and all the obscure, 
> potentially breaking choices that go with it.

I vaguely recall from my days with SCO OpenServer that it did something 
similar. It didn't compile the kernel, but it did relink it when you made 
changes - presumably just meging the stock kernel with your drivers and with 
config options (such as disk cache size) configured..
What you propose sounds like something similar.



Roger Leigh  wrote:

> The *real* goal here is something rather simpler: having both / and /usr 
> mounted in the initramfs.  The primary reason for this is that there are 
> genuine problems with stuff on / needed in early boot having library 
> dependencies located in /usr.  Libraries were moved to / on a case-by-case 
> basis, but it's really just the tip of the iceberg.  E.g. PAM modules needing 
> openssl, datafiles from /usr/share, etc.  It becomes a nightmare to 
> coordinate and manage, particularly when you also have to consider 
> third-party stuff out of your control.  Simply ensuring that /usr is 
> available in the initramfs solves all these problems.
...

Thanks for that explanation

> See https://wiki.debian.org/ReleaseGoals/MountUsrInInitramfs
> Looks like they crippled the /usr mount for the non-systemd case for no good 
> reason though.

Well it would be easy to put it down to malice, but rationally it's more likely 
incompetence. Given how many people seem to have gone into "systemd or on your 
own" mode, it's likely that they have probably not considered the combination 
(or just don't care if it's broken for non-systemd users).
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Giving Devuan sans-initramfs capabilities

[Roger Leigh]

On 03/01/2016 17:11, Simon Hobson wrote:

Roger Leigh  wrote:


The *real* goal here is something rather simpler: having both / and /usr 
mounted in the initramfs.  The primary reason for this is that there are 
genuine problems with stuff on / needed in early boot having library 
dependencies located in /usr.  Libraries were moved to / on a case-by-case 
basis, but it's really just the tip of the iceberg.  E.g. PAM modules needing 
openssl, datafiles from /usr/share, etc.  It becomes a nightmare to coordinate 
and manage, particularly when you also have to consider third-party stuff out 
of your control.  Simply ensuring that /usr is available in the initramfs 
solves all these problems.

...

Thanks for that explanation


See https://wiki.debian.org/ReleaseGoals/MountUsrInInitramfs
Looks like they crippled the /usr mount for the non-systemd case for no good 
reason though.


Well it would be easy to put it down to malice, but rationally it's more likely 
incompetence. Given how many people seem to have gone into "systemd or on your 
own" mode, it's likely that they have probably not considered the combination (or 
just don't care if it's broken for non-systemd users).


I would think it's primarily an omission since sysvinit is no longer 
cared about, so it only needed to work for systemd.  Fixing it to work 
in Devuan would be pretty simple.

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Giving Devuan sans-initramfs capabilities

[Mitt Green]

KatolaZ wrote:

>Thanks for pointing CRUX out Mitt. However, installing from sources is
>probably not what an average Devuan user would like to do :)

I'd like to point that from an end-user perspective installing software
is not much different from even Debian:

1) user adds a repository (because most of the software is in community
repos) and marks it in the config file;
2) user updates info about the repositories, usually using 'prt-get update';
3) user installs software using 'prt-get install'.

prt-get was made to mimic apt-get (as well as with slapt-get
in Slackware and pkgin in pkgsrc).

>I think that there is no real alternative to initrd/initramfs for a
>general-purpose kernel, as those included in the install image of a
>distro. At the same time, nothing prevents a user from compiling and
>installing her own preferred kernel, with or without initramfs.

What prevents devs (kernels packages' maintainers)
from compiling a kernel without initramfs support? (:

Peace,
Mitt___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Giving Devuan sans-initramfs capabilities

[Mitt Green]

aitor_czr wrote:

>Without the initramfs support the distro would not run in live mode.

Sure, as long as an installer usually runs from an initramfs, the support is
needed for an installation media.

Mitt___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Giving Devuan sans-initramfs capabilities

[Mitt Green]

KatolaZ wrote:

>The only reason it is needed, as Rainer pointed out, is to host all the drivers
>needed to mount the root fs (or to be more precise, to mount *any*
>unknown root fs, as a kernel shipped with a general-purpose
>distribution has to do).

>If your root fs does not change every five minutes, you can have a
>custom kernel with ext4 and a few other drivers compiled in, and get
>rid of initramfs altogether. Then, the usage that has been done of
>initramfs in the last few years is just an overkill, IMHO.

I had been playing with CRUX for a while, it is a source-based distro
where the installer only puts the core of the system (userland), they compile
their own kernel right after and where the packages are compiled from sources
but with resolving dependencies (no binaries at all), slow but simple,
anyway, they don't have initramfs (initrd) on the install media.
I, having ext4 and SATA drivers compiled as modules, immediately
caught a kernel panic.

People there describe CRUX as LFS with ports, very minimalistic but still
tons of packages avalable. Maybe someone would like to play with it: crux.nu
Handbook is available.

Cheers,
Mitt___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Giving Devuan sans-initramfs capabilities

[Mitt Green]

KatolaZ wrote:

>You forget the fourth step:
>4) wait for a certain amount of time before your package is compiled.

Sure, but unless you install software all the time each day one by one,
it doesn't really matter. CRUX is not a rolling-release distro, doesn't have
package revisions as in Debian, so there it works and that's great I think.
Count also their aims to keep things minimal and as simple as possible.

>I won't enter here the long-lasting flame on why compiling the same
>software on every single machine that uses it is just a waste of time
>(and resources), so I will simply say "No thanks, I don't want a
>source-based distro".

Sure, if you are an admin with 100 servers it is waste of time.
I simply love the diversity in the Unix world.

>The problem is that as a general-purpose distribution you can't
>forget that 5% of users who will need some of that 95% usually useless
>stuff...

I reckon those 5% should be able to compile their own kernel if they need things
no one uses. It is also about the scope, you know, the target audience, because 
who
mostly uses Debian: too fat/too skinny server admin with ponytail and acne
(don't even try to argue, I've seen too many of them in our local Unix 
conferences (: ),
the same actually applies to CentOS then; these chaps are geeks by nature and 
surely
have some knowledge about the kernel itself. But, of course, as I previously 
said,
there is no need to spend time compiling things if you have 100 servers (even 
if ten).


My €0.02
Mitt___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Giving Devuan sans-initramfs capabilities

[KatolaZ]

On Sat, Jan 02, 2016 at 04:30:14AM -0500, Mitt Green wrote:

[cut]

> 
> I had been playing with CRUX for a while, it is a source-based distro
> where the installer only puts the core of the system (userland), they compile
> their own kernel right after and where the packages are compiled from sources
> but with resolving dependencies (no binaries at all), slow but simple,
> anyway, they don't have initramfs (initrd) on the install media.
> I, having ext4 and SATA drivers compiled as modules, immediately
> caught a kernel panic.

Thanks for pointing CRUX out Mitt. However, installing from sources is
probably not what an average Devuan user would like to do :)

I think that there is no real alternative to initrd/initramfs for a
general-purpose kernel, as those included in the install image of a
distro. At the same time, nothing prevents a user from compiling and
installing her own preferred kernel, with or without initramfs. There
is no additional support to be provided, except from the kernel
sources, which are already there (and do not need to be packaged in a
.deb, for that matter...). 

My2Cents

KatolaZ

-- 
[ Enzo Nicosia aka KatolaZ --- GLUG Catania -- Freaknet Medialab ]
[ me [at] katolaz.homeunix.net -- http://katolaz.homeunix.net -- ]
[ GNU/Linux User:#325780/ICQ UIN: #258332181/GPG key ID 0B5F062F ]
[ Fingerprint: 8E59 D6AA 445E FDB4 A153 3D5A 5F20 B3AE 0B5F 062F ]
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Giving Devuan sans-initramfs capabilities

[Brad Campbell]

On 02/01/16 02:18, Rainer Weikusat wrote:

Steve Litt  writes:

[...]



For a real deployment, this is usually just humbug and can be replaced
with a kernel containing the drivers necessary for mounting a root
filesystem.


That's nice, until you want to do something like an encrypted root, or 
encrypted swap with suspend/resume. That's pretty hard without an initramfs.


And before you say that's a special case, it's pretty standard for any 
laptop in a sensitive environment. In fact we have servers configured 
that way.


Brad
--
Dolphins are so intelligent that within a few weeks they can
train Americans to stand at the edge of the pool and throw them
fish.
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Giving Devuan sans-initramfs capabilities

[aitor_czr]

On 01/02/2016 11:28 AM, Mitt Green  wrote:

I think that there is no real alternative to initrd/initramfs for a
>general-purpose kernel, as those included in the install image of a
>distro. At the same time, nothing prevents a user from compiling and
>installing her own preferred kernel, with or without initramfs.

What prevents devs (kernels packages' maintainers)
from compiling a kernel without initramfs support? (:

Peace,
Mitt


Without the initramfs support the distro would not run in live mode.

   Aitor.
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Giving Devuan sans-initramfs capabilities

[KatolaZ]

On Fri, Jan 01, 2016 at 06:27:10PM +, Simon Hobson wrote:
> John Rigg  wrote:
> 
> > Wasn't the original reason for having an initrd that the boot loader,
> > probably LILO at the time, couldn't handle a kernel image above a
> > certain size?
> 
> I suspect you are thinking of the problem that it couldn't access sectors 
> past a certain point due to limitation in the BIOS - that was the reason for 
> a separate /boot which meant you could guarantee to have any future kernel 
> within the range accessible to LILO.
> 
> The separate issue is having a modular kernel - which I'm in favour of BTW. 
> If you use LVM, MD (raid), disk controllers needing a kernel module, or one 
> of a few other things - then you can have a catch-22 situation where the 
> kernel needs to load a module to access

Guys, kernel modularity has nothing to do with initramfs. The only
reason it is needed, as Rainer pointed out, is to host all the drivers
needed to mount the root fs (or to be more precise, to mount *any*
unknown root fs, as a kernel shipped with a general-purpose
distribution has to do).

If your root fs does not change every five minutes, you can have a
custom kernel with ext4 and a few other drivers compiled in, and get
rid of initramfs altogether. Then, the usage that has been done of
initramfs in the last few years is just an overkill, IMHO. 

HND

KatolaZ

-- 
[ Enzo Nicosia aka KatolaZ --- GLUG Catania -- Freaknet Medialab ]
[ me [at] katolaz.homeunix.net -- http://katolaz.homeunix.net -- ]
[ GNU/Linux User:#325780/ICQ UIN: #258332181/GPG key ID 0B5F062F ]
[ Fingerprint: 8E59 D6AA 445E FDB4 A153 3D5A 5F20 B3AE 0B5F 062F ]
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Giving Devuan sans-initramfs capabilities

[karl]

Katola2:
> On Fri, Jan 01, 2016 at 06:27:10PM +, Simon Hobson wrote:
> > John Rigg  wrote:
> > 
> > > Wasn't the original reason for having an initrd that the boot loader,
> > > probably LILO at the time, couldn't handle a kernel image above a
> > > certain size?
> > 
> > I suspect you are thinking of the problem that it couldn't access
> > sectors past a certain point due to limitation in the BIOS - that
> > was the reason for a separate /boot which meant you could
> > guarantee to have any future kernel within the range accessible
> > to LILO.

A small little /boot first in disk has never given me any problem,
and have apparantly saved me from hassles others have had. You don't
even have to have it mounted unless you change kernel or the like.

I don't see how I could gain anything from not having it, it is a very
pragmatical ting to have.

You wouldn't think of moving the boot record to some nostandard 
location, do you ?

...
> > If you use LVM, MD (raid), disk controllers needing a kernel
> > module, or one of a few other things - then you can have a
> > catch-22 situation where the kernel needs to load a module to
> > access

MD works perfectly fine without initrd. If you don't use autodetect,
then simply supply md=2,/dev/sda2,/dev/sdb2 (adj. for your system) to
your boot cmdline. If you want your / to be a partition within a md 
device, you're in for a little more pain, but why do you want to hurt 
yourself.

The only time I needed a driver for a disk controller as a module was
for a scsi raid which wasn't supported by the kernel, but that was a
rather special case. Other than that you (as a local admin) can just
as well have the driver in the kernel binary.

I havn't tested booting from  a lvm partition.

But sane advice is: keep your boot simple and clean. If you need a few 
extra small partitions for that, who cares ?

...
> If your root fs does not change every five minutes, you can have a
> custom kernel with ext4 and a few other drivers compiled in, and get
> rid of initramfs altogether. Then, the usage that has been done of
> initramfs in the last few years is just an overkill, IMHO. 

Ack.

Regards,
/Karl Hammar

---
Aspö Data
Lilla Aspö 148
S-742 94 Östhammar
Sweden
+46 173 140 57


___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Giving Devuan sans-initramfs capabilities

[Mitt Green]

I forgot about 9MB footprint after the first boot in CRUX, with my custom kernel
supporting everything that I need (pretty much the same kernel I am using
now, except for now it is 3.18.25, then it was 3.18.20).

Here in Devuan I have 19MB but with services on startup (dbus, acpid etc.)

And CRUX also uses eudev and BSD init.___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Giving Devuan sans-initramfs capabilities

[KatolaZ]

On Sat, Jan 02, 2016 at 05:05:29AM -0500, Mitt Green wrote:
> KatolaZ wrote:
> 
> >Thanks for pointing CRUX out Mitt. However, installing from sources is
> >probably not what an average Devuan user would like to do :)
> 
> I'd like to point that from an end-user perspective installing software
> is not much different from even Debian:
> 
> 1) user adds a repository (because most of the software is in community
> repos) and marks it in the config file;
> 2) user updates info about the repositories, usually using 'prt-get update';
> 3) user installs software using 'prt-get install'.
> 

You forget the fourth step:

4) wait for a certain amount of time before your package is compiled.

I won't enter here the long-lasting flame on why compiling the same
software on every single machine that uses it is just a waste of time
(and resources), so I will simply say "No thanks, I don't want a
source-based distro".

cut[]

> 
> What prevents devs (kernels packages' maintainers)
> from compiling a kernel without initramfs support? (:
> 

Precisely the fact that the kernel package maintainers do not know in
advance on which hardware their kernel will run, so they have to
compile-in all the possible drivers for all the possible disc
controllers and all the possible configurations of root
filesystems/volumes. Which is quite a lot of stuff, in the end,
especially since 95% of the users will probably need only 5% of that
stuff. The problem is that as a general-purpose distribution you can't
forget that 5% of users who will need some of that 95% usually useless
stuff...

My2Cents

KatolaZ

-- 
[ Enzo Nicosia aka KatolaZ --- GLUG Catania -- Freaknet Medialab ]
[ me [at] katolaz.homeunix.net -- http://katolaz.homeunix.net -- ]
[ GNU/Linux User:#325780/ICQ UIN: #258332181/GPG key ID 0B5F062F ]
[ Fingerprint: 8E59 D6AA 445E FDB4 A153 3D5A 5F20 B3AE 0B5F 062F ]
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Giving Devuan sans-initramfs capabilities

[richard lucassen]

On Sat, 02 Jan 2016 18:35:29 +
Rainer Weikusat  wrote:

> You already have that choice, you just need to exercise it: Compile a
> kernel which can mount 'your' root filesystem without the help of
> additional userspace software, be it for loading modules or for
> additional configuration, and use that: No initsomething needed.

What about security issues? I'd rather have a kernel that is provided
and built by the security team.

Of course you can compile your own kernel, a package like
"kernel-package" makes things very easy you. But we're talking
about a distrubution kernel, that's a rather different story!

I think it would be a nice extra feature to be able to opt for an
initramfs-less kernel. As an **extra** option. Not a replacement. If
you choose that option you know that there are a set of restrictions
and if you don't want that or if you have special hardware you should
opt for the "normal" initramfs version.

R.

-- 
richard lucassen
http://contact.xaq.nl/
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Giving Devuan sans-initramfs capabilities

[Rainer Weikusat]

Steve Litt  writes:
> Rainer Weikusat  wrote:
>> Steve Litt  writes:
>
>> > Why does everyone think I was advocating the banishment of
>> > initramfs? Go back to my initial post and you'll see I was
>> > suggesting a way to give the owner/admin a *choice* to go without
>> > initramfs.  
>> 
>> You already have that choice, you just need to exercise it: Compile a
>> kernel which can mount 'your' root filesystem without the help of
>> additional userspace software, be it for loading modules or for
>> additional configuration, and use that: No initsomething needed.
>> 
>> In fact, that's exactly the configuration I've been using 'since
>> ever'.
>
> Where can I find documentation on how to do this? The last time I
> compiled a kernel was probably in the 20th century, so I imagine things
> have changed.

Not much. Modules don't have to be compiled separately anymore but
that's about it. 

> You mention that you recompile your kernel. What do you do every time
> apt-get upgrade brings you a new kernel?

There's a Debian package called kernel-package which is supposed to
enable 'easy' creation of kernel packages from a kernel source tree but
IMHO, that's rather contorted and I don't use it. I usually deinstall
the Debian kernel package (nothing depends on that) and then install
kernels based on a tar file created by this script:

-
#!/bin/sh
#
set +e

#*  parameters
#
DEST=install
SOURCE=$1

UTS_PATH=$SOURCE/include/generated
if test -e $UTS_PATH/utsrelease.h;
then
UTS_FILE=$UTS_PATH/utsrelease.h
elif test -e $UTS_PATH/version.h;
then
UTS_FILE=$UTS_PATH/version.h
else
printf "Cannot find kernel version\n" >&2
exit 1
fi

#*  actions
#
rm -rf $DEST/*
mkdir $DEST/boot

VERSION=`grep UTS_RELEASE $UTS_FILE | cut -d' ' -f3 | tr -d '"'`

KSUFF=$VERSION-$1

cp $SOURCE/System.map $DEST/boot/System.map-$VERSION
cp $SOURCE/arch/x86_64/boot/bzImage $DEST/boot/vmlinuz-$VERSION
cd $SOURCE
INSTALL_MOD_PATH=../install make modules_install
cd -

fakeroot < If so, do you have some sort of file containing all your choices so
> it's easy?

The configuration of a kernel is stored in the file .config in the
top-level kernel directory (after a configuration was created,
obviously).
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Giving Devuan sans-initramfs capabilities

[Rainer Weikusat]

Brad Campbell  writes:
> On 02/01/16 02:18, Rainer Weikusat wrote:
>> Steve Litt  writes:
>>
>> [...]
>
>> For a real deployment, this is usually just humbug and can be replaced
>> with a kernel containing the drivers necessary for mounting a root
>> filesystem.
>
> That's nice, until you want to do something like an encrypted root, or
> encrypted swap with suspend/resume. That's pretty hard without an
> initramfs.

That's a different use-case: In this case, the initramfs is not needed
because the kernel needs to load an a priori unknown set of modules in
order to mount the root filesystem (although this will usually be done,
too) but because "userspace stuff" is needed to make the filesystem
accessible (LVM is another example of that).

OTOH, there's litte reason to encrypt / unless the filesystem consists
of a single, large partition and hence, it holds possibly sensitive
information. The 'standard filesystem layout' I've meanwhile gravitated
to is composed of three partitions, /, /usr and /data, the latter being
used to hold /home, /var and /tmp (with / being a sychronously mounted
ext2). Were I to use 'disk encryption', I would thus encrypt the data
partition but not the other two.
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Giving Devuan sans-initramfs capabilities

[Steve Litt]

On Sat, 2 Jan 2016 09:08:37 +
KatolaZ  wrote:


> If your root fs does not change every five minutes, you can have a
> custom kernel with ext4 and a few other drivers compiled in, and get
> rid of initramfs altogether. Then, the usage that has been done of
> initramfs in the last few years is just an overkill, IMHO. 

This was exactly my point. Why can't Devuan put the ext4 kernel module
and the few other drivers for ext4, on directories directly off the
root partition, plus the stub of an rc file to bring the thing to the
mounted state. This would make Devuan the only distro giving the user
an easy choice of initramfs or not.

Personally I'd do it for ext2 and 3 too, but I'm not greedy: If you
give them this capability for ext4, soon enough you'll have a
groundswell of people wanting it for 2 and 3, and it will be
prioritized.

SteveT

Steve Litt 
January 2016 featured book: Twenty Eight Tales of Troubleshooting
http://www.troubleshooters.com/28


___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Giving Devuan sans-initramfs capabilities

[Steve Litt]

On Sat, 02 Jan 2016 19:06:38 +0800
Brad Campbell  wrote:

> On 02/01/16 02:18, Rainer Weikusat wrote:
> > Steve Litt  writes:
> >
> > [...]  
> 
> > For a real deployment, this is usually just humbug and can be
> > replaced with a kernel containing the drivers necessary for
> > mounting a root filesystem.  
> 
> That's nice, until you want to do something like an encrypted root,
> or encrypted swap with suspend/resume. That's pretty hard without an
> initramfs.

Why does everyone think I was advocating the banishment of initramfs?
Go back to my initial post and you'll see I was suggesting a way to
give the owner/admin a *choice* to go without initramfs. Let me quote
my original post:

===
This wouldn't be mandatory. It wouldn't be default. But it would
provide one more attraction to the person who wants to be in control of
his computer, rather than vice-versa. I think it would be a feather in
Devuan's cap, and would further differentiate Devuan from Debian.
===
 
SteveT

Steve Litt 
January 2016 featured book: Twenty Eight Tales of Troubleshooting
http://www.troubleshooters.com/28


___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Giving Devuan sans-initramfs capabilities

[Adam Borowski]

On Sat, Jan 02, 2016 at 08:15:39PM +0100, k...@aspodata.se wrote:
> Steve Litt:
> > Where can I find documentation on how to do this? The last time I
> > compiled a kernel was probably in the 20th century, so I imagine things
> > have changed.
> 
> It should be something like:
> 
> download your kernel from your favourite site, e.g.
> ftp:ftp.sunet.se/pub/Linux/kernels/

Boo!  Do you live in 20th century?  It's a crime to not use git, especially
when patches are involved.  Even if they're not, you save time unpacking /
downloading updates / switching to other releases.

git clone git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git

> make
> make install
> make modules_install

This won't let you uninstall cleanly, or deploy to other machines.

make-kpkg --rootcmd fakeroot --initrd -j6 linux-image
(no --initrd if you don't want initrd, replace 6 with the number of cores in
your box)
dpkg -i ~you/linux-image-*.deb

> ch. bootloader to load your kernal

make-kpkg will handle grub/lilo config automatically.

> > Do you re-recompile? If so, do
> > you have some sort of file containing all your choices so it's easy?
> 
> I think make menuconfig et al. pulls in the current kernels config,
> just make sure you have it in /boot:
>
> # ls -l /boot/*3.12.8*
> -rw-r--r-- 1 root root  118268 Aug  1 15:36 /boot/config-3.12.8-rt11-i3
> -rw-r--r-- 1 root root 1581413 Aug  1 15:36 /boot/System.map-3.12.8-rt11-i3
> -rw-r--r-- 1 root root 3458016 Aug  1 15:36 /boot/vmlinuz-3.12.8-rt11-i3

The first time you need to copy it by hand as .config to your linux source
directory -- if you want to start with the distribution kernel, that has
every obscure driver as module.  You can trim that to only those present
on the compilation box with "make localmodconfig".  Another target of note
is "localyesconfig" which converts modules to built-ins, something you want
in a non-initrd kernel.

-- 
A tit a day keeps the vet away.
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Giving Devuan sans-initramfs capabilities

[Rainer Weikusat]

Steve Litt  writes:

> On Sat, 02 Jan 2016 19:06:38 +0800
> Brad Campbell  wrote:
>
>> On 02/01/16 02:18, Rainer Weikusat wrote:
>> > Steve Litt  writes:
>> >
>> > [...]  
>> 
>> > For a real deployment, this is usually just humbug and can be
>> > replaced with a kernel containing the drivers necessary for
>> > mounting a root filesystem.  
>> 
>> That's nice, until you want to do something like an encrypted root,
>> or encrypted swap with suspend/resume. That's pretty hard without an
>> initramfs.
>
> Why does everyone think I was advocating the banishment of initramfs?
> Go back to my initial post and you'll see I was suggesting a way to
> give the owner/admin a *choice* to go without initramfs.

You already have that choice, you just need to exercise it: Compile a
kernel which can mount 'your' root filesystem without the help of
additional userspace software, be it for loading modules or for
additional configuration, and use that: No initsomething needed.

In fact, that's exactly the configuration I've been using 'since ever'.
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Giving Devuan sans-initramfs capabilities

[Steve Litt]

On Sat, 02 Jan 2016 18:35:29 +
Rainer Weikusat  wrote:

> Steve Litt  writes:

> > Why does everyone think I was advocating the banishment of
> > initramfs? Go back to my initial post and you'll see I was
> > suggesting a way to give the owner/admin a *choice* to go without
> > initramfs.  
> 
> You already have that choice, you just need to exercise it: Compile a
> kernel which can mount 'your' root filesystem without the help of
> additional userspace software, be it for loading modules or for
> additional configuration, and use that: No initsomething needed.

:s/choice/easy choice/

Maybe 1 out of 50 Linux users can reliably compile their own kernels.
 
SteveT

Steve Litt 
January 2016 featured book: Twenty Eight Tales of Troubleshooting
http://www.troubleshooters.com/28


___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Giving Devuan sans-initramfs capabilities

[aitor_czr]

On 01/02/2016 04:49 PM, Stephanie Daugherty  wrote:
Might be worth trying to get interest upstream for functionality to 
"merge" binary modules with an already compiled kernel as a single 
file. Presumably, it wouldn't be *that* difficult for the kernel to 
look for modules at the end of its image and load them early. Not sure 
what the kernel maintainers would say to this idea, but it seems like 
it would be more robust than initrd/initramfs. On Sat, Jan 2, 2016 at 
6:25 AM, aitor_czr  wrote:

>On 01/02/2016 11:28 AM, Mitt Green
>  wrote:
>
>I think that there is no real alternative to initrd/initramfs for a>general-purpose 
kernel, as those included in the install image of a>distro. At the same time, nothing 
prevents a user from compiling and>installing her own preferred kernel, with or without 
initramfs.
>
>What prevents devs (kernels packages' maintainers)
>from compiling a kernel without initramfs support? (:
>
>Peace,
>Mitt


Devuan-installer can replace the kernel in the target (the installed 
system) during the installation adding/removing all the wanted/unwanted 
modules. One year ago i debianized Linux-Libre-3.16.7 adding some 
kernel-modules (like, for example, floppy-modules) to the default 
configuration of debian, including the .udeb packages for d-i:


http://apt-gnuinos.org/pool/main/l/linux/

Shortly i'm going to do the same with the latest version of 
Linux-Libre-4.4-rc7 for the following architectures: i586, i686-pae, 
amd64 and armhf (Raspberry Pi). But now i'm working on netman-gtk3 and 
the .deb packages of vdev.


Any suggestion about the included kernel modules?

   Aitor.

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Giving Devuan sans-initramfs capabilities

[Steve Litt]

On Sat, 02 Jan 2016 18:35:29 +
Rainer Weikusat  wrote:

> Steve Litt  writes:

> > Why does everyone think I was advocating the banishment of
> > initramfs? Go back to my initial post and you'll see I was
> > suggesting a way to give the owner/admin a *choice* to go without
> > initramfs.  
> 
> You already have that choice, you just need to exercise it: Compile a
> kernel which can mount 'your' root filesystem without the help of
> additional userspace software, be it for loading modules or for
> additional configuration, and use that: No initsomething needed.
> 
> In fact, that's exactly the configuration I've been using 'since
> ever'.

Where can I find documentation on how to do this? The last time I
compiled a kernel was probably in the 20th century, so I imagine things
have changed.

You mention that you recompile your kernel. What do you do every time
apt-get upgrade brings you a new kernel? Do you re-recompile? If so, do
you have some sort of file containing all your choices so it's easy?

How do you tell your kernel not to load an initramfs?

Thanks,

SteveT

Steve Litt 
January 2016 featured book: Twenty Eight Tales of Troubleshooting
http://www.troubleshooters.com/28


___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Giving Devuan sans-initramfs capabilities

[Wim]

2016-01-02 15:05 GMT+01:00 Stephanie Daugherty :

> Might be worth trying to get interest upstream for functionality to
> "merge" binary modules with an already compiled kernel as a single file.
> Presumably, it wouldn't be *that* difficult for the kernel to look for
> modules at the end of its image and load them early.
>
> Not sure what the kernel maintainers would say to this idea, but it seems
> like it would be more robust than initrd/initramfs.
>
>
> On Sat, Jan 2, 2016 at 6:25 AM, aitor_czr  wrote:
>
>> On 01/02/2016 11:28 AM, Mitt Green 
>>  wrote:
>>
>> I think that there is no real alternative to initrd/initramfs for 
>> a>general-purpose kernel, as those included in the install image of 
>> a>distro. At the same time, nothing prevents a user from compiling 
>> and>installing her own preferred kernel, with or without initramfs.
>>
>> What prevents devs (kernels packages' maintainers)
>> from compiling a kernel without initramfs support? (:
>>
>> Peace,
>> Mitt
>>
>>
>> Without the initramfs support the distro would not run in live mode.
>>
>>Aitor.
>>
>> ___
>> 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
>
> Hi all,

I like simple things.

Stepanie's idea seems great to my noob mind.

As for live CD's, couldn't they implement a simple switch not to load
modules at the end of kernel load and load initram/fs, for those
circumstances?



Cheers,

Wim
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Giving Devuan sans-initramfs capabilities

[Karl Hammar]

Adam Borowski:
> On Sat, Jan 02, 2016 at 08:15:39PM +0100, k...@aspodata.se wrote:
> > Steve Litt:
> > > Where can I find documentation on how to do this? The last time I
> > > compiled a kernel was probably in the 20th century, so I imagine things
> > > have changed.
> > 
> > It should be something like:
> > 
> > download your kernel from your favourite site, e.g.
> > ftp:ftp.sunet.se/pub/Linux/kernels/
> 
> Boo!  Do you live in 20th century?  It's a crime to not use git, especially
> when patches are involved.  Even if they're not, you save time unpacking /
> downloading updates / switching to other releases.
> 
> git clone 
> git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git

Do you see any difference between the git repo and the tar file ?

$ du -s linux-2.6
3009716 linux-2.6

$ ls -l /Net/ftp/ftp.sunet.se/pub/Linux/kernels/v4.x/linux-4.0.tar.xz 
-rw-r--r-- 1 karl users 82313052 Apr 13  2015 
/Net/ftp/ftp.sunet.se/pub/Linux/kernels/v4.x/linux-4.0.tar.xz

So for someone who has not compiled the kernel from source, I don't
start with the git clone, especially since I don't know anything about 
their network connection. You might not believe it, but there are still
people out there with (plain old telefon system) modems.

> > make
> > make install
> > make modules_install
> 
> This won't let you uninstall cleanly, or deploy to other machines.

That lets me deploy to machines without apt or dpkg.
I don't uninstall kernels that ofthen so I don't mind the manual way.

> make-kpkg --rootcmd fakeroot --initrd -j6 linux-image
> (no --initrd if you don't want initrd, replace 6 with the number of cores in
> your box)
> dpkg -i ~you/linux-image-*.deb
> 
> > ch. bootloader to load your kernal
> 
> make-kpkg will handle grub/lilo config automatically.

I don't want that automation so I do:

# cat /etc/kernel-img.conf 
do_symlinks = no
do_bootloader = no
silent_modules = yes
warn_initrd = no

///

Yes, I used to use something similar:

fakeroot make-kpkg --append-to-version -anne.k6 --revision 1 kernel_image > log 
2>&1

but I got:

$ cat /var/lib/dpkg/info/kernel-package.list 
/etc
/etc/bash_completion.d
/etc/bash_completion.d/make_kpkg
/etc/kernel-pkg.conf
$

and then I found I could just as easily do it by myself.

If you want to use make-kpkg, it nice to set it up, like:

# fgrep := /etc/kernel-pkg.conf 
maintainer := Karl Hammar
email := k...@aspodata.se
priority := Low

///

If you want to do it the debian way, read:

https://www.debian.org/doc/manuals/debian-handbook/sect.kernel-compilation.en.html

Btw, there you'll find:

   CULTURE The good old days of kernel-package
   Before the Linux build system gained the ability to build proper Debian
   packages, the recommended way to build such packages was to use make-kpkg
   from the kernel-package package. 

> > > Do you re-recompile? If so, do
> > > you have some sort of file containing all your choices so it's easy?
> > 
> > I think make menuconfig et al. pulls in the current kernels config,
> > just make sure you have it in /boot:
> >
> > # ls -l /boot/*3.12.8*
> > -rw-r--r-- 1 root root  118268 Aug  1 15:36 /boot/config-3.12.8-rt11-i3
> > -rw-r--r-- 1 root root 1581413 Aug  1 15:36 /boot/System.map-3.12.8-rt11-i3
> > -rw-r--r-- 1 root root 3458016 Aug  1 15:36 /boot/vmlinuz-3.12.8-rt11-i3
> 
> The first time you need to copy it by hand as .config to your linux source
> directory -- if you want to start with the distribution kernel, that has
> every obscure driver as module.  You can trim that to only those present
> on the compilation box with "make localmodconfig".  Another target of note
> is "localyesconfig" which converts modules to built-ins, something you want
> in a non-initrd kernel.

Good to know.

Regards,
/Karl Hammar

---
Aspö Data
Lilla Aspö 148
S-742 94 Östhammar
Sweden
+46 173 140 57


___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Giving Devuan sans-initramfs capabilities

[Adam Borowski]

On Sat, Jan 02, 2016 at 09:32:31PM +0100, Karl Hammar wrote:
> Adam Borowski:
> > On Sat, Jan 02, 2016 at 08:15:39PM +0100, k...@aspodata.se wrote:
> > > download your kernel from your favourite site, e.g.
> > > ftp:ftp.sunet.se/pub/Linux/kernels/
> > 
> > Boo!  Do you live in 20th century?  It's a crime to not use git, especially
> > when patches are involved.  Even if they're not, you save time unpacking /
> > downloading updates / switching to other releases.
> > 
> > git clone 
> > git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git
> 
> Do you see any difference between the git repo and the tar file ?
> 
> $ du -s linux-2.6
> 3009716 linux-2.6

You want du -s .git only, as you're counting both packed and unpacked.

> $ ls -l /Net/ftp/ftp.sunet.se/pub/Linux/kernels/v4.x/linux-4.0.tar.xz 
> -rw-r--r-- 1 karl users 82313052 Apr 13  2015 
> /Net/ftp/ftp.sunet.se/pub/Linux/kernels/v4.x/linux-4.0.tar.xz
>
> So for someone who has not compiled the kernel from source, I don't
> start with the git clone, especially since I don't know anything about 
> their network connection. You might not believe it, but there are still
> people out there with (plain old telefon system) modems.

Such people can specify --depth to make a shallow clone with no history.

But really, I don't see anyone who's capable of compiling their own kernel
use an acoustic modem today.

And unlike tarballs, you clone from git once, then pull only commits you
don't have yet, so in the long run you save bandwidth.

> > > make
> > > make install
> > > make modules_install
> > 
> > This won't let you uninstall cleanly, or deploy to other machines.
> 
> That lets me deploy to machines without apt or dpkg.

This mailing list happens to be for a distribution where both apt and dpkg
are Essential:yes packages.  I'd expect people here to be more likely to
have FreeBSD/whatever machines than to use non-deb Linux.

> I don't uninstall kernels that ofthen so I don't mind the manual way.

So you don't do security upgrades?

I still do have some machines from before I started to just slap a few GB
for / instead of mucking with separate /boot, kernel upgrades there are a
pain as every distribution kernel is more than 100MB unpacked.  You do need
to prune these quickly.

> > > ch. bootloader to load your kernal
> > 
> > make-kpkg will handle grub/lilo config automatically.
> 
> I don't want that automation so I do:
> 
> # cat /etc/kernel-img.conf 
> do_symlinks = no
> do_bootloader = no
> silent_modules = yes
> warn_initrd = no

Why not?  If your use case is not handled by kernel-package and friends,
please submit a bug report so it can be available by everyone.  Having to do
such things by hand goes against the idea of a distribution.  Any moment
spent on micromanaging rather than automating is wasted.

I understand special handling of bootloaders on embedded, but on a regular
server or desktop?  That's reinventing the wheel.

-- 
A tit a day keeps the vet away.
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Giving Devuan sans-initramfs capabilities

[karl]

Adam Borowski:
> On Sat, Jan 02, 2016 at 09:32:31PM +0100, Karl Hammar wrote:
> > Adam Borowski:
> > > On Sat, Jan 02, 2016 at 08:15:39PM +0100, k...@aspodata.se wrote:
> > > > download your kernel from your favourite site, e.g.
> > > > ftp:ftp.sunet.se/pub/Linux/kernels/
> > > 
> > > Boo!  Do you live in 20th century?  It's a crime to not use git, 
> > > especially
> > > when patches are involved.  Even if they're not, you save time unpacking /
> > > downloading updates / switching to other releases.
> > > 
> > > git clone 
> > > git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git
> > 
> > Do you see any difference between the git repo and the tar file ?
> > 
> > $ du -s linux-2.6
> > 3009716 linux-2.6
> 
> You want du -s .git only, as you're counting both packed and unpacked.

Yes, but my point still holds:

$ du -s X/nouveau/linux-2.6/.git
1879408 X/nouveau/linux-2.6/.git
$ du -s /Net/ftp/ftp.sunet.se/pub/Linux/kernels/v4.x/linux-4.0.tar.xz 
80384   /Net/ftp/ftp.sunet.se/pub/Linux/kernels/v4.x/linux-4.0.tar.xz
$ echo 1879408/80384 |  bc
23

> > So for someone who has not compiled the kernel from source, I don't
> > start with the git clone, especially since I don't know anything about 
> > their network connection. You might not believe it, but there are still
> > people out there with (plain old telefon system) modems.
> 
> Such people can specify --depth to make a shallow clone with no history.

Well, why don't you present your advice to the proper target, write a 
howto and send it to the list.

> But really, I don't see anyone who's capable of compiling their own kernel
> use an acoustic modem today.

You'd be surprised, but accept the fact that some people are not 
fortunate re. bandwidth.

> And unlike tarballs, you clone from git once, then pull only commits you
> don't have yet, so in the long run you save bandwidth.

Yes, but we don't know if this or that person wants to do more than one
compile.

> > > > make
> > > > make install
> > > > make modules_install
> > > 
> > > This won't let you uninstall cleanly, or deploy to other machines.
> > 
> > That lets me deploy to machines without apt or dpkg.
> 
> This mailing list happens to be for a distribution where both apt and dpkg
> are Essential:yes packages.  I'd expect people here to be more likely to
> have FreeBSD/whatever machines than to use non-deb Linux.

People on this on this are competent to decide for themself what they 
want, and that might not be what you expect.

> > I don't uninstall kernels that ofthen so I don't mind the manual way.
> 
> So you don't do security upgrades?

Please, not unstalling does not imply not installing.
And manual uninstall is rather benign.

...
> > > make-kpkg will handle grub/lilo config automatically.
> > 
> > I don't want that automation so I do:
> > 
> > # cat /etc/kernel-img.conf 
> > do_symlinks = no
> > do_bootloader = no
> > silent_modules = yes
> > warn_initrd = no
> 
> Why not?
...

It only gives me two kernels, current and old.

///

And please get your tone down.
There is no need for "boo" and other pejorative statements.

I give my advice and you are welcome to present your in a civil tone.

Regards,
/Karl Hammar

---
Aspö Data
Lilla Aspö 148
S-742 94 Östhammar
Sweden
+46 173 140 57


___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Giving Devuan sans-initramfs capabilities

[richard lucassen]

On Fri, 1 Jan 2016 20:23:21 +0100
richard lucassen  wrote:

> Ok, I think we agree. But as OP said: it would be very nice to get rid
> of initramfs. But for a distribution kernel this would be almost
> undoable. So what about the idea to just have an initrd containing all
> necessary modules for mounting / ? The rest can be loaded once the /
> fs has been mounted.

And of course, as suggested by Didier, build in a few popular
filesystems. In these cases an initrd can be omitted. That keeps things
simple IMHO.

R.

-- 
___
It is better to remain silent and be thought a fool, than to speak
aloud and remove all doubt.

+--+
| Richard Lucassen, Utrecht|
+--+
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Giving Devuan sans-initramfs capabilities

[Rainer Weikusat]

Didier Kryn  writes:
> Le 01/01/2016 20:05, Rainer Weikusat a écrit :
>> richard lucassen  writes:
>>> Rainer Weikusat  wrote:
> Plus the drivers for various hardware like cciss devices, just
> having ext4 built in is not enough. Wouldn't it be better to have a
> simple initramfs with just the apropiate modules for the hardware?
 No computer I've either been using privately or professionally ever
 suddenly grew a new motherboard (simplification) overnight. Hence,
 they're all running kernels with the drivers and filesystems necessary
 for booting compiled in.
>>> Of course, but I presume that we're talking about a kernel that will be
>>> distributed by Devuan. If you build in hardware drivers for all
>>> different types of hardware, the kernel gets somewhat big IMHO ;-)
>> Some signals crossed here. I was trying to explain that "a distribution"
>> has to use initrd/ initramfs because of problems specific to
>> distribution kernels but that individual users don't have to use this
>> mechanism if they don't want to because they can just compile a kernel
>> which will work with their hardware (which is usually rather static).
>
> There might be an optional kernel featuring sata, scsi and a few
> popular filesystems. That would match the vast majority of cases.

SCSI is a protocol for accessing storage devices. ATA is also a protocol
for accessing storage devices. SATA is ATA over a single cable (instead
of sixteen parallell cables). There's also SAS (serial-attached SCSI).
But all of this still doesn't get anyone anywhere as drivers are needed
to work with individual SATA or SCSI or SAS controllers. There's a de
facto standard SATA hardware interface called AHCI (defined by Intel)
which only needs an AHCI driver module but there are all kinds of other
SATA implementations not conforming to it. Nothing similar exists for
SCSI/ SAS interfaces.
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Giving Devuan sans-initramfs capabilities

[richard lucassen]

On Fri, 1 Jan 2016 20:48:13 +0100
richard lucassen  wrote:

> And of course, as suggested by Didier, build in a few popular
> filesystems. In these cases an initrd can be omitted. That keeps
> things simple IMHO.

s/filesystems/hardware drivers/

-- 
___
It is better to remain silent and be thought a fool, than to speak
aloud and remove all doubt.

+--+
| Richard Lucassen, Utrecht|
+--+
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Giving Devuan sans-initramfs capabilities

[richard lucassen]

On Fri, 01 Jan 2016 18:18:38 +
Rainer Weikusat  wrote:

> For a real deployment, this is usually just humbug and can be replaced
> with a kernel containing the drivers necessary for mounting a root
> filesystem.

Plus the drivers for various hardware like cciss devices, just having
ext4 built in is not enough. Wouldn't it be better to have a simple
initramfs with just the apropiate modules for the hardware? Which is
e.g. a copy from /lib/modules//initrd/ where modules reside
that are needed for a root fs to be mounted.

R.

-- 
___
It is better to remain silent and be thought a fool, than to speak
aloud and remove all doubt.

+--+
| Richard Lucassen, Utrecht|
+--+
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Giving Devuan sans-initramfs capabilities

[Rainer Weikusat]

richard lucassen  writes:
> Rainer Weikusat  wrote:
>
>> For a real deployment, this is usually just humbug and can be replaced
>> with a kernel containing the drivers necessary for mounting a root
>> filesystem.
>
> Plus the drivers for various hardware like cciss devices, just having
> ext4 built in is not enough. Wouldn't it be better to have a simple
> initramfs with just the apropiate modules for the hardware?

No computer I've either been using privately or professionally ever
suddenly grew a new motherboard (simplification) overnight. Hence,
they're all running kernels with the drivers and filesystems necessary
for booting compiled in.
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Giving Devuan sans-initramfs capabilities

[richard lucassen]

On Fri, 01 Jan 2016 18:42:08 +
Rainer Weikusat  wrote:

> > Plus the drivers for various hardware like cciss devices, just
> > having ext4 built in is not enough. Wouldn't it be better to have a
> > simple initramfs with just the apropiate modules for the hardware?
> 
> No computer I've either been using privately or professionally ever
> suddenly grew a new motherboard (simplification) overnight. Hence,
> they're all running kernels with the drivers and filesystems necessary
> for booting compiled in.

Of course, but I presume that we're talking about a kernel that will be
distributed by Devuan. If you build in hardware drivers for all
different types of hardware, the kernel gets somewhat big IMHO ;-)

-- 
___
It is better to remain silent and be thought a fool, than to speak
aloud and remove all doubt.

+--+
| Richard Lucassen, Utrecht|
+--+
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Giving Devuan sans-initramfs capabilities

[John Rigg]

On Fri, Jan 01, 2016 at 06:32:34PM +, Rainer Weikusat wrote:
> John Rigg  writes:
> > On Fri, Jan 01, 2016 at 12:26:41PM -0500, Steve Litt wrote:
> >> If / is formatted ext4, it can be mounted directly by a kernel with ext4
> >> drivers, no initramfs needed.
> >
> > Wasn't the original reason for having an initrd that the boot loader,
> > probably LILO at the time, couldn't handle a kernel image above a
> > certain size? (My recollection could be faulty here, so corrections
> > welcome).
> 
> Oh wow. That got twisted :-). LILO loads a kernel image via BIOS calls
> and "10,000 years ago" (ie, I've encountered this problem once, on my
> very first Linux install, RH3.0.3, and then "nevermore" despite I've
> been using LILO all the time), the BIOS couldn't load anything beyond
> "the 1024 cylinder boundary" (504M). Hence, a kernel supposed to be
> loaded by LILO had to be located in the first 504M of a disk. This
> becomes a problem when dual-booting similarly ancient "other PC OSes"
> (in my case, OS/2 Warp 4) which insist on residing on the first primary
> partition.

The 1024 cylinder boundary was why a separate /boot partition at the start
of the disc became common, but still doesn't explain why an initrd.img
became necessary. I used to know this stuff but it was a long time ago :-)

John
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Giving Devuan sans-initramfs capabilities

[richard lucassen]

On Fri, 1 Jan 2016 18:46:05 +
John Rigg  wrote:

> The 1024 cylinder boundary was why a separate /boot partition at the
> start of the disc became common, but still doesn't explain why an
> initrd.img became necessary. I used to know this stuff but it was a
> long time ago :-)

And after all I would certainly not give up a seperate /boot fs. A
separate /boot fs is very handy when running multi Linux system sharing
the same /boot (e.g. in my case, the lilo.conf is there and is
symlinked from all /etc/ directories)

I have 2 Devuan instances on two partitions. When I fsck up
the Devuan running on /dev/sda5 I can always boot into the working one
on /dev/sda3 and correct the mistakes I made on sda5

-- 
___
It is better to remain silent and be thought a fool, than to speak
aloud and remove all doubt.

+--+
| Richard Lucassen, Utrecht|
+--+
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Giving Devuan sans-initramfs capabilities

[Rainer Weikusat]

richard lucassen  writes:
> Rainer Weikusat  wrote:
>> > Plus the drivers for various hardware like cciss devices, just
>> > having ext4 built in is not enough. Wouldn't it be better to have a
>> > simple initramfs with just the apropiate modules for the hardware?
>> 
>> No computer I've either been using privately or professionally ever
>> suddenly grew a new motherboard (simplification) overnight. Hence,
>> they're all running kernels with the drivers and filesystems necessary
>> for booting compiled in.
>
> Of course, but I presume that we're talking about a kernel that will be
> distributed by Devuan. If you build in hardware drivers for all
> different types of hardware, the kernel gets somewhat big IMHO ;-)

Some signals crossed here. I was trying to explain that "a distribution"
has to use initrd/ initramfs because of problems specific to
distribution kernels but that individual users don't have to use this
mechanism if they don't want to because they can just compile a kernel
which will work with their hardware (which is usually rather static).
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Giving Devuan sans-initramfs capabilities

[John Rigg]

On Fri, Jan 01, 2016 at 08:02:42PM +0100, richard lucassen wrote:
> And after all I would certainly not give up a seperate /boot fs. A
> separate /boot fs is very handy when running multi Linux system sharing
> the same /boot (e.g. in my case, the lilo.conf is there and is
> symlinked from all /etc/ directories)
> 
> I have 2 Devuan instances on two partitions. When I fsck up
> the Devuan running on /dev/sda5 I can always boot into the working one
> on /dev/sda3 and correct the mistakes I made on sda5

I've used a similar setup in the past, with a development system on
one partition and a standard system on another. It's another reason why
I like to keep /boot in a separate partition.

John
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Giving Devuan sans-initramfs capabilities

[richard lucassen]

On Fri, 01 Jan 2016 19:05:24 +
Rainer Weikusat  wrote:

> > Of course, but I presume that we're talking about a kernel that
> > will be distributed by Devuan. If you build in hardware drivers for
> > all different types of hardware, the kernel gets somewhat big
> > IMHO ;-)
> 
> Some signals crossed here. I was trying to explain that "a
> distribution" has to use initrd/ initramfs because of problems
> specific to distribution kernels but that individual users don't have
> to use this mechanism if they don't want to because they can just
> compile a kernel which will work with their hardware (which is
> usually rather static).

Ok, I think we agree. But as OP said: it would be very nice to get rid
of initramfs. But for a distribution kernel this would be almost
undoable. So what about the idea to just have an initrd containing all
necessary modules for mounting / ? The rest can be loaded once the / fs
has been mounted.

-- 
___
It is better to remain silent and be thought a fool, than to speak
aloud and remove all doubt.

+--+
| Richard Lucassen, Utrecht|
+--+
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Giving Devuan sans-initramfs capabilities

[Didier Kryn]

Le 01/01/2016 20:05, Rainer Weikusat a écrit :

richard lucassen  writes:

Rainer Weikusat  wrote:

Plus the drivers for various hardware like cciss devices, just
having ext4 built in is not enough. Wouldn't it be better to have a
simple initramfs with just the apropiate modules for the hardware?

No computer I've either been using privately or professionally ever
suddenly grew a new motherboard (simplification) overnight. Hence,
they're all running kernels with the drivers and filesystems necessary
for booting compiled in.

Of course, but I presume that we're talking about a kernel that will be
distributed by Devuan. If you build in hardware drivers for all
different types of hardware, the kernel gets somewhat big IMHO ;-)

Some signals crossed here. I was trying to explain that "a distribution"
has to use initrd/ initramfs because of problems specific to
distribution kernels but that individual users don't have to use this
mechanism if they don't want to because they can just compile a kernel
which will work with their hardware (which is usually rather static).



There might be an optional kernel featuring sata, scsi and a few 
popular filesystems. That would match the vast majority of cases.



___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng