Light-Debian-Core-Live-CD-Wheezy + Porteus-Wheezy

[sunburnt]

New drive-info shows raw device because, what if the drive is not parted and formatted.?
Then drive-info would not show anything at all... You have to be able to see the device.

[mcewanw]

New drive-info shows raw device because, what if the drive is not parted and formatted.?
Then drive-info would not show anything at all... You have to be able to see the device.

Actually, that probably explains (?) what happened at one stage when I was testing debiandog-install - I thought I had somehome damaged my usb flash stick because it wasn't showing up at all (having deleted all partitions with gparted). It was fine after I partitioned and formatted the stick thereafter.

[saintless]

I don't see why automating copying of 01-filesystem.squashfs would make the iso size almost double. At least, I imagine you could auto-move that file to become live/debian/base/01-filesystem.xzm during debiandog-install process in case of filesystem FAT. Maybe that's what you mean.

Yes, William, but it will be like the iso is double sized when you use debdog-install on vfat usb stick. It will copy the main module in /live/debian/base and copy to RAM option will use two times more RAM.
This why we need a message box what will happen with option to confirm or not install on vfat.

Auto-moving the main module in case of vfat partitioned usd is not an option. It will make debian boot unusable.
On ext partition it is possible to have both boot options with symlink which does not work on vfat unfortunately.
The point is to give the user both boot options to be tested. After that one of the modules and initrd files can be removed to save space.

I know you and Fred prefer porteus boot but I'm sure other people like me will use debian boot as default choice.

Toni

[saintless]

New drive-info shows raw device because, what if the drive is not parted and formatted.?
Then drive-info would not show anything at all... You have to be able to see the device.

Fred, I think Terry has a point here.
Does new drive-info make debdog-install latest version not to work proper? I also think it is good to see unformated drives in debdog-install window but you can tell better if this creates problems or not.

Question to Fred and Terry- can we use for testing debdog-install to install on hard drive partition instead usb stick? I can test this option easy on separate machine with empty hard drive.

Toni

[fredx181]

Hi All

Auto-moving the main module in case of vfat partitioned used is not an option. It will make debian boot unusable.

Yes, I agree, both boot options should be there.
If the user will be warned and have the choice to copy or not, it should be allright then.

If this is really an obstacle, I've thought about a different setup:

- I can change extension to .squashfs instead of .xzm in initrd1.xz
- put 021-apps-porteus.squashfs in live/debian/modules folder.
- put 01-filesystem.squashfs in live/debian/base

Didn't test this yet but it should work I think if there is included in boot options for DebianDog-live-boot: "live-media-path=/live/debian/base"
It's easy to do but do we want a change like this.

Fred, I think Terry has a point here.
Does new drive-info make debdog-install latest version not to work proper? I also think it is good to see unformated drives in debdog-install window but you can tell better if this creates problems or not.

Yes, Terry is right, didn't think of it.
If you select a raw drive then message comes "partition mount failed"
And some users may not know what's wrong then.
I'll look into it to change message in that case so use Terry,s new drive-info.

Question to Fred and Terry- can we use for testing debdog-install to install on hard drive partition instead usb stick? I can test this option easy on separate machine with empty hard drive.

