salix with lvm and luks

[gapan]

Naming other distributions here in SALIX forums is not very well seen

Fair enough but I don't see why.

Me neither. It's just one of his usual ramblings.

Trying to understand what is really needed to add support for it. cryptsetup and mdadm can easily be added to the default installation, but why kernel-generic? What's the problem with kernel-huge? The installation procedure can also be easily tweaked to ask for a reboot or exit the installation. I read this part:

Older BIOS can not boot an initrd image if you use the 'huge' kernel from salix.

but the question is why? And why does it work with kernel-generic?

[damNageHack]

It is nothing about rambling, flame war or something like that for me. I am very sorry if it seems to be intended as so.

The main question is *who* will write the first lvm frontend application (if so called) for Salix and is it really needed embedded into default setup

Just my 5ct.

[gapan]

It is nothing about rambling, flame war or something like that for me. I am very sorry if it seems to be intended as so.

No you're not.

The main question is *who* will write the first lvm frontend application (if so called) for Salix

You can do that since you're so much interested in it.

and is it really needed embedded into default setup

No.

[pwatk]

Trying to understand what is really needed to add support for it. cryptsetup and mdadm can easily be added to the default installation, but why kernel-generic? What's the problem with kernel-huge? The installation procedure can also be easily tweaked to ask for a reboot or exit the installation.

I suppose it doesn't matter but since your going to need an initrd anyway, you might as well use the generic kernel! On the other hand, the only real difference (apart from size) is seeing errors generated by instmod trying to install built-in modules.

You don't even need cryptsetup and mdadm if you just temporarily copy over the static versions from the installation ramdisk before running mkinitrd.
Other things to consider are usb keyboards (ehci-hcd, uhci-hcd, ohci-hcd, usbhid), hibernation and the possibility someone will add in a new device (e.g. a sata cd/dvd-rom). I just did this and in throws everything out. Using UUID's would solve this but I don't know how to implement this (on the "to do when time stands still" list).

[gapan]

I suppose it doesn't matter but since your going to need an initrd anyway, you might as well use the generic kernel! On the other hand, the only real difference (apart from size) is seeing errors generated by instmod trying to install built-in modules.

But it should work with kernel-huge, right? One can install kernel-huge and then, after the installation is done, can replace it with kernel-generic or whatever.

You don't even need cryptsetup and mdadm if you just temporarily copy over the static versions from the installation ramdisk before running mkinitrd.

So cryptsetup and mdadm are not needed on the installed system, they should just be available during installation, which they already are?

Other things to consider are usb keyboards (ehci-hcd, uhci-hcd, ohci-hcd, usbhid),

But these aren't issues at all, if kernel-huge is used, right?

hibernation and the possibility someone will add in a new device (e.g. a sata cd/dvd-rom). I just did this and in throws everything out. Using UUID's would solve this but I don't know how to implement this (on the "to do when time stands still" list).

Are we still talking about the installation here? What does the installation have to do with any changes you might do after it's done?


It seems to me that the only thing that is really needed is for the installation to not automatically reboot, but offer an option to reboot or exit to command line.

[damNageHack]

LVM support is considered as default functionality nowadays.

I do realise that but writing a frontend to do it for you I'm sure isn't all that easy.

The main question is *who* will write the first lvm frontend application (if so called) for Salix

You can do that since you're so much interested in it.

There is for example EVMS from IBM. Not actively developed any more, but quite good GUI, unfortunately only for the "old" GTK1 available. Also, there are front-ends for ncurses and plain console.
I started another thread some times ago for EVMS, but I am too lazy to search for it ...

[pwatk]

I suppose it doesn't matter but since your going to need an initrd anyway, you might as well use the generic kernel! On the other hand, the only real difference (apart from size) is seeing errors generated by instmod trying to install built-in modules.

But it should work with kernel-huge, right? One can install kernel-huge and then, after the installation is done, can replace it with kernel-generic or whatever.

Yes but I do remember running into troubles at one point with the huge kernel and when I swapped to the generic kernel everything worked. It could have been my fault but I've used the generic kernel during installation ever since.

You don't even need cryptsetup and mdadm if you just temporarily copy over the static versions from the installation ramdisk before running mkinitrd.

So cryptsetup and mdadm are not needed on the installed system, they should just be available during installation, which they already are?

No but only if the user copies them from the installation ramdisk (and knows they're there) before chrooting. I would still include these packages to save any hassle.

Other things to consider are usb keyboards (ehci-hcd, uhci-hcd, ohci-hcd, usbhid),

But these aren't issues at all, if kernel-huge is used, right?

True.

hibernation and the possibility someone will add in a new device (e.g. a sata cd/dvd-rom). I just did this and in throws everything out. Using UUID's would solve this but I don't know how to implement this (on the "to do when time stands still" list).

Are we still talking about the installation here? What does the installation have to do with any changes you might do after it's done?

It seems to me that the only thing that is really needed is for the installation to not automatically reboot, but offer an option to reboot or exit to command line.

That and these few packages, yes

[gapan]

OK, expect the changes in the next iso.

[pwatk]

[lumak]

99% of the people trying to install salix on their system will have no problem using the 'huge' kernel

For the few 1% that actually try installing salix on an older system, the bios can not fit the initrd image within the 15 MB hole between inserting the kernel and some other stuff. At least according to the output from lilo.

From experience, I attempted a 'huge' kernel with an initrd on an old laptop that was designed to run with a max of 256MB of ram. It could not load the initrd image.

I'm sure most systems with at least 1 gig of ram should not have a problem. But then I'm not an expert.

Additionally, if you are trying to run salix on a system with less than a gig of ram, just give up now. Switch to Slackware 7 or something. You will probably have much more luck with that.

Oddly enough, my old laptop supported the smp architecture but then there have been smp capable systems since at least Pentium 3.