Bug#445148: S390: Build w/ /boot partition succeeds, but re-boot fails in fsck - Debian

This is a discussion on Bug#445148: S390: Build w/ /boot partition succeeds, but re-boot fails in fsck - Debian ; tags 445148 confirmed reassign 445148 s390-tools thanks > Install boot went as expected, up until the first re-boot. After > rebooting, system fails in fsck because one of the partitions is > "already mounted". > > Configuration is a 125 ...

+ Reply to Thread
Results 1 to 3 of 3

Thread: Bug#445148: S390: Build w/ /boot partition succeeds, but re-boot fails in fsck

  1. Bug#445148: S390: Build w/ /boot partition succeeds, but re-boot fails in fsck

    tags 445148 confirmed
    reassign 445148 s390-tools
    thanks

    > Install boot went as expected, up until the first re-boot. After
    > rebooting, system fails in fsck because one of the partitions is
    > "already mounted".
    >
    > Configuration is a 125 cylinder /dev/dasda1, which is to be mounted
    > as /boot, and a large /dev/dasdb1 which is to be mounted as /.
    >
    > fsck fails for dasda1, but I don't see anywhere that dasda1 is mounted.
    > mount /boot says that it's already mounted or dasda1 is busy, and
    > umount /boot says it isn't mounted.


    I have reproduced the issue.

    This does not seem to be an installation problem. Instead it looks like
    either the boot loader or the kernel is not releasing the partition
    holding /boot after the kernel and/or the initrd have been loaded.

    I'll send a mail to the linux-s390 mailing list to ask for help with this.

    The workaround is easy:
    - enter the administrator password when requested
    - type 'exit' when in the root shell; this will complete the boot process
    - edit /etc/fstab and change the value in the column "" for the
    /boot partition from 2 to 0 to exclude it from fsck during future boots

    I must say that I'm not sure what the benefits would be of having a separate
    /boot partition on s390, but this still seems like a bug that should be
    resolved.



    --
    To UNSUBSCRIBE, email to debian-bugs-dist-REQUEST@lists.debian.org
    with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

  2. Bug#445148: S390: Build w/ /boot partition succeeds, but re-boot fails in fsck

    severity 445148 serious
    reassign 445148 debian-installer 20070308
    thanks

    On Monday 08 October 2007, Frans Pop wrote:
    > This does not seem to be an installation problem. Instead it looks like
    > either the boot loader or the kernel is not releasing the partition
    > holding /boot after the kernel and/or the initrd have been loaded.


    It is an installation problem after all.
    Basically, on boot the dasds for / (LVM) and /boot are swapped. See [1] for
    a detailed analysis.

    The correct repair for the issue is as follows:
    - enter the administrator password when requested
    - type 'exit' when in the root shell; this will complete the boot process
    - edit /etc/fstab and use /dev/disk/by-path device names for _all_
    partitions, for example (check /dev/disk/by-path for correct names):

    #
    proc /proc proc defaults 0 0
    /dev/disk/by-path/ccw-0.0.0123-part1 / ext3 defaults,[...] 0 1
    /dev/disk/by-path/ccw-0.0.0122-part1 /boot ext3 defaults 0 2
    /dev/disk/by-path/ccw-0.0.0122-part2 none swap sw 0 0

    - reboot

    To the D-I team
    ---------------
    This is a fairly difficult issue as there is not really an easy solution or
    an obvious D-I component that is the culprit (to mind come s390-dasd,
    partman-target, udev-udeb, initramfs-tools and zipl-installer). Therefore
    assigning to d-i itself.

    This issue should IMO definitely be listed in the errata for Etch.

    I also think the issue is broader than just this use case. Basically any
    setup that has / on a different dasd than the first one configured in
    s390-dasd is broken.
    AFAICT any setup in which during s390-dasd dasds are configured in a
    different order than their numeric sort order, will *also* be broken as
    their device names after reboot will be different from what they were
    during installation.

    [1] http://bugs.debian.org/cgi-bin/bugre...=58;bug=445148

    -----BEGIN PGP SIGNATURE-----
    Version: GnuPG v1.4.6 (GNU/Linux)

    iD8DBQBHClEjgm/Kwh6ICoQRAqZTAJ45oChdGUG/M2iTIGr4O94gNgnpKACaA4th
    Bio9McRpE7dEk8/33IGSdOA=
    =IFjR
    -----END PGP SIGNATURE-----


  3. Processed: Re: Bug#445148: S390: Build w/ /boot partition succeeds, but re-boot fails in fsck

    Processing commands for control@bugs.debian.org:

    > severity 445148 serious

    Bug#445148: S390: Build w/ /boot partition succeeds, but re-boot fails in fsck
    Severity set to `serious' from `important'

    > reassign 445148 debian-installer 20070308

    Bug#445148: S390: Build w/ /boot partition succeeds, but re-boot fails in fsck
    Bug reassigned from package `s390-tools' to `debian-installer'.

    > thanks

    Stopping processing here.

    Please contact me if you need assistance.

    Debian bug tracking system administrator
    (administrator, Debian Bugs database)


    --
    To UNSUBSCRIBE, email to debian-boot-REQUEST@lists.debian.org
    with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

+ Reply to Thread