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
