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
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
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
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 sy
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
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 howt
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
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 :)
_
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
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.
Didie
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 th
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.
> > >
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
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 ex
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 motiv
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
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? Non
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-0
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
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
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
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,
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
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'
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 sou
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
>
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
> >int
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 me
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 des
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
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
> > > >
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 oth
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
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
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 underst
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 loc
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 inje
> 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 (whic
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
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
>
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 tha
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. Th
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
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
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
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 somethin
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
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 ke
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 u
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
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.
>
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.
>
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 neces
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 file
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 j
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
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 d
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 ima
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 maintain
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://ma
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 w
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, s
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
e
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
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 thin
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 a
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
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 sour
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 mi
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
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/
--
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 j
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 mo
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?
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 cr
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
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 bee
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
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 f
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
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
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 i
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
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 BI
Steve Litt writes:
[...]
> If / is formatted ext4, it can be mounted directly by a kernel with ext4
> drivers, no initramfs needed.
The only reason why 'initramfs' is ever needed is because the kernel can
mount the 'real' root filesystem without loading a/ some additional
files first. This is a
Steve Litt wrote:
> This idea came to me while I wrote an anti-merge rant a few minutes
> ago...
I was going to reply to that, I'll reply here instead ...
First off, thanks for answering a question I hadn't asked but had always
wondered about the answer to. I "sort of" knew what initramfs was,
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 abo
Hi all,
This idea came to me while I wrote an anti-merge rant a few minutes
ago...
You know, times have changed. Today, a 256GB SSD can be had for less
than $100, and can easily, trivially, hold the entire operating system.
One excellent configuration is to have the root partition, hosted by a
S
88 matches
Mail list logo
