Message ID | 553AA05C.9070803@iki.fi |
---|---|
State | Superseded |
Headers | show |
On 2015-04-24 21:58, Hannu Nyman wrote: > Since the kernel/rootfs split handling was modified 2 years ago by r37283 ( > https://dev.openwrt.org/changeset/37283 ) and by the subsequent checkins, > users have seen rather scary mtd errors in the log at every boot. The message > ends "-- forcing read-only", which looks a bit error-like. That error has > been mentioned in some forum threads, when users have noticed this message > instead of some actual error. > > [ 2.940000] 0x000000070000-0x000000ff0000 : "firmware" > [ 2.970000] 2 netgear-fw partitions found on MTD device firmware > [ 2.970000] 0x000000070000-0x000000188440 : "kernel" > [ 2.980000] mtd: partition "kernel" must either start or end on erase > block boundary or be smaller than an erase block -- forcing read-only > [ 2.990000] 0x000000188440-0x000000ff0000 : "rootfs" > [ 2.990000] mtd: partition "rootfs" must either start or end on erase > block boundary or be smaller than an erase block -- forcing read-only > [ 3.010000] mtd: device 4 (rootfs) set to be root filesystem > [ 3.010000] 1 squashfs-split partitions found on MTD device rootfs > [ 3.020000] 0x000000660000-0x000000ff0000 : "rootfs_data" > > The error text 'mtd: partition "kernel" must either start or end on erase > block boundary or be smaller than an erase block -- forcing read-only' > originates from 6 years ago, when nbd checked in r17658 to kernel 2.6.30. > https://dev.openwrt.org/changeset/17658 > https://dev.openwrt.org/browser/trunk/target/linux/generic-2.6/patches-2.6.30/222-partial_eraseblock_write.patch?rev=17658 > > At that time, this message was rarely shown, as it was normal to have padding > after kernel, so that rootfs started at the next block boundary. Currently > many platforms have kernel & rootfs tightly packed without padding in > between, so the message is shown quite frequently. > > Additionally, I think that the original warning message has a logical fault: > the first "or" should be "and". It should say "must either start AND end on > erase block boundary or be smaller than an erase block". (otherwise 'kernel' > should not cause the warning message as it starts at a boundary...). The > logic in 411-mtd-partial_eraseblock_write.patch is pretty hard to follow, but > that is my reading about the correct reasoning. > https://dev.openwrt.org/browser/trunk/target/linux/generic/patches-3.18/411-mtd-partial_eraseblock_write.patch > > > I propose that the message class is changed from a kernel warning to a kernel > info message and the text is changed to be less scary: 'partition "kernel" is > read-only: it does not start and end at erase block boundary and is larger > than a single block' > > [ 2.970000] 2 netgear-fw partitions found on MTD device firmware > [ 2.970000] 0x000000070000-0x000000188440 : "kernel" > [ 2.980000] mtd: partition "kernel" is read-only: it does not start and > end at erase block boundary and is larger than a single block > [ 2.990000] 0x000000188440-0x000000ff0000 : "rootfs" > [ 2.990000] mtd: partition "rootfs" is read-only: it does not start and > end at erase block boundary and is larger than a single block > > > I would prefer to shorten the message even more, but I didn't invent a > suitable short but informative wording. (Althoug as this is currently most > often just an informative notice, I am not quite sure if the logic needs to > be explained quite that closely in the message.) I think this message is quite pointless anyway, so I'd prefer to simply have it removed instead of changing it. - Felix
--- target/linux/generic/patches-3.18/411-mtd-partial_eraseblock_write.patch +++ target/linux/generic/patches-3.18/411-mtd-partial_eraseblock_write.patch @@ -126,7 +126,7 @@ + slave->mtd.erasesize = slave->mtd.size; } + if ((slave->mtd.flags & (MTD_ERASE_PARTIAL|MTD_WRITEABLE)) == MTD_ERASE_PARTIAL) -+ printk(KERN_WARNING"mtd: partition \"%s\" must either start or end on erase block boundary or be smaller than an erase block -- forcing read-only\n", ++ printk(KERN_INFO"mtd: partition \"%s\" is read-only: it does not start and end at erase block boundary and is larger than a single block\n", + part->name); slave->mtd.ecclayout = master->ecclayout; --- target/linux/generic/patches-4.0/411-mtd-partial_eraseblock_write.patch +++ target/linux/generic/patches-4.0/411-mtd-partial_eraseblock_write.patch @@ -126,7 +126,7 @@ + slave->mtd.erasesize = slave->mtd.size; } + if ((slave->mtd.flags & (MTD_ERASE_PARTIAL|MTD_WRITEABLE)) == MTD_ERASE_PARTIAL) -+ printk(KERN_WARNING"mtd: partition \"%s\" must either start or end on erase block boundary or be smaller than an erase block -- forcing read-only\n", ++ printk(KERN_INFO"mtd: partition \"%s\" is read-only: it does not start and end at erase block boundary and is larger than a single block\n", + part->name); slave->mtd.ecclayout = master->ecclayout;
Since the kernel/rootfs split handling was modified 2 years ago by r37283 ( https://dev.openwrt.org/changeset/37283 ) and by the subsequent checkins, users have seen rather scary mtd errors in the log at every boot. The message ends "-- forcing read-only", which looks a bit error-like. That error has been mentioned in some forum threads, when users have noticed this message instead of some actual error. [ 2.940000] 0x000000070000-0x000000ff0000 : "firmware" [ 2.970000] 2 netgear-fw partitions found on MTD device firmware [ 2.970000] 0x000000070000-0x000000188440 : "kernel" [ 2.980000] mtd: partition "kernel" must either start or end on erase block boundary or be smaller than an erase block -- forcing read-only [ 2.990000] 0x000000188440-0x000000ff0000 : "rootfs" [ 2.990000] mtd: partition "rootfs" must either start or end on erase block boundary or be smaller than an erase block -- forcing read-only [ 3.010000] mtd: device 4 (rootfs) set to be root filesystem [ 3.010000] 1 squashfs-split partitions found on MTD device rootfs [ 3.020000] 0x000000660000-0x000000ff0000 : "rootfs_data" The error text 'mtd: partition "kernel" must either start or end on erase block boundary or be smaller than an erase block -- forcing read-only' originates from 6 years ago, when nbd checked in r17658 to kernel 2.6.30. https://dev.openwrt.org/changeset/17658 https://dev.openwrt.org/browser/trunk/target/linux/generic-2.6/patches-2.6.30/222-partial_eraseblock_write.patch?rev=17658 At that time, this message was rarely shown, as it was normal to have padding after kernel, so that rootfs started at the next block boundary. Currently many platforms have kernel & rootfs tightly packed without padding in between, so the message is shown quite frequently. Additionally, I think that the original warning message has a logical fault: the first "or" should be "and". It should say "must either start AND end on erase block boundary or be smaller than an erase block". (otherwise 'kernel' should not cause the warning message as it starts at a boundary...). The logic in 411-mtd-partial_eraseblock_write.patch is pretty hard to follow, but that is my reading about the correct reasoning. https://dev.openwrt.org/browser/trunk/target/linux/generic/patches-3.18/411-mtd-partial_eraseblock_write.patch I propose that the message class is changed from a kernel warning to a kernel info message and the text is changed to be less scary: 'partition "kernel" is read-only: it does not start and end at erase block boundary and is larger than a single block' [ 2.970000] 2 netgear-fw partitions found on MTD device firmware [ 2.970000] 0x000000070000-0x000000188440 : "kernel" [ 2.980000] mtd: partition "kernel" is read-only: it does not start and end at erase block boundary and is larger than a single block [ 2.990000] 0x000000188440-0x000000ff0000 : "rootfs" [ 2.990000] mtd: partition "rootfs" is read-only: it does not start and end at erase block boundary and is larger than a single block I would prefer to shorten the message even more, but I didn't invent a suitable short but informative wording. (Althoug as this is currently most often just an informative notice, I am not quite sure if the logic needs to be explained quite that closely in the message.) Signed-off-by: Hannu Nyman <hannu.nyman@iki.fi>