Not sure if I understand right.
You can use it on any drive AFAIK but watch out not to wipe windows bootloader (if it's there)

Fred

[saintless]

If this is really an obstacle, I've thought about a different setup:

- I can change extension to .squashfs instead of .xzm in initrd1.xz
- put 021-apps-porteus.squashfs in live/debian/modules folder.
- put 01-filesystem.squashfs in live/debian/base

Didn't test this yet but it should work I think if there is included in boot options for DebianDog-live-boot: "live-media-path=/live/debian/base"
It's easy to do but do we want a change like this.

Hi, Fred.
Not an obstacle since I'm sure the user will chose one of the boot ways and delete the second initrd file.
But from what I tested in the past I think it will not work. The last subfolder for live boot has be named /live so it should be live-media-path=/live/debian/base/live. At least with Grub Legacy the last subfolder has to be named /live.

If it works and you see this easier than editing debdog-install I do not mind. I will rebuild the kernel separate modules for the new live-media-path but I might need some help to edit the existing 3 porteus initrd.xz files for DebianDog.

Edit: I found my post about testing live-media-path. I'm sure it does not work if last subfolder is not named /live with Grub legacy. I guess boot=live kernel paramether is the problem to change last subfolder to different name? I'm not sure boot=live can be changed:

...this is the way to use debian live in different folder (/debian-wheezy for example). Move live folder in /debian-wheezy and use this boot code:

Code: Select all

title Wheezy 1
rootnoverify (hd0,0)
kernel /debian-wheezy/live/vmlinuz1 boot=live config persistence live-media-path=/debian-wheezy/live/ quickreboot noautologin noeject
initrd /debian-wheezy/live/initrd1.img
boot

Toni

[mcewanw]

Fred, Toni: If addressing fat partitions is really going to result in an almost doubling in size of the iso, then why not just make two iso's - one for each method and let the user decide what to download? I don't see the point in doubling the iso when two small iso's would cater for all needs. A small iso is one of the major attractions of Puppy Linux and of DebianDog so far.

[saintless]

Fred, Toni: If addressing fat partitions is really going to result in an almost doubling in size of the iso, then why not just make two iso's - one for each method and let the user decide what to download? I don't see the point in doubling the iso when two small iso's would cater for all needs. A small iso is one of the major attractions of Puppy Linux and of DebianDog so far.

Hi, William.
The iso size will stay the same. Only if using Fat flash drive it will copy the main module two times on the flash drive.

The point to make DebianDog booting both ways was to have separate module with porteus changes and to keep the debian main module untouched while booting both initrd methods.

Making separate iso versions will make PorteusDog 10 Mb smaller and DebianDog 6Mb smaller but keeping separate porteus changes folder is not needed then. They can be added in the main module. It also means PorteusDog is not 100% debian anymore but different version of Porteus-Wheezy. If Fred agree it should go in Porteus-Wheezy folder.

I'm more interested from debian boot method and I seldom use porteus boot. Separating the iso versions will make more difficult to update both versions with the changes and to test if something added breaks porteus or debian boot.

I do not mind separate versions but I think one of the advantages of DebianDog will be the simple switch from debian to porteus included in only one small iso which worth adding the size of one more initd file.
Is it worth to change this just because it is not convenient for Fat flash drive?

Toni

[fredx181]

Hi Toni

Not an obstacle since I'm sure the user will chose one of the boot ways and delete the second initrd file.
But from what I tested in the past I think it will not work. The last subfolder for live boot has be named /live so it should be live-media-path=/live/debian/base/live. At least with Grub Legacy the last subfolder has to be named /live.
If it works and you see this easier than editing debdog-install I do not mind.

It's not about editing debdog-install for me.
It's about trying to get rid of the symlink in case using FAT, so if the user wants to make it work it results in almost double size.

As William suggested two iso's will solve it but here's a different setup I made with a changed initrd1.xz.
The directory setup is also different; in a nutshell:
- The 'debian' folder is changed to 'live' so the subfolders e.g. base, modules are in live folder.
- When using porteus-boot, searching for modules will be in 'live' 'live/base' and 'live/modules'
- extension for porteus-boot modules is .squashfs instead of .xzm

No difference for the live-boot boot options.

For porteus boot there are:
When folder 'live' is on the root of a drive you'd maybe expect the "from=/live/" should work.
It doesn't, it should be "from=/" or completey leave out the 'from' parameter is the same.
Two examples for grub(4dos):
Folder live is at root of drive (no 'from' parameter):

Code: Select all

 title Live-port-dog (sda1/live)
  root (hd0,0)
  kernel /live/vmlinuz1 noauto copy2ram  changes=/live/
  initrd /live/initrd1.xz

Folder 'live' is inside folder 'debdog' (needs 'from' parameter):

Code: Select all

 title Live-port-dog from debdog (sda1/debdog)
  root (hd0,0)
  kernel /debdog/live/vmlinuz1 noauto copy2ram from=/debdog/  changes=/debdog/live/
  initrd /debdog/live/initrd1.xz

It keeps the idea of having two-in-one intact but as I said two separate iso's is also fine by me.

EDIT: Forgot to mention:
Do NOT change the name of the 'live' folder or there's no way to make porteus-boot work

EDIT2: New revision of DebianDog-PorteusDog-new-setup.tar.gz uploaded:
The base_only boot option didn't work previously, now it does.

DebianDog-PorteusDog-new-setup.tar.gz:
https://drive.google.com/file/d/0ByBgCD ... sp=sharing

To edit the other initrd's for other kernels it's just a matter of replacing linuxrc, it's the only file I changed and should work with the others AFAIK.

Fred

[fredx181]

Hi Toni

It also means PorteusDog is not 100% debian anymore but different version of Porteus-Wheezy.

I can't see why it's not 100% debian anymore, what would be the difference then, because of boot-method?
Can you explain?

Fred

[saintless]

Thank you, Fred!
I will test the new setup mode and write back.

I can't see why it's not 100% debian anymore, what would be the difference then, because of boot-method?
Can you explain?

Because it does not use debian initrd file anymore, Fred.
You can't ask in debian forum for help how to make changes=EXIT to work for example. You can't use the documentation about live-boot v2 or v3 codes while using porteus boot method. This is what I mean by not 100% debian anymore.
The mount point with porteus initrd file is different. It is /media in debian and /mnt in porteus. Such small changes might seems not important but they make difference when you ask for help in debian forum.

The same way we can use 01-filesystem.squashfs to boot with some puppy initrd and kernel and it will. Is it still 100% debian?
Or as already tested we can boot any puppy with our separate kernel modules and having /live/cow and /live/image while using puppy. Is it still 100% puppy?

For example the questions Terry asks in debian users forum get the proper answers about the boot process. Nobody asks him why you use live-boot v.2 with Wheezy? He gets answer about DebianDog boot process in debian users forum. It will not happen if he asks for Porteus boot method.

I want DebianDog users to be able to ask questions and get help in debian forums and debian documentation to be valid all the way for DebianDog. We will not be able to answer all the questions all the time in the future in this thread.

Toni

[fredx181]

I want DebianDog users to be able to ask questions and get help in debian forums and debian documentation to be valid all the way for DebianDog. We will not be able to answer all the questions all the time in the future in this thread.

Yes I see what you mean now, Thanks!

Fred

[saintless]

DebianDog-PorteusDog-new-setup.tar.gz:
https://drive.google.com/file/d/0ByBgCD ... sp=sharing

To edit the other initrd's for other kernels it's just a matter of replacing linuxrc, it's the only file I changed and should work with the others AFAIK.

Thank you, Fred! looks great to me this way
I will change the iso structure to this one and rebuild the other porteus initrd files with changed linuxrc file.
We keep one iso with both boot methods.

Toni

[fredx181]

Hi Toni
That's nice, FAT issue solved!

But the PorteusDog users cannot ask anything in the Porteus forum anymore now
Well, no, before they also couldn't anyway.

There's one small downside, I've done an Edit in my post about it also:
Do NOT change the name of the 'live' folder or there's no way to make porteus-boot work, it depends on the name 'live' now.
It's the same as previously the name 'debian' could not be changed.

Btw, what you said about 'live-media-path=' option that it needs to be 'live' is not true.
I've many times used it without 'live' folder, no problems.
To take your example:

Code: Select all

title Wheezy 1
rootnoverify (hd0,0)
kernel /debian-wheezy/live/vmlinuz1 boot=live config persistence live-media-path=/debian-wheezy/live/ quickreboot noautologin noeject
initrd /debian-wheezy/live/initrd1.img
boot

If you would move everything that's inside /debian-wheezy/live/ to /debian-wheezy and then:

Code: Select all

title Wheezy 1
rootnoverify (hd0,0)
kernel /debian-wheezy/vmlinuz1 boot=live config persistence live-media-path=/debian-wheezy/ quickreboot noautologin noeject
initrd /debian-wheezy/initrd1.img

It should work.

Fred

[saintless]

Hi, Fred.

Code: Select all

title Wheezy 1
rootnoverify (hd0,0)
kernel /debian-wheezy/vmlinuz1 boot=live config persistence live-media-path=/debian-wheezy/ quickreboot noautologin noeject
initrd /debian-wheezy/initrd1.img

It should work.

Just tested the same code and I can't make it boot. I get file not found boot message. The strange thing is I can't make it boot now even with live-media-path=/debian-wheezy/live/ and I'm sure I have it working this way before.

I will try in the next days with different Grub installed from puppy and grub4dos from debdog-install on the usb.
I use Grub legacy from old version of GeexBox live cd for HDD install at the moment.

Do NOT change the name of the 'live' folder or there's no way to make porteus-boot work, it depends on the name 'live' now.
It's the same as previously the name 'debian' could not be changed.

Thanks, I will add this information on the site. The boot structure will by easy to change back by downloading the previous initrd.xz files from the site. I will keep them for separate download.

Toni

[fredx181]

Hi Toni

Just tested the same code and I can't make it boot

Just in case you didn't see: that code has 'persistence' as boot parameter which is, as you know, for live-boot v3.

Fred

[saintless]

No, persistence or persistent does not make boot problems for any version of live-boot. I mixed them more than once while testing the first base for Light-Wheezy. Just the save file will not be loaded if the wrong one is used.
The problem is somewhere else.

Toni

[mcewanw]

Hi, William.
The iso size will stay the same. Only if using Fat flash drive it will copy the main module two times on the flash drive.

Ah, okay, I misunderstood. I'm relieved it is that way. It is good to have both options in the one iso, when there is no huge size penalty, of course.

[mcewanw]

Just tested the same code and I can't make it boot. I get file not found boot message. The strange thing is I can't make it boot now even with live-media-path=/debian-wheezy/live/ and I'm sure I have it working this way before.

Hi Toni, maybe nothing to do with it, but good if you could test on newer machine than your old 128MB grunter. I do most of my testing on my own old machine here, which doesn't boot from usb. However, my installations are all on usb flash because the hard disk is failing on this machine. I manage that because I have grub4dos/menu.list/grldr on hard drive and the menu.lst instructed to find kernel etc on the usb flash (doesn't need a bootable flash of course). However, I do have weird issues 'sometimes' and very unpredicatable where I sometimes on the same usb flash get 'file not found boot message'. Usually after deleting and installing some new stuff. The other thing is I currently can boot debiandog from current usb but no longer Puppy guydog (file not found boot message for that one). I have come to the conclusion that my old machine has these BIOS/ATA limitations (no of heads, cylinders, usb size etc) such that BIOS can sometimes luckily find vmlinuz etc if it happens to be on earlier enough cylinder and low down in the GB. Once vmlinuz etc is booting it takes over from the BIOS so the rest of the system works fine thereafter - that's my intuitive suspicion anyway (I've been messing around with fdisk expert mode to try and prove it one way or the other, but nothing conclusive so far...). There are certainly many limits that could come into play - these old machines are not expecting large hard drives and usb flash view of the chs situation probably even worse for them:

