-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
Alexander E. Patrakov wrote:
> Isn't /dev/md_$real_name normally a symlink to /dev/md/$real_name?
I was thinking they were either copies or hardlinks. Let me fire up
qemu again and check for sure, though.
...Nope, you're right, they're symlinks
Bryan Kadzban wrote:
> Not sure what the testing came up with, but I figured out a way to get
> it to work:
>
Congratulations - you did more than Debian. They work only with
/dev/md raids, not with named ones.
> mkdir /dev/md
>
> for array in /dev/md[0-9]* ; do
> # subshell so the $MD_* var
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
Alexander E. Patrakov wrote:
>> The one sticking point is the same sticking point I had with dmraid
>> -- how do you get the /dev/md/* named device nodes to be recreated
>> once the initramfs is finished, from the system bootscripts?
>
> I think
Bryan Kadzban wrote:
> Well, my impression of EVMS is that it's just a different toolkit on top
> of the LVM2 kernel driver (or at least, that's all it is *now*; it used
> to be a different driver too). I'd be inclined to punt it, at least for
> now.
This is a different userspace on top of the de
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
Alexander E. Patrakov wrote:
> I wrote:
>> Bryan Kadzban wrote:
>>
>>> Anything else that it should support?
>>
>> 1) Some users may want to use EVMS instead of LVM2. The packages
>> conflict, but on-disk formats are the same. Unfortunately, I a
I wrote:
> Bryan Kadzban wrote:
>
>> Anything else that it should support?
>
> 1) Some users may want to use EVMS instead of LVM2. The packages conflict,
> but on-disk formats are the same. Unfortunately, I am not an EVMS specialist
> (and it is not on the CD), so no immediate help is available
Bryan Kadzban wrote:
> Anything else that it should support?
1) Some users may want to use EVMS instead of LVM2. The packages conflict,
but on-disk formats are the same. Unfortunately, I am not an EVMS specialist
(and it is not on the CD), so no immediate help is available.
2) Software RAID (w
Bryan Kadzban wrote:
> I'm a bit more interested in what types of setups the initramfs needs to
> support, though. From the initial bug, it sounds like root-on-LVM2 and
> root-on-dmraid (and combinations of the two) require it. It looks like
> hibernation also requires it (to fire up the hibernat
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
Dan Nicholson wrote:
> Simon Geard has been using your initramfs setup.
Uh oh, a user! :-P
(Nah, just kidding. It should be working fine now, especially for a
non-LVM and non-dmraid setup.)
> If you have anything specific you want tested, may
On 7/7/07, Bryan Kadzban <[EMAIL PROTECTED]> wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: RIPEMD160
>
> Bryan Kadzban wrote:
> >> 3) Run "hibernate" and boot again.
> >
> > This will be the real test, of course -- I may get to it tomorrow, or
> > it may be on Saturday (assuming nothing else
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
Bryan Kadzban wrote:
>> 3) Run "hibernate" and boot again.
>
> This will be the real test, of course -- I may get to it tomorrow, or
> it may be on Saturday (assuming nothing else comes up). Will post
> back once I get something committed and te
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
Alexander E. Patrakov wrote:
> Install the "hibernate-script" package, version 1.91 (version 1.93
> has a bug, and I have not tested any later versions):
> http://at-mirror.suspend2.net/downloads/all/hibernate-script-1.91.tar.gz
OK, I saw that i
Bryan Kadzban wrote:
> Is there any downside that you know of if they don't get deactivated?
> If not, it's simpler to leave them up.
I don't know the downside.
>> Things become a bit more complicated if there is no /boot partition.
>
> I'd be happy with requiring a /boot partition, but I'm not
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
Alexander E. Patrakov wrote:
> Create filesystems on /dev/hda1, /dev/myvg/{root,home}, mount them,
> transfer LFS there. Swap on LVM should also work out of the box.
I created LVM on /dev/mapper/hpt*2, leaving /dev/mapper/hpt*1 as /boot.
I then c
Bryan Kadzban wrote:
> Is there any kind of qemu setup I can do to test LVM? Or should I just
> start doing some reading? (Maybe it's obvious how it's supposed to
> work.)
LVM is very easy as long as you have a /boot partition. I.e., create a
virtual disk and partition it as follows:
/dev/hda1
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
Alexander E. Patrakov wrote:
> Bryan Kadzban wrote:
>> And I can't get at the initramfs's /dev/mapper/hpt* device files
>> from the real system, so I can't just copy them. (Plus that'd be a
>> problem when the udev script mounts its tmpfs/ramfs o
Bryan Kadzban wrote:
> And I've checked in something that sort-of works. It runs through the
> initramfs without errors, and boots up and starts running the real init.
> However, if I activate the dmraid disk inside the initramfs, it won't
> re-activate once I hand control off to the real system.
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
Bryan Kadzban wrote:
> And I haven't done much with qemu other than build a pair of initial
> 4G disk image files with the RAID signatures. I haven't actually
> booted up the LiveCD on it yet.
OK, I got qemu running (after recompiling it with gc
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
Alexander E. Patrakov wrote:
> Bryan Kadzban wrote:
>> I think I already have qemu running, so that should help with that.
>> It'll take some setup, but this should help with testing that
>> stuff. Thanks!
>
> Is there any progress?
>
Not on th
Bryan Kadzban wrote:
> On Tue, Jun 19, 2007 at 06:46:20PM +0600, Alexander E. Patrakov wrote:
>> You can test dmraid even without the corresponding hardware. Simply install
>> qemu or any other emulator
>
> I think I already have qemu running, so that should help with that.
> It'll take some set
On Tue, Jun 19, 2007 at 06:46:20PM +0600, Alexander E. Patrakov wrote:
> Debian users of initramfs-tools can choose which set of modules to include
> in the initramfs via config file. Yaird even guesses this information
> automatically at initramfs build time by looking into sysfs, but (as a
> r
Bryan Kadzban wrote:
I have it copying all kernel modules into the initramfs, which ends up
making it enormous if I run it after installing the nvidia module. (The
nvidia module is 9M. Non-nvidia modules total up to about another 8-9M
uncompressed on my system. The compressed initramfs is abou
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
Dan Nicholson wrote:
> Nice to see this come to light. It's needed, not just for LVM, but
> for the general problem of "I want to make a generic modular kernel".
True. The current book doesn't really support modular kernels, but
that's not neces
Nice to see this come to light. It's needed, not just for LVM, but for
the general problem of "I want to make a generic modular kernel".
I didn't seriously look yet, but just skimmed the scripts. Looks good
for a start. There are tons of features that could be added, but a
simple dedicated root is
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
Not sure how many people read lfs-book, but Alexander brought up an
issue with LFS in bug #2033. Upstream (by which I mean the kernel devs)
say that basically any system needs to have support for an initramfs for
several kernel-supported setups t
25 matches
Mail list logo
