From: Richard Weinberger <richard@nod.at>
To: Jaap de Jong <jaap.dejong@nedap.com>
Cc: "linux-mtd@lists.infradead.org" <linux-mtd@lists.infradead.org>
Subject: Re: Mounting issue with old uboot and new rootfs
Date: Wed, 13 Dec 2017 10:43:16 +0100 [thread overview]
Message-ID: <5001344.Umix9c0TK6@blindfold> (raw)
In-Reply-To: <a9bb7f99-d877-ccf8-8918-25d8ce91baa0@nedap.com>
Jaap,
Am Mittwoch, 13. Dezember 2017, 08:45:44 CET schrieb Jaap de Jong:
> On 12-12-17 17:29, Richard Weinberger wrote:
> > Jaap,
> >
> > Am Montag, 11. Dezember 2017, 16:03:25 CET schrieb Jaap de Jong:
> >> Hi All,
> >>
> >> Some time ago I posted a question with a slightly different subject.
> >> Now that I found out a bit more the previous subject is no longer
> >> relevant.
> >>
> >> But I still have issues with mounting in a mixed environment.
> >> I have this board with an older u-boot (2010.09) in combination with a
> >> more
> >> recent kernel (4.9.28).
> >>
> >> The parameters in uboot:
> >> root=ubi0 rw ubi.mtd=3 rootfstype=ubifs
> >>
> >> mtdparts=atmel_nand:128K(bootstrap),256K(u-boot-env),640K(u-boot),-(rootf
> >> s)
> >>
> >> U-boot runs `ubi part rootfs` as one of the steps in the startup process
> >> to
> >> load the kernel. When doing that u-boot reports that the ubi volume is
> >> resized. This is due to the fact that the rootfs is written with the
> >> u-boot
> >> `nand write` command, writing a ubi formatted image.
> >>
> >> When booting the unit the kernel panics:
> >> [ 1.523437] ubi0 error: ubi_read_volume_table: the layout
> >> volume
> >>
> >> was not found [ 1.539062] ubi0 error: ubi_attach_mtd_dev: failed to
> >> attach mtd3, error -22 [ 1.546875] UBI error: cannot attach mtd3
> >>
> >> [ 1.546875] Kernel panic - not syncing: VFS: Unable to mount
> >> root
> >>
> >> fs on unknown-block(0,0) [ 1.546875] Rebooting in 1 seconds..RomBOOT
> >>
> >> Then u-boot restarts and tells:
> >> UBI warning: process_lvol: volume table copy #1 is corrupted
> >> UBI: create volume table (copy #1)
> >> UBI: volume table was restored
> >>
> >> But is able to load the kernel and transfer control to it.
> >> This second run of this kernel does not panic anymore and just starts as
> >> expected! Also, new reboots don't show u-boot issues!
> >>
> >> Some other combinations:
> >> u-boot kernel result
> >> 2010.09 2.6.35 fine
> >> 2010.09 4.9.28 panic
> >> 2016.03 2.6.35 fine
> >> 2016.03 4.9.28 fine
> >>
> >> One thing that I noticed is that the newer u-boot resizes to around 40
> >> less
> >> LEBs than the older u-boot does. Related?
> >
> > Resize? Or missing?
> > This is definitely odd and should not happen.
>
> Below the output of the old uboot when doing its `ubi part rootfs` on a
> new freshly flashed ubi root file system:
> - resizing the volume
>
> Creating 1 MTD partitions on "nand0":
> 0x000000100000-0x000020000000 : "mtd=3"
> UBI: attaching mtd1 to ubi0
> UBI: physical eraseblock size: 131072 bytes (128 KiB)
> UBI: logical eraseblock size: 129024 bytes
> UBI: smallest flash I/O unit: 2048
> UBI: sub-page size: 512
> UBI: VID header offset: 512 (aligned 512)
> UBI: data offset: 2048
> UBI: volume 0 ("my-rootfs") re-sized from 933 to 4042 LEBs
Does everything work as expected if you don't set the resize flag in ubinize?
Maybe this is the culprit.
Thanks,
//richard
next prev parent reply other threads:[~2017-12-13 9:43 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-11-30 15:22 Mounting issue with old rootfs and new kernel Jaap de Jong
2017-11-30 15:28 ` Richard Weinberger
[not found] ` <e144d66c-c754-ad6d-bd0c-ef5384ae7a78@nedap.com>
2017-11-30 16:20 ` Richard Weinberger
2017-12-01 14:26 ` Jaap de Jong
2017-12-04 14:54 ` Jaap de Jong
[not found] ` <1513004605320.75417@nedap.com>
2017-12-12 16:29 ` Mounting issue with old uboot and new rootfs Richard Weinberger
2017-12-13 7:45 ` Jaap de Jong
2017-12-13 9:43 ` Richard Weinberger [this message]
2017-12-13 10:18 ` Jaap de Jong
2017-12-13 16:42 ` Richard Weinberger
2017-12-14 7:28 ` Jaap de Jong
2017-12-14 9:51 ` Jaap de Jong
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=5001344.Umix9c0TK6@blindfold \
--to=richard@nod.at \
--cc=jaap.dejong@nedap.com \
--cc=linux-mtd@lists.infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).