| Message ID | VE1P194MB08307CC25E92898E144AA18BD78F2@VE1P194MB0830.EURP194.PROD.OUTLOOK.COM |
|---|---|
| State | Changes Requested |
| Headers | show |
| Series | ubivol_handler: keep ubi volume ids stable on resize | expand |
Hi Hannes, On 22.08.24 08:01, Hannes Weisbach wrote: > UBI volume resizing is implemented by deleting and (re-)creating a volume. If the volume previously existed, its type (static or dynamic) is copied over, however its volume ID is lost. It was never a problem. > This is a problem for volumes containing a rootfs, since the UBI/MTD/Block adaptoin adptoin ==> adaptation layer in the kernel does not understand the <ubi-device>:<ubi-volume-name> syntax; Really ? I have just a board here with current SW, kernel 6.6 and SWUpdate 2024.05. cat /proc/cmdline ubi.mtd=1 root=ubi0:rootfs1 rootfstype=ubifs And of course, it boots. > volumes have to passed to the root=-parameter by volume ID, ??? I cannot confirm this. > i.e.: root=/dev/ubiblock0_<volid>. Hence, this gets tricky in the bootloader. A simpler approach is to keep volume IDs stable if a volume is re-created. you have to pass ubi.mtd=<mtd dev> and root=<ubi-device>:<ubi-volume-name>, and of course rootfstype=ubifs Best regards, Stefano Babic > > Signed-off-by: Hannes Weisbach <weisbach@neosat.de> > --- > handlers/ubivol_handler.c | 4 +++- > 1 file changed, 3 insertions(+), 1 deletion(-) > > diff --git a/handlers/ubivol_handler.c b/handlers/ubivol_handler.c > index bf1ec00a..7ea4a6f9 100644 > --- a/handlers/ubivol_handler.c > +++ b/handlers/ubivol_handler.c > @@ -310,6 +310,7 @@ static int resize_volume(struct img_type *cfg, long long size) > struct ubi_mkvol_request req; > struct mtd_ubi_info *mtd_info; > int mtdnum, req_vol_type; > + int req_vol_id = UBI_VOL_NUM_AUTO; > char node[64]; > int err; > struct flash_description *flash = get_flash_info(); > @@ -371,6 +372,7 @@ static int resize_volume(struct img_type *cfg, long long size) > } > > snprintf(node, sizeof(node), "/dev/ubi%d", ubivol->vol_info.dev_num); > + req_vol_id = ubivol->vol_info.vol_id; > err = ubi_rmvol(nandubi->libubi, node, ubivol->vol_info.vol_id); > if (err) { > ERROR("Volume %s cannot be dropped", ubivol->vol_info.name); > @@ -392,7 +394,7 @@ static int resize_volume(struct img_type *cfg, long long size) > */ > memset(&req, 0, sizeof(req)); > req.vol_type = req_vol_type; > - req.vol_id = UBI_VOL_NUM_AUTO; > + req.vol_id = req_vol_id; > req.alignment = 1; > req.bytes = size; > req.name = cfg->volname;
> Hi Hannes, Hi Stefano, > layer in the kernel does not understand the > <ubi-device>:<ubi-volume-name> syntax; > > Really ? I have just a board here with current SW, kernel 6.6 and > SWUpdate 2024.05. > > cat /proc/cmdline > ubi.mtd=1 root=ubi0:rootfs1 rootfstype=ubifs > > And of course, it boots. TLDR: I'm using squasfs instead of ubifs and that makes root=<ubidev>:<ubivolname> not work afaict. Long version: I'm using swupdate 2023.12.1 (from buildroot 2024.05). For Linux, I'm at 6.1.0 (but not mainline). But I can try a mainline kernel. My understanding is, that the problem arises with r/o block devices on UBI (UBI, but no ubifs). I'm using squashfs. I tried moving to ubifs but my rootfs gets somewhere in range of 2x - 2.5x the size of squashfs. I don't want to (can?) incur that cost. With squashfs I have to use the UBI/MTD block adaptation layer, so I can have a block device for squashfs (at least that is my understanding). [0] There was also this [1] discussion on linux-mtd which would allow the UBI/MTD block layer to create a block device by with the UBI volume name (i.e. /dev/ubiblock0_<volname>, which in turn you could pass to the root= kernel command line. It was never accepted into mainline, afaict. >> volumes have to passed to the root=-parameter by volume ID, > > ??? I should have said that better. The block device on top of a UBI volume, i.e. /dev/ubiblock<x>_<y> (x is the UBI device ID, y the volume ID), have to be passed to the root=-parameter. > I cannot confirm this. > >> i.e.: root=/dev/ubiblock0_<volid>. Hence, this gets tricky in the bootloader. A simpler approach is to keep volume IDs stable if a volume is re-created. > > you have to pass ubi.mtd=<mtd dev> and Yes. > root=<ubi-device>:<ubi-volume-name>, and of course rootfstype=ubifs Yes - with ubifs. With squashfs you need the block device and pass that as root=. But it is named after the volume ID, which in turn changes :( I'm doing: ubi.mtd=ubi,2048 ubi.fm_autoconvert=1 ubi.block=0,rootfs1 root=/dev/ubiblock0_81 If I'm using root=ubi.rootfs1 or root=ubi0:rootfs1 I get: [...] ubi0:rootfs1: Can't open blockdev VFS: Cannot open root device "ubi0:rootfs1" or unknown-block(0,0): error -2 Please append a correct "root=" boot option; here are the available partitions: [...] and [...] ubi:rootfs1: Can't open blockdev VFS: Cannot open root device "ubi:rootfs1" or unknown-block(0,0): error -2 Please append a correct "root=" boot option; here are the available partitions: [...] I'd love to specify root= by name, if I can. But I'd rather have custom patches in swupdate to resize the ubi volume if required than custom kernel patches. > Best regards, > Stefano Babic I hope I could state my situation and problem better. Best regards, Hannes [0] http://www.linux-mtd.infradead.org/doc/ubi.html#L_ubiblock [1] https://lore.kernel.org/linux-mtd/23922253.ayd0uQntjt@blindfold/t/ Hi Hannes, On 22.08.24 08:01, Hannes Weisbach wrote: > UBI volume resizing is implemented by deleting and (re-)creating a volume. If the volume previously existed, its type (static or dynamic) is copied over, however its volume ID is lost. It was never a problem. > This is a problem for volumes containing a rootfs, since the UBI/MTD/Block adaptoin adptoin ==> adaptation layer in the kernel does not understand the <ubi-device>:<ubi-volume-name> syntax; Really ? I have just a board here with current SW, kernel 6.6 and SWUpdate 2024.05. cat /proc/cmdline ubi.mtd=1 root=ubi0:rootfs1 rootfstype=ubifs And of course, it boots. > volumes have to passed to the root=-parameter by volume ID, ??? I cannot confirm this. > i.e.: root=/dev/ubiblock0_<volid>. Hence, this gets tricky in the bootloader. A simpler approach is to keep volume IDs stable if a volume is re-created. you have to pass ubi.mtd=<mtd dev> and root=<ubi-device>:<ubi-volume-name>, and of course rootfstype=ubifs Best regards, Stefano Babic > > Signed-off-by: Hannes Weisbach <weisbach@neosat.de> > --- > handlers/ubivol_handler.c | 4 +++- > 1 file changed, 3 insertions(+), 1 deletion(-) > > diff --git a/handlers/ubivol_handler.c b/handlers/ubivol_handler.c > index bf1ec00a..7ea4a6f9 100644 > --- a/handlers/ubivol_handler.c > +++ b/handlers/ubivol_handler.c > @@ -310,6 +310,7 @@ static int resize_volume(struct img_type *cfg, long long size) > struct ubi_mkvol_request req; > struct mtd_ubi_info *mtd_info; > int mtdnum, req_vol_type; > + int req_vol_id = UBI_VOL_NUM_AUTO; > char node[64]; > int err; > struct flash_description *flash = get_flash_info(); > @@ -371,6 +372,7 @@ static int resize_volume(struct img_type *cfg, long long size) > } > > snprintf(node, sizeof(node), "/dev/ubi%d", ubivol->vol_info.dev_num); > + req_vol_id = ubivol->vol_info.vol_id; > err = ubi_rmvol(nandubi->libubi, node, ubivol->vol_info.vol_id); > if (err) { > ERROR("Volume %s cannot be dropped", ubivol->vol_info.name); > @@ -392,7 +394,7 @@ static int resize_volume(struct img_type *cfg, long long size) > */ > memset(&req, 0, sizeof(req)); > req.vol_type = req_vol_type; > - req.vol_id = UBI_VOL_NUM_AUTO; > + req.vol_id = req_vol_id; > req.alignment = 1; > req.bytes = size; > req.name = cfg->volname;
Hallo Hannes, On 23.08.24 13:09, Hannes Weisbach wrote: > >> Hi Hannes, > Hi Stefano, > >> layer in the kernel does not understand the >> <ubi-device>:<ubi-volume-name> syntax; >> >> Really ? I have just a board here with current SW, kernel 6.6 and >> SWUpdate 2024.05. >> >> cat /proc/cmdline >> ubi.mtd=1 root=ubi0:rootfs1 rootfstype=ubifs >> >> And of course, it boots. > > TLDR: I'm using squasfs instead of ubifs and that makes root=<ubidev>:<ubivolname> not work afaict. > Ah, ok, got it. You need a block device. > Long version: > > I'm using swupdate 2023.12.1 (from buildroot 2024.05). For Linux, I'm at 6.1.0 (but not mainline). But I can try a mainline kernel. > > My understanding is, that the problem arises with r/o block devices on UBI (UBI, but no ubifs). I'm using squashfs. I tried moving to ubifs but my rootfs gets somewhere in range of 2x - 2.5x the size of squashfs. I don't want to (can?) incur that cost. Sure - but ubifs can be set ro (like squashfs is) and accepts compression. Have you tried with ZST compression ? Size should be near to squashfs. > > With squashfs I have to use the UBI/MTD block adaptation layer, so I can have a block device for squashfs (at least that is my understanding). [0] > Ok, I understand now. > There was also this [1] discussion on linux-mtd which would allow the UBI/MTD block layer to create a block device by with the UBI volume name (i.e. /dev/ubiblock0_<volname>, which in turn you could pass to the root= kernel command line. It was never accepted into mainline, afaict. > >>> volumes have to passed to the root=-parameter by volume ID, >> >> ??? > I should have said that better. The block device on top of a UBI volume, i.e. /dev/ubiblock<x>_<y> (x is the UBI device ID, y the volume ID), have to be passed to the root=-parameter. > >> I cannot confirm this. >> >>> i.e.: root=/dev/ubiblock0_<volid>. Hence, this gets tricky in the bootloader. A simpler approach is to keep volume IDs stable if a volume is re-created. >> >> you have to pass ubi.mtd=<mtd dev> and > Yes. > >> root=<ubi-device>:<ubi-volume-name>, and of course rootfstype=ubifs > > Yes - with ubifs. With squashfs you need the block device and pass that as root=. But it is named after the volume ID, which in turn changes :( > > I'm doing: ubi.mtd=ubi,2048 ubi.fm_autoconvert=1 ubi.block=0,rootfs1 root=/dev/ubiblock0_81 > > If I'm using root=ubi.rootfs1 or root=ubi0:rootfs1 I get: > [...] > ubi0:rootfs1: Can't open blockdev > VFS: Cannot open root device "ubi0:rootfs1" or unknown-block(0,0): error -2 > Please append a correct "root=" boot option; here are the available partitions: > [...] > > and > > [...] > ubi:rootfs1: Can't open blockdev > VFS: Cannot open root device "ubi:rootfs1" or unknown-block(0,0): error -2 > Please append a correct "root=" boot option; here are the available partitions: > [...] > > I'd love to specify root= by name, if I can. But I'd rather have custom patches in swupdate to resize the ubi volume if required than custom kernel patches. > Ok, thanks for clarify this. I do not see drawbacks to apply the patch, so I will pick it up. Best regards, Stefano >> Best regards, >> Stefano Babic > > I hope I could state my situation and problem better. > > Best regards, > Hannes > > [0] http://www.linux-mtd.infradead.org/doc/ubi.html#L_ubiblock > [1] https://lore.kernel.org/linux-mtd/23922253.ayd0uQntjt@blindfold/t/ > > > Hi Hannes, > > On 22.08.24 08:01, Hannes Weisbach wrote: >> UBI volume resizing is implemented by deleting and (re-)creating a volume. If the volume previously existed, its type (static or dynamic) is copied over, however its volume ID is lost. > > It was never a problem. > >> This is a problem for volumes containing a rootfs, since the UBI/MTD/Block adaptoin > > > adptoin ==> adaptation > > layer in the kernel does not understand the > <ubi-device>:<ubi-volume-name> syntax; > > Really ? I have just a board here with current SW, kernel 6.6 and > SWUpdate 2024.05. > > cat /proc/cmdline > ubi.mtd=1 root=ubi0:rootfs1 rootfstype=ubifs > > And of course, it boots. > >> volumes have to passed to the root=-parameter by volume ID, > > ??? > > I cannot confirm this. > >> i.e.: root=/dev/ubiblock0_<volid>. Hence, this gets tricky in the bootloader. A simpler approach is to keep volume IDs stable if a volume is re-created. > > you have to pass ubi.mtd=<mtd dev> and > root=<ubi-device>:<ubi-volume-name>, and of course rootfstype=ubifs > > Best regards, > Stefano Babic > >> >> Signed-off-by: Hannes Weisbach <weisbach@neosat.de> >> --- >> handlers/ubivol_handler.c | 4 +++- >> 1 file changed, 3 insertions(+), 1 deletion(-) >> >> diff --git a/handlers/ubivol_handler.c b/handlers/ubivol_handler.c >> index bf1ec00a..7ea4a6f9 100644 >> --- a/handlers/ubivol_handler.c >> +++ b/handlers/ubivol_handler.c >> @@ -310,6 +310,7 @@ static int resize_volume(struct img_type *cfg, long long size) >> struct ubi_mkvol_request req; >> struct mtd_ubi_info *mtd_info; >> int mtdnum, req_vol_type; >> + int req_vol_id = UBI_VOL_NUM_AUTO; >> char node[64]; >> int err; >> struct flash_description *flash = get_flash_info(); >> @@ -371,6 +372,7 @@ static int resize_volume(struct img_type *cfg, long long size) >> } >> >> snprintf(node, sizeof(node), "/dev/ubi%d", ubivol->vol_info.dev_num); >> + req_vol_id = ubivol->vol_info.vol_id; >> err = ubi_rmvol(nandubi->libubi, node, ubivol->vol_info.vol_id); >> if (err) { >> ERROR("Volume %s cannot be dropped", ubivol->vol_info.name); >> @@ -392,7 +394,7 @@ static int resize_volume(struct img_type *cfg, long long size) >> */ >> memset(&req, 0, sizeof(req)); >> req.vol_type = req_vol_type; >> - req.vol_id = UBI_VOL_NUM_AUTO; >> + req.vol_id = req_vol_id; >> req.alignment = 1; >> req.bytes = size; >> req.name = cfg->volname; >
On 23.08.24 13:35, Stefano Babic wrote: > Hallo Hannes, Hi Stefano, > Sure - but ubifs can be set ro (like squashfs is) and accepts > compression. Have you tried with ZST compression ? Size should be near > to squashfs. I've tried turning compression on. But Buildroot let me only select gzip and lzo. If you say it can do zstd it is probably a restriction of the buildroot menu system? I didn't know r/o ubifs was a possibility. I'll look into r/o ubifs + zstd compression on Monday again. > Ok, thanks for clarify this. I do not see drawbacks to apply the patch, > so I will pick it up. Ok, let me fix the typo in the commit message though. I'll probably reword it a bit to make the problem/intention clearer. I guess I can just repost the patch in this email thread and patchwork will pick it up? Best regards, Hannes
On 23.08.24 13:59, Hannes Weisbach wrote: > > On 23.08.24 13:35, Stefano Babic wrote: >> Hallo Hannes, > > Hi Stefano, > > >> Sure - but ubifs can be set ro (like squashfs is) and accepts >> compression. Have you tried with ZST compression ? Size should be near >> to squashfs. > > I've tried turning compression on. But Buildroot let me only select gzip and lzo. If you say it can do zstd it is probably a restriction of the buildroot menu system? Or in kernel - but ZST for UBIFS is present in 6.1, too. > I didn't know r/o ubifs was a possibility. I'll look into r/o ubifs + zstd compression on Monday again. >> Ok, thanks for clarify this. I do not see drawbacks to apply the patch, >> so I will pick it up. > > Ok, let me fix the typo in the commit message though. I'll probably reword it a bit to make the problem/intention clearer. > > I guess I can just repost the patch in this email thread and patchwork will pick it up? Yes. Best regards, Stefano > > Best regards, > Hannes > > ________________________________________ > Von: Stefano Babic <stefano.babic@swupdate.org> > Gesendet: Freitag, 23. August 2024 13:35 > An: Hannes Weisbach; Stefano Babic; swupdate@googlegroups.com > Betreff: [EXT] Re: AW: [EXT] Re: [swupdate] [PATCH] ubivol_handler: keep ubi volume ids stable on resize > > Hallo Hannes, > > On 23.08.24 13:09, Hannes Weisbach wrote: >> >>> Hi Hannes, >> Hi Stefano, >> >>> layer in the kernel does not understand the >>> <ubi-device>:<ubi-volume-name> syntax; >>> >>> Really ? I have just a board here with current SW, kernel 6.6 and >>> SWUpdate 2024.05. >>> >>> cat /proc/cmdline >>> ubi.mtd=1 root=ubi0:rootfs1 rootfstype=ubifs >>> >>> And of course, it boots. >> >> TLDR: I'm using squasfs instead of ubifs and that makes root=<ubidev>:<ubivolname> not work afaict. >> > > Ah, ok, got it. You need a block device. > >> Long version: >> >> I'm using swupdate 2023.12.1 (from buildroot 2024.05). For Linux, I'm at 6.1.0 (but not mainline). But I can try a mainline kernel. >> >> My understanding is, that the problem arises with r/o block devices on UBI (UBI, but no ubifs). I'm using squashfs. I tried moving to ubifs but my rootfs gets somewhere in range of 2x - 2.5x the size of squashfs. I don't want to (can?) incur that cost. > > Sure - but ubifs can be set ro (like squashfs is) and accepts > compression. Have you tried with ZST compression ? Size should be near > to squashfs. > >> >> With squashfs I have to use the UBI/MTD block adaptation layer, so I can have a block device for squashfs (at least that is my understanding). [0] >> > > Ok, I understand now. > >> There was also this [1] discussion on linux-mtd which would allow the UBI/MTD block layer to create a block device by with the UBI volume name (i.e. /dev/ubiblock0_<volname>, which in turn you could pass to the root= kernel command line. It was never accepted into mainline, afaict. >> >>>> volumes have to passed to the root=-parameter by volume ID, >>> >>> ??? >> I should have said that better. The block device on top of a UBI volume, i.e. /dev/ubiblock<x>_<y> (x is the UBI device ID, y the volume ID), have to be passed to the root=-parameter. >> >>> I cannot confirm this. >>> >>>> i.e.: root=/dev/ubiblock0_<volid>. Hence, this gets tricky in the bootloader. A simpler approach is to keep volume IDs stable if a volume is re-created. >>> >>> you have to pass ubi.mtd=<mtd dev> and >> Yes. >> >>> root=<ubi-device>:<ubi-volume-name>, and of course rootfstype=ubifs >> >> Yes - with ubifs. With squashfs you need the block device and pass that as root=. But it is named after the volume ID, which in turn changes :( >> >> I'm doing: ubi.mtd=ubi,2048 ubi.fm_autoconvert=1 ubi.block=0,rootfs1 root=/dev/ubiblock0_81 >> >> If I'm using root=ubi.rootfs1 or root=ubi0:rootfs1 I get: >> [...] >> ubi0:rootfs1: Can't open blockdev >> VFS: Cannot open root device "ubi0:rootfs1" or unknown-block(0,0): error -2 >> Please append a correct "root=" boot option; here are the available partitions: >> [...] >> >> and >> >> [...] >> ubi:rootfs1: Can't open blockdev >> VFS: Cannot open root device "ubi:rootfs1" or unknown-block(0,0): error -2 >> Please append a correct "root=" boot option; here are the available partitions: >> [...] >> >> I'd love to specify root= by name, if I can. But I'd rather have custom patches in swupdate to resize the ubi volume if required than custom kernel patches. >> > > Ok, thanks for clarify this. I do not see drawbacks to apply the patch, > so I will pick it up. > > Best regards, > Stefano > >>> Best regards, >>> Stefano Babic >> >> I hope I could state my situation and problem better. >> >> Best regards, >> Hannes >> >> [0] http://www.linux-mtd.infradead.org/doc/ubi.html#L_ubiblock >> [1] https://lore.kernel.org/linux-mtd/23922253.ayd0uQntjt@blindfold/t/ >> >> >> Hi Hannes, >> >> On 22.08.24 08:01, Hannes Weisbach wrote: >>> UBI volume resizing is implemented by deleting and (re-)creating a volume. If the volume previously existed, its type (static or dynamic) is copied over, however its volume ID is lost. >> >> It was never a problem. >> >>> This is a problem for volumes containing a rootfs, since the UBI/MTD/Block adaptoin >> >> >> adptoin ==> adaptation >> >> layer in the kernel does not understand the >> <ubi-device>:<ubi-volume-name> syntax; >> >> Really ? I have just a board here with current SW, kernel 6.6 and >> SWUpdate 2024.05. >> >> cat /proc/cmdline >> ubi.mtd=1 root=ubi0:rootfs1 rootfstype=ubifs >> >> And of course, it boots. >> >>> volumes have to passed to the root=-parameter by volume ID, >> >> ??? >> >> I cannot confirm this. >> >>> i.e.: root=/dev/ubiblock0_<volid>. Hence, this gets tricky in the bootloader. A simpler approach is to keep volume IDs stable if a volume is re-created. >> >> you have to pass ubi.mtd=<mtd dev> and >> root=<ubi-device>:<ubi-volume-name>, and of course rootfstype=ubifs >> >> Best regards, >> Stefano Babic >> >>> >>> Signed-off-by: Hannes Weisbach <weisbach@neosat.de> >>> --- >>> handlers/ubivol_handler.c | 4 +++- >>> 1 file changed, 3 insertions(+), 1 deletion(-) >>> >>> diff --git a/handlers/ubivol_handler.c b/handlers/ubivol_handler.c >>> index bf1ec00a..7ea4a6f9 100644 >>> --- a/handlers/ubivol_handler.c >>> +++ b/handlers/ubivol_handler.c >>> @@ -310,6 +310,7 @@ static int resize_volume(struct img_type *cfg, long long size) >>> struct ubi_mkvol_request req; >>> struct mtd_ubi_info *mtd_info; >>> int mtdnum, req_vol_type; >>> + int req_vol_id = UBI_VOL_NUM_AUTO; >>> char node[64]; >>> int err; >>> struct flash_description *flash = get_flash_info(); >>> @@ -371,6 +372,7 @@ static int resize_volume(struct img_type *cfg, long long size) >>> } >>> >>> snprintf(node, sizeof(node), "/dev/ubi%d", ubivol->vol_info.dev_num); >>> + req_vol_id = ubivol->vol_info.vol_id; >>> err = ubi_rmvol(nandubi->libubi, node, ubivol->vol_info.vol_id); >>> if (err) { >>> ERROR("Volume %s cannot be dropped", ubivol->vol_info.name); >>> @@ -392,7 +394,7 @@ static int resize_volume(struct img_type *cfg, long long size) >>> */ >>> memset(&req, 0, sizeof(req)); >>> req.vol_type = req_vol_type; >>> - req.vol_id = UBI_VOL_NUM_AUTO; >>> + req.vol_id = req_vol_id; >>> req.alignment = 1; >>> req.bytes = size; >>> req.name = cfg->volname; >> >
diff --git a/handlers/ubivol_handler.c b/handlers/ubivol_handler.c index bf1ec00a..7ea4a6f9 100644 --- a/handlers/ubivol_handler.c +++ b/handlers/ubivol_handler.c @@ -310,6 +310,7 @@ static int resize_volume(struct img_type *cfg, long long size) struct ubi_mkvol_request req; struct mtd_ubi_info *mtd_info; int mtdnum, req_vol_type; + int req_vol_id = UBI_VOL_NUM_AUTO; char node[64]; int err; struct flash_description *flash = get_flash_info(); @@ -371,6 +372,7 @@ static int resize_volume(struct img_type *cfg, long long size) } snprintf(node, sizeof(node), "/dev/ubi%d", ubivol->vol_info.dev_num); + req_vol_id = ubivol->vol_info.vol_id; err = ubi_rmvol(nandubi->libubi, node, ubivol->vol_info.vol_id); if (err) { ERROR("Volume %s cannot be dropped", ubivol->vol_info.name); @@ -392,7 +394,7 @@ static int resize_volume(struct img_type *cfg, long long size) */ memset(&req, 0, sizeof(req)); req.vol_type = req_vol_type; - req.vol_id = UBI_VOL_NUM_AUTO; + req.vol_id = req_vol_id; req.alignment = 1; req.bytes = size; req.name = cfg->volname;
UBI volume resizing is implemented by deleting and (re-)creating a volume. If the volume previously existed, its type (static or dynamic) is copied over, however its volume ID is lost. This is a problem for volumes containing a rootfs, since the UBI/MTD/Block adaptoin layer in the kernel does not understand the <ubi-device>:<ubi-volume-name> syntax; volumes have to passed to the root=-parameter by volume ID, i.e.: root=/dev/ubiblock0_<volid>. Hence, this gets tricky in the bootloader. A simpler approach is to keep volume IDs stable if a volume is re-created. Signed-off-by: Hannes Weisbach <weisbach@neosat.de> --- handlers/ubivol_handler.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-)