Re: [LEDE-DEV] can't install luci
On 2016-10-16 14:35, Matthias Schiffer wrote: On 10/16/2016 09:18 AM, Torbjorn Jansson wrote: On 2016-10-15 18:55, Matthias Schiffer wrote: On 10/15/2016 06:30 PM, Torbjorn Jansson wrote: On 2016-10-15 17:39, Matthias Schiffer wrote: On 10/15/2016 05:19 PM, Matthias Schiffer wrote: On 10/15/2016 05:04 PM, Torbjorn Jansson wrote: Hello i decided to give lede a try on one of my rasberry pi computers and i almost immediately ran into problems. opkg update works fine, but when i do: opkg install luci-ssl i get: root@lede:~# opkg install luci-ssl Installing luci-ssl (git-16.288.36935-1e1a706-1) to root... Downloading http://downloads.lede-project.org/snapshots/packages/arm_arm1176jzf-s_vfp/luci/luci-ssl_git-16.288.36935-1e1a706-1_all.ipk. Collected errors: * satisfy_dependencies_for: Cannot satisfy the following dependencies for luci-ssl: * luci-mod-admin-full * * opkg_install_cmd: Cannot install package luci-ssl. i checked the url and luci-mod-admin-full is indeed missing. can someone explain whats going on and how to fix it? Hi, a recent patch caused the libnl-tiny build to fail [1], which in turn broke a lot of other packages that directly or indirectly depend on it. We're working on fixing this ASAP. Regards, Matthias I've just had a closer look at the issue, it was caused by a dependency issue of our 2-phase build bot setup: Phase 2 tried to build the packages based on an outdated SDK version, as Phase 1 has not finished building the newest version the SDK yet. This broke some packages, as patches depending on SDK changes were added together with the SDK changes themselves. The issue will fix itself as soon as the build bots have finished the next round of builds. Sorry for the inconvenience! and how often do the build bots rebuild things? once a day? Phase 1 rebuilds are triggered for each master commit, but there are many targets and builds take some time. You can find the current build status on http://phase1.builds.lede-project.org/grid . Phase 2 builds can be seen on http://phase2.builds.lede-project.org/grid . The issue will disappear as soon as phase 1 has finished for your target (and thus produced a new SDK), and the next phase 2 build after that has finished, too. This should be done in less than a day. phase 1 & 2 is done for my target in question (an rpi) but i suspect it was still done in wrong order or something because there is still lots of missing packages including those making luci-ssl work. Yes, that's the case. The next arm_arm1176jzf-s_vfp build should finally fix everything. it did fix the issue and i got it working. i did notice one odd thing while trying to mount an extra sd card. when i click save and apply in luci in the block mount page all mounts get screwed up and i have to reboot. after reboot it works as intended, it is just the apply step that goes wrong for some reason, i suspect it removed mounts it is not supposed to mess with like /proc and /sys (ran mount manually after and it complained about missing mtab) ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] [RFC 0/1] x86: Add support for the PC Engines APU2 Board
On 10/16/2016 05:30 PM, STR . wrote: >> I'd rather like to see the bcp38 stuff a default, but although we made the >> code work right for one layer of nat, too many people have more than that. :( > Double NAT? > Common for fibre providers, and 3G/4G, where the "modem" isn't a modem but a router and the only thing you can do is placing your lede device in a DMZ, but you cannot remove the nat without hacking (for 3G/4G) or at all for fibre providers. Or without disabling any routing on the lede device and let the other device take over the router role. -Alberto ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] [RFC 0/1] x86: Add support for the PC Engines APU2 Board
On 10/16/2016 08:30 AM, STR . wrote: BQL + fq_codel kills bufferbloat at line rate (10,100,1000mbit) on ethernet cards. It also works if you have hardware flow control on the the ethernet. It can't do anything on downloads. If your connection is not at line rate or the download is overbuffered (looks like 20Mbit here), you need a soft shaper like the ones in sqm-scripts (htb + fq_codel or cake) set 5-15% below the observed rate to win. So I was misreading it. Thanks for clearing that up, this was tested on an 8M down ADSL, I'll check out the sqm-scripts. Do you know of someone making a bigger better case for it? I'd like one with 6 antenna slots for just that reason - and better heat management. This has been a gripe for everyone owning an APU2 it seems. 6 holes for antenna? I know none. You can find $30 hand punches on Amazon/Ebay and their largest punch size is typically perfect for SMA connectors. The APU2 case is easily punched since it is aluminum. https://www.amazon.com/Neiko-02612A-Multi-Purpose-Power-Punch/dp/B0002T87CW/ref=sr_1_3?ie=UTF8=1476634765=8-3=metal+punch Also, I've run these systems at full load (500Mbps+) for 24 hours and though the case gets warm, system has remained stable. A warm case actually means it is transferring heat... Thanks, Ben -- Ben GreearCandela Technologies Inc http://www.candelatech.com ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] [RFC 0/1] x86: Add support for the PC Engines APU2 Board
> BQL + fq_codel kills bufferbloat at line rate (10,100,1000mbit) on ethernet > cards. It also works if you have hardware flow control on the the ethernet. > It can't do anything on downloads. > If your connection is not at line rate or the download is overbuffered > (looks like 20Mbit here), you need a soft shaper like the ones in sqm-scripts > (htb + fq_codel or cake) set 5-15% below the observed rate to win. So I was misreading it. Thanks for clearing that up, this was tested on an 8M down ADSL, I'll check out the sqm-scripts. > Do you know of someone making a bigger better case for it? I'd like one with > 6 antenna slots for just that reason - and better heat management. This has been a gripe for everyone owning an APU2 it seems. 6 holes for antenna? I know none. The Calexium case can definitely do better thermal management but useless for you since you can't add all the radios+antenna - http://store.calexium.com/en/boitiers/324-pc-engines-alix-2d3-2d13-or-openvox-ipc100-110-120-case-with-hdd-wifi-black.html Check the last post on this page for ideas on thermal management - http://pcengines.info/forums/?page=post=795B2ACC-F4B0-4181-9B4A-54EC757D4001=DF5ACB70-99C4-4C61-AFA6-4C0E0DB05B2A=2 > I'd rather like to see the bcp38 stuff a default, but although we made the > code work right for one layer of nat, too many people have more than that. :( Double NAT? > ... after we finish up the airtime fairness code and rip out some more wifi > latencies. Eagerly looking forward to this! ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
[LEDE-DEV] LEDE Reboot r1588+145 vs LEDE Reboot r1588+257 on TP-Link Archer C7 v2 / constant bootloop on 257
Hi, i tried to upgrade my TP-Link Archer C7 v2 from 145 to 257 and router seems to be in constant reboot cycle. When I reset the config via recovery, the router boots fine, currently I'm back on v145. Unfortunately I don't have serial (and AP is under warranty), so I guess I can't investigate it (the network ping holds only like 5 secs, not enough time for log..). I tried it flashing twice - same results. Using the same sources (but different config), others sets like tl-mr3020-v1,-tl-wa850re-v1,tl-wr841-v11 etc. are absolutely fine. I know it's very vague description but any idea what could be causing this between 145 and 257 versions ? My TP-Link Archer C7 v2 config if it helps : http://pastebin.com/zBeRpczT PS : Yes, I know I can start from scratch and see, when it broke unfortunately I can't break internet connectivity except of night... PS2 : Reason I would like to update are random lost of Wifi connectivity (I didn't investigate more yet, LEDs are blinking but WiFi seems to be gone), versions prior to 145 were also fine. Thank you. Bretislav ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] [PATCH]fstools: added xfs and f2fs to block-mount
Damn, while this patch adds only partial xfs support to fstools (it allows to mount xfs by block mount). Most of fstools have code to use f2fs too already so the fact that block mount couldn't mount f2fs is 100% a bug and this patch fixes that. I'm going to add xfs support to other fstools components in a following patch. -Alberto On 10/15/2016 07:25 PM, Alberto Bursi wrote: > added the code to recognize the filesystem checkers for xfs and f2fs > added xfs and f2fs to the filesystem whitelist of block. > > Signed-off-by: Alberto Bursi> - > > --- fstools/block.c 2016-10-15 19:15:31.916714011 +0200 > +++ fstools/block.c 2016-10-15 19:22:44.164702448 +0200 > @@ -702,6 +702,8 @@ static void check_filesystem(struct blki > { > pid_t pid; > struct stat statbuf; > + const char *xfsck = "/sbin/xfs_repair"; > + const char *f2fsck = "/usr/sbin/fsck.f2fs"; > const char *e2fsck = "/usr/sbin/e2fsck"; > const char *dosfsck = "/usr/sbin/dosfsck"; > const char *ckfs; > @@ -712,6 +714,10 @@ static void check_filesystem(struct blki > > if (!strncmp(pr->id->name, "vfat", 4)) { > ckfs = dosfsck; > + } else if (!strncmp(pr->id->name, "f2fs", 4)) { > + ckfs = f2fsck; > + } else if (!strncmp(pr->id->name, "xfs", 3)) { > + ckfs = xfsck; > } else if (!strncmp(pr->id->name, "ext", 3)) { > ckfs = e2fsck; > } else { > @@ -1170,8 +1176,10 @@ static int mount_extroot(char *cfg) > } > if (pr) { > if (strncmp(pr->id->name, "ext", 3) && > - strncmp(pr->id->name, "ubifs", 5)) { > - ULOG_ERR("extroot: unsupported filesystem %s, try > ext4\n", > pr->id->name); > +strncmp(pr->id->name, "xfs", 3) && > +strncmp(pr->id->name, "f2fs", 4) && > +strncmp(pr->id->name, "ubifs", 5)) { > +ULOG_ERR("extroot: unsupported filesystem %s, try ext4, > xfs, f2fs, ubifs\n", pr->id->name); > return -1; > } > > ___ > Lede-dev mailing list > Lede-dev@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/lede-dev > ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] [RFC 1/1] x86: Add support for the PC Engines APU2 Board
Hey Stijn, Thanks for the feedback, will get this fixed up for the next RFC as well. Please keep the feedback coming. :) - Chris B On Sat, Oct 15, 2016 at 9:41 AM, Stijn Tintelwrote: > On 14-10-16 20:19, Chris Blake wrote: >> The following patch adds support for the PC Engines APU2 Embedded Board >> as a profile under the X86_64 target. More information on this board can >> be found at www.pcengines.ch/apu2c4.htm >> >> Note that this patch is a part of an RFC, and should not be merged yet. >> >> Signed-off-by: Chris Blake >> --- >> target/linux/x86/64/config-default | 12 + >> target/linux/x86/64/profiles/001-PCEngines.mk | 20 + >> target/linux/x86/base-files/etc/board.d/01_leds| 22 ++ >> target/linux/x86/base-files/etc/board.d/02_network | 26 ++ >> target/linux/x86/base-files/etc/diag.sh| 37 ++ >> target/linux/x86/base-files/lib/x86.sh | 13 + >> target/linux/x86/config-4.4| 1 + >> .../linux/x86/files/drivers/gpio/gpio-nct5104d.c | 432 >> + >> target/linux/x86/files/drivers/leds/leds-apu2.c| 371 ++ >> target/linux/x86/modules.mk| 36 ++ >> .../x86/patches-4.4/800-add-apu2-led-driver.patch | 29 ++ >> .../801-sp5100_tco-add-apu2-support.patch | 91 + >> .../patches-4.4/802-add-nct5104d-gpio-driver.patch | 27 ++ >> 13 files changed, 1117 insertions(+) >> create mode 100644 target/linux/x86/64/profiles/001-PCEngines.mk >> create mode 100755 target/linux/x86/base-files/etc/board.d/01_leds >> create mode 100755 target/linux/x86/base-files/etc/board.d/02_network >> create mode 100755 target/linux/x86/base-files/etc/diag.sh >> create mode 100755 target/linux/x86/base-files/lib/x86.sh >> create mode 100644 target/linux/x86/files/drivers/gpio/gpio-nct5104d.c >> create mode 100644 target/linux/x86/files/drivers/leds/leds-apu2.c >> create mode 100644 target/linux/x86/modules.mk >> create mode 100644 >> target/linux/x86/patches-4.4/800-add-apu2-led-driver.patch >> create mode 100644 >> target/linux/x86/patches-4.4/801-sp5100_tco-add-apu2-support.patch >> create mode 100644 >> target/linux/x86/patches-4.4/802-add-nct5104d-gpio-driver.patch > Please use the correct prefix for patches, see > https://git.lede-project.org/?p=source.git;a=blob;f=target/linux/generic/PATCHES > I would add the watchdog patches like this instead of squashing them, > created with git format-patch: > target/linux/generic/patches-4.4/097-0001-sp5100_tco-Add-AMD-Mullins-platform-support.patch > target/linux/generic/patches-4.4/097-0002-sp5100_tco-Add-AMD-Mullins-platform-support.patch > target/linux/generic/patches-4.4/097-0003-sp5100_tco-fix-the-device-check-for-SB800-and-later-chipsets.patch > target/linux/generic/patches-4.4/097-0004-watchdog-sp5100_tco-properly-check-for-new-register-.patch > > Thanks, > Stijn ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] [RFC 0/1] x86: Add support for the PC Engines APU2 Board
Everything important in CeroWrt long ago made it upstream - the apu2 (which, btw, I have been using as my main test platform for the make-wifi-fast work) has BQL on the intel network drivers, already, fq_codel is the default in lede, sch_cake is available as an optional package, and the make-wifo-fast ath9k work is partially upstream in lede, with only the airtime fairness patches remaining to get folded in (http://blog.cerowrt.org/post/real_results/ more detail here: https://blog.tohojo.dk/2016/06/fixing-the-wifi-performance-anomaly-on-ath9k.html ). dnsmasq-dnssec is an optional package in lede as are the sqm-scripts, luci-app-sqm, and the bcp38 support. So all that is pretty generic to lede/openwrt now. Ath10k needs work, mt72 needs work, but in neither case is that specific to the apu2. What never made it to openwrt from cerowrt was: A) the controversial "rename the devices to reflect the security model" portion of the firewall code. That code allowed for never having to reload the firewall as it used a pattern match on the device name to dynamically add devices to a secure or guest zone. Instead of having one rule for eth0, eth1, eth2, I renamed devices to se00, se01, ge00, and used "s+" as the match. I never figured out how to make that work with vlans, and it was my hope we'd end up with something using nftables that did the same thing. Not huge on reloading firewall rules all the time B) homenet support - that's available in openwrt but not well incorporated. That's hnetd, and babeld and the mdns-proxy stuff. C) routing, not bridging, by default, Routing makes a lot of sense in a lot of cases, and making sure openwrt does that well is something that should be on-going tested - with batman, babel, olsr, etc. The rest of the time bridging is generally faster and simpler. There may well be other cerowrt features I'm forgetting, but that's all I can think of. I look forward to migrating my apu2s to lede soon! ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] [RFC 0/1] x86: Add support for the PC Engines APU2 Board
On 10/16/2016 11:49 AM, STR . wrote: > Could we also build 'lsusb' along with lspci? I'd recommend bundling the > usb-serial-kmod too as a lot of mini-pci devices present themselves as USB. Yes to this. Many 3G/4G modems on mini-pcie port are using usb lines of mini-pcie port and not pcie lines. -Alberto ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
[LEDE-DEV] [RFC 0/1] x86: Add support for the PC Engines APU2 Board
My 2c on USB, lm-sensors and the NCT chip on this board. > This is an RFC to port the PC Engines APU2 board to LEDE. Currently this is based on my unofficial repo at https://github.com/riptidewave93/LEDE-APU2 and after a discussion on the lede-dev IRC on the best plan of action, which was to move this device to a profile under x86_64. > Default Packages: > - flashrom - BIOS Upgrades > - lm-sensors - Temp Monitoring lm-sensors does not report individual core temps. FreeBSD/PFsense reports all 4 core temps correctly. root@lede:/# sensors k10temp-pci-00c3 Adapter: PCI adapter temp1:+62.0°C (high = +70.0°C) (crit = +105.0°C, hyst = +104.0°C) root@lede:/# sensors -u k10temp-pci-00c3 Adapter: PCI adapter temp1: temp1_input: 62.375 temp1_max: 70.000 temp1_crit: 105.000 temp1_crit_hyst: 104.000 Could this be an issue of missing PCI device IDs? From https://github.com/torvalds/linux/blob/master/include/linux/pci_ids.h k10temp.c has these missing: #define PCI_DEVICE_ID_AMD_16H_NB_F3 0x1533 #define PCI_DEVICE_ID_AMD_16H_NB_F4 0x1534 #define PCI_DEVICE_ID_AMD_16H_M30H_NB_F3 0x1583 #define PCI_DEVICE_ID_AMD_16H_M30H_NB_F4 0x1584 temp1max is set to 70C, the AMD GX-412TC in the APU uses the PCengines case as a heatsink via thermal pads. If ambient temps are high (=>30C), I've seen the CPU go as high as 73C, AMD rates the GX-412TC from 0C - 90C so should temp1max be set to something like 75C? The board has 2x USB3.0 ports at the rear and 2x USB 2 header on the SoC. Could we also build 'lsusb' along with lspci? I'd recommend bundling the usb-serial-kmod too as a lot of mini-pci devices present themselves as USB. USB 3.0 seems to be working: root@lede:/# lspci | grep XHCI 00:10.0 USB controller: Advanced Micro Devices, Inc. [AMD] FCH USB XHCI Controller (rev 11) /* According to the USB 3.0 spec, all USB 3.0 devices must support LPM. However, there are some that don't, and they set the U1/U2 exit latencies to zero. With some quirks? root@lede:/# dmesg|grep LPM [1.324138] usb usb3: We don't know the algorithms for LPM for this host, disabling LPM. > - NCT5104D GPIO Driver This is simply good to know info. The NCT5104D I/O controller with an alternate BIOS (work in progress, provided by PCengines support on request) can provide 2 more serial ports (com3/4) while disabling GPIO/I2C. This is useful in some situations as COM1 is generally tied to serial console and sadly com2/UART b provided via headers on the board does not provide all the signals. "UART-b is brought to J3 unshifted. Even though J3 has five pins only transmit, receive and ground are connected. - Paul" Likely unrelated, perhaps at some point changes from CeroWRT could be incorporated as the APU2 does suffer from buffer bloat - https://www.bufferbloat.net/projects/cerowrt/wiki/How_is_CeroWrt_different_f rom_OpenWrt/ ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] Adding support for dlink dwr-512
Mathias, Thanks for the tips. I'm going to work on it. Bye. > -Ursprüngliche Nachricht- > Von: Mathias Kresin [mailto:d...@kresin.me] > Gesendet: Sonntag, 16. Oktober 2016 09:54 > An: Giuseppe Lippolis; lede- > d...@lists.infradead.org > Betreff: Re: [LEDE-DEV] Adding support for dlink dwr-512 > > Hi Giuseppe, > > find a few remarks inline. > > 16.10.2016 00:03, Giuseppe Lippolis: > > Hi all, > > I'm proceeding to finalize the support: > > Now the wifi is enabled, the LEDs and the buttons are supported. > > > > To complete the device support I need to: > > 1. enable the 3G modem > > 2. crack the header file to generate the factory image > > Run the strings command on the binboy binary. The binary includes some > text which looks to me like the description of different headers. > > It might be possible that there is already a tool for writing the binboy header > in tools/firmware-utils. > > > > > Will take some time. > > > > In the meantime, here the patch: > > > > diff --git a/target/linux/ramips/base-files/etc/board.d/02_network > > b/target/linux/ramips/base-files/etc/board.d/02_network > > index c8b57ca..719078c 100755 > > --- a/target/linux/ramips/base-files/etc/board.d/02_network > > +++ b/target/linux/ramips/base-files/etc/board.d/02_network > > @@ -71,6 +71,7 @@ ramips_setup_interfaces() > > dir-320-b1|\ > > dir-610-a1|\ > > dir-615-h1|\ > > + dwr-512-b|\ > > firewrt|\ > > hlk-rm04|\ > > mac1200rv2|\ > > diff --git a/target/linux/ramips/base-files/lib/ramips.sh > > b/target/linux/ramips/base-files/lib/ramips.sh > > index bb379f7..a0f041e 100755 > > --- a/target/linux/ramips/base-files/lib/ramips.sh > > +++ b/target/linux/ramips/base-files/lib/ramips.sh > > @@ -154,6 +154,9 @@ ramips_board_detect() { > > *"DIR-860L B1") > > name="dir-860l-b1" > > ;; > > + *"DWR-512 B") > > + name="dwr-512-b" > > + ;; > > *"Dovado Tiny AC") > > name="tiny-ac" > > ;; > > diff --git a/target/linux/ramips/base-files/lib/upgrade/platform.sh > > b/target/linux/ramips/base-files/lib/upgrade/platform.sh > > index 0ef2308..36ea469 100755 > > --- a/target/linux/ramips/base-files/lib/upgrade/platform.sh > > +++ b/target/linux/ramips/base-files/lib/upgrade/platform.sh > > @@ -50,6 +50,7 @@ platform_check_image() { > > dir-620-a1|\ > > dir-620-d1|\ > > dir-810l|\ > > + dwr-512-b|\ > > duzun-dm06|\ > > e1700|\ > > esr-9753|\ > > diff --git a/target/linux/ramips/dts/DWR-512-B.dts > > b/target/linux/ramips/dts/DWR-512-B.dts > > index e69de29..2a69ce7 100644 > > --- a/target/linux/ramips/dts/DWR-512-B.dts > > +++ b/target/linux/ramips/dts/DWR-512-B.dts > > @@ -0,0 +1,109 @@ > > +/dts-v1/; > > + > > +/include/ "rt5350.dtsi" > > + > > +/ { > > + compatible = "ralink,rt5350-soc"; > > + model = "D-Link DWR-512 B"; > > + > > + gpio-keys-polled { > > + compatible = "gpio-keys-polled"; > > + #address-cells = <1>; > > + #size-cells = <0>; > > + poll-interval = <20>; > > + > > + wps { > > + label = "wps"; > > + gpios = < 0 1>; > > + linux,code = <0x211>; > > + }; > > + }; > > + > > + gpio-leds { > > + compatible = "gpio-leds"; > > + > > + sms { > > + label = "dwr-512-b:green:sms"; > > + gpios = < 8 1>; > > + }; > > + status { > > + label = "dwr-512-b:green:status"; > > + gpios = < 9 1>; > > + }; > > + 2g { > > + label = "dwr-512-b:green:2g"; > > + gpios = < 17 1>; > > + }; > > + 3g { > > + label = "dwr-512-b:green:3g"; > > + gpios = < 19 1>; > > + }; > > + sstrengthr { > > + label = "dwr-512-b:red:sigstrength"; > > + gpios = < 20 1>; > > + }; > > + sstrengthg { > > + label = "dwr-512-b:green:sigstrength"; > > + gpios = < 21 1>; > > + }; > > + }; > > +}; > > + > > + { > > + status = "okay"; > > + > > + mx25l6405d@0 { > > + #address-cells = <1>; > > + #size-cells = <1>; > > + compatible = "macronix,mx25l6405d", "jedec,spi-nor"; > > + reg = <0>; > > + spi-max-frequency = <3000>; > > + fast-read; > > + > > + partition@0 { > > + label = "bootloader"; > > + reg = <0x0 0x1>; > > + read-only; > > + }; > > + > > + partition@1 { > > + label = "Kernel"; > > + reg = <0x1 0x14>; > > + read-only; > > + }; > > + > > + partition@15 { > > + label = "rootfs"; >