Re: [leaf-devel] findfs in linuxrc
Am 01.01.2016 um 14:15 schrieb kp kirchdoerfer: > Happy New Year to all! > > > Am Donnerstag, 31. Dezember 2015, 12:23:39 schrieb Erich Titl: >> Hi KP >> >> Am 30.12.2015 um 20:11 schrieb kp kirchdoerfer: >>> Erich; >> >> .. >> >>> Looking at the busybox documentation, it seems it does support handling of >>> LABEL and UUID. >>> >>> We should give it a try. >> >> I have built a initrd with findfs enabled in busybox and struggled for a >> few hours with linuxrc (which is not that seamlessly written in this >> aspect) to boot from a UUID specified partition. >> >> title LEAF Styx primary boot UUID >> root (hd0,1) >> kernel /linux1 \ >> console=ttyS0,38400 \ >> init=/linuxrc rw \ >> usb_wait=3 \ >> VERBOSE=1 \ >> intel_idle.max_cstate=0 \ >> processor.max_cstate=1 \ >> root=/dev/ram0 \ >> boot=UUID=C765-30E4:vfat \ >> reboot=bios \ >> zswap.enabled=1 \ >> zswap_size=128M \ >> initrd=initrd2.lrp \ >> libata.force=1.00:pio4 \ >> PKGPATH=UUID=C765-30E4:vfat \ >> LEAFCFG=UUID=C765-30E4:vfat >> savedefault >> >> initrd /initrd2.lrp >> >> title LEAF Styx primary boot with label >> root (hd0,1) >> kernel /linux1 \ >> console=ttyS0,38400 \ >> init=/linuxrc rw \ >> usb_wait=3 \ >> VERBOSE=1 \ >> intel_idle.max_cstate=0 \ >> processor.max_cstate=1 \ >> root=/dev/ram0 \ >> boot=LABEL=PRIMARY:vfat \ >> reboot=bios \ >> zswap.enabled=1 \ >> zswap_size=128M \ >> initrd=initrd2.lrp \ >> libata.force=1.00:pio4 \ >> PKGPATH=LABEL=PRIMARY:vfat \ >> LEAFCFG=LABEL=PRIMARY:vfat >> savedefault >> >> initrd /initrd2.lrp >> >> >> >> SALT# blkid >> /dev/zram0: UUID="341406ff-6ca6-4b89-bfc5-5c9020bb0cc6" TYPE="swap" >> /dev/sda1: SEC_TYPE="msdos" UUID="C72F-3FC7" TYPE="vfat" >> PARTUUID="d0302fd7-01" >> /dev/sda2: SEC_TYPE="msdos" LABEL="PRIMARY" UUID="C765-30E4" TYPE="vfat" >> PARTUUID="d0302fd7-02" >> /dev/sda3: SEC_TYPE="msdos" LABEL="SECONDARY" UUID="C784-A612" >> TYPE="vfat" PARTUUID="d0302fd7-03" >> /dev/sda5: SEC_TYPE="msdos" UUID="C7A6-1054" TYPE="vfat" >> PARTUUID="d0302fd7-05" >> >> >> >> I have successfully booted using either UUID and LABEL or the classical >> /dev notation, which makes this initrd suitable for all our supported >> type of partition identification. This initrd has been weeded out quite >> a bit. It needs a kernel with compiled in storage drivers from previous >> tests and it does not copy modules which reduces the memory footprint of >> our system quite a bit. > > Erich, sounds great! > >> We can safely remove findfs from hdsupp now. >> >> I will push the corresponding branch to the repository before midnight :-) > > I looked into the source, a few notes/questions. > > If you remove moddb we need something else to save and load firmware - > currently we use moddb.lrp. I _believe_ moddb is the wrong place for firmware. This is, because there is no automatic insertion of firmware anyway, it is somehow manually selected and never gets replaced. In this case we might just as well add it to local, which I don't think is too apropriate neither, but more closely related to the real local character of firmware. > > Is configuring modules in /etc/modules still supported? > We still need this for modules that are not detectable by hwdetect (non- > hardware related modules) Of course > > While it looks ok, how shorewall uses modules.sqfs, it will needs to be added > as patch - if at all. > Another approach could be to add those modules to /etc/modules, as we did in > the beginning with all modules more than a dozen years ago :) If you look at the init.sh you see that modules.sqfs is temporarily mounted for shorewall to start. > This will load netfilter modules, even if one uses something else than > shorewall to configure the firewall rules. Right, I am plannng to build two small scripts which make modules available for whoever needs it. > > I'd like to see the kernel config changes in the 4.4 configs - I'm pretty > shure > we'll update the kernel for next major version, and I'm also shure that > changing linuxrc/modules loading that much will be rather part of a new > major > version, than an update in the maintenance version 5.2 with kernel 4.1. Right, we just need to make sure this is tested well, as upgrade needs to somehow handle it too. It makes upgrade a lot easier than before, but it requires quite a bit more storage on whatever medium. > > Currently building and will do some testing... > cheers ET -- ___ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] findfs in linuxrc
Happy New Year to all! Am Donnerstag, 31. Dezember 2015, 12:23:39 schrieb Erich Titl: > Hi KP > > Am 30.12.2015 um 20:11 schrieb kp kirchdoerfer: > > Erich; > > .. > > > Looking at the busybox documentation, it seems it does support handling of > > LABEL and UUID. > > > > We should give it a try. > > I have built a initrd with findfs enabled in busybox and struggled for a > few hours with linuxrc (which is not that seamlessly written in this > aspect) to boot from a UUID specified partition. > > title LEAF Styx primary boot UUID > root (hd0,1) > kernel /linux1 \ > console=ttyS0,38400 \ > init=/linuxrc rw \ > usb_wait=3 \ > VERBOSE=1 \ > intel_idle.max_cstate=0 \ > processor.max_cstate=1 \ > root=/dev/ram0 \ > boot=UUID=C765-30E4:vfat \ > reboot=bios \ > zswap.enabled=1 \ > zswap_size=128M \ > initrd=initrd2.lrp \ > libata.force=1.00:pio4 \ > PKGPATH=UUID=C765-30E4:vfat \ > LEAFCFG=UUID=C765-30E4:vfat > savedefault > > initrd /initrd2.lrp > > title LEAF Styx primary boot with label > root (hd0,1) > kernel /linux1 \ > console=ttyS0,38400 \ > init=/linuxrc rw \ > usb_wait=3 \ > VERBOSE=1 \ > intel_idle.max_cstate=0 \ > processor.max_cstate=1 \ > root=/dev/ram0 \ > boot=LABEL=PRIMARY:vfat \ > reboot=bios \ > zswap.enabled=1 \ > zswap_size=128M \ > initrd=initrd2.lrp \ > libata.force=1.00:pio4 \ > PKGPATH=LABEL=PRIMARY:vfat \ > LEAFCFG=LABEL=PRIMARY:vfat > savedefault > > initrd /initrd2.lrp > > > > SALT# blkid > /dev/zram0: UUID="341406ff-6ca6-4b89-bfc5-5c9020bb0cc6" TYPE="swap" > /dev/sda1: SEC_TYPE="msdos" UUID="C72F-3FC7" TYPE="vfat" > PARTUUID="d0302fd7-01" > /dev/sda2: SEC_TYPE="msdos" LABEL="PRIMARY" UUID="C765-30E4" TYPE="vfat" > PARTUUID="d0302fd7-02" > /dev/sda3: SEC_TYPE="msdos" LABEL="SECONDARY" UUID="C784-A612" > TYPE="vfat" PARTUUID="d0302fd7-03" > /dev/sda5: SEC_TYPE="msdos" UUID="C7A6-1054" TYPE="vfat" > PARTUUID="d0302fd7-05" > > > > I have successfully booted using either UUID and LABEL or the classical > /dev notation, which makes this initrd suitable for all our supported > type of partition identification. This initrd has been weeded out quite > a bit. It needs a kernel with compiled in storage drivers from previous > tests and it does not copy modules which reduces the memory footprint of > our system quite a bit. Erich, sounds great! > We can safely remove findfs from hdsupp now. > > I will push the corresponding branch to the repository before midnight :-) I looked into the source, a few notes/questions. If you remove moddb we need something else to save and load firmware - currently we use moddb.lrp. Is configuring modules in /etc/modules still supported? We still need this for modules that are not detectable by hwdetect (non- hardware related modules) While it looks ok, how shorewall uses modules.sqfs, it will needs to be added as patch - if at all. Another approach could be to add those modules to /etc/modules, as we did in the beginning with all modules more than a dozen years ago :) This will load netfilter modules, even if one uses something else than shorewall to configure the firewall rules. I'd like to see the kernel config changes in the 4.4 configs - I'm pretty shure we'll update the kernel for next major version, and I'm also shure that changing linuxrc/modules loading that much will be rather part of a new major version, than an update in the maintenance version 5.2 with kernel 4.1. Currently building and will do some testing... kp -- ___ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] findfs in linuxrc
Hi KP Am 30.12.2015 um 20:11 schrieb kp kirchdoerfer: > Erich; > .. > > Looking at the busybox documentation, it seems it does support handling of > LABEL and UUID. > > We should give it a try. I have built a initrd with findfs enabled in busybox and struggled for a few hours with linuxrc (which is not that seamlessly written in this aspect) to boot from a UUID specified partition. title LEAF Styx primary boot UUID root (hd0,1) kernel /linux1 \ console=ttyS0,38400 \ init=/linuxrc rw \ usb_wait=3 \ VERBOSE=1 \ intel_idle.max_cstate=0 \ processor.max_cstate=1 \ root=/dev/ram0 \ boot=UUID=C765-30E4:vfat \ reboot=bios \ zswap.enabled=1 \ zswap_size=128M \ initrd=initrd2.lrp \ libata.force=1.00:pio4 \ PKGPATH=UUID=C765-30E4:vfat \ LEAFCFG=UUID=C765-30E4:vfat savedefault initrd /initrd2.lrp title LEAF Styx primary boot with label root (hd0,1) kernel /linux1 \ console=ttyS0,38400 \ init=/linuxrc rw \ usb_wait=3 \ VERBOSE=1 \ intel_idle.max_cstate=0 \ processor.max_cstate=1 \ root=/dev/ram0 \ boot=LABEL=PRIMARY:vfat \ reboot=bios \ zswap.enabled=1 \ zswap_size=128M \ initrd=initrd2.lrp \ libata.force=1.00:pio4 \ PKGPATH=LABEL=PRIMARY:vfat \ LEAFCFG=LABEL=PRIMARY:vfat savedefault initrd /initrd2.lrp >> SALT# blkid /dev/zram0: UUID="341406ff-6ca6-4b89-bfc5-5c9020bb0cc6" TYPE="swap" /dev/sda1: SEC_TYPE="msdos" UUID="C72F-3FC7" TYPE="vfat" PARTUUID="d0302fd7-01" /dev/sda2: SEC_TYPE="msdos" LABEL="PRIMARY" UUID="C765-30E4" TYPE="vfat" PARTUUID="d0302fd7-02" /dev/sda3: SEC_TYPE="msdos" LABEL="SECONDARY" UUID="C784-A612" TYPE="vfat" PARTUUID="d0302fd7-03" /dev/sda5: SEC_TYPE="msdos" UUID="C7A6-1054" TYPE="vfat" PARTUUID="d0302fd7-05" I have successfully booted using either UUID and LABEL or the classical /dev notation, which makes this initrd suitable for all our supported type of partition identification. This initrd has been weeded out quite a bit. It needs a kernel with compiled in storage drivers from previous tests and it does not copy modules which reduces the memory footprint of our system quite a bit. We can safely remove findfs from hdsupp now. I will push the corresponding branch to the repository before midnight :-) cheers ET -- ___ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] findfs in linuxrc
Erich; Am Dienstag, 29. Dezember 2015, 12:52:20 schrieb Erich Titl: > Hi KP > > Am 28.12.2015 um 21:12 schrieb kp kirchdoerfer: > > Hi Erich; > > ...>> > > >> It requires a different busybox. The current one does not provide findfs. > > > > It requires findfs in initrd, but not necessarily as busybox applet. > > It does not make sense to me to require it to be pulled from hdsupp > unless the busybox findfs applet is not handling LABEL and UUID. Looking at the busybox documentation, it seems it does support handling of LABEL and UUID. We should give it a try. kp -- ___ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] findfs in linuxrc
Hi KP Am 28.12.2015 um 21:12 schrieb kp kirchdoerfer: > Hi Erich; > ...>> >> It requires a different busybox. The current one does not provide findfs. > > It requires findfs in initrd, but not necessarily as busybox applet. It does not make sense to me to require it to be pulled from hdsupp unless the busybox findfs applet is not handling LABEL and UUID. > >> It just puzzles me that nobody ever barfed about it. This makes me think >> it was never used. > > Or users had read the wiki page and followed the instructions. > Then it "just works" - hopefully :) ;-) I believe we need to include this in busybox. The labeling of partitions may not necessarily be done on a LEAF box and be there before the first boot. Without findfs loading of the packages and modules will fail and it might not be easily understood. cheers ET -- ___ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] findfs in linuxrc
Hi Erich; Am Montag, 28. Dezember 2015, 20:55:39 schrieb Erich Titl: > Hi KP > > Am 28.12.2015 um 20:43 schrieb kp kirchdoerfer: > > Hi Erich; > > > > Am Montag, 28. Dezember 2015, 19:59:45 schrieb Erich Titl: > >> Hi KP > >> > >> Am 28.12.2015 um 17:23 schrieb kp kirchdoerfer: > >>> Am Mittwoch, 23. Dezember 2015, 15:30:53 schrieb Erich Titl: > Hi Andrew > >> > >> ... > >> > >>> /lib/libuuid.so.1.3.0 and its symbolic links > >>> > >>> It is marked as an feature "for advanced users" and never has been > >>> enabled > >>> in busybox, but as part of hdsupp.lrp, which means not having findfs in > >>> busybox, does not allow a judgement if the code snippet in linuxrc is > >>> used or not. > >> > >> If it is not included in busybox all this does not make much sense. It > >> will just not work. > > > > Yes it will not work out-of-the-box as outlined by David, but it works if > > one follows the wiki page- hopefully, I haven't checked myself... > > It will not work at all unless you have findfs. As described on the wiki page (pull from hdsupp, and rebuild initrd) > >> So why clutter linuxrc with old and broken code? > > > > I do not consider it as broken code, until I'm proofed wrong. > > Unless you have findfs it will not work. > > > David invested some work to find a solution for a specific setup/problem: > > > > > > "On some systems with multiple disk devices it is not possible to > > guarantee > > the order in which these are identified at boot time. The disk which > > starts out as /dev/sda might become /dev/sdb after a reboot." > > I _guess_ this is true if you add hardware. That would not surprise me. > It might be true for USB based boot for different systems. > > > As-Is it requires the user to rebuild initrd, which is painful, but we may > > better improve this than to neglect a problem. > > It requires a different busybox. The current one does not provide findfs. It requires findfs in initrd, but not necessarily as busybox applet. > It just puzzles me that nobody ever barfed about it. This makes me think > it was never used. Or users had read the wiki page and followed the instructions. Then it "just works" - hopefully :) kp -- ___ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] findfs in linuxrc
Hi KP Am 28.12.2015 um 20:43 schrieb kp kirchdoerfer: > Hi Erich; > > Am Montag, 28. Dezember 2015, 19:59:45 schrieb Erich Titl: >> Hi KP >> >> Am 28.12.2015 um 17:23 schrieb kp kirchdoerfer: >>> Am Mittwoch, 23. Dezember 2015, 15:30:53 schrieb Erich Titl: Hi Andrew >> >> ... >> >>> /lib/libuuid.so.1.3.0 and its symbolic links >>> >>> It is marked as an feature "for advanced users" and never has been enabled >>> in busybox, but as part of hdsupp.lrp, which means not having findfs in >>> busybox, does not allow a judgement if the code snippet in linuxrc is >>> used or not. >> If it is not included in busybox all this does not make much sense. It >> will just not work. > > Yes it will not work out-of-the-box as outlined by David, but it works if one > follows the wiki page- hopefully, I haven't checked myself... It will not work at all unless you have findfs. >> >> So why clutter linuxrc with old and broken code? > > I do not consider it as broken code, until I'm proofed wrong. Unless you have findfs it will not work. > David invested some work to find a solution for a specific setup/problem: > > "On some systems with multiple disk devices it is not possible to guarantee > the order in which these are identified at boot time. The disk which starts > out > as /dev/sda might become /dev/sdb after a reboot." I _guess_ this is true if you add hardware. That would not surprise me. It might be true for USB based boot for different systems. > > As-Is it requires the user to rebuild initrd, which is painful, but we may > better improve this than to neglect a problem. It requires a different busybox. The current one does not provide findfs. It just puzzles me that nobody ever barfed about it. This makes me think it was never used. cheers ET -- ___ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] findfs in linuxrc
Hi Erich; Am Montag, 28. Dezember 2015, 19:59:45 schrieb Erich Titl: > Hi KP > > Am 28.12.2015 um 17:23 schrieb kp kirchdoerfer: > > Am Mittwoch, 23. Dezember 2015, 15:30:53 schrieb Erich Titl: > >> Hi Andrew > > ... > > > /lib/libuuid.so.1.3.0 and its symbolic links > > > > It is marked as an feature "for advanced users" and never has been enabled > > in busybox, but as part of hdsupp.lrp, which means not having findfs in > > busybox, does not allow a judgement if the code snippet in linuxrc is > > used or not. > If it is not included in busybox all this does not make much sense. It > will just not work. Yes it will not work out-of-the-box as outlined by David, but it works if one follows the wiki page- hopefully, I haven't checked myself... > > I suggest to keep it, and probably to enhance our basic system to enable > > this feature by default. > > Now here is the question, 'what for'? > > - Does LEAF work any better with it - NO > - Does it make any handling easier - doubtful > - Does it make LEAF faster - NO > - Does it make LEAF more secure - NO > > So why clutter linuxrc with old and broken code? I do not consider it as broken code, until I'm proofed wrong. David invested some work to find a solution for a specific setup/problem: "On some systems with multiple disk devices it is not possible to guarantee the order in which these are identified at boot time. The disk which starts out as /dev/sda might become /dev/sdb after a reboot." As-Is it requires the user to rebuild initrd, which is painful, but we may better improve this than to neglect a problem. kp -- ___ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] findfs in linuxrc
Hi KP Am 28.12.2015 um 17:23 schrieb kp kirchdoerfer: > Am Mittwoch, 23. Dezember 2015, 15:30:53 schrieb Erich Titl: >> Hi Andrew >> ... > /lib/libuuid.so.1.3.0 and its symbolic links > > > It is marked as an feature "for advanced users" and never has been enabled in > busybox, but as part of hdsupp.lrp, which means not having findfs in busybox, > does not allow a judgement if the code snippet in linuxrc is used or not. If it is not included in busybox all this does not make much sense. It will just not work. > > I suggest to keep it, and probably to enhance our basic system to enable this > feature by default. Now here is the question, 'what for'? - Does LEAF work any better with it - NO - Does it make any handling easier - doubtful - Does it make LEAF faster - NO - Does it make LEAF more secure - NO So why clutter linuxrc with old and broken code? cheers ET -- ___ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] findfs in linuxrc
Am Mittwoch, 23. Dezember 2015, 15:30:53 schrieb Erich Titl: > Hi Andrew > > Am 23.12.2015 um 12:22 schrieb Andrew: > > It seems like it was dropped by unknown reason, so it should be enabled. > > Well, apparently nobody noticed, so I doubt it is used at all. > > cheers > > ET Hi Erich looking at http://bering-uclibc.zetam.org/wiki/Bering-uClibc_5.x_-_User_Guide_-_Basic_Configuration_-_LEAF_Packages#Configuring_syslinux.cfg_or_isolinux.cfg I read For advanced users there is an alternative syntax for LEAFCFG which can reference disks by a persistent block device name - either the file system LABEL or the UUID. This borrows the syntax from other Linux distributions. For example: LEAFCFG=LABEL=LEAFBUC:vfat would use the disk with the DOS filesystem label "LEAFBUC", or LEAFCFG=UUID=3290c629-123e-4c44-b79b-1c71e312a079 (since the filesystem type is optional). Note that this facility is not supported by default since the extra utilities needed to identify devices in this way are not included in the standard initrd.lrp files, and most users prefer a smaller initrd.lrp. However, it is possible to enable this behaviour by following the instructions for Modifying initrd.lrp and adding the following files from hdsupp.lrp: /sbin/findfs /lib/libblkid.so.1.1.0 and its symbolic links /lib/libuuid.so.1.3.0 and its symbolic links It is marked as an feature "for advanced users" and never has been enabled in busybox, but as part of hdsupp.lrp, which means not having findfs in busybox, does not allow a judgement if the code snippet in linuxrc is used or not. I suggest to keep it, and probably to enhance our basic system to enable this feature by default. kp -- ___ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] findfs in linuxrc
Hi Andrew Am 23.12.2015 um 12:22 schrieb Andrew: > It seems like it was dropped by unknown reason, so it should be enabled. Well, apparently nobody noticed, so I doubt it is used at all. cheers ET -- ___ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] findfs in linuxrc
It seems like it was dropped by unknown reason, so it should be enabled. 23.12.2015 13:11, Erich Titl пишет: > Hi David > > Am 23.12.2015 um 11:41 schrieb David M Brooke: >> Hi Erich, >> >> I added that code in 2012 in response to a user request. >> The need for findfs was flagged up at the time. > I guessed so, but looking at the actual busybox configuration this code > snippet is lame. > > # Actually there is no findfs in busybox, so this is lame > > # Convert any UUID= or LABEL= to device file name > case "$1" in > UUID=*|LABEL=*) dev=`/sbin/findfs "$1"`;; > *) dev="$1";; > esac > > So either we reenable findfs or remove the code as it will throw errors > if anyone uses UUID or LABEL. > > cheers > > ET > > -- > > ___ > leaf-devel mailing list > leaf-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/leaf-devel -- ___ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] findfs in linuxrc
Hi David Am 23.12.2015 um 11:41 schrieb David M Brooke: > Hi Erich, > > I added that code in 2012 in response to a user request. > The need for findfs was flagged up at the time. I guessed so, but looking at the actual busybox configuration this code snippet is lame. # Actually there is no findfs in busybox, so this is lame # Convert any UUID= or LABEL= to device file name case "$1" in UUID=*|LABEL=*) dev=`/sbin/findfs "$1"`;; *) dev="$1";; esac So either we reenable findfs or remove the code as it will throw errors if anyone uses UUID or LABEL. cheers ET -- ___ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] findfs in linuxrc
Hi Erich, I added that code in 2012 in response to a user request. The need for findfs was flagged up at the time. See http://sourceforge.net/p/leaf/mailman/message/29449905/ David > On 23 Dec 2015, at 10:16, Erich Titl wrote: > > Hi Folks > > Looking at linuxrc I see that there is some code to use UUID or LABEL to > identify a hard disk for boot. > > Now this code uses findfs, which is not enabled in busybox making the > code lame. I suggest to drop it entirely as there appears not to be a > real use case. > > cheers > > ET > -- ___ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
