Kernel 2.6.21.3 (from -current)
Douglas Mayne
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
Grant
>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/
r...@biteme.org
> 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
Robby Workman
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
Douglas Mayne
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
Grant
...
>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 :o)
Grant.
--
http://bugsplatter.mine.nu/
Douglas Mayne
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
Robby Workman
> On Thu, 14 Jun 2007 10:19:29 +1000, Grant wrote:
>
>> On Wed, 13 Jun 2007 19:59:15 GMT, Robby Workman <newsg...@rlworkman.net> 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 :o)
>>
>> 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
Robby Workman
>
> 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
Robby Workman
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
Douglas Mayne
<snip>
>
> BTW, what filesystem is used by -current's mkinitrd?
>
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
Eric Hameleers
> 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
Douglas Mayne
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.test/msg/7d9c438b53944b21
get_gpg_message.scr:
http://groups.google.com/group/alt.test/msg/60bcfac5ba660817
def_inp:
http://groups.google.com/group/alt.test/msg/a002d577e6a30104
Thanks for the info.
--
Douglas Mayne
Ron Gibson
> 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 - rsgi...@verizon.borg
Replace borg with net
Douglas Mayne
> On Tue, 12 Jun 2007 18:44:24 -0600, Douglas Mayne wrote:
> <snip>
>>
>> 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.
>
<snip>
>
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