Kernel 2.6.21.3 (from -current) - Slackware

This is a discussion on Kernel 2.6.21.3 (from -current) - Slackware ; I just tried to run Pat's kernel from -current. I wasn't able to achieve immediate success because I boot with a custom initrd. The kernel from current seems to provide support for ext2 filesystems as a module. This is not ...

+ Reply to Thread
Results 1 to 15 of 15

Thread: Kernel 2.6.21.3 (from -current)

  1. Kernel 2.6.21.3 (from -current)

    I just tried to run Pat's kernel from -current. I wasn't able to achieve
    immediate success because I boot with a custom initrd. The kernel from
    current seems to provide support for ext2 filesystems as a module. This is
    not ideal, IMO, because my custom initrd is using ext2. If any of you have
    pull with Pat, I'd appreciate ext2 being "built into" the kernel.

    If not, then this is a word to wise when the loader issues a kernel panic
    when booting with an initrd.

    BTW, what filesystem is used by -current's mkinitrd?

    --
    Douglas Mayne

  2. Re: Kernel 2.6.21.3 (from -current)

    On Tue, 12 Jun 2007 18:44:24 -0600, Douglas Mayne wrote:

    >I just tried to run Pat's kernel from -current. I wasn't able to achieve
    >immediate success because I boot with a custom initrd. The kernel from
    >current seems to provide support for ext2 filesystems as a module. This is
    >not ideal, IMO, because my custom initrd is using ext2.


    I don't run Pat's kernels once I have a custom kernel in place, the latest
    -current boots fine here:

    ~$ uname -a
    Linux slack3 2.6.21.3-smp #2 SMP Thu May 24 21:09:15 CDT 2007 i686 i686 i386 GNU/Linux

    Grant.
    --
    http://bugsplatter.mine.nu/

  3. Re: Kernel 2.6.21.3 (from -current)

    Douglas Mayne wrote:

    > If any of you have pull with Pat, I'd appreciate ext2 being "built
    > into" the kernel.


    That's a laugh. Expect most of the pgp trash trollers to jump in
    now pretending that they have "pull" with "Pat." The worst of the
    bunch is the hillbilly who goes by the name of The Coward Hicks.
    During PV's illness a while ago, The Coward actually tried to take
    over the distribution. It was hilarious and his motives were
    totally transparent to all the posters in this ng.

    cordially, as always,

    rm

  4. Re: Kernel 2.6.21.3 (from -current)

    On 2007-06-13, Douglas Mayne wrote:
    > I just tried to run Pat's kernel from -current. I wasn't able to achieve
    > immediate success because I boot with a custom initrd. The kernel from
    > current seems to provide support for ext2 filesystems as a module. This is
    > not ideal, IMO, because my custom initrd is using ext2. If any of you have
    > pull with Pat, I'd appreciate ext2 being "built into" the kernel.
    >
    > If not, then this is a word to wise when the loader issues a kernel panic
    > when booting with an initrd.
    >
    > BTW, what filesystem is used by -current's mkinitrd?



    Without further information, I can only offer a halfway decent guess;
    however, it sounds as if you're attempting to use the kernel from -current
    in a manner it's not intended to be used. I'm guessing that you're either
    trying to use it on an 11.0 system or that you're using it in an incomplete
    -current environment.

    Do this:
    # gzip -d /boot/initrd.gz
    # file /boot/initrd
    If you get this:
    initrd: Linux rev 1.0 ext2 filesystem data
    then there's your problem - the initrd was created with the mkinitrd tools
    from 11.0, which build an ext2 filesystem (since the generic kernels in 11.0
    included ext2 statically built).
    The output from an initrd built with -current's mkinitrd should be this:
    initrd: ASCII cpio archive (SVR4 with no CRC)

    As a side note, this is another in the long list of reasons why people should
    not attempt to use -current packages on a stable release of Slackware - unless
    you follow the changes closely and know exactly what they are and what they
    mean, you will get bitten eventually (and in most cases, sooner rather than
    later).

    RW

  5. Re: Kernel 2.6.21.3 (from -current)

    On Wed, 13 Jun 2007 19:59:15 +0000, Robby Workman wrote:

    > On 2007-06-13, Douglas Mayne wrote:
    >> I just tried to run Pat's kernel from -current. I wasn't able to achieve
    >> immediate success because I boot with a custom initrd. The kernel from
    >> current seems to provide support for ext2 filesystems as a module. This is
    >> not ideal, IMO, because my custom initrd is using ext2. If any of you have
    >> pull with Pat, I'd appreciate ext2 being "built into" the kernel.
    >>
    >> If not, then this is a word to wise when the loader issues a kernel panic
    >> when booting with an initrd.
    >>
    >> BTW, what filesystem is used by -current's mkinitrd?

    >
    >
    > Without further information, I can only offer a halfway decent guess;
    > however, it sounds as if you're attempting to use the kernel from -current
    > in a manner it's not intended to be used. I'm guessing that you're either
    > trying to use it on an 11.0 system or that you're using it in an incomplete
    > -current environment.
    >
    > Do this:
    > # gzip -d /boot/initrd.gz
    > # file /boot/initrd
    > If you get this:
    > initrd: Linux rev 1.0 ext2 filesystem data
    > then there's your problem - the initrd was created with the mkinitrd tools
    > from 11.0, which build an ext2 filesystem (since the generic kernels in 11.0
    > included ext2 statically built).
    > The output from an initrd built with -current's mkinitrd should be this:
    > initrd: ASCII cpio archive (SVR4 with no CRC)
    >
    > As a side note, this is another in the long list of reasons why people should
    > not attempt to use -current packages on a stable release of Slackware - unless
    > you follow the changes closely and know exactly what they are and what they
    > mean, you will get bitten eventually (and in most cases, sooner rather than
    > later).
    >
    > RW
    >

    Thanks for the reply, and for the information that -current is using a
    cpio format for its initrd. As I said, I use a custom initrd which is
    using ext2 as its filesystem. As you say, I was bit sooner, rather than
    later on the fact that PV's kernel wouldn't mount it, ending with a kernel
    panic. I looked at the change log for current, and it clearly states that
    an initrd is required to boot when using that kernel- but it doesn't state
    that the initrd must be cpio. Thanks for the info.

    I was attempting to save a long compilation cycle for a simple check, but
    the lack of built in ext2 support stymied the quickest solution. Well, I
    am back running after a recompile cycle, with ext2 built in:

    # cat /proc/version
    Linux version 2.6.21.5-smp (root@slackbox) (gcc version 3.4.6) #1 SMP Tue
    Jun 12 18:44:49 MDT 2007

    I agree with what you are saying about mixing packages for the most part,
    but the kernel itself may be an exception. Configuring all of the options
    for the kernel is tricky, and PV's configuration is good enough for me in
    most cases. However, I still think it is a good idea to use ext2 with
    initrd's because of the ability to mount them (loopback) for testing, etc.
    ext2 is less popular than it used to be, I guess.

    Going Offtopic...
    The primary way that I am using initrd's is to enable startup for
    encrypted root filesystems:
    http://www.xmission.com/~ddmayne2/erf-dm/

    Thanks again. Thanks for your work and for your packaging, especially
    for OpenOffice. That has come in handy a lot lately.

    --
    Douglas Mayne

  6. Re: Kernel 2.6.21.3 (from -current)

    On Wed, 13 Jun 2007 19:59:15 GMT, Robby Workman wrote:
    ....
    >As a side note, this is another in the long list of reasons why people should
    >not attempt to use -current packages on a stable release of Slackware - unless
    >you follow the changes closely and know exactly what they are and what they
    >mean, you will get bitten eventually (and in most cases, sooner rather than
    >later).


    I ran 'upgradepkg /path/to/slackware-current/slackware/*/*tgz' into a
    slackware-11.0 VM (instead of a slack-current VM) and can confirm it
    kills slack-11 stone silly dead )

    Grant.
    --
    http://bugsplatter.mine.nu/

  7. Re: Kernel 2.6.21.3 (from -current)

    On Thu, 14 Jun 2007 10:19:29 +1000, Grant wrote:

    > On Wed, 13 Jun 2007 19:59:15 GMT, Robby Workman wrote:
    > ...
    >>As a side note, this is another in the long list of reasons why people should
    >>not attempt to use -current packages on a stable release of Slackware - unless
    >>you follow the changes closely and know exactly what they are and what they
    >>mean, you will get bitten eventually (and in most cases, sooner rather than
    >>later).

    >
    > I ran 'upgradepkg /path/to/slackware-current/slackware/*/*tgz' into a
    > slackware-11.0 VM (instead of a slack-current VM) and can confirm it
    > kills slack-11 stone silly dead )
    >
    > Grant.
    >

    The kernel would be affected by that tactic (upgradepkg). You'll need an
    initrd to boot with the 2.6.21.3 kernel in current. If you provided the
    correct initrd, then I think it might boot, and not be "most sincerely
    dead." Then again, I haven't downloaded -current (as of now).

    I tempted to test for myself, with just the "a" packages. It could be an
    interesting experiment.

    --
    Douglas Mayne

  8. Re: Kernel 2.6.21.3 (from -current)

    On 2007-06-14, Douglas Mayne wrote:
    > On Thu, 14 Jun 2007 10:19:29 +1000, Grant wrote:
    >
    >> On Wed, 13 Jun 2007 19:59:15 GMT, Robby Workman wrote:
    >> ...
    >>>As a side note, this is another in the long list of reasons why people should
    >>>not attempt to use -current packages on a stable release of Slackware - unless
    >>>you follow the changes closely and know exactly what they are and what they
    >>>mean, you will get bitten eventually (and in most cases, sooner rather than
    >>>later).

    >>
    >> I ran 'upgradepkg /path/to/slackware-current/slackware/*/*tgz' into a
    >> slackware-11.0 VM (instead of a slack-current VM) and can confirm it
    >> kills slack-11 stone silly dead )
    >>
    >> Grant.
    >>

    > The kernel would be affected by that tactic (upgradepkg). You'll need an
    > initrd to boot with the 2.6.21.3 kernel in current. If you provided the
    > correct initrd, then I think it might boot, and not be "most sincerely
    > dead." Then again, I haven't downloaded -current (as of now).



    No, it would be "most sincerely dead" :-)

    The upgrade will proceed in alphabetical order. Since "b" arrives before
    "g" the bash package will be upgraded before glibc-solibs. Since bash
    is linked to libc.so.6 (part of glibc-solibs [and glibc, but that's another
    discussion], it will promptly stop working. Even if it continues to run
    (since it's already loaded into memory), you'll find that any post-install
    scripts that spawn a subshell, as well as any future package upgrades,
    will not work. At that point, you'll be looking for this:
    http://rlworkman.net/howtos/glibc-recovery

    Have fun! :-)
    RW

  9. Re: Kernel 2.6.21.3 (from -current)

    On 2007-06-13, Douglas Mayne wrote:
    >
    > Thanks again. Thanks for your work and for your packaging, especially
    > for OpenOffice. That has come in handy a lot lately.



    You're welcome - glad to hear it. On the subject of openoffice.org,
    I just pushed new 2.2.1 packages two days ago, and the script on
    SlackBuilds.org has also been updated (for those of you who prefer
    to make the package yourself).

    RW

  10. Re: Kernel 2.6.21.3 (from -current)

    On 2007-06-14, Grant wrote:
    > On Wed, 13 Jun 2007 19:59:15 GMT, Robby Workman wrote:
    > ...
    >>As a side note, this is another in the long list of reasons why people should
    >>not attempt to use -current packages on a stable release of Slackware - unless
    >>you follow the changes closely and know exactly what they are and what they
    >>mean, you will get bitten eventually (and in most cases, sooner rather than
    >>later).

    >
    > I ran 'upgradepkg /path/to/slackware-current/slackware/*/*tgz' into a
    > slackware-11.0 VM (instead of a slack-current VM) and can confirm it
    > kills slack-11 stone silly dead )
    >


    Yep. This is why UPGRADE.TXT exists on the mirrors.

    Now, if we can just figure out a way to break that R34DM3 encryption
    for the newbs...

    RW

  11. Re: Kernel 2.6.21.3 (from -current)

    On Tue, 12 Jun 2007 18:44:24 -0600, Douglas Mayne wrote:

    >
    > BTW, what filesystem is used by -current's mkinitrd?
    >

    Pardon my responding to my own question here. I wanted to add a few
    notes to this thread for my own benefit. Robby Workman responded that
    mkinitrd creates an initrd with these properties:

    cpio archive (SVR4 with no CRC)

    I don't use cpio often. The exact command used by slackware's initrd is
    shown below:

    find . | cpio -o -H newc | gzip -9c > $OUTPUT_IMAGE

    With a custom initrd mounted loopback, then it can be converted to
    the required format using this sequence:

    # mount -o loop initrd.img /mnt/new_initrd
    # (cd /mnt/new_initrd && find . | cpio -o -H newc) \
    | gzip -9c >initrd.cpio.gz

    --
    Douglas Mayne

  12. Re: Kernel 2.6.21.3 (from -current)

    Douglas Mayne schreef:


    > Going Offtopic...
    > The primary way that I am using initrd's is to enable startup for
    > encrypted root filesystems:
    > http://www.xmission.com/~ddmayne2/erf-dm/


    Slackware 12.0RC1 is able to install itself to an encrypted root
    partition. It also supports encrypted swap out of the box.
    The technology used is that of the LUKS-enhanced version of cryptsetup
    - the former cryptsetup-luks has replaced the old cryptsetup and uses
    it's name as of now.
    There is a README in the making (at least I hope to finish it before
    end of the weekend) that describes the extra manual steps you need to
    take during install.
    Moving an existing Slackware installation to an encrypted partition
    should also be possible, but you would need extra free space to
    migrate your data.
    The advantage of LUKS is that you can change the passphrase that
    unlocks the encrypted volume without having to re-encrypt the data
    partition.
    The README_LVM.TXT in the root of -current explains some of the tricks
    used for encrypted partitions - both installing to LVM and/or to an
    encrypted volume uses device-mapper.
    Read Slackware-current's 'mkinitrd' man page on how to add LVM and
    crypt support to your initrd.

    Eric

  13. Re: Kernel 2.6.21.3 (from -current)

    On Fri, 15 Jun 2007 19:31:53 +0200, Eric Hameleers wrote:

    > Douglas Mayne schreef:
    >
    >
    >> Going Offtopic...
    >> The primary way that I am using initrd's is to enable startup for
    >> encrypted root filesystems:
    >> http://www.xmission.com/~ddmayne2/erf-dm/

    >
    > Slackware 12.0RC1 is able to install itself to an encrypted root
    > partition. It also supports encrypted swap out of the box.
    > The technology used is that of the LUKS-enhanced version of cryptsetup
    > - the former cryptsetup-luks has replaced the old cryptsetup and uses
    > it's name as of now.
    > There is a README in the making (at least I hope to finish it before
    > end of the weekend) that describes the extra manual steps you need to
    > take during install.
    > Moving an existing Slackware installation to an encrypted partition
    > should also be possible, but you would need extra free space to
    > migrate your data.
    > The advantage of LUKS is that you can change the passphrase that
    > unlocks the encrypted volume without having to re-encrypt the data
    > partition.
    > The README_LVM.TXT in the root of -current explains some of the tricks
    > used for encrypted partitions - both installing to LVM and/or to an
    > encrypted volume uses device-mapper.
    > Read Slackware-current's 'mkinitrd' man page on how to add LVM and
    > crypt support to your initrd.
    >
    > Eric
    >

    Thanks for the note. I'll take a look at it. I haven't used LUKS as of
    yet. I am glad that cryptsetup and the other tools libgcrypt, libgpg-error
    have been added to -current. Should these libraries be in "a" ?

    Going offtopic:
    I have an update to my project which uses gpg messages to unlock the
    device mapper key and encryption parameters. I guess LUKS is
    another tool to do something similar. I hope I'm not reinventing the
    wheel too much. In my system, multiple users are accomodated by having
    them listed as recipients for a gpg message. That way multiple users can
    be accomodated without sharing a common passphrase, while allowing for
    passphrase recovery, etc. The authorized users unlock the disk's
    encryption using their standard gpg passphrase and this helps to avoid
    the end-user password overload phenomenon. If for whatever reason, an
    authorized user should be deauthorized (have his authorization revoked),
    then the disk should be re-encrypted for maximum safety. I don't know how
    this compares to LUKS. From what I've heard, other disk encryption systems
    (such as pointsec) recommend re-encrypting when a given user is revoked.

    I hope to document the update and post it before too long. I posted some
    of the updated scripts here (if you are interested):

    linuxrc:
    http://groups.google.com/group/alt.t...9c438b53944b21

    get_gpg_message.scr:
    http://groups.google.com/group/alt.t...bcfac5ba660817

    def_inp:
    http://groups.google.com/group/alt.t...02d577e6a30104

    Thanks for the info.

    --
    Douglas Mayne

  14. Re: Kernel 2.6.21.3 (from -current)

    On Wed, 13 Jun 2007 18:29:40 -0600, Douglas Mayne wrote:

    > The kernel would be affected by that tactic (upgradepkg). You'll need an
    > initrd to boot with the 2.6.21.3 kernel in current. If you provided the
    > correct initrd, then I think it might boot, and not be "most sincerely
    > dead." Then again, I haven't downloaded -current (as of now).


    > I tempted to test for myself, with just the "a" packages. It could be an
    > interesting experiment.


    I sure am glad I build my own custom kernels and never need an "initrd".

    If I couldn't boot I'd use a live CD, chroot and build one like that.

    Geez in the past I've had to pull the case covers, and hang the HD off of
    my mobo controller so I could patch the kernel for Promise EIDE
    controllers.


    --
    Linux Help: http://rsgibson.com/linux.htm
    Email - rsgibson@verizon.borg
    Replace borg with net


  15. Re: Kernel 2.6.21.3 (from -current)

    On Fri, 15 Jun 2007 08:40:58 -0600, Douglas Mayne wrote:

    > On Tue, 12 Jun 2007 18:44:24 -0600, Douglas Mayne wrote:
    >
    >>
    >> BTW, what filesystem is used by -current's mkinitrd?
    >>

    > Pardon my responding to my own question here. I wanted to add a few
    > notes to this thread for my own benefit.
    >


    >

    A few more notes...

    Kernel startup using initramfs is quite different from the initrd
    based startup that I have used up until now.

    0. I found this link with an overview of initramfs
    http://linuxdevices.com/articles/AT4017834659.html

    1. ramfs is similar to tmpfs. The kernel documentation discusses
    initramfs in this file:
    Documentation/filesystems/ramfs-rootfs-initramfs.txt

    2. The kernel startup executes init, not linuxrc. Override with rdinit=
    on grub command line. Other kernel parameters are not used, (except "rw" ?)

    3. Final startup from initramfs uses switch_root, not pivot_root.
    switch_root will free the memory used by initrd, which may not be what is
    wanted.

    --
    Douglas Mayne

+ Reply to Thread