http://www.tldp.org/HOWTO/Large-Disk-HOWTO-4.html

Certainly, in the past, when larger hard discs started coming out, it was important to create a small partition for the bootup files alone (vmlinux etc, which was in /boot usually, so /boot mounted to own small partition back then), in low down cylinders etc - otherwise bios couldn't find vmlinuz.

If I'm right, that would explain much mysterious behaviour when sometimes the same thing seems to work and other times it doesn't. Nothing to do with filesystem formats, in such cases, though might depend sometimes on the boot loader programs (grub/syslinux/wee etc) capabilities also.

I have one 4GB usb flash stick that always refused to boot from my grub4dos setup, but last night after mucking around with fdisk expert mode changing amount of cylinders seen etc, I somehow had debiandog booting from it in a 1 GB ext4 partition. Unfortunately, I wiped it without noting down what I did and I'm been starting from scratch trying to repeat that success ever since! In attempts since I just get the file not found boot message, and in some attempts the machine actually freezes on boot attempt needing a power off before trying again. However I do have debiandog booting from a different flash stick of even greater size (8GB) on this machine (via hard disk grub4dos arrangement). On that one I have an empty first 1GB fat32 partition, followed by a 6GB ext4 partition with debiandog on it and also Puppy guydog (which as I say won't boot, yet debiandog does... all very weird - the same usb flash drives all boot fine on my other newer machine)

Having said all of the above, to be honest, I have no idea what the issue is - maybe nothing to do with BIOS at all, though why I got that 4GB card working only once and why debiandog visible and guydog not on same partition is a real mystery...

[saintless]

Hi, William.

Hi Toni, maybe nothing to do with it, but good if you could test on newer machine than your old 128MB grunter.

Thanks, I also suspect this could be the cause of my troubles or the version of Grub I have. I will use grub4dos test on another computer today. I need to be sure it is not a problem caused from the remount /live/image line and one squeeze path_id file added in initrd.img

Thanks to Fred we will not use symlink in the iso and vfat partition issue is solved.

Toni