You are not logged in.
OTOH, larch 5.3.8 stopped to work for me since initscripts-2008.09-2 is out. There is a problem with rc.sysinit (after booting some files like /dev/null are not accessible).
miko
I'll try to find a bit of time to investigate.
larch: http://larch.berlios.de
Offline
miko wrote:OTOH, larch 5.3.8 stopped to work for me since initscripts-2008.09-2 is out. There is a problem with rc.sysinit (after booting some files like /dev/null are not accessible).
miko
I'll try to find a bit of time to investigate.
Well, I didn't get your problem exactly, but because of a (reported) Arch bug, there was a problem with /dev/null when using mklarch and when booting the result some change or other has resulted in /dev/loop0 getting created a bit slowly. These problems should be fixed in larch-5.3.9 and larch-live-5.3.4 (now available).
larch: http://larch.berlios.de
Offline
Well, I didn't get your problem exactly, but because of a (reported) Arch bug, there was a problem with /dev/null when using mklarch and when booting the result some change or other has resulted in /dev/loop0 getting created a bit slowly. These problems should be fixed in larch-5.3.9 and larch-live-5.3.4 (now available).
Thanks, that fixed my problem!
Offline
Has anyone tested larch with the 2.6.27 kernel? I got errors about aufs (which is actually installed) and unionfs and squashfs not being found when I tried to larchify my system this morning. Any thoughts?
Offline
Has anyone tested larch with the 2.6.27 kernel? I got errors about aufs (which is actually installed) and unionfs and squashfs not being found when I tried to larchify my system this morning. Any thoughts?
I'll try to have a look in a few days time ...
larch: http://larch.berlios.de
Offline
redline6561 wrote:Has anyone tested larch with the 2.6.27 kernel? I got errors about aufs (which is actually installed) and unionfs and squashfs not being found when I tried to larchify my system this morning. Any thoughts?
I'll try to have a look in a few days time ...
Thanks, gradgrind! Larch really is a wonderful tool.
Offline
Please keep maintaining it. It's a wonderful tool
Offline
I have just built and tested a usb-stick using the mini2 example profile and it worked fine, so if redline6561 or anyone else is having any problems please give me details - but make sure you are using the latest kernel/aufs packages first.
larch: http://larch.berlios.de
Offline
Thanks, gradgrind. I tried larchifying my system last night after updating to the latest kernel and it worked. I hadn't gotten around to posting on here yet. Thanks for your help. :-)
Offline
Has anyone tested larch with the 2.6.27 kernel? I got errors about aufs (which is actually installed) and unionfs and squashfs not being found when I tried to larchify my system this morning. Any thoughts?
I made a DVD ISO live image a few days ago.
No problems.
Offline
Can't boot into the larchified System after kernel upgrade!
It's a current arch32 bit System
LiveCd stops with:
:: Setting up union file system
/init: 191: /bin/mknod: not found
/init: 191: /bin/mknod: not found
/init: 191: /bin/mknod: not found
:: End of live system set-up
Waiting for devices to settle ... done
:: Initramfs Completed - control passing to kinit
Kernel panic - not syncing: Attempted to kill init!
Offline
Can't boot into the larchified System after kernel upgrade!
It's a current arch32 bit SystemLiveCd stops with:
:: Setting up union file system
/init: 191: /bin/mknod: not found
/init: 191: /bin/mknod: not found
/init: 191: /bin/mknod: not found
:: End of live system set-up
Waiting for devices to settle ... done
:: Initramfs Completed - control passing to kinit
Kernel panic - not syncing: Attempted to kill init!
Very strange! My current arch32 system doesn't have a line 191 in the init script (/lib/initcpio/init from mkinitcpio 0.5.19-1). Is your system really up to date? Could you investigate a bit further?
larch: http://larch.berlios.de
Offline
Hello,
gradgrind
I have some questions regarding your scripts and modifing them
I:
Question: Am i dealing at the following point with busybox?
Forget about the part between ????????????????? and ????????????????????
i just wanted to post it for showing my stupidity and path of thoughts( or
thoughtpath?). You can fly over it.
larch1 script:
????????????????????
test_live_data_dir ()
{
/bin/mount -r -t iso9660 "$1" $2 >/dev/null 2>/dev/null || \
/bin/mount -r -t vfat -o noatime,nodiratime "$1" $2 >/dev/null 2>/dev/null || \
/bin/mount -r -t ext2 -o noatime,nodiratime "$1" $2 >/dev/null 2>/dev/null
if [ $? -eq 0 ]; then
if [ -f "$2/larch/larchboot" ]; then
LDEV="$1"
msg_ " ... found at $1"
return 0
else
/bin/umount $2 2>/dev/null
msg_ " ... $1 mounted, but no 'larch/larchboot' found"
fi
else
msg_ " ... not $1"
fi
return 1
}
modified:
test_live_data_dir ()
{
/bin/mount -r -t nfs 192.168.0.2:/mnt/export_larch "$1" $2 >/dev/null 2>/dev/null
if [ $? -eq 0 ]; then
if [ -f "$2/larch/larchboot" ]; then
LDEV="$1"
msg_ " ... found at $1"
return 0
else
/bin/umount $2 2>/dev/null
msg_ " ... $1 mounted, but no 'larch/larchboot' found"
fi
else
msg_ " ... not $1"
fi
return 1
}
I don`t know the "$1" parameter, but i would like to know if mount is
capable like in busybox to mount nfs at this moment in the script.
Maybe the "$1" is boot parameter root=/dev/xxx by grub?
I am trying to learn something here, but i don`t quite understand.
Is "$1" become "LDEV" become "$root". I think i am wrong.
????????????????????????????
Mmmm... now I think something else.
test_live_data_dir () #does implement the different type parameters iso, vfat and ext2.
It fakes the mount with the -f parameter and outputs if one
the tries define the filesystem mount is successfull.
# then try cdroms #here the real probing of devices are defined. Get info about the
cdrom(s) of the system and then do test_live_data_dir ()
# # test USB devices (and disks) repeatedly until timed out #same here
Mmmm i hope i am on the right way.
When i think about it, i don`t really need the probing for devices
if i have a static nfs server where i wanted to boot from.
So what does this leaves of the script:
run_hook ()
{
msg_ ":: Creating writeable filesystem (tmpfs)"
/bin/mkdir "/tfs"
/bin/mount -t tmpfs -o "size=60%" tmpfs "/tfs"
# Directory for test mounts (and then for live CD)
cdmount="/livecd"
/bin/mkdir "${cdmount}"
/sbin/modprobe loop
/bin/mount -r -t nfs 192.168.0.22:/mnt/export_livelarch "${cdmount}" >/dev/null 2>/dev/null
}
What do you think about it?
Ha Ha Ha , this is probably also garbage, but i will need this step to do
something else. If this works in theory i will try to use uuid to bind
the larch system to a usbstick.
The nfs stuff is only for learning and maybe i will try to do a diskless
tftp boot with larch, but i will have to learn how to setup a nfs server
and a diskless install first. So this only for theory and is far away.
So merged questions are:
1. Am i at this point in busybox?
2. Does this script will work in theory or is dead at the beginning?
II.
Kernel update:
I don`t think that you haven`t thought about something like the following,
but i will describe what i will do in the next days, if i have enough time.
The reason why i tell you, is that i would like to know if you have tried
something like that and if this is a deathbirth (todgeburt).
I will create a live system and boot from it.
Do a pacman -S kernel-26
Then execute: /sbin/mkinitcpio -c /lib/initcpio/mkinitcpio.conf -k $1 -g larch.img
For $1 the actual and updated kernel
Or maybe modify mkinitcpio.conf with
HOOKS="base udev pata scsi sata usb larch1 larch2___aufs___ larch3"
This should create hopefully the kernel and larch.img in boot.
Mount the booting partition at a created path.
I think aufs don`t like it and mount will complain that it is busy.
Maybe i will force the mount. I don`t the consequence of it, but
i will see.
Copy the new kernel and larch.img to the boot of the mounted booting
device.
Umount it and reboot.
Some question here:
Is the /lib also saved at the shutdown?
Did i forget something?
-----------------
If the script is okay, i will try to use it with uuid and
after or the other way around, i will try the kernel-update
procedure in the next days and report my results.
As you can see i have to learn many things about scripting.
I like to have something to earn to get better and
your project is of interest of me and you scripts and their
documentations are very nice.
So i hope that i don`t bother you and you can help me a little bit.
Thanks for your answers.
Offline
Hello,
gradgrindI have some questions regarding your scripts and modifing them
I:
...The nfs stuff is only for learning and maybe i will try to do a diskless
tftp boot with larch, but i will have to learn how to setup a nfs server
and a diskless install first. So this only for theory and is far away.So merged questions are:
1. Am i at this point in busybox?
2. Does this script will work in theory or is dead at the beginning?
No, there is no busybox in larch (as it stands), it is just the standard Arch klibc environment. I don't know if you can do nfs mounts, I haven't looked into this, but I expect it's possible somehow. Maybe someone else knows.
II.
Kernel update:
I don`t think that you haven`t thought about something like the following,
but i will describe what i will do in the next days, if i have enough time.
The reason why i tell you, is that i would like to know if you have tried
something like that and if this is a deathbirth (todgeburt).I will create a live system and boot from it.
Do a pacman -S kernel-26
Then execute: /sbin/mkinitcpio -c /lib/initcpio/mkinitcpio.conf -k $1 -g larch.img
For $1 the actual and updated kernel
Or maybe modify mkinitcpio.conf with
HOOKS="base udev pata scsi sata usb larch1 larch2___aufs___ larch3"
Isn't that what's in /lib/initcpio/mkinitcpio.conf anyway?
This should create hopefully the kernel and larch.img in boot.
Mount the booting partition at a created path.
I think aufs don`t like it and mount will complain that it is busy.
Maybe i will force the mount. I don`t the consequence of it, but
i will see.
Copy the new kernel and larch.img to the boot of the mounted booting
device.
Umount it and reboot.
Some question here:
Is the /lib also saved at the shutdown?
Did i forget something?
Yes, I think something like that should work. To write to the medium you can just remount it 'rw'. That's no problem.
If the script is okay, i will try to use it with uuid and
after or the other way around, i will try the kernel-update
procedure in the next days and report my results.
The use of UUID might well be worth investigating - I haven't got around to it yet.
Good luck with your experiments!
(oh, by the way, Todgeburt = stillbirth)
larch: http://larch.berlios.de
Offline
Hello,
gradgrind
Oh i see the last post was 666, so maybe it`s not a good omen. :-)
I`ve got a good and a bad message for you.
First the bad message:
I.
I`ve got the same problem as brickwedde.eu.
Trying to create a usb larch system with larchifying a running system.
:: Setting up union file system
/init: 191: /bin/mknod: not found
Same here. What i examine is, that the command before that referers to
/tfs/bin/
First i thought it could have something to do with an error about a
future dating of the commands before, but this wasn`t the case, as
i explain in the following.
First i update my system and update the larch-script.
Then larchify without a profile. Same error ocurred.
Then larchify with a profile (mini2). Same error.
Then mklarch mini2. Date error, but booted perfectly.
So my question at brickwedde.eu:
Do you use qemu or another vm?
In experienced before, this could be a problem, i have to consider.
Do larchify with or without a profile have any changed result fo you?
At gradgrind: What are the differences with or without a profile
for the init-scripts. I know that, when i larchify a running system
with a password included root, it will behave like the system
running before, but when i include a profile it will "destroy"
my password and will autologin.?
And another question in the nklarch procedure. When i change the
instldir in the mklarch-script, it still behaves like nothing
changed. Is this the suggested default, bacause when i use mklarch and input
the instldir at the command it will consider the new dir? Maybe linux will
cache the script and doesn`t update it, but i don`t think so.
Then the good one:
II.
The kernel update as mentioned above has worked! :-)
update kernel
use larch hooks
remount the usb-medium rw
copy larch.img and vmlinuz
remount ro
reboot
check if the the kernel has a current date.
Yes!
That`s great!
So i am sorry for not testing the uuid, but i will, if i have
some time the following weekend, if the problem of above is fixed for me
and i mean for me, because i think it could be again the vm, but maybe
doing the same procedure with a real system and experience the error
doesn`t occur could explain this behaviour.
We will see.
Thanks for your answers.
Offline
Well, to comfort supersticious people I'd better get over that numeric hurdle!
The profile should make no difference to the init stuff, except possibly if there is a custom mkinitcpio.conf.
I am not really friends with any virtual machines at the moment, but I promise that if I do manage to reproduce the error, I'll have a look at it. Any further information is welcome!
Glad to hear that the kernel update worked.
larch: http://larch.berlios.de
Offline
Hello,
gradgrind
To safe you some time, i`ve tested the procedure with a real
system.
Let`s see.
I`ve copied my vm image to a real usbstick, extendend with a
usb hook.
Booting it.
larchify the system.
installed it to another usbstick(not a real usbstick, but a an old
harddrive (1200Mb connected with an adapter)
same error occured.
What is interesting is, that the mknod or better /bin/mknod error
ocurred again, when i boot the main system to be larchifyed.
So i think that the error could be in the arch system itself.
Because i`d copied the vm the system to a real harddrive the error
could be created in the vm itself and then would be transferred into
the real system. Thats`s one explanation. If this isn`t the case,
the problem is in arch itself.
So clearify the problem, the /bin/mknod occured in the copied system
not in the larch-system, but booted anyway.
You said that the profile process has no influence in the init-scripts.
But the init is overwriting the root-password and autologin, even when
i am larchifying an existing system with a profile (correct me if i am wrong here,
because this statement is only grounded (profounded? i hate altavita translations. Maybe
i should look at my oxford)
in my memory.
The sysinit.rc has to be influenced by larch.
As you mentioned. When i read correctly, you modified the init-scripts.
What it is against (opposite) my thoughts, is that the error occured at creating the
unionfs. I really don`t know. As i mentioned before i am still a user, not
a developer. If you got any suggestions how to examine this error
in a more detailed way, please tell me.
Oh and by the way do you
use larchify by yourself?
use a usbstick as target?
use grub?
I ask this, because the problem
could be in these choices. But i don`t
think so. Everything spoke against it.
Just to clarify some things.
Greetings
and thanks for your answers.
Offline
I'll try to find a bit of time to investigate (no promises as to when, though!).
I don't use GRUB on my larch builds, so I suppose I should test that again.
I nearly always use USB sticks.
I mostly only use larchify on a system that was built with mklarch.
(if the struggle with English gets too much, please mail me in German)
larch: http://larch.berlios.de
Offline
Hello,
gradgrind
To examine this error, i looked for the first time mknod is used.
I searched for "Setting up union file system"
and following use of /bin/mknod
found it in the larch3-hook.
Didn`t think it was in anyway in wrong use or a typing error.
So i thought about and thought about and thought .... .
After that i thought why not try to look at the init-img
itself, after i that i realize that sysinit could not have anything to
do with the error.
So asked how could i mount (in this case the original kernel26.img)
the init-img, to see if /bin/mknod is really in there.
I asked in this topic:
http://bbs.archlinux.org/viewtopic.php? … 52#p447252
How to do that.
gunzip -dc /boot/kernel26.img >/anywhere/kernel26.dec.img
and then
mount -o loop /anywhere/kernel26.dec.img /elsewhere/
but didn`t have any success.
Then mount -t ext2 -o loop /anywhere/kernel26.dec.img /elsewhere/
Same here.
Came to cpio, didn`t archieve decompressing the files.
But i use archive-manager (or better gnome-file-roller)
to look into the decompressed kernel-image.
Now the weird part. I didn`t found /bin/mknod!
That`s really weird, because i thought that udev would need it.
To make things clear, i looked into the default kernel26.img, maybe
larch.img is differrent. But it`s really unexpected for me, that it is missing.
And by the way the first use of /bin/mknod in larch3 is in line 135 not
191 (if this is a line and not an error).
I don`t know, maybe something has changed in arch, but weird enough,
why did it work with mklarch?
Greetings
and thanks for your answers
Ps: Maybe you know better how to mount the kernel26.img, if so
please post, that would benefit my experience.
update now i know thanks bender02 how to extract the files,
but to compress is in the future.
Last edited by paraflu (2008-11-10 16:22:10)
Offline
Indeed accessing cpio archives is a bit of an occult art, for reading them I generally just use mc.
It sounds like there is some problem with building the initcpio, maybe you could investigate that?
Also maybe you could tell me more about what you are trying to do (system you are trying to larchify, etc.). And you are using just 'larchify /'?
(And why is your initcpio called kernel26.img?)
Last edited by gradgrind (2008-11-11 07:56:19)
larch: http://larch.berlios.de
Offline
Hello,
gradgrind
The kernel26.img is the normal kernel26-init-image, which i
examine first, because i didn`t have larch.img accessable at this time.
When i looked into it, i didn`t find /bin/mknod, because i thought
it should be even in the normal kernel, which should in the case of
mknod should not be different to larch.img.
After looking into the mkinitcpio-wiki and looking around in which
package mknod exist, i found it in coreutils (if i remember right.).
In my "normal" system /bin/mknod exist, but not in the kernel26.img.
So the next step was to look into an larch.img of a larchify -gu /.
Didn`t found it there.
As i mentioned it after that i used mklarch -gu mini2 to build a new system.
In this larch.img i found /bin/mknod.
So i thought, because of slighty differences in the mkinitcpio.conf of mini2
(it`s the profile dir), i copy it into /lib/initcpio/ and larchify again.
No sucess.
After looking into mkinitcpio.conf i found the parameter binaries=
, so i thought i include /bin/mknod into it.
larchify -gu /
And "et voila" , /bin/mknod is included!
And the larch-system boots.
So it is a little bit dirty, but it works.
What still bothers me is that mklarch can do, but a installed
system does not.
I will make a new topic, where i will ask if mknod is still included
in the kernel26.img or if my system is not in right condition.
It would helpful if other would examine their kernel26.img in
the existence of mknod.
I still haven`t got any answer for that , but with this little fix
larchify will work for me again.
So let`s see and i will edit this post for the link to the mentioned topic.
Greetings
and thanks for your answers.
Edit:
Here is the link:
http://bbs.archlinux.org/viewtopic.php? … 88#p448788
Last edited by paraflu (2008-11-13 18:45:46)
Offline
Offline
I've put larch-5.3.10 up. It has a couple of minor tweaks, but mainly it has a new script, larch2hdd, which installs the currently running larch system (without any changes during the current session) to a hard disk (etc) partition and installs GRUB to the MBR of that device or the partition. Occasionally someone has asked for this and I eventually got round to doing it. As always, please let me know if there are any problems.
larch: http://larch.berlios.de
Offline
having some problems with mesa and libgl somewhat when i want to build my livecd :
Analyse de l'intégrité des paquets...
(431/431) Analyse des conflits entre fichiers [######################] 100%
Erreur: la préparation de la transaction a échoué
Erreur: la validation de la transaction a échoué (conflit de fichiers)
/home/larchroot/usr/lib/pkgconfig/gl.pc est présent à la fois dans 'libgl' et 'mesa'
Des erreurs se sont produites, aucun paquet n'a été mis à jour.
Offline
That file is (in current repos) only present in libgl - check the versions? Are you trying to use 'testing' - maybe there is some problem there?
larch: http://larch.berlios.de
Offline