frugal install -- menu.lst for old grub version?

[ikke]

I found it!

I did this to reproduce:

Code: Select all

# dd if=/dev/zero of=ext4 bs=1M count=10 2>/dev/null && mkfs.ext4 -F ext4 >/dev/null 2>&1 && file ext4 && tune2fs -O ^has_journal ext4 && file ext4
ext4: Linux rev 1.0 ext4 filesystem data, UUID=e8052e1a-c68a-4e69-a801-2bd113194d68 (extents) (huge files)
tune2fs 1.41.14 (22-Dec-2010)
ext4: Linux rev 1.0 ext2 filesystem data, UUID=e8052e1a-c68a-4e69-a801-2bd113194d68 (extents) (huge files)


So file consider ext4 only if both the feature "extent" AND "has_journal" is present. So an ext4 filesystem without a journal is shown as ext2 with file...and with extents fetaure.

So I will modify the SaLT system to take care of such a case.

Ikke, to verify this, issue the following command as root (in your actual OS) and then try again the LiveCD:

Code: Select all

# tune2fs -j /dev/sdc1

You can add options "-c 0 -i 0 -m 0" if you do not want to have a check on it regularly and if you do not want to reserve some place for user root.
I'm pretty sure the LiveCD will now find your partition and boot it correctly.

JRD, YOU ARE RIGHT! Bravo! Magnifique!! Congratulations! Problem solved!!

Yes, indeed I made the ext4 filesystem this way :

Code: Select all

mke2fs -t ext4 -O ^has_journal /dev/sdc1

Reason : to assure a longer life to the stick and still enjoy the
advantages of ext4.

with

Code: Select all

tune2fs -j /dev/sdc1

you restored the journal and now
everything is OK.

Thank you very much for your efforts. Merci beaucoup!

Can you please send me a patch so that I can remove the journal and still be
able to boot SalixLive?

Wish also to thank Chador. Danke sehr!

[Shador]

So I will modify the SaLT system to take care of such a case.

I don't know what your idea is to solve this. But I'd suggest for ext* we try the best guess of file first and if that fails all other ext* in ascending order. This would be in accordance with the way the linux kernel does it.

BTW, we need to find another refined option to find which version of ext is on a partition as file seems not reliable.

If the Linux kernel with access to anything it wants does it that way, I guess there's no better solution. I can only imagine that we use ext4 drivers for ext* partitions. It's fully backwards-compatible and doesn't implicitly upgrade the fs, right?

Can you please send me a patch so that I can remove the journal and still be able to boot SalixLive?

Let's see what we're gonna do with this issue. Probably we need to declare it a known bug for this release. But I guess we could upload a modified initrd with the fix incorporated that you can put in place yourself.
What's your plan, JRD?

Wish also to thank Chador. Danke sehr!

You're welcome.

[JRD]

Great we've finally found it

I've already commit the patch to svn actually.
Well, I prefer to have a good detection that doing what the kernel do: rely on a fail-retry process by iterating in order with the contents of /etc/filesystems. I think it's ugly and time-consume.

The diff:
http://salix.svn.sourceforge.net/viewvc ... ision=3221
http://salix.svn.sourceforge.net/viewvc ... threv=3221

To patch the initrd, here is the process (sorry it's a bit long):
As root:

Code: Select all

# mkdir loop tmp
# unxz initrd.xz
# mount -o loop initrd loop
# cd tmp
# tar xf ../loop/lib.tar.xz
# patch -p0 -i salt-ext4.patch
# tar caf ../loop/lib.tar.xz .
# cd ..
# umount loop
# rm -rf tmp && rmdir loop
# xz -C crc32 initrd


salt-ext4.patch

[ikke]

Can you please send me a patch so that I can remove the journal and still be able to boot SalixLive?

Let's see what we're gonna do with this issue. Probably we need to declare it a known bug for this release. But I guess we could upload a modified initrd with the fix incorporated that you can put in place yourself.

Would not call this a bug. Maybe I had to inform you earlier that I had formatted the stick with the '^has_journal' option'.

Oh yes, an updated initrd would be most welcome.

Once again : thank you.

Regards,

[burninbush]

My interest in Salix was only for the live media, don't need another standard install of slack 13.37. I saw the structure of the dvd and thought perhaps you intended to support expansion of that system with xz modules, a la Slax/Nimblex/Porteus/others, but in looking at the site I see no evidence for that.

Seems you don't read this forum nor had a serious look at the Salix LiveCDs. One of the reasons I am a rather heavy user of Salix Live is the possibility to adapt it to your needs through modules ('.salt', not '.xz').

Ahhh ... well then, I have obviously missed finding it.

Is there a repo of Salix .salt modules somewhere? I just now looked again and can't see any links.

I do see in the documentation a list of cheatcodes that might have been lifted directly from Slax [5.xx section], but they don't work on this 13.37 live release. If from= and changes= worked I probably wouldn't be here asking dumb questions. I do see an edit stating that persistence is auto enabled; is there a cheat to disable changes when you want to boot without, for example when it is causing a kernel panic?

TIA for any help.

[ikke]

Great we've finally found it

Oh yes. Very great. Magnifique!

To patch the initrd, here is the process (sorry it's a bit long):
As root:

Code: Select all

# mkdir loop tmp
# unxz initrd.xz
# mount -o loop initrd loop
# cd tmp
# tar xf ../loop/lib.tar.xz
# patch -p0 -i salt-ext4.patch
# tar caf ../loop/lib.tar.xz .
# cd ..
# umount loop
# rm -rf tmp && rmdir loop
# xz -C crc32 initrd


salt-ext4.patch

Followed scrupuleusement your instructions. Think there is a small error in your patchfile. Guess that line 316 of 'lib/SaLT' should be 'fi' to close what you have added. Kindly have a look and confirm.

Once more : thank you very much. Without your help ...

Regards,

[JRD]

Oh yes my bad, there should be a "fi" yes....I commit it too quickly

[Shador]

Well, I prefer to have a good detection that doing what the kernel do: rely on a fail-retry process by iterating in order with the contents of /etc/filesystems. I think it's ugly and time-consume.

I agree with you. Still I think they wouldn't have gone that way without good reason, which definitely is not laziness. I'm a bit afraid that there might be other cases where the auto-detection fails and thus the system is not bootable. What about just using -t ext4 i.e. the backwards-compatible ext4 drivers always unconditionally for ext*? There don't seem to be any major downsides as long as ext4 support is available.

[JRD]

Because SaLT is not only for Salix and thus, maybe someone use a kernel where ext4 is not available, to gain space for example.
And the kernel is doing like this to prevent detecting the filesystem I guess. But we use an initrd, so we can use external binaries, like file and the magic number databases.

[ikke]

Oh yes my bad, there should be a "fi" yes....I commit it too quickly

Guess I owe you more than one beer, unless you prefer wine.
Regards.