[Buildroot] Udev on a live CD system does not appear to populate /dev

Stefan Fröberg stefan.froberg at petroprogram.com
Thu Nov 8 16:29:17 UTC 2012


I forgot to mention one more thing:

If you ever want to use the maximum compression method supported by
modern kernels (XZ compression)
then change that initramfs generation command to this:

find .  -not \( -path "./boot" -prune \) -print0 | cpio --null -ov --format=newc
 | xz --check=crc32 > /livecd/initramfs.xz

Without that --check=crc32 parameter you won't be able to boot
XZ-compressed initramfs.

Regards
Stefan

8.11.2012 18:02, Antony Vennard kirjoitti:
> Hi Stefan,
>
> Thanks for that. I have followed your instructions for making a live cd
> manually with mkisofs - actually this is helpful since a later job is to
> add UEFI booting to the disk, which is easier this way (although I am
> going to look at modifying buildroot, if I can).
>
> I am using grub, and have modified my grub command line to use:
>
> title LiveCD
> kernel /vmlinuz vga=0x317
> initrd /initramfs.bz2
>
> The kernel has bz2, xz and gzip initramfs support built in - so all good
> there. However, the kernel complains there's no root parameter. What
> should I specify for this?
>
> Thanks,
>
> Antony
>
> On 08/11/2012 12:35, Stefan Fröberg wrote:
>> Hi Antony
>>
>> Just one guestion: What bootloader are you using for your Live CD ?
>> (I use grub)
>>
>> 8.11.2012 11:56, Antony Vennard kirjoitti:
>>> Hi All,
>>>
>>> I'm not using initramfs - I'm using the ISO 9660 target which as far
>>> as I can see produces an initrd, a kernel and an ext2 raw image which
>>> it mounts as a ramdisk. If I select the initramfs options, the cpio
>>> filesystem is generated prior to the iso9660 one, *but the initramfs
>>> afterwards!* Which means, as far as I can see, that initramfs would
>>> not be placed on the disk - unless buildroot manipulates the iso
>>> filesystem post creation? I could of course mkisofs myself, but I was
>>> trying to avoid that - although if this fixes udev, I'll do it.
>>>
>> Keep in mind that the buildroot way of making initramfs (that is if you
>> select intramfs from menuconfig) is
>> to embed your initramfs directly into kernel.
>>
>> There are three disadvantages in here:
>>
>> 1 ) It will make your kernel fatter
>> 2 ) It will makes things more complicated than necessary
>> You might have two initramfs settings: One that is embedded directly
>> into your kernel and
>> another that you have made by hand by yourself. And it's very possible
>> that they could have conflicting stuff between them
>> You can have several initramfs files (at least with grub bootloader),
>> the last ones overlaying the first ones, in order.
>> 3 ) It will makes less flexibe.
>>  
>> All kernels since 2.6 have initramfs inside them, it's just that by
>> default that environment is empty.
>>
>> Embedding initramfs directly to kernel might be good for those users who
>> don't use any bootloader or are using a bootloader which can't
>> be feeded external, separate initramfs file(s) (like grub) and want to
>> have minimal system always available (as piggybacked inside kernel).
>>
>>
>>> I've nothing /dev related in my fs/skeleton, and only the default
>>> values in device_table.txt. Since I'm using udev, I did expect it
>>> would populate everything it needed in /dev - although unless I add
>>> entries for null, console and a tty into device_table.txt, I end up
>>> with a distribution that loops forever saying "could not find
>>> /dev/tty1" (if I've configured tty1 as the location for getty for
>>> example). I can't mitigate this by re-writing the inittab to launch
>>> getty "once" as opposed to respawn, since buildroot rewrites that -
>>> and askfirst:/bin/sh works, except that the respawn error messages are
>>> written all over /dev/console, making it unusable...!
>>>
>>> By the sounds of things this is wrong, but I'm currently attempting to
>>> preconfigure some devices in device_table.txt - e.g. /dev/null,
>>> /dev/urandom et al pseudo devices, and I'm borrowing Ubuntu's rules.d
>>> to see if these are any more effective than Fedora's. Leaving
>>> device_table.txt as its default causes the tty1 missing loop. I am not
>>> expecting this to work - I cannot see how udev rules differ greatly
>>> between distributions - just eliminating it as a possible cause.
>>>
>>> Any further ideas as to what I can try? Is mdev a better choice?
>>>
>> Well mdev is at least easier to configure than udev.
>>
>> The only thing you must make sure in your init process is that /proc and
>> /sys are mounted as early as possible (/etc/inittab is good place for that)
>> and that echo /sbin/mdev > /proc/sys/kernel/hotplug   is also somewhere
>> in /etc/init.d/rcS (maybe at the start of that file)
>>
>> And check that you have etc/mdev.conf and etc/init.d/S10mdev (witch is
>> called by /etc/init.d/rcS)
>>
>> This is what I would do (and have done with my live CD)
>> Forget the buildroot way of making initramfs for now and see if you can
>> construct live CD by hand:
>>
>> 1 ) make clean
>>
>> 2 ) make sure you have all the needed init stuff in  fs/skeleton/etc
>> directory (inittab, init.d/rcS, init.d/S* files etc.....)
>>      also make sure that sbin/init is a symlink to /bin/busybox
>> (I have also symlink of init --> /bin/busybox in top of fs/skeleton but
>> I not sure if that is stricly needed ...
>> I think kernel should be looking from /sbin/init if no other init found)
>>
>> 3 )  do make menuconfig as you would normally but remember to unselect
>> cpio, initramfs and iso9660 from menuconfig
>>        remember to select grub from under Bootloader section if you
>> don't already have it
>>        don't select too much of stuff even if you have massive amounts 
>> of RAM in your test systems.
>>        reason being that you are making initramfs later here from your
>> output/target directory and if you have massive
>>       amount's of stuff in there then it will take forever to boot. (I
>> have managed to do live CD with massive amounts of stuff on it and
>>      booting fast with only 192 MB RAM but that needed some major hacking)
>>
>> 4 ) do    make linux-menuconfig  and check that under General setup the
>> setting Initramfs source files is empty
>>      also check the compression support here that you want to use for
>> your external initramfs (let's suppose its' the default GZ for now)
>>
>> 5 ) do make
>>
>> 6 ) after buildroot has finished make sure that everything is okay in
>> your output/target (check especially boot/ etc/ and /dev directory)
>>      also make sure you have /boot/grub/menu.lst or /boot/grub/grub.conf
>> (the other is usually just symlink to other) and check it's settings
>>     (If you are not familiar with grub then I can help with it's
>> settings, especially important is the line where you tell grub the external
>>    initramfs file)
>>      remove the symlink (iso9660 format does not support symlinks)
>>
>> 7 ) Create directory where you want to put your kernel & bootloader
>> (a.ka. the whole contents of /boot dir) and external initramfs file
>>      that is generated next:   
>>     
>>       mkdir /livecd && cp -r output/target/boot /livecd
>>
>> 8 ) from output/target dir   do    find .  -not \( -path "./boot" -prune
>> \) -print0 | cpio --null -ov --format=newc | gzip -9 > /livecd/initramfs.gz
>> (we don't need boot directory inside initramfs. it needs to stay outside
>> of it. that why it was copied previously)
>>
>> 9 ) make iso9660 normally from the contents of your /livecd
>> mkdir /livecd_output && cd /livecd && mkisofs --joliet -R -b
>> boot/grub/stage2_eltorito -no-emul-boot -boot-load-size 4
>> -boot-info-table -iso-level 4 -hide-rr-moved -c boot.catalog -o
>> /livecd_output/your_livecd.iso .
>>
>> (remember that . at the end)
>>
>> 10) burn the iso to CD or even better use qemu or VirtualBox to boot
>> your iso without wasting CD disc.
>>
>> If this manual way worked then next try buildroot way.
>>
>> Best regards
>> Stefan
>>
>>> Thanks for your help,
>>>
>>> Antony
>>>
>>> ________________
>>>
>>> Macrium™ Software is a trading name of Paramount Software UK Ltd,
>>> Registered in England and Wales Number 02973414
>>> Registered Office: Kilburn House, Manchester Science Park, Lloyd St.
>>> North, Manchester M15 6SE United Kingdom
>>>
>>> The information contained in this e-mail is confidential, privileged,
>>> or otherwise protected from disclosure. It is intended only for the
>>> use of the authorized individual as indicated in the e-mail. Any
>>> unauthorized disclosure, copying, distribution or taking of any action
>>> based on the contents of this material is strictly prohibited.
>>>
>>> If you have received this e-mail in error, please delete it immediately.
>>>
>>>
>>>
>>> _______________________________________________
>>> buildroot mailing list
>>> buildroot at busybox.net
>>> http://lists.busybox.net/mailman/listinfo/buildroot



More information about the buildroot mailing list