Upgrading kernel in Mandrake 10.0 - Mandrake

This is a discussion on Upgrading kernel in Mandrake 10.0 - Mandrake ; Hi, I have a router box with Mandrake 10.0. The system is heavily modified (in terms of networking setup and package versions), but I am still running a 2.6.8.1mdk kernel. I wanted to finally upgrade the kernel as well, so ...

+ Reply to Thread
Results 1 to 9 of 9

Thread: Upgrading kernel in Mandrake 10.0

  1. Upgrading kernel in Mandrake 10.0

    Hi,

    I have a router box with Mandrake 10.0. The system is heavily
    modified (in terms of networking setup and package versions),
    but I am still running a 2.6.8.1mdk kernel.

    I wanted to finally upgrade the kernel as well, so I downloaded
    2.6.18 sources, compiled them with ext3 and jbd as modules
    (/ is ext3), did a mkinitrd --with=ext3 --with=jbd, updated
    grub and... I am getting a "/dev/null: read-only filesystem"
    right after init boots (the error claims to be in line 1 of
    /etc/rc.sysinit). I couldn't figure what I did wrong.

    Passing a 'rw' option to the kernel the filesystem gets mounted
    but then fails on e2fsck (as it is mounted read-write).
    Commenting out fsck check in rc.sysinit the system does boot with
    the new kernel and works, but the solution is, erm, ugly.

    How do I properly upgrade a kernel in something as old as Mandrake 10.0?
    I can upgrade init scripts to recent ones, no problem, just need them to
    work.

    Thanks in advance,
    --
    tomasz k. jarzynka / 601 706 601 / tomee(a-t)kadu(d-o-t)net

    "Człowiek obdarowany został mową tylko po to, by ukrywać swoje myśli.
    -- Charles Maurice Talleyrand-Perigord"


  2. Re: Upgrading kernel in Mandrake 10.0

    On Thu, 19 Oct 2006 22:53:39 +0200, Tomek Jarzynka wrote:
    > How do I properly upgrade a kernel in something as old as Mandrake 10.0?


    I recommend clearing about 10 gig and do a clean install of Mandriva 2007
    if not Mandriva 2006 into the new 10 partition.

    That way fallback is your current install, if new install fails.

    > I can upgrade init scripts to recent ones, no problem, just need them to
    > work.


    For my dual nic firewall/NATing system, a few stats

    vendor_id : AuthenticAMD
    model name : AMD-K6(tm) 3D processor
    stepping : 12
    cpu MHz : 451.092
    cache size : 64 KB
    bogomips : 904.14


    $ free
    total used free shared buffers cached
    Mem: 255992 251280 4712 0 61540 146460
    -/+ buffers/cache: 43280 212712

    and it just works.
    $ cat /etc/release
    Mandriva Linux release 2007.0 (Official) for i586

  3. Re: Upgrading kernel in Mandrake 10.0

    Nudna wrotka - Bit Twister napisal w
    :

    > On Thu, 19 Oct 2006 22:53:39 +0200, Tomek Jarzynka wrote:
    >> How do I properly upgrade a kernel in something as old as Mandrake 10.0?

    > I recommend clearing about 10 gig and do a clean install of Mandriva 2007
    > if not Mandriva 2006 into the new 10 partition.
    > That way fallback is your current install, if new install fails.


    And spend months tweaking various scripts? I don't feel like it.
    Nevermind I can't really afford machine's downtime.

    --
    tomasz k. jarzynka / 601 706 601 / tomee(a-t)kadu(d-o-t)net

    "Dzięki crontab możemy spowodować, aby codziennie o północy budziły się
    demony
    -- Konrad R. Wągrowski"


  4. Re: Upgrading kernel in Mandrake 10.0

    On Fri, 20 Oct 2006 00:54:21 +0200, Tomek Jarzynka wrote:

    > And spend months tweaking various scripts?


    What tweaking, I have had to not do any tweaking.
    Custom scipts I add to /etc/rc.d

  5. Re: Upgrading kernel in Mandrake 10.0

    Nudna wrotka - Bit Twister napisal w
    :

    > On Fri, 20 Oct 2006 00:54:21 +0200, Tomek Jarzynka wrote:
    >> And spend months tweaking various scripts?

    > What tweaking, I have had to not do any tweaking.
    > Custom scipts I add to /etc/rc.d


    Network connection checks, GPRS backup link support, OpenVPN restarts,
    kernel-mode PPPoE, lighttpd, custom PHP, static RPM for backup and many
    many others.

    --
    tomasz k. jarzynka / 601 706 601 / tomee(a-t)kadu(d-o-t)net

    "Człowiek obdarowany został mową tylko po to, by ukrywać swoje myśli.
    -- Charles Maurice Talleyrand-Perigord"


  6. Re: Upgrading kernel in Mandrake 10.0

    On Fri, 20 Oct 2006 01:22:16 +0200, Tomek Jarzynka wrote:
    > Nudna wrotka - Bit Twister napisal w
    >:
    >
    >> On Fri, 20 Oct 2006 00:54:21 +0200, Tomek Jarzynka wrote:
    >>> And spend months tweaking various scripts?

    >> What tweaking, I have had to not do any tweaking.
    >> Custom scipts I add to /etc/rc.d

    >
    > Network connection checks,


    Yep, I created network_ck to run after nework and run
    service network restart
    if I cannot ping the gateway.

    > GPRS backup link support, OpenVPN restarts,
    > kernel-mode PPPoE, lighttpd, custom PHP, static RPM for backup and many
    > many others.


    Well sounds like you will need a testbed or play in the wee hours of
    the morning to migrate to new releases.

    You may want to read http://www.mandriva.com/security/productlifetime

  7. Re: Upgrading kernel in Mandrake 10.0

    On Thursday 19 October 2006 22:53, Tomek Jarzynka stood up and addressed the
    masses in /alt.os.linux.mandrake/ as follows...:

    > Hi,
    >
    > I have a router box with Mandrake 10.0. The system is heavily
    > modified (in terms of networking setup and package versions),
    > but I am still running a 2.6.8.1mdk kernel.


    Are you sure this is Mandrake 10.0 and not 10.1? The stock Mandrake 10.0
    kernel has version 2.6.3. Version 2.6.8.1mdk would be the kernel of
    Mandrake 10.1 instead - and a Cooker version too, judging by the low
    patchlevel number.

    > I wanted to finally upgrade the kernel as well, so I downloaded
    > 2.6.18 sources, compiled them with ext3 and jbd as modules
    > (/ is ext3), did a mkinitrd --with=ext3 --with=jbd, updated
    > grub and... I am getting a "/dev/null: read-only filesystem"
    > right after init boots (the error claims to be in line 1 of
    > /etc/rc.sysinit). I couldn't figure what I did wrong.


    /ext2/ and /ext3/ filesystems are automatically remounted read-only if there
    is some filesystem damage that you haven't repaired yet. You *should
    however be able to override this default via mount options in */etc/fstab.*

    The above all said, the fact that you can't write to */dev/null* also
    suggests that you're not running /udev,/ and that thus your kernel is
    trying to access the */dev/null* on your (read-only) root partition. I
    happen to be running Mandrake 10.0 myself, and the /udev/ version supplied
    with it does not use */dev* but */udev* to store its device special files -
    which sort of breaks the entire purpose.

    Again, this said, I have a few recommendations for you. Like I wrote in the
    paragraph above, I'm also running MDK 10.0, but with a /vanilla/ 2.6.17.13
    kernel.

    I would first of all recommend checking what is wrong with your root
    filesystem. Run /fsck/ on it from single-user mode - i.e. runlevel 1 - or
    from a rescue CD. Secondly, why go through the trouble of creating
    essential drivers such as /ext3/ and /jbd/ as modules and using
    an /initrd?/

    If you're going to be running a custom kernel, then it makes much more sense
    compiling such stuff into the kernel itself and doing without an /initrd/ -
    it's what I always do. The only stuff you really need to compile as
    modules - or omit from the configuration at all - is the stuff for which
    you have or need a proprietary driver, e.g. nVidia drivers, certain
    wireless network drivers, et al.

    > Passing a 'rw' option to the kernel the filesystem gets mounted
    > but then fails on e2fsck (as it is mounted read-write).


    Check the filesystem without that it is mounted, i.e. from a rescue CD.

    > Commenting out fsck check in rc.sysinit the system does boot with
    > the new kernel and works, but the solution is, erm, ugly.


    Check your */etc/fstab* for the numbers at the end of the record for your
    root filesystem. If you set the last number to 0, the filesystem won't get
    checked on boot.

    > How do I properly upgrade a kernel in something as old as Mandrake 10.0?
    > I can upgrade init scripts to recent ones, no problem, just need them to
    > work.


    Compile your kernel with the important stuff in-line, as I said. Don't use
    an /initrd./ And check that filesystem for damage first.

    --
    With kind regards,

    *Aragorn*
    (registered GNU/Linux user #223157)

  8. Re: Upgrading kernel in Mandrake 10.0

    Nudna wrotka - Aragorn napisal w
    :

    >> I have a router box with Mandrake 10.0. The system is heavily
    >> modified (in terms of networking setup and package versions),
    >> but I am still running a 2.6.8.1mdk kernel.


    > Are you sure this is Mandrake 10.0 and not 10.1? The stock Mandrake 10.0
    > kernel has version 2.6.3. Version 2.6.8.1mdk would be the kernel of
    > Mandrake 10.1 instead - and a Cooker version too, judging by the low
    > patchlevel number.


    Yes, probably it's a 10.1 (or was a 10.1, I recently even upgraded glibc
    to 2.4 and gcc to 4.1.1).

    > The above all said, the fact that you can't write to */dev/null* also
    > suggests that you're not running /udev,/ and that thus your kernel is
    > trying to access the */dev/null* on your (read-only) root partition. I
    > happen to be running Mandrake 10.0 myself, and the /udev/ version supplied
    > with it does not use */dev* but */udev* to store its device special files
    > - which sort of breaks the entire purpose.


    Could you elaborate? I don't see a /udev directory.
    By the way, I just figured I am apparently not using udev.
    /etc/init.d/udev says udev is running, but mount shows nothing about /dev!

    > I would first of all recommend checking what is wrong with your root
    > filesystem. Run /fsck/ on it from single-user mode - i.e. runlevel 1 - or
    > from a rescue CD. Secondly, why go through the trouble of creating


    Umm, I'm not sure if I can afford checking 100G of data on a UDMA33
    controller on a public server... But maybe I will be forced to.

    > essential drivers such as /ext3/ and /jbd/ as modules and using
    > an /initrd?/


    I thought this has something to do with the initial filesystem setup and
    that it is required...

    > If you're going to be running a custom kernel, then it makes much more
    > sense compiling such stuff into the kernel itself and doing without an
    > /initrd/ -
    > it's what I always do. The only stuff you really need to compile as
    > modules - or omit from the configuration at all - is the stuff for which
    > you have or need a proprietary driver, e.g. nVidia drivers, certain
    > wireless network drivers, et al.


    Well, actually I like to leave many features as modules - this way I can
    patch and upgrade the functionality without rebooting.

    > Check your */etc/fstab* for the numbers at the end of the record for your
    > root filesystem. If you set the last number to 0, the filesystem won't
    > get checked on boot.


    It has "1 1" which is the default.

    > Compile your kernel with the important stuff in-line, as I said. Don't
    > use
    > an /initrd./ And check that filesystem for damage first.


    I'll try. But as a side note, I found a Gentoo udev faq that recommended
    doing # mount -o bind / /foo and then checking /foo/dev. In my case -
    /dev/null was an empty file and not a device, so the initial device
    structure was broken! I fixed it, unmounted /foo and wonder if this will
    fix the boot problem.

    --
    tomasz k. jarzynka / 601 706 601 / tomee(a-t)kadu(d-o-t)net

    "If a train station is where the train stops, what is a work station?"


  9. Re: Upgrading kernel in Mandrake 10.0

    On Saturday 21 October 2006 23:09, Tomek Jarzynka stood up and addressed the
    masses in /alt.os.linux.mandrake/ as follows...:

    > Nudna wrotka - Aragorn napisal w
    > :
    >
    >> The above all said, the fact that you can't write to */dev/null* also
    >> suggests that you're not running /udev,/ and that thus your kernel is
    >> trying to access the */dev/null* on your (read-only) root partition. I
    >> happen to be running Mandrake 10.0 myself, and the /udev/ version
    >> supplied with it does not use */dev* but */udev* to store its device
    >> special files - which sort of breaks the entire purpose.

    >
    > Could you elaborate?


    Most modern distributions make use of /udev/ to create and/or delete device
    special files "on the fly". Instead of using the on-disk */dev* population
    - as was traditionally the case - /udev/ mounts a /tmpfs/ on */dev.*

    Now, if you're _not_ running /udev,/ then - as was typical for
    Mandrake/Mandriva back in the days of /devfs/ and so presumably now still -
    you will be using on-disk */dev* entries. Since */dev* resides on the root
    partition - i.e. if you're not using /udev/ and thus a /tmpfs/ - then
    having a read-only root filesystem would make certain device special files
    unwritable. */dev/null* is such a device that needs write access.

    > I don't see a /udev directory.


    That was in MDK 10.0, but you say you're running 10.1. So _if_ /udev/ is
    indeed running on your system, the device special files should reside on
    a /tmpfs/ mounted on */dev* (and covering anything residing there on the
    root filesystem itself).

    > By the way, I just figured I am apparently not using udev.
    > /etc/init.d/udev says udev is running, but mount shows nothing about /dev!


    Yeah, I still haven't figured out how /mount/ seems to obscure a /tmpfs/
    being mounted on */dev,* but perhaps...

    cat /etc/mtab

    .... will show something. I believe /mount/ doesn't check that file but
    rather checks */proc/mounts* instead. It's also possible that the /udev/
    filesystem was mounted without writing to */etc/mtab.* I don't use /udev/
    at this stage and so I haven't really checked on how it's initialized.

    >> I would first of all recommend checking what is wrong with your root
    >> filesystem. Run /fsck/ on it from single-user mode - i.e. runlevel 1 -
    >> or from a rescue CD. Secondly, why go through the trouble of creating

    >
    > Umm, I'm not sure if I can afford checking 100G of data on a UDMA33
    > controller on a public server... But maybe I will be forced to.


    Well... It's your choice... ;-)

    >> essential drivers such as /ext3/ and /jbd/ as modules and using
    >> an /initrd?/

    >
    > I thought this has something to do with the initial filesystem setup and
    > that it is required...


    No, it isn't. Distributions typically make use of an /initrd/ because they
    keep their kernel as modular as possible to suit all possible hardware
    combinations. You don't need an /initrd/ to boot a kernel, as long as the
    kernel has support for everything it needs built-in, or has access to the
    modules at the least so that it can load them.

    If for instance your modules are on a /reiserfs/ filesystem and your kernel
    doesn't have /reiserfs/ support built-in, then it won't be able to load the
    modules - or mount the root filesystem for that matter - unless you use
    an /initrd/ with a /reiserfs/ module on it.

    >> If you're going to be running a custom kernel, then it makes much more
    >> sense compiling such stuff into the kernel itself and doing without an
    >> /initrd/ - it's what I always do. The only stuff you really need to
    >> compile as modules - or omit from the configuration at all - is the stuff
    >> for which you have or need a proprietary driver, e.g. nVidia drivers,
    >> certain wireless network drivers, et al.

    >
    > Well, actually I like to leave many features as modules - this way I can
    > patch and upgrade the functionality without rebooting.


    Patching and upgrading are not as strict requirements as people believe they
    are. If you already start out with a pretty securely set-up system, then
    you could go for a long time without ever needing to upgrade or patch
    anything.

    >> Check your */etc/fstab* for the numbers at the end of the record for your
    >> root filesystem. If you set the last number to 0, the filesystem won't
    >> get checked on boot.

    >
    > It has "1 1" which is the default.


    Yes, it's the default, and it also says that it has the highest priority for
    checking (and filesystem /dump'ing/). If you don't want your root
    filesystem checked at boot time - not a good idea, but under the
    circumstances it may help you - then change the last 1 to 0.

    The first 1 pertains to the /dump/ utility, which is pretty deprecated these
    days as a means for making backups. You can safely set that to 0 as well.

    >> Compile your kernel with the important stuff in-line, as I said. Don't
    >> use
    >> an /initrd./ And check that filesystem for damage first.

    >
    > I'll try. But as a side note, I found a Gentoo udev faq that recommended
    > doing # mount -o bind / /foo and then checking /foo/dev. In my case -
    > /dev/null was an empty file and not a device, so the initial device
    > structure was broken! I fixed it, unmounted /foo and wonder if this will
    > fix the boot problem.


    Part of it, probably. You still have the damaged filesystem to deal
    with. ;-)

    --
    With kind regards,

    *Aragorn*
    (registered GNU/Linux user #223157)

+ Reply to Thread